Damn Vulnerable DeFi — Challenge #1 Unstoppable (high-level)

Educational challenge: a lender holds a large DVT balance and offers free flash loans. Lab goal: stop the pool from offering flash loans (availability failure), starting from a small DVT balance.

Vulnerability class / root cause

• Internal accounting variable poolBalance is updated only along the depositTokens path.
• flashLoan uses a hard assert(poolBalance == token.balanceOf(pool)) (or equivalent) before lending.
• ERC-20 tokens can still arrive via plain transfer, increasing the real token balance without updating poolBalance.
• That desync trips the assert and halts flash loans (denial of service). Related taxonomy often cited: unexpected ether/token balance assumptions (SWC-132-style thinking).

Impact (abstract)

Flash-loan functionality becomes permanently (or until manual rescue) unavailable—protocol liveness failure, not necessarily direct theft of the million tokens.

Mitigations / lessons

• Do not assert on balances that third parties can nudge; prefer graceful errors or accounting that ignores unsolicited transfers.
• Track deposits only via explicit deposit APIs; treat direct transfers as donations that must not break invariants—or reject them.
• Avoid assert-for-input-validation (assert may consume remaining gas / be treated as invariant, depending on toolchain era).
• Monitor for stuck lending paused states after unexpected ERC-20 receipts.

Solve steps and PoC omitted.