The $292M bridge release that no burn ever backed

On 18 April 2026, KelpDAO's LayerZero-based bridge released roughly 116,500 rsETH, about $292 million, to an attacker-controlled address. Every transaction involved in that release was valid. The bridge received a well-formed cross-chain message, verification passed, and the destination contract executed exactly what it was written to do. The problem was that the event which should have justified the release had never happened.

The failure happened outside the contract

There was no reentrancy, no missing access control, no arithmetic bug. Attackers compromised two internal RPC nodes used by the LayerZero DVN and disrupted an external RPC provider at the same time, which forced the verifier onto infrastructure they controlled. The DVN then asked those nodes what had happened on the source chain and was told that 116,500 rsETH had been burned. No such burn existed.

Because the bridge ran a 1-of-1 DVN configuration, that single manipulated answer was enough for the cross-chain message to be accepted. The destination chain received what looked like a fully verified instruction and paid out against it.

The sequence

• RPC compromise: two internal DVN nodes taken over and an external provider disrupted, forcing verification onto attacker-controlled infrastructure
• Phantom burn: manipulated chain data reports 116,500 rsETH burned on the source chain, with no matching burn transaction anywhere
• Verification passes: the 1-of-1 DVN setup accepts the forged observation and the message is signed off
• Release: the Ethereum-side bridge contract sends roughly 116,500 rsETH, about $292 million, to the attacker
• Follow-on attempt: a second forged packet targeting a further 40,000 rsETH, around $95 million, stopped by rapid intervention

Why a transaction-level monitor sees nothing

Read the Ethereum transaction on its own and there is nothing to flag. It contained a valid bridge interaction, a well-formed cross-chain message, verification that completed successfully, contract execution exactly as designed, and an asset transfer that looks like every other legitimate withdrawal.

A conventional monitoring stack examining that transaction in isolation would clear it. The anomaly did not live inside the transaction. It lived between two chains, in the gap between what the destination paid out and what the source had ever authorised.

The invariant that broke

Every bridge rests on one accounting relationship: assets released on the destination chain must be less than or equal to assets burned or locked on the source chain. That relationship is not a heuristic or a risk score. It either holds or it does not.

Reconstructing the incident against that check makes the failure immediate:

• Source-chain rsETH burn: 116,500 expected, 0 observed
• Destination-chain rsETH release: 116,500 expected, 116,500 observed
• Matching source event: required, not found
• Cross-chain state: consistent expected, inconsistent observed

One side of the ledger moved. The other never did.

How the reconstruction works

The approach is not to ask whether a transaction is malicious. It is to ask whether the transaction makes sense against the state and events on the other chain. That runs in layers:

• Bridge release monitoring: significant outflows from bridge contracts surfaced as high-impact events
• Cross-chain event reconciliation: destination-chain releases matched against the corresponding source-chain burn or lock
• Invariant validation: the released amount checked against the expected source-chain state transition
• Missing-event detection: a release with no findable source burn or lock treated as a cross-chain integrity violation
• Attack-flow correlation: bridge event, asset movement, destination address, and surrounding activity combined into a severity decision

Reduced to its trigger condition the rule is short. A destination release greater than zero with a matching source burn of zero is a cross-chain invariant violation, severity critical. It is built to catch releases backed by a source event that does not exist, has not occurred, or cannot be independently verified.

What this class of attack teaches

The attacker did not need a smart-contract vulnerability. No reentrancy, no missing access control, no oracle manipulation, no arithmetic overflow, no unauthorised execution. They manipulated the trust layer used to establish cross-chain state, and the destination contract did precisely what it was programmed to do. That makes it a system-state failure, not a transaction-level one.

The same reasoning covers a wider class of incidents: phantom burn and phantom mint attacks, unbacked asset releases, bridge accounting inconsistencies, forged cross-chain messages, source-to-destination state mismatches, and compromised verification-layer activity. In each case the individual transactions can be flawless while the overall system state is impossible.

This case study is based on publicly available information about the KelpDAO bridge incident. The detection described here is a retrospective reconstruction of publicly observable on-chain activity and should not be read as a claim that Chain Monitor was deployed on KelpDAO at the time of the original incident.