What Is a Blockchain Oracle? How They Work and Why They Fail

In DeFi, oracles play an important role as they help to connect external data with blockchain. Thus, they significantly expand the usage of smart contracts making it possible for them to operate with the information from the real world.

Yet, oracles are not perfect and the technology does not always work as it should. Oracles may fall victim to manipulations or rely on incorrect data reporting and thus fail their users.

What kind of failures oracles may experience and what can be done to prevent this? Read on to find out.

What is a Blockchain Oracle?

As mentioned above, an oracle is an entity that connects the blockchain with external systems. Thus, it feeds the blockchain with real-world data and enables smart contracts to execute in accordance with this information.

In their essence, blockchain oracles fall into two broad categories:

• Centralized oracles. With such oracles, there is usually a single entity that stores the data and sends it to the blockchain by request. Such oracles are prone to failures as they rely on a single source of truth that can be altered or compromised.
• Decentralized oracles. These oracles are managed by multiple node operators who combine multiple sources of data. Thus, they collectively provide accurate and reliable data to the blockchain.

As you may guess, there are many ways for things to go wrong when centralized oracles are involved. Therefore, the trustworthiness of such oracles is disputable. 

Oracle Type Comparison: Which Designs Hold Up Under Pressure?

Not all oracles carry the same risk. The table below maps the four main designs against the failure modes that actually matter in production.

👉 Quick takeaway: Centralized oracles are the simplest but carry the highest failure and manipulation risk. Decentralized Oracle Networks provide the strongest resistance for high-value DeFi through quorum-based aggregation. AI-assisted and cross-chain oracles are emerging but not yet mature enough for production high-value applications.

The key architectural difference in a DON is quorum signing. No single node can push a corrupted price. A supermajority of independent validators must agree before data lands on-chain. Slashing penalties give those validators a direct financial reason to report honestly.

How to Choose an Oracle Design

1. Assess value at risk. If your protocol holds more than $1M in user funds, a centralized oracle is not an acceptable baseline.
2. Count independent data sources. Fewer than five independent sources means a coordinated manipulation attack is feasible.
3. Check for slashing. Validators with no skin in the game have no deterrent against lazy or malicious reporting.
4. Verify fallback logic. Ask whether the protocol pauses gracefully or liquidates blindly when the primary feed goes stale.
5. Review the audit trail. Protocols like Lido V3 commission formal oracle security audits. Absence of a public audit is a red flag.

How Do Centralized Oracles Fail?

With the lack of an unbiased source of truth, centralized oracles can easily fall victim to external manipulations. 

For example, oracles may submit an event that has never occurred or neglect to provide the required data to the blockchain at all. Alternatively, they may simultaneously send two conflicting pieces of data to the blockchain and simply break the logic of the smart contract that operates this information.

Having spotted such abnormalities, malicious actors can perform different attacks to steal funds from DeFi services. Let’s investigate some real-world examples of such attacks.

What Happens if Oracles Fail?

There are many cases of oracles failing to provide correct data to those who requested it. We’ve listed some of the most notable events below.

Compound – An exploit of a centralized oracle

In November 2020, a decentralized exchange Compound lost around $89 million after an exploit of an oracle provided by a centralized platform Coinbase.

As a DeFi protocol, Compound enables its users to borrow crypto on a peer-to-peer basis by providing collateral to secure the loan. The value of the collateral must be higher than the borrowed sum to avoid losses due to market volatility. If the value of the collateral drops below a predefined level, the position gets liquidated automatically.

To estimate this value, Compound relied on the data provided by Coinbase Pro. Presumably due to an exploit, the oracle fed the smart contract with an incorrect price of DAI which was $1.3 instead of a normal $1 which resulted in massive liquidations.

Synthetix – Incorrect data from an oracle

In June 2019, another DeFi platform Synthetix almost lost $1 billion as a result of incorrect data that it obtained from an oracle. 

Synthetix operates mostly with non-crypto assets such as fiat-based currencies. To provide its users with the pricing data it relied on a number of centralized off-chain oracles. One of these oracles happened to report incorrect data for the price of the Korean Won making it 1000x higher.

A sophisticated bot trained to spot such abnormalities exploited this discrepancy getting away with a solid sum of money. Luckily for the platform, the creator of this bot later agreed to return the funds.

bZx – Hacker manipulating prices in an oracle

BZx is a cryptocurrency platform where users can borrow and lend crypto in a completely decentralized way. 

In February 2020, it experienced a series of attacks as an unknown hacker discovered a vulnerability in Kyber Network, a single price oracle that the platform relied on.

The attackers managed to manipulate the prices of wBTC and sUSD on Uniswap. Since Kyber relied on the reserves of this platform, the changes in prices on Uniswap inevitably influenced the prices on Kyber as well. 

Eventually, the oracle was misled by incorrect prices which resulted in a loss of around $1 million in crypto.

Mango Markets – An oracle relying on a small number of data sources

The case of an oracle exploit associated with Mango Markets, a Solana-based DeFi platform, is particularly interesting. 

The hacker who manipulated the price of the $MNGO token through an oracle identified himself publicly as Avraham Eisenberg afterward. What’s more, he claimed that the actions he performed were actually legal being nothing else but a “profitable trading strategy”.

Mango Markets used oracles for $MNGO price calculation via moving averages from a few exchanges. 

The security auditing company OtterSec stated on its Twitter that the attacker was able to manipulate the Mango collateral spiking its value and then taking “massive loans” from the platform’s treasury.

Later Eisenberg proposed returning $67 million and keeping the remaining $47 million as a bug bounty. The proposal was supported by the community, but the hacker still faced a lawsuit from the platform and a complaint from the SEC afterward.

Oracle Cascade Triggers $19.3B Market Impact

The incidents above share a common thread: one bad data point, one vulnerable protocol. The 2025 cascade event was different in scale.

A price-feed failure propagated across multiple interconnected DeFi protocols simultaneously. The knock-on liquidations contributed to a market-wide shock that Phemex reported at $19.3B in losses. No single protocol was the culprit. The failure spread because multiple protocols shared the same underlying oracle dependency without independent fallback feeds.

That systemic pattern is what makes modern oracle risk harder to contain than the earlier single-protocol exploits. Orochi Network’s 2025-2026 verification-failure database tallies more than 50 incidents and over $2.5B in direct losses from verification failures, a category that includes oracle manipulation as a primary vector.

The lesson is not that oracles are broken. It is that shared infrastructure failure spreads faster than anyone’s incident-response team can react. Redundancy at the protocol level, not just the oracle level, is now a baseline expectation.

How To Prevent Oracle Failures

Prevention works at three levels: oracle design, protocol architecture, and ongoing monitoring. Liquid Loans addresses the first two directly. The third is an industry-wide responsibility that every protocol using external data feeds should take seriously.

Oracle Design: Decentralization and Dispute Mechanisms

Liquid Loans runs on the Fetch Oracle, a fully decentralized oracle on PulseChain. Reporters are financially incentivized to submit accurate data. Submit bad data and you face penalties. Other network participants can dispute any submission, triggering an off-chain vote before the data is accepted on-chain. That dispute layer is what separates this design from simpler multi-node oracles that aggregate without verification.

Protocol Architecture: Redundancy That Actually Works

A backup oracle is only useful if the protocol knows when to switch. Current best practice from ChainScore Labs and Ethereum.org specifies four components of a genuinely fault-tolerant design

• Quorum signing: A supermajority of independent validators must agree before data is accepted. One compromised node cannot corrupt the output.
• Slashing: Validators lose staked collateral for provably incorrect submissions. Financial skin in the game is the strongest deterrent available.
• Deterministic aggregation: The aggregation method is fixed and verifiable on-chain, removing any discretionary step an attacker could exploit
• Automatic fallback: When the primary feed goes stale or returns an anomalous value, the protocol routes to a secondary source (such as Chainlink) without manual intervention.

Monitoring: Catching Failures Before They Cascade

Even well-designed oracles need active monitoring. Three signals matter most in production.

1. Feed staleness: How long since the last on-chain update? A feed that has not updated in 30 minutes during high volatility is a warning sign.
2. Deviation threshold breaches: A sudden price move of 10% or more in a single update cycle deserves automated scrutiny before liquidations trigger.
3. Node dropout rate: If a significant fraction of DON validators go offline simultaneously, the remaining quorum may not reflect true market consensus.

CVE-2026-8102, disclosed in mid-2026, demonstrated that even established DON implementations carry exploitable attack surfaces. Rapid patch deployment and on-chain governance mechanisms for emergency parameter updates are now considered baseline requirements, not optional extras.

Oracle Failure: What Actually Goes Wrong Step by Step

Most explanations of oracle failure stay abstract. Here is what the failure chain actually looks like when a price feed goes wrong in a lending protocol.

1. The oracle submits a corrupted price. In the Compound incident, DAI was reported at $1.30 instead of $1.00. In the bZx attack, wBTC prices on Uniswap were manipulated before Kyber read them.
2. The smart contract trusts the data and acts on it. Lending protocols calculate collateral ratios automatically. A 30% price inflation on DAI meant borrowers appeared undercollateralized when they were not.
3. Liquidations trigger at scale. Automated liquidation bots execute immediately. By the time a human notices, the damage is done. In the Compound case, $89M in positions were liquidated in a single event.
4. The protocol may freeze. Some designs pause all operations when a feed anomaly is detected. Pausing protects users from further liquidations but also halts all borrowing and redemption activity.
5. Recovery requires governance action. Restoring a corrupted or stale feed, or switching to a backup oracle, typically requires a governance vote or an emergency multisig action. That process takes time. Cross-chain timing issues compound the delay.

The 2025 cascade showed a sixth step that earlier incidents did not: shared oracle dependencies mean one corrupted feed can propagate liquidations across multiple protocols before any single team can respond.