Mango Markets and the Benefits and Limitations of Oracles

Oracles are tools that stream information about some on- or off-chain event onto the blockchain. This can be anything, from price to volume to the weather, though in this article we will be discussing price oracles. In DeFi, price oracles are used to publish cryptocurrency price data on-chain, which are crucial data inputs for smart contracts. The crudest data sourced through a price oracle would comprise a single traded instrument with no outlier management. At its most robust, a variety of data providers (of which Kaiko is one) take inputs from a variety of exchanges, apply outlier detection, and provide the aggregate to an oracle like Chainlink or Pyth, which then broadcast an aggregated price based on the values they receive from a number of data providers.

Price and Oracle Manipulation

Price manipulation exploits are some of the earliest and most common exploits in DeFi. In the summer of 2020, as DeFi was taking off and before oracles were widely used, there was a constant parade of protocols being drained of funds as attackers would pump the price of an illiquid token (often the protocol’s native or governance token), inflate the value of their own position, and use this inflated value to pull out more “valuable” tokens like ETH or USDC. In the early days, protocols would often use a direct price feed from a single DEX, making price manipulation relatively easy. When protocols would tweet a post-mortem analysis of an exploit, their replies would be filled with some variation of “Chainlink fixes this,” and, oftentimes, they were right.

Oracles provide a layer of protection against these kinds of attacks, though they do not make them impossible. See for example what happened on the lending and borrowing protocol Inverse Finance, which got hit twice this year, first by a relatively simple manipulation of INV-ETH on Sushiswap.

All it took was an abnormally large swap of ETH for INV to manipulate the price, which Inverse Finance’s oracle picked up, allowing the attacker to drain funds. On Sushiswap, the price hit a high of nearly $4,000 USD; on Uniswap V2, over $15k; on Coinbase it reached a high of $490. Unfortunately, Inverse was using a Keep3r oracle which relied entirely upon DEX price data (in his blog post announcing the creation of these oracles, creator Andre Cronje acknowledges they do not provide optimum security). More robust oracles likely would have limited the impact of clearly erroneous values from DEXs and relied more on Coinbase and other CEXs during the price movements.

However, there is no blame to be placed on the oracle here. Oracles are simply tools that provide data to a protocol. In this case, the oracle functioned exactly as designed: it tracked the price of INV on DEXs with a short TWAP (set by the protocol) and no outlier detection. Provided that there is sufficient transparency from the oracle provider, it is the responsibility of DeFi protocols to understand how the oracle they are using operates and how the price feeds that are used as inputs could be manipulated. For illiquid and/or small market cap tokens that are offered on few or no centralized exchanges, price manipulation and thus oracle manipulation is relatively easy; protocols should recognize this and take steps to mitigate its effects.

Limitations of Oracles

Oracles are not a panacea and have two main limitations:

• They cannot implement risk management to limit the effects of market manipulation measures for a protocol
• The outputs are only as good as the inputs

Point one is tongue-in-cheek but more relevant than ever; the explosion of decentralized perpetual futures exchanges — brought about by cheaper transactions on L1s like Avalanche and Solana and Ethereum Layer 2s like Arbitrum — has put the importance of anti-market abuse measures (like position limits) in the spotlight. For example, about a month ago, a trader took advantage of GMX’s oracle pricing — which allows users to open large positions at the oracle price with no slippage — and thin AVAX order books to profit from unnatural price movements (detailed in my tweet thread here).

Point two was demonstrated by the recent exploit (or, depending on your opinion, “highly profitable trading strategy”) on Mango Markets. Put simply (and more closely detailed in this Twitter thread), the attacker (or trader) opened a long MNGO perpetual futures position, pumped the oracle price upon which MNGO-PERP was based, and used the unrealized and short-lived “profit” of over $400mn to borrow from Mango, draining it of all funds — over $100mn worth.

What’s the takeaway from this timeline? For me, it’s that this whole process was relatively easy. For whatever reason, MGNO is offered on very few CEXs (not even Binance or Kucoin!), with FTX, AscendEX, and BingX as the only exchanges with any meaningful volumes. The FTX order book was incredibly thin ahead of the exploit.

Total market depth 1% away from the midpoint in each direction was just over $20k in the hours leading up to the price movement. At 10:45pm UTC, ask depth (in red) was $957 and bid depth (in green) was just $743.

The Pyth MNGO-USD oracle reflected a high price of $0.155. When examining each publisher (i.e. the data provider that contributes a price to the oracle) it’s interesting to see how their collection and outlier detection methods differed: one publisher hit a high of $0.829 while another hit a high of just $0.07.

The Switchboard oracle that Mango used incorporated data from FTX, AscendEX, and the the MNGO-USDC DEX pair mentioned above.

The oracle functioned as designed, which the Mango team acknowledged, saying that the oracle providers were not at fault. The token was simply too illiquid, and the oracle’s outputs were only as good as its inputs.

What Next?

Hopefully DeFi protocols have realized that simply using a Chainlink or Pyth price oracle does not absolve them of risk management. As mentioned previously, decentralized futures exchanges are prime targets for these sorts of attacks, as they are essentially leveraged versions of the lending/borrowing protocols that are usually the marks for these exploits.

As detailed by FTX CEO Sam Bankman-Fried, FTX’s risk engine uses its own form of outlier detection and charges a greater percentage margin for larger positions (the MNGO position taken on Mango Markets would have had to be fully collateralized on FTX), among other checks. Others have suggested that position limits could be established based on an oracle-provided measure of liquidity like bid-ask spread. This could add a level of difficulty to an attack, but it’s my hunch that a sophisticated and well-capitalized attacker would be able to spoof liquidity, especially if a token is only offered on a few exchanges.

For what it’s worth, one of the attackers involved in the Mango exploit tweeted that lending protocols should store a 24-hour rolling oracle price and require new positions to be valid under both the current oracle price and the rolling price. This actually seems like a pretty good solution.

As the bear market drags on I expect to see more and better-capitalized exploit attempts in this vein. The same attacker mentioned above detailed a theoretical exploit of Aave V2 using $100mn in starting capital to pump REN and potentially drain $500mn from the protocol.

A combination of solutions — using oracles, limiting (or not offering) leverage on illiquid tokens, using a longer rolling price for opening new positions, and more — will be critical to prevent these types of exploits in the future.