How Does a Smart Contract Know It Rained in London?

Imagine a smart contract with one very simple rule:

If central London receives at least 10 millimeters of rain today, pay Alice $10,000.

The money is already locked. The condition is written in code. Nobody needs to approve the claim or negotiate the payout.

There is just one awkward question.

How does the contract know it rained?

It cannot look out a window. It cannot walk to a weather station. And during normal Ethereum execution, it cannot simply open a web connection and ask a weather API what happened.

The strange part is that this blindness is not a missing feature. It is part of what makes the system work.

The Blind Machine

Ethereum is not one computer running your contract. Many independent nodes have to process the same transactions and arrive at the same result. Given the same prior state and the same transaction inputs, they need to compute the same new state ^[1].

Now imagine the contract could call a normal web API halfway through execution.

One node asks at 14:03:01 and gets 9.9 mm. Another asks a second later and gets 10.1 mm after the weather database updates. A third gets a timeout.

Suddenly, identical blockchain transactions no longer have identical inputs.

That is why smart contracts do not behave like ordinary web applications. The Ethereum Virtual Machine is deliberately isolated from arbitrary network requests during execution. External information has to enter the blockchain in a form that every node can see and agree on.

So Ethereum can be extremely certain about things already inside its own world — balances, signatures, contract storage, token transfers — while knowing absolutely nothing by itself about the rain outside.

Someone Has to Bring the Fact Inside

This is where oracles enter the picture ^[1].

At the simplest extreme, an off-chain system could read a weather source, sign a value such as 12.4 mm, and submit that value to a contract. More sophisticated oracle systems may combine many reporters, data sources, signatures, market observations, or dispute mechanisms.

But the basic problem is always the same: something outside the blockchain has to become information the blockchain can use.

Suppose a trusted oracle address submits:

London rainfall today: 12.4 mm.

Ethereum can verify the digital signature. It can prove which key authorized the message. It can prove exactly what value was submitted and when it entered the chain.

What it cannot prove from the signature alone is that 12.4 mm of rain actually fell.

That distinction is the heart of the oracle problem:

Verifying a message is not the same as verifying reality.

Hack What the Contract Believes

This matters because smart contracts do not need to contain a coding bug to produce a disastrous result. Sometimes the code does exactly what it was designed to do — with a bad input.

A lending protocol is a good example. Imagine depositing $150 worth of collateral to borrow $100. The contract needs to keep checking what that collateral is worth. If its value falls too far, the position can be liquidated.

Everything depends on the price.

In October 2021, C.R.E.A.M. Finance lost roughly $130 million in an exploit involving its collateral-pricing mechanism ^[2]. The attacker used large amounts of temporarily borrowed capital and manipulated a value involved in pricing yUSD vault collateral.

The important detail is not the complexity of the trades. It is what happened next.

The lending system accepted an inflated collateral value and then behaved accordingly. From the contract's point of view, the attacker appeared to own far more valuable collateral than was economically justified, so the protocol allowed massive borrowing against it.

The contract did not forget how collateralization worked.

It believed the number it had been told.

Flash loans can make attacks like this much more powerful because they let an attacker command enormous capital inside a single atomic transaction. But the flash loan is not the oracle weakness by itself. The deeper weakness is that the protocol accepts a price or accounting value that can be manipulated cheaply enough.

So How Do You Make a Fact Believable?

There is no single oracle design because there is no single kind of external truth.

A continuously changing ETH price is not the same problem as a rainfall total. A market price already forming on-chain is not the same as a flight cancellation. And a claim that can wait six hours for a dispute is very different from a liquidation that needs a price now.

Different systems therefore manufacture acceptable evidence in different ways.

Ask Many Messengers — Chainlink

Instead of trusting one reporter, a decentralized oracle network can combine reports from multiple independent node operators and multiple data sources.

Chainlink's Offchain Reporting architecture lets oracle nodes exchange and aggregate observations off-chain, then submit a quorum-backed report on-chain ^[3].

The idea is straightforward: one bad server, one broken API, or one dishonest reporter should not get to decide the answer alone.

This does not make the feed magically true. It changes the attacker's job. Corrupting one source is much easier than corrupting enough independent parts of the reporting system to make a false value look legitimate.

Watch the Market Itself — Uniswap TWAP

Sometimes the blockchain does not need an outside messenger at all.

Uniswap v2 and v3 can support time-weighted average prices, or TWAPs, derived from price observations produced by trading activity already happening on-chain ^[4].

Instead of asking, "What is ETH worth right now?", a protocol can ask something closer to:

"What price has this market been showing over the last several minutes?"

That matters because briefly pushing a thin market to an absurd price may be possible. Holding the distortion over a longer observation window is usually much more expensive and exposes the attacker to arbitrage and capital costs.

A TWAP does not eliminate manipulation. It makes the attack depend on liquidity, time, market structure, and how the integrating protocol uses the result.

Bring Fresh Evidence Only When You Need It — Pyth

Another question is not who produced the price, but when the blockchain should pay to receive it.

Some oracle systems continuously push updates on-chain. That keeps data ready for contracts to read, but frequent updates cost money whether anybody uses the value or not.

Pyth is useful because it also supports a pull pattern ^[5]. Fresh signed price updates can exist off-chain until an application needs one. A user or application then carries that update into the transaction, and the contract verifies it before using it.

Instead of updating every possible price all the time, the application can effectively say:

"I need a fresh price now. Here is the signed evidence."

Pyth also supports push-style integrations, so the real distinction is architectural rather than tribal: should data live on-chain continuously, or arrive only when execution actually needs it?

Assume It Is True Until Someone Objects — UMA

Then there is the wonderfully different approach: do not try to prove every claim up front.

UMA's Optimistic Oracle lets someone propose an answer and back it with economic value. A dispute window follows. If nobody challenges the claim, the system can accept it. If someone does challenge it, the question escalates into UMA's dispute-resolution process ^[6].

That makes sense for facts that do not need millisecond updates and may be awkward to encode as a permanent price feed.

The logic is almost social:

We will accept this claim unless somebody is willing to risk money saying it is wrong.

Most Oracle Security Is About Changing the Cost of a Lie

Look across these designs and a pattern appears.

None of them opens a magical window through which the blockchain can inspect reality directly.

Instead, they make false information harder, slower, riskier, or more expensive to get accepted.

A decentralized feed may require corrupting several independent reporters. A TWAP may force an attacker to sustain a distorted market over time. An optimistic oracle can make a false assertion vulnerable to challenge and loss of a bond.

Cryptographic signatures add another layer: they can make it extremely difficult to forge who said what.

The engineering problem is therefore often not:

How do we make lying impossible?

It is:

How do we make an accepted lie harder to produce than it is worth?

Even Perfect Cryptography Still Needs a Window

This is where the problem gets stranger.

Modern cryptography can prove remarkable things. A proof can establish that a computation was performed correctly, that a particular key signed some data, that a value was included in an authenticated dataset, or that a private input satisfies a public condition.

But suppose a weather sensor signs:

Rainfall: 10.2 mm.

Cryptography may prove that the sensor's key really signed that message and that nobody altered it afterward.

It still cannot tell you whether the sensor was calibrated correctly, whether someone poured water over it, or whether it was actually sitting in London.

A proof can make the digital evidence extraordinarily trustworthy.

Some observation still has to connect that evidence to the world.

The Contract Still Cannot Look Outside

That is the part hidden by phrases like code is law.

A smart contract can make the consequences of an accepted fact rigid. Once the system accepts 12.4 mm of rain, the payout can be automatic, deterministic, and very difficult to interfere with.

But the code does not create the fact.

Someone measured something. A market produced a price. Reporters signed observations. Traders created an average. A proposer posted a claim and nobody disputed it.

The oracle is the machinery that turns one of those processes into something the blockchain is willing to act on.

And that means the deepest oracle question is not really:

How does blockchain code get outside data?

It is:

Why should the blockchain believe it?

The contract can prove who sent the number.

It still cannot look outside and see if it is raining.