A series of incidents exploiting price data rather than contract bugs established a whole discipline of oracle design.
The basic attack
Move the price a protocol reads, then transact against the manipulated price.
Which requires the protocol to source its price from something movable.
Reading a pool's instantaneous price is the classic vulnerable design.
Why pools are movable
A pool's price is determined by its reserve ratio.
Which a large trade changes directly.
Shallow pools can be moved substantially with modest capital.
Flash loans as an enabler
Uncollateralised borrowing repaid within the same transaction.
Which removed capital as a barrier to these attacks.
They did not create the vulnerability; they made exploiting it available to anyone.
Time-weighted averages
Averaging price over a window rather than reading it instantaneously.
Which requires an attacker to hold a manipulated price rather than move it briefly.
This raises the cost substantially and does not eliminate the attack.
Aggregated external feeds
Multiple independent reporters submitting prices with a median taken.
Which is the approach most substantial protocols adopted.
Staleness checks and deviation limits are necessary complements.
Illiquid assets
Protocols accepting thinly traded assets as collateral remain exposed regardless of oracle design.
Which is a listing decision rather than a technical one.
Several incidents followed the addition of an illiquid asset to a lending market.
The economic security question
What it costs to move a price sufficiently, against what can be extracted.
Which is calculable in advance from pool depth and position limits.
Protocols that performed that calculation before launch generally avoided this category entirely.
The pattern
These were economic design failures rather than code defects, which is why audits did not catch them.
This is historical analysis rather than advice.
Specific incident patterns
Borrow against inflated collateral, or repay a debt at a deflated valuation.
Which are the two basic profit routes.
Both require the protocol to accept a manipulable price for a position it will act on.
Governance token manipulation
The same technique applied to acquire voting power temporarily.
Which produced governance attacks alongside price manipulation.
Snapshot-based voting addresses this specific vector.
Cross-protocol dependencies
A protocol reading another protocol's price inherits that protocol's manipulability.
Which produced incidents where the exploited protocol had done nothing wrong itself.
Dependency mapping is now part of serious protocol risk assessment.
Post-mortem quality
Detailed public analyses were published after most of these incidents.
Which built shared understanding across the field quickly.
The category declined substantially as the standard mitigations spread.
Where the risk remains
Newly listed illiquid assets and protocols on smaller networks with thin markets.
Insurance fund depletion
Protocols absorbing losses from these attacks depleted reserves.
Which left them exposed to subsequent incidents.
Reserve adequacy relative to value at risk is a checkable figure.
Response quality
Protocols publishing detailed post-mortems contributed to shared understanding.
Which accelerated adoption of mitigations across the field.
The category has declined substantially as a proportion of incidents since.
The economic security framing
Treating manipulation cost against extractable value as a design parameter.
Which is now standard in serious protocol design.
Position limits relative to pool depth are the practical control.
Newer networks
Thin markets and immature oracle infrastructure reproduce the conditions.
Which is why the same attacks appear on newer chains.
What a user can check
What price source a protocol uses, whether it checks staleness, and how deep the market for the collateral actually is.
Why it still matters
These were not code defects. The contracts executed exactly as written, against a price that was true at the moment it was read and false in every meaningful sense.
That distinction — between correct code and correct design — is where most remaining risk in the field sits.
Reading the primary material
Published post-mortems set out the exact transaction sequences.
Which makes the mechanism concrete rather than abstract.
Reading two or three makes the pattern recognisable in advance.
The design question
What would it cost to move the price this protocol reads, and what could be extracted if someone did.
Where the category stands now
Incident frequency has declined substantially on established networks as mitigations spread.
Which demonstrates that this class of failure was solvable rather than inherent.
It continues to appear on newer chains with thin markets and immature oracle infrastructure.
The one sentence version
Correct code acting on a manipulable price is a design failure, not a bug, which is why audits did not catch it.
A note on why this category declined
Detailed public post-mortems circulated quickly, the mitigations were straightforward, and standard oracle infrastructure became widely available.
That combination of shared information and available tooling is what closed the category on established networks.
The checkable version
What price source does this protocol read, does it check for staleness, and how deep is the market for the collateral it accepts.
Three questions answerable from documentation and chain data.