/web3-audit

name: web3-audit
description: Smart contract security audit — 10 DeFi bug classes (accounting desync, access control, incomplete path, off-by-one, oracle, ERC4626, reentrancy, flash loan, signature replay, proxy), pre-dive kill signals (TVL < $500K etc), Foundry PoC template, grep patterns for each class, and real Immunefi paid examples. Use for any Solidity/Rust contract audit or when deciding whether a DeFi target is worth hunting.

WEB3 SMART CONTRACT AUDIT

10 bug classes. Pre-dive kill signals. Foundry PoC template. Real paid examples.

See also: [[Smart Contract Audit]], [[Trust Map]], [[Methodology]], [[A→B Chains]], [[Web3 Bug Classes]], [[Web3 Grep Arsenal]], [[Web3 POC Foundry]], [[Web3 Triage Report]], [[Web3 Hunt Foundation]], [[Code Sleuth]], [[Fizz]], [[Pashov Solidity Auditor]], [[Pashov X-Ray]], [[Lead Ledger]], [[Triage]], [[Report Writing]]

---

PRE-DIVE KILL SIGNALS (check BEFORE any code review)

> ZKsync lesson: $322M TVL + OZ audit + 750K LOC + 5 sessions = 0 findings. Large well-audited bridges are extremely hard.

1. **TVL < $500K** → max payout capped too low for effort 2. **2+ top-tier audits** (Halborn, ToB, Cyfrin, OpenZeppelin) on simple protocol → bugs already found 3. **Protocol < 500 lines, single A→B→C flow** → minimal attack surface 4. **Formula**: `max_realistic_payout = min(10% × TVL, program_cap)` — if < $10K, skip

**Soft kill:** OZ/ToB/Cyfrin audit on current version + codebase > 500K LOC → expect 40+ hours for maybe 1 finding. Only proceed if bounty floor > $50K AND you have protocol-specific expertise.

**Target scoring (go if >= 6/10):**

• TVL > $10M: +2
• Immunefi program with Critical >= $50K: +2
• No top-tier audit on current version: +2
• < 30 days since deploy: +1
• Protocol you've hunted before: +1
• Source code + natspec comments: +1
• Upgradeable proxies: +1

---

THE ONE RULE

> "Read ALL sibling functions. If `vote()` has a modifier, check `poke()`, `reset()`, `harvest()`. The missing modifier on the sibling IS the bug."

This single rule explains 19% of all Critical findings.

---

5-LAYER REASONING — WHERE THE CRITICALS ACTUALLY LIVE

The criticals on audited code are rarely in the code. Rank effort by where bugs live:

**Layer 1 — Deployment config, not contract code (biggest source of criticals on audited code).** The invariant is enforced in Solidity but violated at deploy time:

• Rate provider / oracle pointed at a manipulatable spot price (Curve pool, short-window Uniswap TWAP, Balancer pool) instead of Chainlink → exchange rate manipulation → share-price theft
• Decimal mismatch: rate provider returns 6 decimals where the accountant assumes 18 (10^12 error); scaling helpers only scale if `inputDecimals`/`outputDecimals` are set at deploy
• Ownership not actually renounced (`transferOwnership(address(0))` skipped), or `STRATEGIST_ROLE` held by a hot EOA
• Two vaults sharing one accountant; a `manageRoot` computed against a stale decoder
• **You CANNOT see this from source. It needs the live addresses + mainnet RPC.**

**Layer 2 — Fork mainnet and run invariant fuzzers.** Simulate the state machine against live state (Foundry fork tests + `invariant_` fuzzing):

• `totalAssets() == Σ(balances valued via getRate())` — break this → mint/drain
• Share price monotonicity across deposit/withdraw/vest/postLoss sequences
• First-depositor / donation inflation: `mulDivDown(ONE_SHARE, getRate())`; donation or `claimFees` timing that shifts `getRate()` between enter and exit = repeatable-loss critical

**Layer 3 — The integration layer, not the target.** Real tokens with real quirks; a decoder correct for the "canonical" ABI is wrong for the deployed variant:

• stETH / rebasing / fee-on-transfer / 18-vs-6 tokens where a balance read or transfer assumption breaks
• A proxy token with different `decimals()`, or a `beforeTokenTransfer` hook that re-enters
• Read-only reentrancy via `getRate()` reading an external contract manipulatable in the same tx

**Layer 4 — Chase new deployments and upgrades.** The newly added, unaudited contract is where the critical lives (tellers/decoders/adapters). A hardened adapter (bounds added post-finding) means the NEXT one won't be. Watch the deployer for fresh contracts; audit before the program updates scope.

**Layer 5 — Chain a medium into a critical.** 1-wei accounting drift or a rounding direction in `mulDivDown` compounded over N deposits = extractable loss.

**The uncomfortable truth:** if the audited code is sound, the critical is at Layer 1 (config/oracle targets) or Layer 2 (fork-fuzzing `getRate()` against a manipulatable feed) — both need live chain access, not more file reads. When file reads run dry: request deployment addresses + RPC, fork, and fuzz.

---

1. ACCOUNTING STATE DESYNCHRONIZATION

> #1 Critical bug class — 28% of all Criticals on Immunefi.

What It Is

Two state variables supposed to stay in sync. One code path updates A but forgets B. Later code reads both and makes decisions based on stale B.

Real Value = A - B
If A updated but B isn't → Real Value appears larger → phantom value

Root Cause Patterns

**Variant 1: Phantom Yield** (Yeet protocol — 35 duplicate reports)

function startUnstake(uint256 amount) external {
    totalSupply -= amount;  // decremented BEFORE transfer
    // aToken.balanceOf(this) still reflects old value
    // yieldAmount = aToken.balanceOf - totalSupply = phantom yield
}

**Variant 2: Fast Path Skips State Update** (Alchemix V3)

function claimRedemption(uint256 tokenId) external {
    if (transmuter.balance >= amount) {
        transmuter.transfer(user, amount);
        _burn(tokenId);
        return;  // EARLY RETURN — cumulativeEarmarked, _redemptionWeight, totalDebt never updated
    }
    // Slow path: updates all state vars correctly
    alchemist.redeem(...);
}

**Variant 3: Update Happens in Wrong Order** (Alchemix)

function deposit(uint256 amount) external {
    _sha