Kelp DAO
Lazarus Group, the North Korean state-sponsored hacking unit, drained $292 million from KelpDAO's cross-chain bridge in a single transaction. The bridge used LayerZero for cross-chain messaging, but Kelp had configured it to trust just one verifier, LayerZero Labs' own. The attackers compromised the developer credentials for that verifier, then made the bridge believe a fake withdrawal was legitimate. About 18% of all rsETH in circulation moved to the attackers in a single block.
Our pre-hack assessment flagged Kelp's cross-chain messaging trust assumptions and supply-chain exposure as the protocol's weakest layers. Both failed at once: a single trusted verifier was compromised through its developer credentials.
The attackers compromised the verifier's developer credentials, signed off a fake withdrawal as if it were legitimate cross-chain traffic, and drained the bridge totheir primary addressin a single block.
Full forensic detail
Step-by-step reconstruction, root cause, counterfactuals, remediation, and disclosure timeline.
Exploit anatomy
Aave V3/V4 supply() + borrow()Root cause
Two failures combined here. First, KelpDAO's rsETH OFT adapter ran a 1-of-1 DVN setup. Only LayerZero Labs' single verifier needed to attest to cross-chain messages. No independent second validator existed. Single point of failure in the trust model. Second, the attacker compromised the upstream RPC infrastructure feeding that sole verifier via social engineering and binary replacement. The DVN then signed valid attestations for fabricated messages. Every on-chain transaction appeared cryptographically valid. The validator's signature was valid. The message format was valid. The corruption happened at the data layer beneath the verification logic. The system needed cross-chain invariant monitoring to detect the attack (verifying that token burns on the source chain actually occurred). No such monitoring existed. At the time, 40-47% of LayerZero OApps used the same 1-of-1 configuration. LayerZero's own V2 OApp Quickstart documentation showed sample code wiring pathways with one required DVN and no optional DVNs.
// KelpDAO rsETH OFT adapter DVN configuration (reconstructed) requiredDVNs: [LayerZero Labs DVN] requiredDVNCount: 1 optionalDVNs: [] optionalDVNCount: 0 // Single attestation from LayerZero Labs DVN was sufficient // to authorize release of any amount of rsETH on destination chain
Prevention analysis
Attack prevented outright. A second independent DVN would have rejected the forged attestation. No corresponding burn existed on any source chain. LayerZero recommended multi-DVN configurations but didn't enforce them.
Attack detected in real-time. A monitor verifying source-chain burns against destination-chain releases would have flagged the phantom burn immediately. No such system was running.
Partial mitigation only. A per-transaction or per-epoch cap on rsETH releases would have capped the drain well below 116,500 tokens, buying time for manual intervention.
Infrastructure compromise caught earlier. Hardware attestation or canary queries to RPC nodes would have revealed the binary replacement within hours, not weeks.
Similar incidents
40-47% of LayerZero OApps used identical 1-of-1 DVN configuration at time of exploit
Same threat actor (TraderTraitor/UNC4899). Infrastructure-level compromise of off-chain signing systems rather than smart contract vulnerability. Social engineering initial access vector.
Bridge validator compromise by Lazarus Group. Insufficient validator threshold (5-of-9 compromised). Social engineering initial access.
Cross-chain bridge exploit resulting in unauthorized token minting on destination chain, though Wormhole was a smart contract vulnerability rather than infrastructure compromise.
Remediation
Timeline
Get your protocol scored across 12 dimensions, or request ongoing coverage.