This is about suggesting ideas to prevent a similar attack from happening.
The problem can be summarised as:
1- An oracle that’s easy to manipulate (MNGO)
2- A perp market with no limit that uses that oracle (MNGO-PERP)
3- Allowing cross-margin and borrowing against perp unrealised PnL.
I think the basic solution is to limit perp global OI based on oracle manipulation difficulty score.
Oracle “difficulty” score should be based on the following factors. These factors should be provided by the oracle as metadata or maybe sourced from another oracle
1 - Number of sources (source_count)
2 - 30D Volume for all source (total_volume)
3 - Price stability (volatility)
Oracle difficulty score = total_volume x 1/volatility x source_count
OI Limit = constant * Average_30days(“Oracle difficulty score”)
This way we have:
- OI Limit correlates directly to the difficulty of manipulating an oracle.
- OI Limit should “lag” behind difficulty score e.g. use the average score over the past 30 days.
- In a normal situation where the market is increasing in liquidity, it would happen over time so the OI limit would naturally grow with it.
- In an abnormal situation where the market suddenly increases in liquidity (because e.g. someone is faking volume) then the OI limit will still stay in place, you need to keep doing it over 30 days and even then the other constant factors (like number of source) cannot be manipulated.
To come up with the constant in the formula above, we can work it out backwards by looking at a “benchmark market” e.g. BTC. We know we want X maximum open interest globally in the exchange and we know what the params are for BTC (volume, sources, volatility). AFAIK that maximum OI is based on the treasury vault, we can assume 100m USDC for example.
Once we fit the formula to the benchmark model, we use it for all markets.
These are some initial ideas. I hope we can come up with something based on this! In either case, I think MangoV4 can now be an even better product by learning from that incident.
Thanks for the suggestions, some kind of oracle-difficulty oracle could indeed help automatically adjust parameters like an OI limit.
Fwiw, one of the mango v4 goals is to be able to safely list even tokens with unreliable pricing. We talked about that briefly in Mango v4: Feature Preview. Overview of new features expected for… | by Brian Smith | Mango Markets | Medium. The two hard restrictions we were planning to use are:
- untrusted token deposits do not count as collateral: you can’t borrow against them
- unrealized perp pnl in untrusted perp markets does not count as collateral
These would have been enough to prevent the exploit.
I’m not yet clear on the specific mechanics of an OI limit and whether it’s helpful to have in addition. It may be nice to have, since it’s adjustable without having to worry about causing liquidations.
Safely changing leverage parameters is something I’m thinking about generally: Maybe the protocol should have a mechanism for gradually scaling them to a new value over several weeks.
Good to see this being discussed.
The exploiter himself recommends a rolling 30 day oracle price here: https://twitter.com/avi_eisen/status/1582368460645945345
"Simple way to make lending protocols more robust:
Store a rolling 24 hour historical oracle price. For liquidations, use the current price, but for opening new positions it has to be valid under both the current and old price."
An interest nuance there is to use current price for liquidations but to open a position it has to be good against the historical price also.
I think it’s a required level of security to have debt limits in addition to OI limits even on the very liquid markets. One way to realize this is to directly limit these values, but I am afraid that this could have unforeseen consequences as it could prevent users from quoting those markets and hence cause issues in the funding rate calculation. FTX margin system instead uses a position dependent initial margin fraction, which has the nice effect that OI is technically uncapped but practically just increased the collateral requirements so high that OI can’t reasonably increase.
Oracle stability is another issue, I have been working with switchboard on a solution for this as well. Happy to give more details, once we are ready to list more illiquid tokens