Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mitigating price feed manipulation #72

Spreek opened this issue Dec 25, 2019 · 0 comments

Mitigating price feed manipulation #72

Spreek opened this issue Dec 25, 2019 · 0 comments


Copy link

@Spreek Spreek commented Dec 25, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.