hunting-defi-economic-and-oracle-flaws

name	hunting-defi-economic-and-oracle-flaws
description	Hunt a decentralized-finance protocol for a way to profit by moving a price or breaking an economic invariant, rather than by defeating an access check or re-entering. Covers a price read from a spot source an attacker can move within a transaction, a manipulable oracle or a single-source feed with no sanity bound, a swap or liquidation that trusts a pool ratio a flash loan can skew, rounding or fee-accounting that a repeated interaction drains, share or collateral math that lets a first or precise depositor steal value, and a slippage or deadline parameter left unchecked. Use when the fix is an economic or pricing safeguard (a manipulation-resistant oracle, a bound, corrected math), not an authorization check or a reentrancy guard. The manipulable price or invariant is the source, the value the attacker extracts is the sink, and a value decision that trusts a movable input is the bug.
license	MIT

Hunting DeFi economic and oracle flaws: profiting by moving a price nobody bounded

Some of the most valuable protocol bugs break no access check and re-enter nothing: they move a price or exploit accounting math to extract value through actions the protocol permits. A contract reads a spot price a flash loan can swing inside one transaction, trusts a pool ratio an attacker sets, or rounds a fee in a direction a repeated call drains. This hunt is about the economic layer, the values a protocol trusts and the invariants it assumes hold. It is distinct from access control (nothing here requires a missing gate) and from reentrancy (nothing here requires re-entry); if the fix is a manipulation-resistant oracle, a sanity bound, or corrected math, it is an economic flaw and belongs here. The discipline in a crowded field is proving the manipulation is profitable after costs, not just that a price can move.

When to use

• A protocol reads a price, a pool ratio, or a share value to make a swap, loan, or liquidation decision.
• Fee, rounding, or share math runs on values an attacker can influence within a transaction.
• You want to know whether an attacker can profit by moving a price or breaking an accounting invariant.

Scope check

Analyze only protocols you own or are authorized to assess, and simulate an economic exploit only on a fork or test network, a manipulation here extracts real value from real liquidity providers. Prove profitability on a fork. If you can't name the authorization, stop.

The loop

1. Find the value decisions and their inputs first. List the points where the protocol reads a price, a ratio, or a share value to move funds (a swap, a loan, a liquidation, a mint or redeem), and for each trace the input it trusts and whether an attacker can move that input within a transaction. The economic bug lives at a value decision that trusts a movable input; establish those before anything else.

2. Check the price source. Look for a price read from a spot source an attacker can move in the same transaction (a single pool's instantaneous ratio), a single-source oracle with no sanity bound or staleness check, or a feed that can be pushed outside a sane range without the protocol noticing.

3. Check flash-loan-amplified manipulation. Look for a decision that trusts a pool ratio or a balance an attacker can skew with borrowed capital for one transaction, swinging a price, a collateral valuation, or a liquidation threshold, then unwinding, so the attacker needs no capital of their own.

4. Check accounting, rounding, and share math. Look for a fee or reward computation that rounds in a direction a repeated interaction accumulates, share or collateral math that misprices the first or a precisely sized deposit, and an invariant (total shares versus total assets, debt versus collateral) that a sequence of permitted actions can break.

5. Check slippage and deadline protection. Look for a swap or trade that accepts an unchecked minimum output or an absent deadline, letting a sandwich or a delayed execution extract value the user did not agree to.

6. Confirm and record. Confirm by simulating the manipulation on a fork and showing a net profit after the cost of moving the price, the flash-loan fee, and gas. Kill the lead if the price comes from a manipulation-resistant source (a time-averaged or multi-source oracle with sanity and staleness bounds), if the decision already bounds or sanity-checks the value, if the rounding favors the protocol or the dust is economically negligible, if a share-inflation vector is closed (a minimum initial deposit, a dead-share mint, virtual offsets), if slippage and deadline are enforced, or if the manipulation costs more than it yields at realistic liquidity. Record the value decision, the movable input, and the profit path.

Where economic flaws leak

• The bug is a value decision trusting a movable input. No gate is missing and nothing re-enters; the finding is a price or ratio the protocol trusts that an attacker can move, so start at the decision.
• Spot price is manipulable by construction. An instantaneous single-pool ratio moves within a transaction; reading it for a value decision is the flaw, not an edge case.
• A flash loan removes the capital barrier. Any manipulation that needs only single-transaction capital is in reach; do not dismiss a price swing as too expensive without pricing the flash loan.
• Rounding in the wrong direction compounds. A fee or share computation that rounds toward the caller is drained by repetition even when each increment looks negligible.
• Profitability is the proof, not possibility. A price that can move is a lead; the finding is a net profit after manipulation cost, flash-loan fee, and gas at realistic liquidity.

Worked example (a confirm and a kill)

Confirm. A lending market values collateral using the spot ratio of a single pool; an attacker takes a flash loan, swings that pool to inflate their collateral's apparent value, borrows against the inflated valuation, and repays the loan, leaving the market with bad debt. A fork simulation shows a net profit after fees and gas. Confirmed oracle manipulation via a spot-price collateral valuation, critical, remediation = value collateral with a manipulation-resistant, time-averaged, multi-source oracle with sanity and staleness bounds.

Kill. A protocol reads a price that looks spot, but it comes from a time-averaged oracle over a window long enough that a single-transaction swing barely moves it, with a staleness check and a sanity bound rejecting outliers; a fork attempt to move the effective price nets a loss after the cost of holding the swing. Killed, kill_reason = "the price is a bounded time-averaged multi-source feed, so single-transaction manipulation is not profitable after cost."

Rationalizations to reject

• "The price comes from a real pool." -> A single pool's spot ratio is movable within a transaction; a real pool is exactly what a flash loan swings. The source's manipulation resistance is what matters.
• "Manipulating it would cost too much." -> Priced with a flash loan? Single-transaction capital is cheap; compute the cost against the yield before dismissing it.
• "The rounding is off by a tiny amount." -> In which direction, and can it be repeated? Rounding toward the caller is drained by repetition regardless of the per-call size.
• "The first deposit is an edge case." -> First-depositor and precise-deposit share math is a known value-theft vector; confirm a minimum deposit, dead shares, or virtual offsets close it.
• "The swap has slippage protection." -> Is a real minimum output enforced and a deadline set? An unchecked minimum or absent deadline is a sandwich vector.

Executing this in practice

You need the value decisions (swaps, loans, liquidations, mints, redeems), the price, ratio, and share inputs each trusts and whether an attacker can move them in a transaction, the oracle sources and their bounds, the fee, rounding, and share math, and the slippage and deadline handling. For each decision, simulate whether moving the input yields a net profit after cost on a fork. Reading the code tells you which input is trusted; the fork simulation tells you whether manipulating it pays.

Related

• hunting-smart-contract-reentrancy - the sibling for control-flow re-entry, including a read-only reentrancy that feeds a mid-transaction value into a pricing decision this skill then adjudicates.
• auditing-smart-contract-access-control - the sibling for missing or defeated gates; a privileged parameter setter reachable by the wrong caller that skews pricing starts there and lands here.
• hunting-business-logic-flaws - the general analogue: extracting value through permitted actions in an unintended sequence, of which economic manipulation is the on-chain form.
• FINDING-SCHEMA.md - source = the manipulable price or invariant, sink = the value the attacker extracts, evidence = a fork simulation showing net profit after manipulation cost.