SIP 92: Historical iSynths Pricing Tracks When Last Frozen Source

AuthorJustin J Moses

Simple Summary

Ensure historical pricing in ExchangeRates is aware of when an iSynth was last frozen.


Add historical pricing of when an iSynth was frozen to fix a bug with fee reclamation (SIP-37) that incorrectly applies existing frozen iSynth status to past settlements.


The current implementation of fee reclamation settlement asks the ExchangeRates contract what was the rate of the src and dest synths waitingPeriodSecs seconds after the trade completed. If either synth is an iSynth, then it also checks to see if the iSynth is currenly frozen, and if so, applies those iSynth limits regardless. This is problematic in the cases where an iSynth is frozen (or unfrozen) after the waiting period expires but before a settlement is processed, as fee reclamation incorrectly applies the current frozen bands to a price that may not have required it at the time.



The solution is to track which roundId an iSynth is frozen at and if a price is requested at a roundId at or before then, to only apply the inverse frozen status in those cases. Then, when unfrozen, this tracking needs to be removed.


This is the simplest solution that has the least impact to gas usage and the current system. There is slightly more gas required looking up any frozen roundId with an additional SLOAD, but this impact is minimal.

Technical Specification

Add a new mapping(bytes32 => uint) roundFrozen property to ExchangeRates that is populated during freezeRate() and removed during setInversePricing()

Test Cases

Implementation and tests:

Configurable Values (Via SCCP)


Copyright and related rights waived via CC0.