Oracles: how outside data reaches the blockchain and where it breaks

How does a smart contract know what an asset is worth if the blockchain cannot see anything outside itself? It learns from an oracle: a system that collects data off-chain, reduces it to a single value and writes that value to the blockchain in a transaction. The contract accepts the value like any other input and has no way to check it independently.

That makes the oracle not a supporting detail but part of the trust model of any protocol that works with prices: margin, liquidations and settlement all run on the data it reports. Below is how oracles are built, which architectures exist and how they fail.

The oracle problem

The oracle problem is that a blockchain guarantees the correct execution of code, but not the correctness of the outside data that code relies on. Every node in the network must reach the same result by repeating the same computation, so a contract cannot query an exchange's website itself: different nodes at different times would get different answers.

The ethereum.org documentation states the consequence directly: for a contract to execute correctly, the oracle's data must be correct, and having to trust oracle operators undermines the “trustless” nature of smart contracts.

How data reaches the network: push and pull

There are two basic delivery models: data is published to the network in advance and on a regular schedule (push), or it is supplied on request at the moment of use (pull). Ethereum.org describes them as “publish-subscribe” and “request-response.”

• Push. The oracle operator regularly writes new values to a feed contract, and other contracts read the latest value. The data is already on-chain, but every update costs gas, so between updates the price can lag the market.
• Pull. Data is requested when it is needed. According to ethereum.org, this model suits cases where the dataset is too large to store in a contract. The value is fresh at the moment of use, but the operation gains an extra step.

Choosing between them is a trade-off among cost, freshness and complexity. Update frequency is a separate parameter: the less often a value is updated, the longer the contract works with a price that no longer matches the market.

Aggregation: one price from many sources

An oracle usually does not take its price from a single venue: it combines several sources so that a failure or outlier at one of them does not determine the result. Typical methods are the median or a weighted average, where the weight depends on, for example, trading volume or the venue's reliability.

Aggregation reduces risk but does not eliminate it. If the sources are correlated, or most of them are illiquid markets, the median will not help. The aggregation method also becomes a point of trust in its own right: the final price depends on the weights and filters, and so does whose position gets liquidated.

Decentralized or in-house oracle

Oracles differ in who computes and signs the final value: an independent network of nodes or a single organization. A node network removes the single point of failure; an in-house oracle is faster and more flexible but adds a trusted party.

This trade-off is examined in BIS Bulletin No 76 (September 2023). The authors write that pursuing full decentralization leads to complex consensus protocols that reduce blockchain efficiency even further, while partial centralization means adding trusted parties to a system designed to be trustless. In other words, there is no option without trust; the choice is where that trust sits. It is also worth noting that decentralizing the nodes does not solve the source problem: if every node reads the same illiquid markets, they will consistently deliver the same distorted price to the network.

How oracles break

Oracle failures fall into technical breakdowns and deliberate manipulation. The outcome is the same: the contract applies its rules at the wrong price.

The least obvious case is the first. The oracle works “correctly,” faithfully relaying the source price, but the source itself is easy to move. The attack then targets not the oracle but the market it listens to.

Part of the defense lies not in the oracle itself but in the contracts that consume its data. Common design techniques include checking the time of the last update and refusing to use a stale value, capping how far the price may jump in a single update and setting more conservative limits for illiquid assets. Each of these is a trade-off too: an overly strict freshness check halts operations precisely when the market moves fastest.

The Mango Markets case: the CFTC's position

The Mango Markets case illustrates how, according to the regulator, buying up a token on illiquid source venues distorted an oracle price and made it possible to withdraw other users' assets from the platform. On January 9, 2023, the U.S. Commodity Futures Trading Commission (CFTC) announced a civil action against Avraham Eisenberg in connection with the Mango Markets platform. What follows summarizes the regulator's position as set out in the press release: these are allegations, not facts established by a court as of the publication date.

According to the CFTC, on October 11, 2022, the defendant opened large leveraged positions on Mango Markets in a swap contract whose value depended on the price of the MNGO token against USDC. He then rapidly bought significant amounts of MNGO on three venues whose data served as inputs to the Mango Markets price oracle. The regulator alleges that the oracle price of MNGO rose more than 13-fold within 30 minutes. According to the CFTC, he used the inflated value of the swap positions as collateral to withdraw more than $110 million in assets from the platform. The press release also mentions a criminal charge brought by the U.S. Attorney's Office for the Southern District of New York. The subsequent course of the cases is not covered in this article.

The mechanism the regulator describes illustrates the thin-market scenario. The oracle was not hacked: it relayed the price its sources were showing. If the allegations are taken as stated, the vulnerability arose where illiquid sources met protocol rules that accepted the oracle-based valuation as collateral.

Example: the Variational oracle

Variational uses its own oracle. According to the documentation, it streams several real-time data feeds for each market and uses a weighted combination of prices from different venues. The project explains the choice of an in-house oracle by the ability to add new assets quickly, including exotic markets.

How oracle data is used in the Omni application is described on the prices page. The index price comes from the oracle and serves as an input to the mark price, which in turn is used to calculate unrealized PnL, margin and liquidations. For swaps, according to the same page, the index price comes not from the oracle but from traditional finance partners.

The remaining links in the chain are described on technical pages:

• according to the Partners page, Variational is integrated with most major centralized and decentralized venues for price streaming, and oracle data is signed using Fireblocks;
• according to the Mainnet Contracts page, the oracle contract is deployed on Arbitrum, and its address is published.

Not publicly disclosed are the exact venue weights, the list of sources per market, the contract update frequency, the signing scheme (how many keys and who holds them) and the procedure when a source fails. This means an outside observer can see what is written to the oracle contract but cannot reproduce how the price was computed.

In BIS terms, this is the trusted-party option: the project itself defines the aggregation method, and signing goes through a provider it has chosen. A specialized signing provider is meant to reduce the risk of key compromise, but it does not make the oracle decentralized. It is reasonable to assume that the decisive factor is the quality of internal procedures, which cannot be verified from outside. Oracle risks — a stale price, a weighting error, a thin source — feed directly into the margin and liquidation calculations covered in the article “Margin and liquidation: the risks behind the terms”.

Summary: trust can be moved, not removed

The oracle is where a blockchain trusts the outside world, and a protocol that works with prices cannot be more reliable than this link. Architectures differ in how they deliver data, how they aggregate it and who signs the result, but none removes trust entirely: it shifts to a node network, an organization or the source markets.

For any oracle, it helps to know which sources it draws on and how liquid they are, how often the value is updated, who signs it and what happens when something fails. For Variational, some of the answers are in the documentation, while the weighting method and failure procedures were not publicly described as of the date of review.