Oracles: how blockchains learn what's happening outside

A smart contract can check balances, signatures and its own state perfectly. What it can't do is look anything up. It has no idea what ETH costs in dollars, who won a match, or whether it rained in Madrid yesterday. Blockchains are deliberately sealed: every node must reach the same result from the same data, and the outside world doesn't offer that.

Yet lending protocols need prices, stablecoins need exchange rates, and insurance contracts need real-world events. The bridge between the sealed chain and the outside world is called an oracle — and it's one of the most attacked parts of decentralised finance.

What an oracle does

An oracle is any mechanism that puts outside data onto the chain where contracts can read it. Typically:

1. One or more data providers collect information — say, the ETH/USD price from many exchanges.
2. They sign it and submit it to an oracle contract on the chain, regularly or when it changes enough.
3. Other contracts read the latest value from that oracle contract and act on it.

The contract trusts the oracle completely. If the oracle says ETH is worth $10, a lending protocol reading it will treat ETH as worth $10 — and liquidate or lend accordingly.

The oracle problem

That's the core difficulty: a protocol can be perfectly coded and still be only as trustworthy as its data. Decentralising the contract doesn't help much if a single source feeds it prices.

Oracle designs try to reduce that dependence in different ways:

• Multiple independent reporters whose answers are aggregated, so one bad or compromised source can't move the result.
• Many underlying data sources, so one manipulated exchange doesn't skew the price.
• On-chain price averages taken over time from decentralised exchanges, which are harder to move for long.
• Economic penalties for reporters who submit wrong data.

How oracles get exploited

Many of the largest DeFi losses weren't contract bugs in the usual sense — they were oracle failures:

• Spot-price manipulation. A protocol reads the current price from a single small trading pool. An attacker borrows a large amount in one transaction, pushes that pool's price, borrows or liquidates against the false price, then reverses the trade — all before the transaction ends. Flash loans make this possible without any capital of their own.
• Thin markets. A token traded mostly in one small pool is cheap to push around, and any protocol accepting it as collateral inherits that weakness.
• Stale data. An oracle that stops updating during a fast market can let people borrow against prices that no longer exist.
• Compromised reporters or admin keys that can change where the oracle gets its data.

The same reasoning applies to bridges: a system is only as secure as the component that tells it what happened elsewhere.

Why it matters to you

You don't interact with oracles directly, but they decide what happens to your money in many protocols:

• Lending: your collateral's value — and whether you get liquidated — comes from an oracle.
• Stablecoins: several designs depend on price feeds to stay on target.
• Derivatives and synthetic assets: settlement prices come from oracles.

Before using a protocol with real money, it's worth knowing: where does it get its prices? Is it a well-established, multi-source feed, or a single pool? What happens if the feed stops updating? A protocol that can't answer those questions clearly is asking you to take a risk you can't see.

Oracles and SSP

SSP itself doesn't depend on oracles to protect your funds. Your coins sit in a 2-of-2 multisig vault, and moving them depends only on signatures from your two devices — not on any external price.

The prices you see in SSP — your portfolio value in your chosen currency — are for display. They don't affect what a transaction does or whether it's valid.

Oracles become your concern when you take funds into DeFi protocols through WalletConnect. There, SSP shows you what you're signing and needs both devices to approve, but it can't evaluate whether the protocol's price feed is sound. That due diligence is yours — and verifying the contracts and who controls them is part of it.

The honest summary

Blockchains can't see outside themselves, so oracles bring the data in — and every contract that relies on that data inherits the oracle's weaknesses. Many big DeFi exploits manipulated a price feed rather than breaking the code.

When you use a protocol that depends on prices, ask where those prices come from. Well-aggregated, multi-source oracles are much harder to fool than a single pool — and "decentralised" code with a single point of data is not as decentralised as it looks.