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 where they 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 here's the catch: 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 & Betting: Game scores trigger payouts in prediction markets
  • Cross-Chain Data: Bridge contracts need information from other blockchains
  • Supply Chain & IoT: Tracking requires sensor data, GPS coordinates, shipment verification

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 creates a critical vulnerability. If that source is hacked or malfunctions, every smart contract using that oracle is affected.

Man-in-the-Middle Attacks: Data can be intercepted and modified between the source and the blockchain. Preventing this remains challenging.

Lack of Transparency: Some oracles don't show how they collect and validate data. You see a price appear on-chain, but have no way to verify where it came from or how it was validated.

Consensus vs. Authenticity: Decentralized oracle pools might achieve consensus, all nodes agree on the data but that doesn't guarantee the underlying data source is authentic or accurate. 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.

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.

Security considerations​

Oracle security matters because smart contracts depend on accurate external data. Here's how oracles protect against bad data:

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​

Consider these factors when selecting an oracle for your Cardano application:

  • What sources does the oracle use? How reliable are they?
  • Does the publication model match your needs?
  • How distributed is the oracle network?
  • Can you audit the data collection and validation process?
  • How hard is it to integrate?
  • What are the fees for consuming oracle data?

For most Cardano applications, Pyth is the recommended oracle. It is an industry-grade network delivering 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.