What Is Oracle Manipulation? A Comprehensive Guide

Oracle manipulation refers to exploiting defects in a blockchain oracle and causing it to report inaccurate or stale information about off-chain events. Oracle manipulation is often part of a broader attack on a protocol. By corrupting oracles, malicious actors can cause a protocol’s smart contracts to execute based on erroneous inputs—in a way that benefits them.

Oracles have become a favorite target for hackers, especially as more Web3 projects seek to build “hybrid applications” that combine on-chain execution with data from the real world. A synthetic assets market that allows users to gain exposure to assets like gold, oil, or fiat currencies (without holding those assets) is an example of a hybrid application. 

A protocol such as that described above will require information about the latest prices of listed assets to settle financial contracts on-chain. But this is difficult since blockchains are isolated from the real world (a requisite for reaching consensus in deterministic fashion). 

This is where oracles—capable of sourcing off-chain data and publishing it on-chain—come into the picture. An oracle is itself a smart contract that accepts, verifies, and stores data submitted by some entity. This way, other on-chain contracts can query the contract for data while executing business logic. 

As explained by Eskandari et al, most oracles share a similar high-level architecture that includes the following components:

1. Ground truth: The information required by an on-chain contract for execution. An example could be the price of the US Dollar or Ether (ETH), the result of an election, or weather information. 

2. Data source: The source of information that an on-chain contract needs. For example, a centralized exchange (CEX) or decentralized exchange (DEX) can provide information about the latest price of a token. 

3. Data feeders: The entity responsible for extracting requested off-chain data (ground truth) from various sources and “feeding” it to the oracle contract. 

3. Selection of data feeders: Oracle services need to select those who can complete data requests. The selection process may be permissionless (allowing anyone to submit oracle data) or permissioned (allowing only approved entities to submit oracle data).  

4. Data aggregation: Decentralized oracle networks that rely on multiple data feeders need a way to aggregate various data points into a single output. This could be executed using statistical methods (like calculating the average or median of a dataset) or a consensus mechanism where oracle nodes agree on which data to submit. 

5. Dispute phase: To incentivize honest reporting, oracles often allow participants to dispute data provided by other nodes. Malicious attempts to challenge a valid submission or submit invalid data can be punished using some form of reputation/staking system. 

Oracle manipulation attacks leverage weaknesses in one or more components of an oracle’s architecture. The goal of an oracle manipulation attack is usually to force the oracle into misreporting information and trigger invalid execution in a smart contract that uses data from the compromised oracle. 

Since the data source determines the quality of information reported by an oracle, attackers often target it as part of oracle manipulation attacks. Spot price manipulation is a classic example of this kind of attack. 

Here is an example:

1. An overcollateralized lending protocol uses the spot price of an asset—taken from a decentralized exchange like Uniswap—to calculate the value of a user’s collateral. This helps determine how much the user can borrow or when the debt position is nearing an undercollateralized status. 

2. Using flash loans, an attacker can create artificial demand for a token and inflate its price on a specific market. This in turn leads the DEX—acting as a price oracle—to report abnormally high prices for the asset, which causes the lending protocol to incorrectly value user-provided collateral and issue “bad loans”. 

While manipulating spot prices on a DEX is more common, this attack could occur in many other places such as centralized exchanges (CEX). Other sources of data can also be corrupted to achieve similar purposes—for example, hacking an API service that provides asset price information and changing reported values. 

A centralized oracle service can be corrupted if the oracle node decides to submit incorrect information or deliberately refuses to update the oracle contract with the latest information. Even if the oracle operator is honest, attackers can cause damage by compromising the oracle node’s infrastructure and hijacking the system. Such oracles are said to suffer from a “single point of failure” as any issue affecting the sole oracle node will inevitably affect the oracle’s reliability and security. 

Decentralized oracles distribute the task of sourcing and reporting off-chain data among a network of nodes, increasing fault tolerance and resistance to manipulation and censorship. If, however, the selection process is flawed—for example, if it lacks strong cryptoeconomic incentives—attackers can execute oracle attacks. 

A plausible scenario is one where an attacker bribes a fraction of oracle nodes to collude in reporting false information. Alternatively, the malicious actor could ask data feeders to collectively halt updates to the oracle contract’s data. In the latter case, the reliant smart contract may execute on out-of-date information or stop functioning at all—both of which have negative downstream consequences. 

Decentralized oracles receive data from multiple reporters, but the client smart contract needs a single value. Thus oracles need a mechanism to aggregate data before submitting it to the oracle contract. Should this component of the oracle’s architecture suffer design flaws, an attack manipulating values reported by the oracle is feasible. 

To illustrate, consider an off-chain oracle that naively calculates the mean or median value of a dataset to get the price of an asset. In the former case, a malicious oracle node can report an abnormally low or high value to significantly skew the dataset. Something similar can happen if an attacker manages to insert an incorrect value between two valid values such that the oracle takes the attacker-provided value as the median. 

On-chain oracles (pioneered by Uniswap) use the time-weighted average price (TWAP) mechanism to calculate the value of a given asset. While TWAP oracles make short-term manipulation attacks costly, this doesn’t always work out. In particular, the cost of manipulating a TWAP oracle to report a false value can be low in the case of low-liquidity assets. 

Oracle manipulation is problematic for lending protocols as it can lead to widespread insolvency. For example, an oracle exploit can result in the protocol creating bad debt positions where the collateral’s value is lower than the user’s debt. This would force liquidity providers to eat losses since debtors have little incentive to pay back debt. 

DeFi money markets avoid insolvency by tracking the market price of collateral assets and liquidating debt positions before they become undercollateralized. But those liquidations may be unwarranted if the protocol performs the calculation using bad oracle data. 

Besides protocol insolvency, oracle exploits can also cause total economic failure in other contexts. A case in point: algorithmic stablecoins and rebase tokens may lose price pegs if oracles misreport price movements. 

Whether you’re building your oracle from scratch or integrating an oracle service, it’s critical to understand the tradeoffs, benefits, and attack vectors inherent in different oracle designs. This will help with making informed decisions about using oracles and guide planning for worst-case scenarios. 

A popular strategy among DeFI projects is to use a dual oracle system that combines an off-chain oracle (eg. Chainlink Price Feeds or UMA’s optimistic oracle) and an on-chain oracle (eg. Uniswap V3 TWAP oracles). This provides a degree of security and fault tolerance since the system can switch to another oracle if using the default option is infeasible (e.g. if the oracle’s data becomes corrupted). 

While using a centralized oracle is nice for efficiency, the downsides (mostly) outweigh the benefits. A decentralized oracle service that utilizes multiple reporters isn’t entirely secure against manipulation, but the costs are usually high enough to deter such attacks. Ideally, you want an oracle with sound cryptoeconomic incentives (like staking on the accuracy of data or assigning reputation scores). 

You shouldn’t always assume that the data provided by a particular oracle is valid—verify incoming data at intervals instead of blindly trusting oracles to function correctly. This could mean, for instance, creating a script that compares the prices provided by an oracle to values from another source (at every few blocks) and checking for large deviations. 

In the absence of a fallback mechanism, you should have measures in place to contain the effects of oracle manipulations. A possibility is pausing a protocol’s smart contracts if the source of oracle data (or the oracle itself) becomes suspect. 

Smart contracts that are dependent upon oracles can be subject to various attacks. If oracles are insecure, exploitation of these vulnerabilities can cause financial losses, degraded user experiences, and other impacts.

Before launching a smart contract that connects to oracles, it’s important to undergo a full security audit of the oracle’s business logic and implementation. Reach out to us at Halborn to find out how we can protect your project from an oracle manipulation attack.