SIP-92: Historical iSynths Pricing Tracks When Last Frozen

Author	Justin J Moses
Status	Implemented
Type	Governance
Network	Ethereum
Implementor	TBD
Release	TBD
Created	2020-11-09

Simple Summary

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

Abstract

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.

Motivation

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.

Specification

Overview

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.

Rationale

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()