In April, KelpDAO's rsETH bridge was hacked for 116,500 rsETH (about $292M). The attacker got the Ethereum side to release the funds against a burn on Unichain that never happened. Nobody stole a signing key. The bridge's verifier checked the source chain the way almost every bridge, indexer, and oracle does today, by asking an RPC node what happened, and the RPC node lied to it. This post walks through how that worked, why the verifier was doing its job exactly as designed when it signed off, and what changes when the verifier checks a proof instead of a report.
What happened
KelpDAO's rsETH moves between chains over LayerZero. When rsETH leaves Unichain for Ethereum, it's burned on Unichain, and a message saying "116,500 rsETH was burned, release it on Ethereum" travels to the Ethereum side. The part of LayerZero that vouches for that message is called a DVN (a Decentralized Verifier Network), which is basically a set of nodes that read the source chain and sign a statement that the message really was sent. Each application picks which DVNs it requires. KelpDAO's configuration required exactly one, LayerZero Labs' own.
The attack started on March 6, a month and a half before any money moved. The attacker (LayerZero attributes it to Lazarus) socially engineered a LayerZero developer, got hold of session keys, and used them to get into the cloud environment that runs LayerZero's RPC nodes. Two of the internal nodes the DVN read Unichain through had their node software swapped for a patched version. The patched nodes answered honestly to everyone, including LayerZero's monitoring, and served forged responses only to the DVN's IP addresses.
On April 18 the attacker launched a denial-of-service attack against the external RPC provider the DVN also used. With that path down, the DVN failed over to the only nodes it could still reach, the two poisoned ones. Those nodes reported a Unichain block containing a burn of 116,500 rsETH. The DVN signed the message, the Ethereum endpoint checked that the signed hash matched the payload, and the adapter released the tokens. Within about 46 minutes the rsETH was posted as collateral on Aave, around 82,650 WETH was borrowed against it, and most of it was on its way to Bitcoin through THORChain inside 36 hours.
The burn was fabricated from top to bottom. Unichain's outbound message counter had never gone past 307, and the forged message was number 308. The whole rsETH supply on Unichain at the time was 49.26 rsETH. There was never enough there to burn. After the funds moved, the patched binaries deleted themselves along with their logs.
Where the lie got in
The attacker never had the DVN's signing keys. The DVN signed exactly what it was supposed to sign, an attestation that this burn occurred on the source chain as the DVN saw it, and the signature was genuine. What was wrong was the DVN's picture of Unichain, which came from an RPC node, and nothing in the system could tell a true picture from a false one.
That's the same trust relationship almost everything in crypto has with the chain. Indexers, oracle committees, and bridge verifiers all read the chain through a node and pass along what they read, so the consumer ends up trusting the reader, the reader ends up trusting its node, and the node is a piece of software running on somebody's server. Ethereum itself is built so that every piece of data on it can be verified, but that guarantee ends at the node's API. Once the answer comes back as JSON, it's just an assertion.
LayerZero's fix was to stop signing as the sole verifier on any channel, so that two independent DVNs would have to be fooled at once. That does make the attack harder. It doesn't change what a DVN is, which is an honest reporter of whatever its node tells it.
What a proof changes
Unichain is an OP Stack rollup, which means it posts its blocks and state roots to Ethereum. Anything that really happened on Unichain is committed to, on Ethereum, by Unichain itself. A burn that never happened isn't.
That commitment is what our proofs are anchored to. Instead of a signed report that an event occurred, we produce a zero-knowledge proof that a specific set of events is in a specific window of the source chain's blocks, and that those blocks are the real ones, by recomputing the root the source chain committed on Ethereum. The Ethereum contract that consumes the proof checks it against that committed root directly. It never talks to an RPC node, and it doesn't care who ran the prover. The prover can be fed lies by a poisoned node too, and it can even try to prove them, but a proof about a block that Unichain never committed won't verify. There's no version of the KelpDAO attack that gets past that check, because the burn was never in any real Unichain block and the proof can only be built from real ones.
Two properties matter for a bridge here. The first is inclusion: this burn is really in this block, and the block is really part of the chain. That's the check the DVN was standing in for, and it's the one that would have stopped April 18. The second is the emitting contract. Our proofs are over a declared filter, which pins the contract address and event signature, so a burn from a look-alike rsETH contract on Unichain wouldn't pass either. On top of those two, Willow proves completeness, meaning that no matching event in the window was left out, which is what a bridge needs when it's settling a batch rather than a single message.
We've already run this construction across a chain. Recently a contract on Ethereum mainnet verified a proof that a window of Base blocks had been indexed completely and correctly, anchored to the root Base finalized on Ethereum, for about $0.25 in gas. Unichain is the same kind of chain as Base, so the same proof runs on it. The tradeoff is that a proof anchored to a finalized root inherits the rollup's finality delay, which is the same delay a native withdrawal has today.
The wider pattern
The class of attack KelpDAO belongs to is narrow. DefiLlama catalogues roughly 600 exploits, and the large majority are stolen keys, manipulated prices, or plain bugs in application contracts. A proof of what a chain did does nothing for those. The class where it helps is specific: a system acted on a claim about a source chain, and the claim was false. In that class the losses have been large.
Nomad lost $190M in August 2022. A routine upgrade initialized the bridge's trusted root to zero, which happened to be the value for "not yet proven," so every message counted as proven. People copied the first attacker's transaction, swapped in their own address, and drained the bridge in hundreds of copycat withdrawals.
BNB Chain's Token Hub was drained in October 2022. The bridge's Merkle proof verifier (Cosmos's IAVL library) didn't check that a node in the range proof had no right child, so the attacker forged a proof and minted 2 million BNB, about $570M at the time. Validators halted the chain within about 90 minutes and froze most of it, but over $100M had already been bridged out.
Hyperbridge was hit in April 2026. The verifier for its Merkle Mountain Range proofs was missing a bounds check on the leaf index, which let a forged proof through and minted a billion bridged DOT. The attacker only got about $237K out before the gateway was paused.
These three had an actual bug. Each verifier was supposed to check a proof and checked it wrong, and two of them were Merkle proof verifiers, so checking proofs doesn't by itself make a verifier safe. The verifier is code and it has to be right. What's different is the shape of the target. A verifier is a fixed piece of code with a fixed statement it accepts, and you can audit it, fuzz it, and formally verify it once. A fleet of RPC nodes has to be kept honest every day, against an adversary who has been inside your cloud for six weeks.
KelpDAO is the one with no bug at all. The DVN worked as designed, and the design was to believe a node.
Where Willow is today
Willow is the first cryptographically verifiable blockchain indexer. We index a chain's blocks and hand back a proof that the data is correct and complete, which a contract on Ethereum can verify before it acts. Proofs of Ethereum and Base activity have both verified on mainnet, and the same construction extends to any chain that commits its state to Ethereum.
If you're building a bridge, or anything else that moves money based on what another chain did, and you'd rather verify that data than trust whoever reported it, we'd love to hear from you at [email protected].
Sources: LayerZero Labs incident report · Chainalysis · rekt.news · Nomad hack analysis (Immunefi) · BSC Token Hub analysis (Coinbase) · Hyperbridge post-mortem