The Oracle Problem

Source

If you read Molly White's timeline of cryptocurrency catastrophes Web3 is Going Just Great you will notice that many of the more expensive disasters are tagged "oracle manipulation" attacks. Last March, Chainalysis posted Oracle manipulation attacks rising: a unique concern for DeFi in which they wrote:

Overall, we estimate that in 2022, DeFi protocols lost $403.2 million in 41 separate oracle manipulation attacks.

What are oracles and how can manipulating them earn an average of $1.1M/day? Below the fold I attempt an explanation.

What Are Oracles?

Once Ethereum made it possible to store programs on a blockchain and execute them, the question of the sources for these programs' inputs arose. After all, "Garbage in, garbage out" has been a computer science mantra since at least 1957. These programs have access to data on the blockchain, which is assumed to be the ultimate repository of truth, but for all other data they must rely on APIs provided by external services. These services are called "oracles" because, like the ancient Greek oracles, they provide "wise and insightful counsel".

These oracular services are typically, like the Greek ones, opaque and centralized. Their pronouncements have to be taken on trust, violating on of the claimed core principles of cryptocurrencies (albeit one more honored in the breach than the observance). This isn't a bug, it is a feature. In An impossibility theorem on truth-telling in fully decentralized systems, Rodney Garratt and Cyril Monnet of the Bank for International Settlements show that:

We show that truthful reporting about the realization of a publicly observed event cannot be implemented as a unique equilibrium in a completely decentralized environment. Our work provides a theoretical underpinning of the need for oracles and the related “oracle problem".

This is a fundamental problem for the utopian fully decentralized systems.

How Are Oracles Used?

The primary use of oracles is to provide "smart contracts" with price information to drive their trading strategies. In TWAP Oracle Attacks: Easier Done than Said? Torgin Mackinga et al describe this mechanism:

Lending protocols and exchanges enable each other in a bi-directional relationship, with exchanges informing lending protocols about exchange rates and lending protocols providing liquidity to exchanges. The former relationship is often called an oracle, where the exchange acts as an oracle and provides market data to the lending protocol. Lending protocols crucially depend on oracles for their price feeds,

Lending protocols are the heart of Decentralized Finance (DeFi). Mackinga et al explain:

Lending protocols are smart contracts that allow borrowers to borrow funds at an interest rate. The borrowed assets come from a pool of assets that creditors have deposited as their investments. If this pool suffers a loss due to a bad debt, the loss is distributed among these creditors. If the borrower pays back the debt on time, the interest is divided among the creditors who contributed to the pool from which the loan was made from. Due to the inability of these protocols to take action against loan defaulters (borrowers are just public keys on a blockchain), they use over-collateralization to keep the protocols liquid.

How do these lending protocols work? Suppose Alice has some FOO coins each "worth" V_FOO in USDT upon which she wants to earn interest, so she deposits N_FOO into the lending protocol's "smart contract". Now Bob has some BAR coins each "worth" V_BAR in USDT but sees a profit opportunity in FOO that will take time to mature, so cannot be achieved with a flash loan. He deposits M_BAR into the lending protocol's "smart contract" and withdraws N_FOO. The lending protocol sets a collateralization ratio C>1 such that, during the term of the loan:

N_FOO•V_FOO < C•M_BAR•V_BAR

I.e. Bob's BAR collateral is "worth" C times the FOO loan. If, during the loan, Bob is right and FOO appreciates against BAR he will be required to deposit additional BAR to ensure the inequality remains satisfied.

Should Bob fail to do so, a liquidator Charles may step in. Mackinga et al explain:

Before a loan gets fully undercollateralized (C < 1) it can go through a period of “bad health”, where its C has fallen from the time when the loan was made and is now too close to 1 (with some tolerance). To avoid the risk of going fully undercollateralized, the protocol offers liquidators a chance to pay back the loan at a discount, and redeem the remaining collateral for themselves. This makes the protocol whole again, the liquidator gets collateral for a slightly cheaper price, and the borrower is liquidated. The borrower is thus motivated to “top-up” the collateral to make sure that the loan never becomes unhealthy.

In other words, Charles pays a bit less than N_FOO•V_FOO and gets Bob's M_BAR "worth" more.

Note how this protocol depends upon real-time knowledge of V_FOO and V_BAR, the "prices" at which FOO and BAR are trading on exchanges. This information is accessible to "smart contracts" only via oracles. They might, for example, report the Time Weighted Average Price (TWAP) for each coin across a number of exchanges. Mackinga et al describe two kinds of oracle:

These assets are traded on many centralized exchanges which operate in the real world, outside of the blockchain. Through trusted third parties, it is possible to get these exchange rates into the lending protocol. These trusted third parties are also called off-chain oracles. They are dependent on a trusted third party, so they are not fully on-chain. Their operation is not fully governed by a smart contract that can be audited by users and about which users can have assurances of immutability. Lending protocols, which are themselves deployed as auditable smart contracts on-chain, could prefer on-chain oracles, which are deployed as smart contracts, but can still report market-based exchange rates of assets. Automated market makers (AMMs), a type of exchange, serve as a natural on-chain price oracle. They support trades between many pairs of assets and can report the relative exchange rates between asset pairs through state variables available on-chain.

An example AMM is Uniswap V2, which works like this:

Constant Function AMMs are a type of decentralized exchange that uses a well-known, simple formula to trade one asset for another. An AMM trading pair is a liquidity pool containing reserves RA, RB of two different assets A and B. If the AMM is using the constant product model, the reserves have a constant product RA · RB = K. There is a percentage fee (1 − γ) that is collected for every trade. When a user sells b units of B, they get a units of A such that the constant-product function (RB + γ · b)(RA − a) = K is preserved. The spot price of asset A is given by RA/RB, the spot price of asset B is RB/RA.

The spot price on the AMM is maintained by arbitrageurs comparing it with the price on centralized exchanges and other AMMs, buying in the cheaper and selling in the more expensive market. This imports the off-chain price into the blockchain. Note that although the AMM operates on-chain, the prices it reports are not the result of decentralized consensus and depend upon trust in arbitrageurs who in turn depend upon trusting price data feeds from centralized off-chain exchanges. AMMs provide the appearance of trustlessness but not the reality.

How Can Oracles Be Manipulated?

For example, Mackinga et al:

analyze the cost of manipulating on-chain time-weighted average price (TWAP) oracles that use the arithmetic mean.

They show multiple attacks that profit using transactions large relative to the size of the AMM's pools to move the price it reports for the target trading pair. The capital for these transactions is assumed to be available from more liquid off-chain exchanges. Both a single-block attack, and a two-block MEV-style attack via collusion with a miner are possible. These attacks are of two kinds:

• Under-collateralized loan attack. By increasing the price of coin A by buying it using coin B on the AMM the lending protocol uses as an oracle, the attacker is able to borrow from the lending protocol coin B worth more than the coin A collateral, sell it and not repay the loan. The profit is the difference between the value of the borrowed coin B and the sacrificed collateral coin A.
• Liquidation attack. The attacker detects a loan of coin A close to liquidation and decreases the price of its collateral coin B by selling it for coin A on the AMM the lending protocol uses as an oracle, forcing the loan to be liquidated thus obtaining the collateral coin B for less than its market price.

A recent under-collateralized loan attack netted Avraham Eisenberg around $117M. Chainalysis describes the attack:

1. Eisenberg started with $10 million USDC (it’s possible he also used funds not attributable to him on-chain to manipulate asset prices on other exchanges), split across two separate accounts at Mango Markets.
2. Eisenberg used one account to short 488 million MNGO (MNGO, or Mango, is the governance token for Mango Markets) — effectively selling 488 million MNGO on leverage — while the other account took the opposite side of that trade, using leverage to buy the same amount.
3. Eisenberg’s leveraged purchase of MNGO, combined with further buying of MNGO on other DEXes, pushed the price of MNGO up very quickly on spot exchanges. This was possible because MNGO was a low-liquidity asset without much trading volume. The account used to purchase MNGO immediately profited roughly $400 million in paper gains because all of Eisenberg’s buying activity significantly boosted the asset’s price.
4. With such a high portfolio value, Eisenberg was able to borrow against his artificially inflated MNGO holdings and remove virtually all of the assets held by Mango Markets. This activity caused MNGO’s price to drop immediately, so his long positions were liquidated due to loss of collateral value, but it was too late — Eisenberg had already “borrowed” all of Mango Market’s assets with any real value.

Eissenberg pulled off a major heist, but most of the oracle manipulation attacks are far smaller, especially since the smaller and less liquid the coin, the easier it is to mount one.

Can Oracle Manipulation Be Prevented?

Based on Rodney Garratt and Cyril Monnet's An impossibility theorem on truth-telling in fully decentralized systems, Chanelle Duley et al's The oracle problem and the future of DeFi:

examines the “oracle problem” in DeFi and highlights the challenges of resolving it by laying out the trade-off between trust and efficiency in decentralised platforms. When this trade-off is understood, the future of DeFi in its purest sense looks bleak. Progress can be made by departing from decentralisation and by importing trusted actors into the crypto DeFi ecosystem. However, trust is a notion that is explicitly rejected in crypto. In any case, trust is not something that can be easily bolted onto an otherwise trustless system. Trust in finance is foundational ... As a result, the pure form of crypto-based DeFi is likely to remain the preserve of cryptoassets only.

They write:

The obvious solution of increased regulation and supervision runs counter to the decentralisation ethos underpinning crypto DeFi. For this and related reasons, there is little clarity on legal recourse if a smart contract were triggered by false information ..., especially in jurisdictions where crypto activities are not regulated or forbidden.

They pose an "intriguing question":

whether it would be technically feasible to design oracles that could themselves be fully decentralised. If so, this would eliminate the problems introduced with centralised external oracles. Yet implementing fully decentralised oracles that can incorporate real-world information presents severe challenges. Indeed, some argue that such decentralisation is not only practically difficult, but logically impossible, because it faces the inherent challenge of ensuring truthful reporting in the absence of a single authoritative source (Garratt and Monnet (2023)). However, even if decentralising oracles may be logically coherent, there is no doubt that efforts to reduce the need for trust in the reporting of real-world information through consensus mechanisms can be very costly, affecting financial resources, operational efficiency and consumer protection.

The current situation in DeFi is that the rhetoric stresses decentralization and trustlessness, but the reality is that at some levels in the stack centralized systems are trusted. The result is losses from oracle manipulation averaging $1.1M/day, not to mention a plethora of other attacks..