Blockchain oracle design: pick the pattern first

TL;DR: Pick the data pattern first: publish-subscribe for price feeds, request-response for one-off outcomes, immediate-read for rarely changing data. Then choose your trust model, aggregate with the median, sign every message with a domain separator and nonce, and plan the fallback before the first outage.

A smart contract can't look anything up. It can't check a price, a flight status or the weather. It only knows what's already on the chain.

An oracle fixes that. It's the thing that carries outside data onto the chain. Get the design wrong and your contract trusts bad data, with real money attached.

Here's the short version. Pick the data pattern first. Then pick how much you trust the sources. Then add the checks that stop one bad value from doing damage.

Pick the pattern first

There are three ways data reaches a contract. Academic research on oracle design patterns groups them like this:

• Publish-subscribe. Nodes push fresh values on-chain all the time, on a timer or when the price moves past a set amount. Use it for price feeds. Lending and trading apps need current data at any moment.
• Request-response. The contract asks, an off-chain node fetches the answer, and a callback writes it back. Use it for one-off questions, like an insurance payout or a random number.
• Immediate-read. A trusted layer stores the value ahead of time, and the contract reads it in the same transaction. Use it when the data changes rarely and speed matters less than certainty.

Stale data on a price feed means bad liquidations. A weather payout can wait an hour. So start with how often your contract needs the data, and the rest follows.

Decide who you trust

Once you know the pattern, you need to decide how the network agrees on a value. A survey of oracle implementations splits this into two camps.

• Voting-based. Node operators lock up collateral and vote on the value. Lie, and you lose your stake. This resists fake identities well, but costs more gas.
• Reputation-based. Nodes are weighted by how accurate they've been. It's cheaper and quicker to start. The risk is a node that behaves for months, then cheats once on a big payout.

For high-value contracts, voting or a mix is usually worth the gas. For low-stakes data, reputation is fine.

Here's the bit people miss. Decentralised isn't a yes-or-no label. Cardano's developer docs split it into three layers: the data source, the aggregation, and the delivery to the chain. A network with ten delivery nodes that all read one data source still has a single point of failure. Check each layer on its own.

How the data flows

Most production oracles share the same shape, and a recent systematisation of oracle designs lays it out well.

1. Your app calls an on-chain interface contract. It checks the request and emits an event.
2. Off-chain feeders see the event and fetch the raw values from APIs or exchanges.
3. A selection layer picks which feeders take part in this round.
4. The reports get combined into one value.
5. The interface contract writes the result on-chain and calls your contract back.

On publish-subscribe feeds, step four often happens off-chain. The nodes agree among themselves and send one signed report on-chain. That saves a lot of gas.

Two habits save you pain later. Batch updates into one transaction where you can. And give every request a timeout, so a callback that never arrives doesn't leave your contract stuck.

Prove where the data came from

Agreement between sources doesn't tell you where the data came from. Proofs do that. You have three main options:

• Signed payloads. The data provider signs its answer, and your contract checks the signature. Simplest option, and a good fit when the provider is friendly.
• TLS-notary style proofs. The feeder proves it got a specific response from a specific web server. Handy for ordinary APIs that were never built for blockchains.
• Trusted execution environments (TEEs). The fetching code runs in a locked hardware enclave, and it produces proof that nobody changed it. Use it when inputs must stay private.

One catch. A proof shows where a value came from. It doesn't show the source is honest. A real source can still report a manipulated price. So proofs and aggregation work as a pair, not as swaps for each other.

For anything you sign, put three things in the message: a domain separator (a label saying what kind of message it is), a nonce or timestamp, and the value in a fixed format. Then a signature made for one contract can't be replayed on another, and an old value can't be replayed as a new one. The Sui oracle docs cover this well. It's cheap on day one and painful to retrofit.

Stop one bad value doing damage

Use the median, not the average. A single wild outlier moves a mean a long way. It barely moves a median. Mean-based feeds have been exploited in the real world, and that's why most production systems settle on the median.

• Document the method. Treat the aggregation rule as a setting you can tighten as more money rides on the feed.
• Smooth volatile assets. A trimmed mean or time-weighted median stops one price spike in one block from steering the result.
• Set a quorum. Require a minimum number of independent feeders before a value counts, and raise it with the value at stake.
• Add a dispute window. For big payouts, leave time for someone to challenge a report before funds move.

Money backs this up. Feeders who report far from the final value lose some of their stake. For that to work, the penalty has to beat the profit from cheating. If one successful attack pays more than the stake is worth, the design has failed, however clever the maths.

Build the integration for a messy network

Real networks drop connections and send things twice. Plan for it.

1. Design the request and the callback together. The callback should fail safely if your contract's state changed since the request.
2. Retry for gas spikes, not just outages. Cap the retries, and give the chain a clear signal when a request has failed for good.
3. Treat every webhook as a duplicate. This guide on webhook reliability shows how idempotency keys stop a repeat delivery from firing the same on-chain action twice.
4. Guard your signing keys. Rotate them on a schedule. Never let one key hold too much weight in a quorum.
5. Version your encoding. If the data format changes, bump a version field so the verifier rejects the mismatch instead of misreading it.

Map three paths before you write code: the happy path, the slow-feeder path, and the failed-for-good path. Most teams only test the first one.

Plan for failure

Every oracle fails eventually. A source goes down, a feeder drops off, or values drift too far apart to trust. What your contract does next matters more than how it behaves on a good day.

• Add redundancy. Several feeders, reading several independent sources.
• Define a fallback. Fall back to the last good value with a clear stale flag. Or pause only the function that needs the data. Or send big decisions to a human or governance step.
• Fail over gently. Move load to backup feeders in stages. Dumping all traffic on a backup at once can knock it over too.
• Watch every feeder. Track latency, errors and drift from the consensus. Catch the slide before it triggers a fallback.

Cross-chain adds one more rule. Put a chain ID inside the signed message, so a value meant for one network can't be accepted on another. And treat every extra chain hop as added delay and added trust.

A quick checklist

Before you choose, answer these:

• How fresh must the data be? Seconds, or minutes?
• Can you afford the gas for voting, or does reputation fit?
• Do you need proof of the source, or is agreement enough?
• Which layer has the most risk: source, aggregation or delivery?
• Does any input need to stay private?
• Who pays when a report gets challenged?
• What alert tells you a feeder has gone stale?

Test on a testnet that mirrors real load. Put telemetry on every feeder. And rehearse an outage before a real one makes you write the plan under pressure.

What we'd do first

Most teams chase fancy proofs too early. A domain separator, a median and a sane timeout stop far more real incidents than an exotic scheme sitting on a shaky integration. Get those three right, add monitoring, then look at zero-knowledge or MPC proofs later.

If you're wiring contracts into a bigger build, these are good next reads. Smart contract integration covers the frontend side. Smart contract security covers what to check before you deploy. Blockchain and AI looks at where the two fit together. And observability for LLM apps has the same monitoring habits for the AI side. For the wider picture on connecting systems, see the role of APIs in AI software.

From our group sites: connecting AI systems the right way and AI API integration gotchas.

Want this built for you?

We build the product around the contract, with the data feeds, failover and monitoring included. That's app development with the blockchain parts handled.

Got a dApp that needs reliable outside data? See what we build or talk to James. Let's get cracking.

Frequently asked questions

What is a blockchain oracle?

It's a system that carries outside data, like prices, weather or events, onto a blockchain. Smart contracts can't fetch that data themselves. The oracle fetches it, checks it and delivers it on-chain so the contract can act on it.

Should I use median or mean aggregation for an oracle feed?

Use the median as your default. One outlier can drag a mean a long way, but it barely moves a median. For volatile data, add a trimmed mean or a time-weighted median.

Which coding language is used in blockchain?

It depends on the chain. Solidity is the main one for Ethereum and chains that work like it. Rust is common on Solana. The off-chain oracle pieces, like feeders and aggregators, are often built in Go, Rust or TypeScript.

What are the four types of blockchain?

Public, private, consortium and hybrid. They differ in who can join and who can validate. The oracle patterns in this post apply to all four, though decentralisation needs often differ.

What oracle does XRP use?

There's no single official oracle standard listed in public XRP Ledger docs. Teams building there usually plug in a third-party or custom oracle for the feed they need.