How Oracle Price Feeds Work: A Publisher's View of Getting a Price On-Chain
A smart contract cannot see the outside world. It cannot query an exchange, read a website, or check what Bitcoin is trading at. Everything it knows about prices, it has to be told, and whatever tells it has to be trusted, because the contract will act on the number without question.
That problem is the oracle problem, and it is the reason a lending protocol holding billions in collateral depends on a price feed it did not build and cannot verify on its own. With a sound feed the system works. With a faulty one, as several protocols have learned expensively, the contract liquidates positions that should not be liquidated, or lets an attacker borrow against collateral that is not worth what the feed claims.
This article explains how oracle price feeds actually work: how a price gets from a trade on an exchange to a number a smart contract can read, what happens along the way to make it trustworthy, how the major networks differ, and what has gone wrong when the process failed, written from the perspective of a data publisher into eight of those networks, a vantage point most explainers lack.
Why smart contracts need oracles
Blockchains are deterministic by design. Every node must be able to reach the same state by replaying the same transactions, which means no transaction can depend on anything external: a web request, a random number, a price on Coinbase. If it did, different nodes could get different answers, and consensus would break.
But almost every useful financial contract depends on a price. A loan needs to know whether its collateral is still worth more than the debt. A perpetual future needs to know the underlying's price to settle funding and trigger liquidations. A stablecoin needs to know what its backing is worth. None of that information lives on-chain.
An oracle is the mechanism that brings it there. At its simplest, an oracle is a party that reads a price off-chain and writes it on-chain in a transaction the contract can read. The entire design challenge is making that party trustworthy, or, better, making it so that no single party has to be. Eskandari and co-authors' survey of oracle designs, presented at ACM Advances in Financial Technologies in 2021, frames the field around exactly this question: how to move a ground-truth value on-chain without creating a point that can be bought or broken.
How a price gets from an exchange to a smart contract
A price passes through six stages on its way to a smart contract. The stages are similar across networks; what differs is how each is implemented and who does it.
It starts at the source. Somewhere, an asset trades: on exchanges, in order books, in DEX pools. Those trades, quotes and reserves are the raw material. A data publisher, which is Blocksize's role, then collects that raw material across many venues, filters out anomalies and drifting sources, weights by volume, and produces a single price per asset. The process is the one described in Real-Time Crypto Data Aggregation: How It Works, and its quality determines everything downstream. A publisher submitting a single-exchange price is submitting that exchange's quirks.
The publisher signs the price with a cryptographic key and submits it to the oracle network. The signature proves who submitted it and that it has not been altered. The network receives prices from multiple publishers for the same asset and combines them, typically by taking a median, sometimes with additional weighting or confidence measures. That step removes dependence on any single publisher: if one submits a bad price, the median ignores it.
Node operators, independent parties running the network's software, then check the submissions against each other, against the aggregate, and against rules about staleness and deviation. Submissions that fail are rejected, and depending on the network, publishers whose submissions repeatedly fail can be penalised financially. Finally, the validated aggregate is written to the blockchain, either proactively on a schedule or when a consumer requests it, and from that point any smart contract can read it.
Every one of these stages is a place where things can go wrong, and every network's design is a set of choices about how to make each stage harder to corrupt.
Push oracles vs pull oracles
The most consequential design difference is how the price reaches the chain.
Push oracles write the price on-chain proactively. The network maintains an on-chain contract holding the latest value, and updates it when one of two conditions is met: a deviation threshold, meaning the price has moved by more than a set percentage since the last update, commonly 0.5% for major assets, or a heartbeat, a maximum time since the last update, commonly an hour, after which the price is refreshed regardless. Consumers read the stored value whenever they need it. Chainlink's Data Feeds are the canonical push model, and RedStone Classic, API3 and Supra's push feeds work similarly.
The push model's strength is simplicity for the consumer: the price is always there, and reading it costs nothing beyond a storage read. Its cost is that the network pays gas for every update, which limits update frequency, and that between updates the on-chain price can lag the market by up to the deviation threshold.
Pull oracles deliver the price on demand. The network publishes signed prices off-chain continuously; when a consumer needs one, it fetches the latest signed price and submits it on-chain as part of its own transaction, where the contract verifies the signature and uses the value. Pyth pioneered this model at scale, with prices updating as often as every few hundred milliseconds off-chain. RedStone Core and Supra's pull feeds follow the same pattern.
The pull model's strength is freshness and cost: the consumer gets a price that is milliseconds old and pays gas only when it actually needs one. Its cost is complexity for the consumer, who must fetch and submit the price instead of simply reading it, and who must check that the price is not stale.
Neither is universally better. A lending protocol checking collateral once per block may prefer push for its simplicity. A perpetuals exchange needing a fresh price at the moment of every trade will prefer pull. Several networks now offer both.
How the eight major oracle networks differ
Blocksize publishes into eight oracle networks. Each solves the same problem with a different emphasis.
Chainlink is the largest by value secured. Its Data Feeds use a Decentralised Oracle Network of independent node operators who reach consensus off-chain through a protocol called Off-Chain Reporting, then submit a single aggregated transaction carrying all their signatures. The on-chain value is the median of the operators' reports. Updates trigger on deviation or heartbeat. Chainlink's newer Data Streams add a pull-based option with sub-second latency. Node operators build reputation over time, and staking has been introduced progressively to add economic accountability.
Pyth is built around first-party publishers: exchanges, market makers and data providers submitting their own prices directly, instead of node operators fetching from third-party APIs. Each publisher submits a price plus a confidence interval expressing its uncertainty. The network aggregates these into a single price and confidence band, designed to be robust to individual outliers and to widen the band when publishers disagree. Since September 2024, Oracle Integrity Staking lets publishers and delegators stake the PYTH token; stake can be slashed for publishing inaccurate data, with the Pyth DAO governing the use of slashed funds. Pyth is a pull oracle by default.
RedStone is modular, offering three delivery models over the same data: Core (pull, updates under ten seconds), Classic (push, with heartbeat and deviation thresholds), and a hybrid for perpetuals and options that combines both with front-running protection. Multiple independent data providers must agree before a price is accepted, and RedStone has integrated with EigenLayer's restaking infrastructure so that providers stake assets which can be slashed for inaccurate data.
Supra runs its own consensus among a rotating set of nodes, its Distributed Oracle Agreement protocol, reaching finality in under a second. It draws from more than forty data sources, publishes a single aggregated figure it calls the S-Value, and offers both push and pull delivery. Its node provenance dashboard provides a historical audit trail of which nodes contributed to each value.
API3 takes the first-party principle to its logical end: the data source itself runs the oracle node. API providers deploy a piece of software called Airnode that serves their data directly on-chain, with no intermediary node operator. Its price feeds, called dAPIs, aggregate signed data from several such first-party sources. API3 has also pioneered Oracle Extractable Value recapture, in which the right to update a price feed is auctioned to searcher bots, and the proceeds, which would otherwise be captured by liquidators front-running the update, are returned to the protocol using the feed.
SEDA provides a programmable oracle layer where data requests are resolved by a network of executors and validated by a separate set of nodes, allowing feeds to be customised to the consumer's requirements.
Band operates a Cosmos-based oracle chain where validators fetch data from sources on request, aggregate it, and relay it to consumer chains via inter-blockchain communication. It uses a per-query cost model.
Tellor uses an optimistic model. Reporters stake TRB tokens and submit data; anyone can dispute a submission by paying a fee, and disputes are resolved by token-holder vote. If the reporter is found to have submitted bad data, their stake is slashed and awarded to the disputer. Instead of validating every submission before acceptance, Tellor relies on the economic threat of a dispute to keep reporters honest.
The common thread is that every network has an answer to the question "what happens when a publisher submits a bad price?": median aggregation, confidence weighting, consensus requirements, slashing, disputes. What differs is the mechanism. And every network's answer depends on the assumption that most publishers, most of the time, are submitting accurate prices. The quality of what publishers submit in the first place therefore matters as much as anything the network does afterwards.
What an oracle network does with a bad price
The network-level mechanisms exist because publishers can be wrong, whether through error or attack. Walking through what actually happens is the clearest way to see them work.
Suppose Blocksize's aggregation produces a Bitcoin price of $68,000 and, through some fault, submits $60,000 to a network where six other publishers submit prices between $67,950 and $68,050.
In a median-based network like Chainlink, the on-chain value is the middle of the seven submissions. The $60,000 outlier sits at one end and has no effect. If it persisted, the publisher's reputation would suffer, and on networks with staking, stake could be at risk.
In a confidence-weighted network like Pyth, the aggregation algorithm identifies the $60,000 submission as inconsistent with the others, down-weights it, and, if the divergence is large enough, widens the published confidence interval to signal disagreement. Consumers reading a wide confidence band can choose to pause. Under Oracle Integrity Staking, a pattern of such submissions would lead to slashing.
In a consensus-required network like RedStone or Supra, the submission fails to match the other providers and is not accepted into the aggregate at all.
In an optimistic network like Tellor, the price might be written on-chain initially. Any observer can dispute it, and if the dispute succeeds, the reporter loses stake and the value is removed.
The publisher, in every case, is checked by parties with no incentive to agree with it. That check is the mechanism this whole article has been describing, and it is the reason a price that has passed through an oracle network carries a form of validation that no exchange price and no single-provider feed has.
Oracle manipulation exploits: bZx, Harvest, Cream and Mango
The exploits that have shaped oracle design are worth knowing, because each exposed a specific weakness.
bZx, in February 2020, suffered two attacks days apart, using flash loans to manipulate the price on a single DEX that bZx used as its price source, then borrowing against the distorted collateral value. Combined losses were around $1 million, small in money and large in consequence: Qin, Zhou, Livshits and Gervais analysed the attacks in their 2021 Financial Cryptography paper on flash loans, the first widely read demonstration that a single-source on-chain price could be moved within a single transaction.
Harvest Finance, in October 2020, lost to a flash-loan attack that manipulated the price of stablecoins in a Curve pool it used for valuation, letting the attacker deposit and withdraw at distorted rates. Initial reports put the loss at around $24 million; Harvest's own post-mortem revised it to roughly $34 million, of which $2.5 million was returned.
Cream Finance, in October 2021, lost approximately $130 million to a flash-loan attack that manipulated the price of a yield-bearing token used as collateral, allowing the attacker to borrow far more than the collateral was worth. It was one of the largest DeFi exploits at the time.
Mango Markets, in October 2022, was attacked with real capital instead of a flash loan. The attacker used roughly $10 million across two accounts to drive up the price of Mango's thinly traded governance token on the small number of venues its oracle drew from, then borrowed against the inflated collateral. The CFTC alleged more than $110 million was taken; the SEC put the figure at approximately $116 million. The trader's criminal conviction was later overturned on jurisdictional grounds, but the mechanism was never disputed.
Pyth, in September 2021, suffered a failure without an attack. Its Bitcoin feed briefly reported a price near $5,400 while the market was around $43,500, because two publishers submitted near-zero prices that received disproportionate weight. No exploit followed, but the incident showed that having multiple publishers is not enough on its own: the aggregation must be robust to their errors, and consumers should check confidence intervals.
Every one of these, except Pyth's, was a breadth failure: the oracle drew from too few sources, or too thin ones, and an attacker could move them. Pyth's was a depth failure: enough sources, but inadequate filtering. The two terms, and the trade-offs between them, are set out in What Is Price Accuracy in Crypto. The lessons map directly onto the aggregation principles a publisher is supposed to apply before submitting anything.
The data publisher's role in oracle accuracy
Most oracle explainers describe the network, the nodes, the consensus, the delivery, and treat the data going in as a given. From the publisher's side, the emphasis is reversed. The network's job is to make sure that no single bad submission can corrupt the result. The publisher's job is to make sure its submission is not the bad one.
That means the aggregation a publisher does before submitting is where accuracy is actually created: drawing from many venues instead of one, filtering anomalous trades, excluding venues that have drifted, weighting by real volume so that a thin exchange cannot dominate, handling missing data with defined rules, and publishing the methodology so that the network and its consumers can see what they are getting. Where DEX-native assets are involved, the publisher also has to choose between trade-based and state-based pricing, a distinction covered in Crypto Prices Explained.
A publisher that does this well submits prices that sit consistently near the network's median, contributes to tight confidence intervals, and never triggers a dispute. A publisher that submits a single exchange's price is one outage away from being the outlier the network has to filter out, for the reasons measured in Rethinking Crypto Data.
Blocksize as a first-party oracle data publisher
Blocksize is a first-party data publisher into all eight networks described above. What it submits is the same aggregated price it delivers off-chain: calculated across more than 70 centralised and decentralised exchanges, filtered for anomalous trades and drifting venues, volume-weighted, and produced by a published methodology. The networks and the role are described on the oracles page.
That dual role is the point. The prices Blocksize delivers to institutions through its API are the prices it submits on-chain, where they are checked against every other publisher by node operators with no incentive to agree. A feed that survives that process continuously has been validated by parties outside the publisher's control, a form of assurance that a single-vendor feed, however well built, cannot offer. The same property is what makes the feed suitable for autonomous consumers of every kind, as Crypto Market Data for AI Agents sets out.
For protocols, that makes Blocksize a source whose accuracy is tested every time it publishes. For off-chain consumers, it makes the same feed one whose accuracy has already been tested before they receive it.
Frequently asked questions
What is an oracle price feed? A mechanism for bringing an asset's price from off-chain sources onto a blockchain, where smart contracts can read it. Because contracts cannot access external data directly, an oracle network collects prices from publishers, aggregates and validates them, and writes the result on-chain.
How do oracles work? A publisher aggregates a price from off-chain sources and submits it, signed, to the oracle network. The network combines submissions from multiple publishers, typically via a median, and node operators validate the result before it is delivered on-chain, either proactively (push) or on demand (pull).
What is the difference between push and pull oracles? Push oracles write prices on-chain proactively, updating when the price moves beyond a threshold or after a set time. Pull oracles publish signed prices off-chain continuously and let consumers fetch and submit the latest one when needed. Push is simpler to consume; pull is fresher and cheaper per update.
What is oracle manipulation? Moving the price an oracle reports so that a smart contract acts on a false value, typically by manipulating the price on the venue or venues the oracle draws from, often within a single transaction using a flash loan. Most major DeFi exploits have used this mechanism.
What is a first-party oracle? An oracle design where the data source itself submits its prices directly to the network, instead of third-party node operators fetching from public APIs. Pyth and API3 are built around this model; Blocksize is a first-party publisher into both, among others.
How is a bad price handled by an oracle network? It depends on the network. Median aggregation ignores outliers; confidence-weighted aggregation down-weights them and widens the reported uncertainty; consensus-required networks reject them; optimistic networks allow them to be disputed and slash the reporter. In every case, the publisher is checked by parties independent of it.
What is total value secured? The total value in protocols that depend on a given oracle for price data. It measures how much is riding on the oracle's accuracy, and therefore how expensive a failure would be.