What Is a Blockchain Oracle?

Every liquidation, mint and redemption in DeFi runs on a number some oracle wrote to the chain. When that number is wrong, contracts still execute exactly as coded, on bad data.

A blockchain reaches consensus by having every node re-run the same transactions and arrive at the same result. That only works if every input is already on the chain. If a contract could call an external API, two nodes might get different answers a few seconds apart, and consensus would break. Blockchains are closed by design.

The oracle problem follows from that. Outside data has to be written onto the chain by someone, and the contract has no native way to check whether that someone told the truth. A decentralized protocol that reads from one trusted reporter inherits that reporter’s trust model. Its own design does not change this.

Solving the oracle problem means shrinking how much anyone has to trust the path from source to contract.

Most blockchain oracles follow the same path from source to contract.

• Sourcing. Nodes collect raw data where it originates: trades on centralized and decentralized exchanges, a custodian’s API, a fund administrator’s NAV report, or the state of a smart contract.
• Aggregation. The raw inputs are combined into one value. A common method takes the median across sources, drops outliers and rejects data that is too old.
• Delivery. The final value is written to an oracle contract on each destination chain, where other contracts read it.

Delivery runs in one of two modes. A push oracle writes updates on a schedule, or whenever the value moves past a set deviation threshold. A pull oracle publishes signed values that the application brings onchain at the moment it needs one, so it pays only for the updates it uses.

DIA’s price feeds show the full path. Independent feeder nodes pull trade data directly from exchanges, with no third-party aggregator in between. They submit it to Lasernet, DIA’s rollup-based Ethereum L2. There, aggregation runs a median with outlier filtering, staleness checks and a minimum-validity threshold before the value is delivered across 60+ blockchains as a push or pull feed.

Oracles are usually grouped by the data they deliver. Each type answers a different question for the contract.

Price oracles

A price oracle reports what an asset trades for. Lending markets, perpetuals and options depend on it, since collateral values and liquidation thresholds move with the market. Liquid crypto assets are the familiar case. Equities, ETFs, commodities and FX rates are the newer one, as tokenized versions of those assets reach DeFi.

DIA’s price oracle covers 3,000+ crypto assets sourced from 100+ exchanges. Its RWA oracle delivers real-world asset prices with sub-second to two-second updates.

Reserve and fair value oracles

Some assets have no reliable market price. A tokenized treasury fund, a vault share or a reserve-backed stablecoin may trade thinly or not at all. A thin market price can be pushed far from what the asset is worth.

A fair value oracle computes the value from fundamentals: reserves divided by supply, net asset value, or the exchange rate written into the token’s own contract. Proof of reserves applies the same idea to backing. It reports whether the assets behind a token cover what has been issued. DIA Value is DIA’s fair value oracle, and its proof of reserves oracle is one of the methods inside it.

Randomness oracles

A smart contract cannot produce a random number on its own, because every node has to compute the same output. A randomness oracle supplies one that nobody can predict before it is published and anyone can verify afterwards. Onchain games, lotteries, prediction markets and NFT mints use it to prove outcomes were fair.

DIA’s verifiable randomness is built on drand, a distributed randomness beacon, and each value carries a signature that can be checked onchain.

Verifiable offchain data oracles

A growing share of what DeFi needs sits behind private APIs: custodian balances, fund administrator NAVs, exchange account statements. A verifiable offchain data oracle proves where a value came from.

With zkTLS, a proof is generated inside the encrypted session with the source. A contract can then check that a reported balance came from the stated endpoint and was not changed on the way. Zero-knowledge proofs can also show that a condition holds, such as reserves exceeding supply, without publishing the figure behind it. DIA ZK delivers this as verifiable offchain data.

Most oracle incidents trace back to a short list of weaknesses. A contract cannot tell a bad input from a good one, so each weakness upstream becomes a loss downstream.

• Manipulation. If an oracle reads its price from a thin market, an attacker can move that market for a few blocks, often with borrowed funds. They then borrow against the inflated collateral or trigger liquidations at the distorted price.
• Single source. An oracle that depends on one exchange, one data vendor or one attester fails when that source goes offline or reports a wrong number. The same risk sits one level up: a market that can read from only one oracle provider has no fallback if that provider degrades.
• Latency and staleness. A price that was right ten minutes ago can be wrong now. In a fast market, a stale feed keeps positions open that should have been liquidated, or liquidates them at a price the market has already left. Assets that trade on traditional venues add trading sessions and market closes to the problem.
• Wrong method. A market price applied to an asset that barely trades measures the wrong thing. A vault share or tokenized fund can show a market price far from its redemption value, and a lending market that uses it will misprice its collateral.

Each failure above has a matching control. They share one principle: anyone relying on a value should be able to check how it was produced.

• Many sources, outliers dropped. A median across many venues barely moves when one thin market is pushed, and outlier filters remove the pushed value entirely.
• Traceable sourcing. When feeders pull directly from exchanges and submit to a public ledger such as Lasernet, each input can be traced to its venue and the aggregation can be audited.
• Freshness you can check. Staleness checks and deviation thresholds bound latency. DIA’s RWA feeds support deviation thresholds down to 0.01%, set per asset, and carry a signed value and timestamp, so a contract can confirm how fresh a price is before it acts.
• Fundamentals for illiquid assets. Reading a redemption rate or reserve balance from contract state produces a value that a thin market cannot move. Value can also run alongside market feeds to flag a depeg.
• Proofs from the source. A zkTLS proof shows a value came from the stated source and was not altered in transit.

Verification also has a boundary. A proof binds a value to its source. It does not make the source honest. If a custodian’s API reports a balance it does not hold, the proof will faithfully confirm a wrong number. For reserves held fully offchain, trust in the source remains, and a credible oracle says where that line sits.

Tokenized treasuries, fund shares, yield-bearing stablecoins and tokenized equities are moving into lending markets and vaults. The teams behind them are asset issuers, risk curators and vault deployers. They ask questions a crypto price feed was never built to answer. What is this asset worth when it does not trade? Is the reserve behind it real? Can I check that myself?

Those questions widen the job of a DeFi oracle. Coverage has to reach every asset a protocol accepts as collateral, liquid or illiquid, onchain or off. Every value has to be checkable by the people whose capital depends on it. DIA’s positioning puts both in one line: Price any asset. Verify every feed.

DIA’s products map onto that job. Market and Real price traded assets, crypto and real-world. Value prices assets from their fundamentals. ZK proves where offchain data came from, and Random delivers randomness that anyone can verify.