Design a Blockchain Oracle Network

Problem statement

Smart contracts are deterministic state machines sealed inside a consensus boundary: they cannot fetch an asset price, a weather reading, a sports result, or a proof that a bank transfer settled. A blockchain oracle network closes that gap. It collects observations from off-chain sources, aggregates them into a single defensible value with explicit uncertainty, and delivers that value on-chain in a way that a consumer contract can verify without trusting any single party.

The design target is a decentralized oracle network (DON) that serves continuous price feeds and on-demand generic data to consumer contracts on multiple chains. Four capabilities are mandatory per the brief: off-chain data collection from multiple providers; aggregation logic (median or weighted) that finalizes a value on-chain; token incentives for node operators; and a tamper-proof submission flow that rejects malicious or replayed updates.

Why this is not a caching problem

A naive design polls an HTTPS API and writes the result to a contract. That design fails in four distinct ways. First, a single source can be bribed, hacked, or simply wrong, and every consumer inherits the failure. Second, spot prices from thin venues are manipulable with flash-loan capital, as demonstrated by real DeFi losses such as the October 2020 Harvest Finance attack, where flash-loaned capital skewed a pool price the strategy trusted. Third, on-chain writes are scarce and expensive, so update cadence must be an economic decision, not a polling interval. Fourth, consumers on other chains need the same value with verifiable provenance, which turns delivery into a cross-chain attestation problem.

The correct framing is therefore three planes. The observation plane ingests redundant market or event data at high frequency off-chain. The consensus plane runs a Byzantine-fault-tolerant reporting protocol among staked node operators, producing one signed aggregate per round. The settlement plane commits aggregates on-chain, exposes freshness and provenance metadata, and enforces economic security through staking, slashing, and dispute windows. A strong interview answer keeps these planes separate and states which guarantees live in which plane.

Public operating baseline versus design assumptions

Public, company-reported evidence shows the category is real and large. Chainlink reports enabling on the order of sixteen trillion dollars of transaction value across its services and securing tens of billions of dollars of DeFi TVL at peak. Pyth reports 120+ first-party publishers, 500+ price feeds, and distribution to 100+ blockchains with a 400 ms update cadence on its appchain. UMA's optimistic oracle resolves prediction-market and bridge outcomes for products such as Polymarket and Across. These are cited company figures, not requirements for our fictional system.

For capacity planning this answer explicitly assumes: 2,000 active feeds across 12 consumer chains, 40 node operators per DON, 8 upstream venues per feed observed at 4 Hz per node, a 0.5% deviation threshold with a 30-minute heartbeat for push feeds, and a pull stream serving 5,000 signed reports per minute at peak. Every uncited number below is a stated assumption, budget, or target.