An oracle is the service that delivers off-chain data, such as an asset's reference price, to a smart contract onchain. It is both a point of trust and a point of failure, so its update frequency, deviation thresholds, and fallback behavior must be designed deliberately. For pegged tokens, the oracle is part of the depeg attack surface.
Choose the oracle in the spec, not during development. Teams that pick it late inherit its constraints instead of designing around them, and the heartbeat and fallback logic belong in the MDD.
How it works
An oracle bridges off-chain data and onchain logic. Smart contracts execute deterministically against their inputs, but many of those inputs, asset prices, exchange rates, proof-of-reserve confirmations, interest rates, originate off-chain. An oracle reads that data from one or more sources, reaches consensus across a network of nodes or a centralized feed, and writes a verifiable result onchain. The contract trusts the oracle the way it trusts its own code: absolutely, within the scope of the call.
Three parameters need to be specified. Update frequency, or heartbeat, sets the maximum staleness of the feed. Deviation threshold sets the minimum price change that triggers an out-of-band update between heartbeats. Fallback behavior sets what the contract does if the feed is stale, unavailable, or returns a value outside an expected range. Skipping any of these is itself a design decision, usually the wrong one.
Why it matters
For pegged and asset-backed tokens, the oracle is a first-order component of the peg, not a supporting service. If the contract uses the oracle price to set collateral ratios, trigger redemptions, or calculate NAV per share, oracle manipulation is a direct path to depeg. Flash-loan attacks that briefly move a market price used as an oracle input have been a recurring exploit vector in DeFi. A design that does not model oracle failure and manipulation as threat scenarios is incomplete.
Design consequence
Different architectures trade off differently. Decentralized networks such as Chainlink aggregate prices across independent node operators, making manipulation expensive but adding aggregation latency. Onchain TWAP oracles, introduced by Uniswap v3, derive prices from actual trade history, making them manipulation-resistant over the averaging window but slow to reflect rapid moves. Many production designs pair a primary oracle with a fallback of a different type, so a single-source failure does not halt the protocol.
See RWA Tokenomics for how this applies in practice.
Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.
80+ projects advised. Complete tokenomics in 4 to 6 weeks.