KelpDAO Audit Passed. $292M Left Anyway.

What it is

Runtime Verification's analysis of the April 2026 KelpDAO exploit, proposing "formal modeling" — a structured trust-assumption methodology — as the gap-filler between smart-contract audits and off-chain infrastructure risk. The piece also references a companion post-mortem from Blockaid with the technical exploit breakdown, and briefly contrasts the attack with the April 2026 Drift Protocol exploit ($285M, multi-week multisig social engineering).

How it works

Formal modeling means writing down, before deployment: every principal the system trusts (including off-chain components like DVNs), every property the system is supposed to guarantee, and every way those properties fail if a given principal is compromised. Applied retroactively to KelpDAO, the method would have forced the DVN to be modeled as a named trust principal rather than invisible plumbing, surfaced the question "what happens if this DVN is compromised," and traced the consequence chain through to full escrow drainage and same-block Aave extraction — producing a risk map rather than a pass/fail audit result.

flowchart TD
    A[Smart contract audit] -->|covers| B[On-chain code]
    A -.->|does not cover| C[Off-chain trust config]
    C --> D[DVN compromised]
    D --> E{DVN redundancy?}
    E -->|1-of-1, no| F[Forged message accepted]
    E -->|N-of-M, yes| G[Attack blocked]
    F --> H{Collateral circuit-breaker?}
    H -->|none| I[Instant Aave borrow, unrecoverable]
    H -->|present| J[Extraction slowed/halted]

Preconditions / Affected

Applies to any protocol where a cross-chain bridge or messaging layer (e.g., LayerZero OFTAdapter-style pathways) has: a low/no-redundancy off-chain verifier set (the piece cites KelpDAO's specific requiredDVNCount=1, optionalDVNCount=0), and downstream lending/collateral integrations (e.g., Aave-style markets) that accept the bridged asset without deposit-size circuit-breakers.

What to do

The piece names two concrete levers a formal model would surface for prioritization: (1) validator/DVN redundancy — require multiple independent DVNs to attest before a cross-chain message executes; (2) circuit-breakers — caps or throttles on collateral acceptance (on the OFTAdapter and/or on lending-protocol deposit size) so a forged-message extraction can't settle in a single block. No code, config syntax, or specific redundancy threshold is given beyond "multiple independent DVNs."

Caveats

This is a methodology pitch, not a verified framework with published results — Runtime Verification states the approach "doesn't guarantee safety," only visibility, and the full technical exploit mechanics are deferred to Blockaid's separate post-mortem rather than detailed here.