Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
We have seen some recent abuse of price feeds on illiquid synths (in particular sMKR and iMKR). In this writeup, I want to propose a few ideas to mitigate these attacks and future (potentially more dangerous versions). See this reddit thread for some more context on the current attacks.
1. Disabling sMKR and iMKR
This is a good start to stop the current ongoing attack. See my proposed SIP 34 for more details.
I also think we should have a discussion on liquidity requirements for other current synths and what we will require for future synths. But that is lower priority than fixing the immediate attack vector.
2. Upper limits on any synth with dangerously low liquidity
A more dangerous version of this attack would happen if an even lower liquidity underlying had its orderbooks completely cleared. Such oracle attacks have happened in the past in crypto and if successful could completely destroy the project. It is therefore of crucial importance that any such attacks be mitigated. For example, suppose that an attacker was able to clear the orderbooks of a particular asset and set the price to 100BTC while holding a large number of synths. They would then be able to quickly exit via the uniswap pool. It's unclear whether such an attack would currently be profitable -- but it is nevertheless extremely dangerous.
I therefore believe that at a minimum, any synth that has some illiquidity dangers (definitely sDEFI, possibly sMKR (if not removed), sCEX, sTRX, sXTZ) needs to have an upper limit (similar to the lower limit of the inverse synths). This will put a cap on profit of this attack, almost certainly making it infeasible. It also turns it into more of a moderate severity rather than a project killing black swan.
It surely is some inconvenience for traders who may find their positions hitting the upper limit and getting closed. But given the risks involved, I think we need such a limit regardless.
3. Upper limit on minting
The SNX token itself also has a serious liquidity problem that I believe presents some danger. We do have some ideas to incentivize liquidity. However, in the meantime, it also seems somewhat vulnerable to an orderbook clearing attack. An attacker that can set the price of SNX arbitrarily can potentially mint an arbitrary amount of synths and then exit through the uniswap pool. Again, it's not clear whether such an attack would currently be profitable, but it is another existential black swan risk for the project.
Furthermore, even in the case of extremely high volatility without manipulation, it could still pose a risk. Without liquidation/direct redemption, there are incentive problems for minters if their c-ratio gets near or below 100%, as they may prefer to just "walk" away and default on their debt rather than pay back more debt than their SNX is worth. So volatility that results in 90%+ drawdowns in the span of 1-2 weeks (a single fee period) could cause severe issues by itself.
In order to mitigate this, I suggest that we implement a new oracle system for the purposes of determining c-ratio. For example, one choice could be min(current SNX price, 2*(7 day lagged SNX price). This would make oracle attacks/orderbook clearing attacks impractical while also reducing the likelihood of severe volatility resulting in incentive issues.
All thoughts welcome. Suggestion 1 should in my opinion be a high priority, the other two may not be as high of a priority (but I still advise addressing those attacks as a successful attack could completely wipe out minters).