Smart contracts get called trustless a lot, but most of the ones moving real money aren't running on data the chain generated itself. A lending protocol needs to know an asset's price to decide whether to liquidate a position. The blockchain has no native way to determine that price. It can only execute deterministic logic using the data supplied to it. That handoff, getting real-world data onto a deterministic ledger without recreating a single point of failure, is the oracle problem, and it's one of the most consistently exploited weak points in DeFi.
This article compares push-based and pull-based price delivery, examines Chainlink and Pyth’s aggregation models, and explains how on-chain TWAPs work as complementary references.
Push And Pull Oracles Solve Different Problems
How a price actually gets onto the chain shapes a protocol's cost, latency, and failure modes more than almost any other design decision.
Push model (Chainlink Data Feeds) | Pull model (Pyth, Chainlink Data Streams) | |
How it updates | Oracle network proactively writes to an on-chain reference contract | Price is generated off-chain continuously, the calling contract pulls it on demand |
Update trigger | A feed-specific deviation threshold or heartbeat interval, whichever condition is met first. | Sub-second off-chain updates, delivered only when a transaction requests them |
Who pays gas | Oracle operators submit updates, while the funding and economic arrangement depends on the specific feed and network design | The calling application, per transaction |
Best fit | Lending protocols like Aave or Compound that need an always-on reference for liquidations | Perpetual DEXs like GMX or Jupiter where tight spreads depend on near-instant pricing |
Main risk | Idle cost during low demand, and delayed updates during network congestion | Stale data if the application doesn't independently verify freshness before using the price |
Chainlink's own architecture documentation frames the push model's deviation and heartbeat triggers as the two conditions that jointly determine update frequency, whichever threshold is crossed first initiates a new aggregation round. Chainlink's own comparison of the two approaches confirms the core tradeoff is really about who bears the cost and who bears the freshness risk, not which model is objectively better.
Reaching Consensus On A Single Price Is Its Own Hard Problem
A decentralized oracle network only protects a protocol if the aggregation step itself resists manipulation by a minority of dishonest nodes.
Chainlink's Off-Chain Reporting Protocol
Chainlink's Off-Chain Reporting (OCR) protocol lets a network of n nodes aggregate their individual observations off-chain, then submit a single signed transaction on-chain, which is what keeps gas costs manageable across large node sets. Chainlink's own OCR research paper describes the protocol as Byzantine fault-tolerant, able to tolerate up to $f$ dishonest nodes in a network of $n$ nodes, provided $n \ge 3f + 1$ under Chainlink OCR 1.0 specifications. The value ultimately reported is the median of all submitted observations, which guarantees the result remains within the range of honest observations submitted in that round. However, median aggregation alone does not prevent reported values from reflecting correlated data sources, thin exchange liquidity, stale source API data, or market-wide dislocations.
That guarantee is narrower than it sounds. A 2026 NDSS Symposium paper studied exactly how much room Byzantine nodes have to strategically sway the median while staying technically within the honest range. Using Chainlink's real-world ETH price data, the researchers found dishonest nodes could still induce price deviations of up to 8.47 percent, with downstream financial impact on individual incidents in the low hundreds of thousands of dollars, and cumulative impact across many incidents reaching into the millions. The paper's title makes the point directly, validity is not enough, a technically valid median can still be a meaningfully wrong price.
Pyth's First Party Model
Pyth takes a different approach to the same problem, sourcing prices directly from market makers and exchanges like Jump Trading and Jane Street rather than scraping public APIs through a third-party node layer. Publishers submit both a price and a confidence interval, a number reflecting how much liquidity or uncertainty exists around that quote at that specific venue. Pyth's own network documentation describes a stake-weighted median aggregation, where low-stake publishers have minimal influence on the final price, and the algorithm is built so the aggregate price stays close to the market even if a small share of publishers submit prices far off.
Twap As A Slower But Sturdier Backstop
Protocols like Uniswap derive time-weighted average prices (TWAP) directly from on-chain liquidity pool ratios rather than any external feed at all. Averaging price across multiple blocks makes TWAP naturally resistant to single-block flash loan manipulation, but that same averaging makes it a lagging indicator, and sustained, well-capitalized buying pressure across many blocks can still move it, just more slowly and more expensively than a single-block attack.
Three Exploits That Show Where Theory Meets Reality
Almost no real oracle attack is a hack of the oracle's own code. Nearly all of them manipulate the underlying data source the oracle was faithfully reporting on.
Mango Markets, Manipulating A Thin Market
In October 2022, Avraham Eisenberg drained $116 million from the Solana-based Mango Markets using two accounts he controlled. According to the CFTC's complaint, he rapidly bought MNGO across the exchanges Mango's oracle sourced prices from, driving the oracle-reported price up more than thirteen-fold within a thirty-minute window. With his MNGO holdings now valued far above their real market price, he used them as collateral to borrow and withdraw the platform's available assets before the price could correct.
The lesson is blunt, an oracle is only as trustworthy as the liquidity of the market it's reading, and MNGO's average daily volume before the attack was under $100,000, making it trivial to move with a few million dollars of capital. This case is still legally unresolved as of mid-2026, a federal judge vacated Eisenberg's criminal convictions in May 2025 over a venue issue, and he faces retrial, which is a reminder that the technical lesson here is settled even where the legal one isn't.
The Luna Collapse And A Feed That Got Paused Correctly
During the May 2022 Terra/LUNA collapse, Chainlink's own circuit breaker paused the LUNA price feed once it fell below a defined threshold, specifically to stop stale, misleading data from continuing to be delivered as the token's value approached zero. The oracle behaved exactly as designed. The failure was downstream, some protocols that consumed the paused feed didn't handle the paused state correctly in their own contracts, and continued lending against the last reported price rather than treating a paused feed as a signal to halt new activity entirely.
Attackers bought LUNA for fractions of a cent on the open market and deposited it as collateral still valued at the stale price. The real lesson isn't the oracle. It's what a consuming contract does when the oracle stops updating.
Moonwell, A $5.8 Million Price For A Token Worth A Few Thousand Dollars
In November 2025, Chainlink's oracle for wrsETH, a restaked ETH derivative, briefly reported the token's value at roughly $5.8 million against Moonwell's lending markets on Base and Optimism, while ETH, which the asset is designed to track, traded at under $3,500. The attacker exploited this within 30 seconds by depositing 0.02 wrstETH and receiving about $116k in collateral. With this collateral, they were able to take out a flash loan of 20 wstETH. By repeating this process across multiple transactions, the attacker was able to drain a total of 295 ETH. In the end, the attacker netted about $1 million, while leaving the protocol with about $3.7 million in bad debt.
Additionally, the protocol's WELL governance token fell by 13.5% within a single day. Notably, the protocol had followed generally accepted best practice by using Chainlink rather than a thinner third-party source, which is exactly why the case matters. Correct architecture doesn't fully protect against a single bad data point if there's no independent sanity check on the value received. As Halborn's breakdown of the incident puts it, the project relied on a single source of pricing information and had no guardrails to flag an unrealistic price, such as wrstETH being valued far above ETH itself
Controls That Could Have Reduced the Impact
Every case study above traces back to a small set of missing guardrails, not a fundamentally broken architecture.
- Use more than one data source. Compare a decentralized push or pull feed against an independent on-chain TWAP, and treat a large disagreement between the two as a reason to pause, not average out.
- Check for staleness explicitly. Read the feed's updatedAt timestamp on every use, and if it falls outside the expected heartbeat window plus a safety margin, halt the action rather than proceed on an old price.
- Apply sanity bounds to incoming prices. If a price moves an implausible amount in a single update, such as the multi-order-of-magnitude jump seen in the Moonwell case, require a secondary confirmation or trigger an automatic pause instead of accepting it outright.
- Define explicit behavior for a paused or failed oracle. Don't just catch the error, decide in advance what the protocol should still allow. Existing users withdrawing collateral is very different from new loans being issued against a data feed that isn't currently trustworthy.
- Layer in a risk management network where one is available. Cross-chain and multi-asset protocols can use tooling like Chainlink's Risk Management Network to flag or block data batches showing anomalous behavior before they ever reach a consuming contract.
What This Means For Protocol Design
None of the three case studies above involved a broken cryptographic primitive or a failure of Byzantine fault tolerance math in the strict sense. Mango Markets exploited thin liquidity that a correctly functioning oracle faithfully reported. The LUNA-era losses came from contracts mishandling a pause signal the oracle sent correctly. Moonwell lost money to one bad data point that a second, independent check would have caught in seconds.
Oracles are the connective tissue between deterministic code and a non-deterministic world. Across all three case studies, the security of that connection depended less on which architecture a protocol picked and more on whether the receiving contract treated every incoming price as something to verify, not something to trust by default.
Frequently Asked Questions
Can a protocol just run its own oracle instead of relying on Chainlink or Pyth?
Technically yes, but it recreates the exact problem decentralized oracles solve, a single self-run feed is one compromised server away from a bad price, with none of the aggregation or economic penalties that make third-party networks harder to manipulate.
Do decentralized exchanges like Uniswap need an external oracle at all if they already have TWAP?
Not for their own trading function, but any external protocol borrowing that TWAP as a price reference does, since TWAP reflects that specific pool's liquidity, not the asset's broader market price.
If a price feed has a confidence interval, like Pyth's, should a protocol just use the midpoint and ignore it?
No, ignoring it defeats its purpose. A wide confidence interval is itself a signal that liquidity is thin or uncertain at that moment, and protocols that check it can pause or reduce exposure automatically rather than acting on a shaky number.
Related Articles
- Consensus, Custody and Cryptographic Architecture, A Technical Reference
- Smart Contract Audit Methodology, Static Analysis, Formal Verification and Coverage Gaps
- Cross-Chain Bridge Security, A Technical Post-Mortem of Major Exploits and Design Lessons
- Evaluating Cryptographic Claims in Whitepapers Against Verifiable On-Chain Evidence
