Smart contracts are deterministic and therefore blind to anything outside their own chain, which creates a whole category of infrastructure.
Why the problem exists
Every node must compute the same result, so a contract cannot call an external service.
Which means external information must be submitted as a transaction by someone.
The question then becomes who submits it and why they should be believed.
Single source designs
One party reports the data.
Which is simple and makes that party a single point of failure and of control.
It is acceptable where the reporter is the natural authority on the fact and unacceptable where value depends on it.
Aggregated designs
Multiple independent reporters submit and the contract takes a median or similar function.
Which tolerates some faulty or dishonest reporters.
The security depends on the reporters being genuinely independent, which is harder to verify than to claim.
Update mechanics
Feeds update on a schedule, on a price deviation threshold, or on request.
Which means a feed can be stale between updates.
Contracts consuming a feed should check its timestamp, and failure to do so has caused documented losses.
On-chain price sources
Reading a pool price directly is possible and manipulable, since a large trade moves it.
Which has been exploited repeatedly using flash loans to move a price within a single transaction.
Time-weighted averages make manipulation more expensive by requiring the price to be held rather than briefly moved.
They are not immune, and the cost of attack scales with the averaging window and pool depth.
Flash loans
Uncollateralised borrowing repaid within the same transaction.
Which is possible because the whole transaction reverts if repayment fails.
They are not an attack in themselves — they remove capital as a barrier to attacks that were always possible.
Beyond prices
Randomness, event outcomes, weather, identity attestations and cross-chain messages all use oracle patterns.
Verifiable randomness is a specific case, since a predictable source can be exploited by whoever can predict it.
Assessing a feed
Who reports, how many, what the update conditions are, what happens if reporting stops, and whether the consuming contract checks staleness.
Oracle failure has been the proximate cause of a substantial share of large incidents in the field.
Incentives and penalties
Reporters are generally paid for accurate reporting and may be penalised for provable deviation.
Which is what aligns behaviour where the reported fact is verifiable after the event.
For facts that cannot be verified later, the mechanism is weaker and relies on reputation.
Push and pull models
Feeds that update proactively differ from those where the consumer requests a fresh value with a proof.
Which shifts cost to the consumer and can provide fresher data.
Both are in production use and suit different applications.
Failure handling
Contracts should define what happens when a feed is unavailable or clearly wrong.
Which includes circuit breakers, bounds checking and pausing rather than proceeding on bad data.
Protocols that proceeded on an obviously incorrect price have lost substantial sums.
Cross-chain messaging
The same trust question applies — who attests that something happened elsewhere.
Which is why messaging protocols and bridges share failure modes.
Designs verifying source chain consensus directly are stronger and considerably more complex to build.
Assessing dependency
Any protocol depending on external data inherits that dependency's risk.
Which is worth identifying explicitly when evaluating how a protocol can fail.
Manipulation cost
The useful question is what it would cost to move a price source enough to profit.
Which is calculable from pool depth and from the size of the position that could be exploited.
Protocols that did this calculation before launch have generally avoided the corresponding class of incident.
Redundancy
Using multiple independent feeds and requiring agreement is the standard mitigation.
Which costs more and has repeatedly proven worthwhile.
Governance of feeds
Who can add, remove or change reporters is a control point worth identifying.
Which is frequently a multisignature arrangement or a token governance process.
A feed with unaccountable control over its reporter set has a trust assumption regardless of how many reporters it has.
Practical takeaway
Every protocol depending on external data has a dependency worth naming explicitly.
Which is where a substantial share of failures has originated.
Latency
The delay between a real-world change and its reflection on chain creates an exploitable window.
Which matters for liquidation systems and for anything time-sensitive.
Faster updates cost more, and the trade-off is a design decision rather than an oversight.
Summary
Contracts are only as reliable as what tells them about the world.
Which makes this layer worth understanding for anyone assessing protocol risk.
Reading incident reports
Published post-mortems of oracle-related failures are detailed and instructive.
Which is the fastest way to understand the failure modes concretely.
Most protocols publish these after incidents, and the patterns repeat.
The layer is invisible until it fails, which is why it repays attention beforehand.