Skip to main content

Oracles on Cardano

What are oracles?​

Oracles connect blockchains with external data sources, bridging the gap between on-chain smart contracts and off-chain information. They fetch, verify, and deliver real-world data to smart contracts in a format they can use.

The name comes from ancient oracles who delivered messages from the gods to mortals. Modern blockchain oracles bring real-world information from APIs, websites, and datasets onto the blockchain where smart contracts can access it.

Blockchains are deterministic systems that can only see data within their own ledger. Oracles solve this limitation by bringing external data on-chain.

Why oracles matter​

Smart contracts execute conditional logic: when event X happens, trigger action Y. Their code runs on a decentralized network, producing the same result every time. This "trustless" quality comes from cryptographic proofs and distributed consensus and no need for a trusted third party.

But smart contracts need real-world data as inputs. A DeFi protocol needs current prices. An insurance contract needs weather data. A prediction market needs event outcomes. This data must be trustworthy because smart contract execution has real economic consequences, and blockchain transactions can't be reversed.

Common oracle use cases:

  • Price feeds: exchange-rate changes trigger trades, liquidations, or limit orders in DeFi protocols.
  • Real-world events: weather data triggers crop-insurance payouts; flight delays trigger travel-insurance claims.
  • Sports and betting: game scores trigger payouts in prediction markets.
  • Cross-chain data: bridge contracts need information from other blockchains.
  • Supply chain and IoT: tracking requires sensor data, GPS coordinates, shipment verification.
  • Randomness: Raffles, lotteries, and games need a verifiable random draw, which a validator cannot generate itself. See On-chain randomness

The oracle problem​

The "oracle problem" refers to a fundamental challenge: how can smart contracts trust external data to be authentic and accurate?

DeFi alone is critically dependent on oracle-provided data. But there are many opportunities for false data to slip into the collection, validation, and publication pipeline. This creates a lucrative attack vector, bad actors can trigger large payouts from smart contracts by feeding them false information.

Key challenges​

  • Single point of failure: an oracle that pulls from just one data source is a critical vulnerability. If that source is hacked or malfunctions, every smart contract using the oracle is affected.
  • Man-in-the-middle attacks: data can be intercepted and modified between the source and the blockchain, and preventing this is hard.
  • Lack of transparency: some oracles don't show how they collect and validate data. You see a price appear on-chain with no way to verify where it came from.
  • Consensus vs. authenticity: a decentralized oracle pool can agree on a value without that value being authentic. Agreement on bad data is still bad data.

Oracles on Cardano's eUTXO model​

Cardano's Extended UTXO (eUTXO) model offers unique advantages for oracle implementations. A functional oracle system on Cardano requires three components: diverse data sources, a computation platform to validate accuracy, and network participants to transfer data on-chain.

Reference inputs​

The Vasil hard fork introduced reference inputs, UTXOs that transactions can read without consuming them. This eliminates a major bottleneck for oracles:

Multi-oracle validation​

Smart contracts can reference UTXOs from multiple oracle providers simultaneously, performing on-chain reconciliation. The script reads values from different oracles and verifies they fall within an acceptable deviation threshold:

This on-chain check provides a trustless, programmatic guarantee against single oracle network failure or attack. Even if one oracle is compromised, the deviation check catches the problem.

Publication models​

Oracles use different publication models depending on the use case:

Push model​

Data is published continuously at regular intervals. Smart contracts read whatever's most recent. Updates happen:

  • At fixed intervals (e.g., every 5 minutes, hourly)
  • When data deviates beyond a threshold from the last publication
  • Or both, regular updates plus deviation triggers

Pull model​

Data is fetched only when requested. A smart contract or user asks for data, and the oracle responds (just-in-time delivery).

Who publishes, and what that guarantees​

The push/pull split is also a trust choice, not just a question of timing.

In a push design, the oracle network writes the price on-chain itself, into a UTXO your contract reads as a reference input. The value is produced and published independently of the protocol that consumes it, so a protocol cannot quietly substitute a different number: it never touches the publication step.

In a pull design, the oracle signs the price off-chain and whoever builds the transaction submits it on-chain, where a validator checks that signature before accepting the value. This is the model Cardano's recommended oracle, Pyth, uses, and it is a standard, sound pattern: the signature is what makes it trustless. Verifying several oracle signatures instead of one raises the bar further, but the shape is the same. A common on-chain shape for pull feeds: the signed price rides in the redeemer of a withdrawal validator that runs once for the whole transaction, while an oracle NFT read as a reference input only authenticates the feed's identity, so every consumer in the transaction shares one verification and the value stays per-transaction fresh without ever being written into a UTXO first.

Be precise, though, about what that signature does and does not cover:

  • Integrity is guaranteed. A forged or altered price will not verify. No one can feed your contract a number the oracle did not sign.
  • Liveness and timing are not. Whoever assembles the transaction decides whether and when to include an update, so a pull feed can be withheld, delayed, or posted only when it suits the submitter, and the signature check alone will not catch that. Enforce a freshness window yourself (Pyth exposes timestamp_us for exactly this), and where reuse matters, post the verified price into a public oracle UTXO that any contract can reference, so the feed stays composable instead of staying locked inside one protocol's transaction.

This is also why the multi-oracle reconciliation above is worth the effort: reading and cross-checking more than one feed on-chain protects you when any single feed is stale, withheld, or wrong.

Designing with a price feed​

Once your contract can read a verified price, the design question becomes: when does it read, and which parts of the update does it use? Most oracle-consuming designs reduce to one of two shapes.

Settlement at a deadline. The contract stores a question at creation (which feed, what threshold, by when) and reads the oracle exactly once, at resolution. Prediction markets, options expiry, and parametric insurance all work this way. The timing belongs in the transaction validity interval, not just in application code: interactions that must happen before the deadline require the validity upper bound at or below it, and the resolving transaction requires the lower bound at or above it. That turns the freshness rule from the previous section into something the ledger enforces structurally rather than something your off-chain code promises.

Live parameter. Every interaction reads the current update and feeds it into the contract's logic as an input: lending protocols checking collateral ratios, liquidation triggers, dynamic pricing, in-game economies. Here the freshness window matters on every transaction, because each one acts on the value it carries.

The update itself carries more signal than the headline number, and each field maps to a mechanic:

  • Price and exponent are the headline value.
  • Confidence and the bid-ask spread measure how certain the market is. A contract can widen its safety margins, scale position limits, or refuse to act at all when the spread blows out. That is volatility protection with no extra infrastructure.
  • The EMA against the spot price is a momentum signal: spot above the moving average means the asset is trending up. This gives trend-aware logic without storing any price history on-chain.
  • Two feeds combined yield a cross-asset ratio, so anything can be priced in anything: an ADA-denominated contract can settle a EUR obligation by dividing two USD feeds.
  • The update timestamp can be an input, not only an accept/reject check: behavior can degrade gracefully as data ages instead of failing outright.

Two architecture patterns are worth knowing. A market or game lifecycle can live in a single UTXO identified by a state-thread token, with position tokens minted against user actions and burned to claim; the oracle read then happens exactly once, at the state transition that settles the outcome. And keeping oracle verification in a swappable provider validator, separate from a pure logic validator that consumes normalized price data, lets you test the logic against a mock provider on a local devnet and swap in the real oracle for production. The Pyth guide shows the settlement shape in working Aiken, and its complete example composes both patterns into a full prediction market.

Security considerations​

Oracle security matters because smart contracts depend on accurate external data. Oracles defend against bad data in several ways:

Data source diversity​

Multiple independent data sources verify accuracy and reduce vulnerability. If one source is compromised or fails, others catch the problem. Aggregating diverse sources helps identify outliers and produces more reliable values.

Decentralized validation​

Multiple independent validator nodes collect and verify data before publication. This reduces single points of failure and makes it harder for attackers to manipulate feeds they'd need to compromise multiple nodes.

Cryptographic verification​

Oracles use cryptographic signatures, tokens, or NFTs to prove data authenticity. Smart contracts verify these proofs before accepting oracle data as valid input.

Transparency and auditability​

Audit trails document how data was collected, validated, and published. This transparency lets you verify oracle operations and hold providers accountable.

Outlier detection​

Statistical methods identify and exclude anomalous data that deviates significantly from expected ranges, preventing manipulation or errors from affecting outputs.

Choosing an oracle​

The factors that actually differentiate oracles are concrete, and the sections above explain what each one buys you: the data sources a feed draws from and how diverse they are, the publication model (push or pull) and the trust choice it implies, how distributed the operator set is, whether collection and validation are auditable, the integration effort, and the fee for consuming updates. Weigh them against your use case, in particular against whether you read the feed once at settlement or on every interaction.

For most Cardano applications, Pyth is the recommended oracle: sub-second, high-frequency price feeds through a pull-based model, with on-chain verification handled by an Aiken library, so your contract reads verified updates directly from the transaction it validates.

Contracts can also read multiple oracle feeds and reconcile them on-chain, as shown above, so a single feed failing or being manipulated does not compromise the result. See the Pyth integration guide to wire it into your validator and off-chain code.

Next steps​

  • Pyth: wire the recommended oracle into your validator and off-chain code
  • Randomness: verifiable random values, the other hard data problem