Evercrest Technologies, the company behind KelpDAO, has sued LayerZero Labs, its Canadian affiliate, and CEO Bryan Pellegrino in British Columbia over April’s $292 million rsETH exploit.
The claim alleges negligent misrepresentation, negligence and defamation, seeks aggravated and punitive damages, and says Kelp users have withdrawn more than $650 million since the attack.
Pellegrino has called the suit meritless. By Aug. 4, projects tied to roughly $14.5 billion in assets had announced moves from LayerZero to Chainlink’s CCIP, nearly 50 times the amount stolen.
The lawsuit now asks a court to settle a responsibility dispute that customers have been pricing on their own since April.
Two failures had to line up
On April 18, attackers tricked LayerZero’s verifier into approving a forged cross-chain transfer. LayerZero’s incident report traces the intrusion to a developer who was socially engineered into cloning a malicious GitHub repository in March.
The attackers reached LayerZero’s RPC environment, poisoned two internal nodes, and knocked an external RPC provider offline, so the verifier signed a message built on false source-chain data and 116,500 rsETH left Kelp’s bridge.
That compromise succeeded because Kelp’s bridge required approval from a single verifier, LayerZero’s own, leaving one party able to authorize the release. The on-chain signature check worked as designed, since the signature was valid and simply attested to false information.
LayerZero’s report splits the blame accordingly, assigning the number of required verifiers to the application and the compromised RPC layer to LayerZero as its operator.
| Security layer | What was supposed to happen | What failed | Who controlled that layer |
|---|---|---|---|
| Verifier count | Multiple independent verifiers could reject a bad message | Kelp required only LayerZero’s verifier | Application / Kelp |
| RPC data | Verifier receives accurate source-chain state | Attackers poisoned LayerZero-operated RPC infrastructure | LayerZero |
| Independent check | A second verifier could disagree with false data | No second required verifier existed | Application configuration |
| Signature generation | Verifier signs only valid source-chain events | LayerZero’s verifier signed false data | LayerZero-operated verifier |
| On-chain contract | Accept valid signatures from configured verifier set | Worked exactly as configured | Smart contract logic |
Kelp’s claim targets what happened to LayerZero before the hack
Evercrest alleges LayerZero reviewed and approved the single-verifier setup in writing, including telling Kelp in February 2024 there was “no problem” with a default configuration.
The suit also alleges LayerZero warned another developer, USDT0, about risks in default verifier configurations while withholding a comparable warning from Kelp.
Those allegations have yet to be tested in court. LayerZero’s account puts the choice on Kelp, saying the application had previously used a two-of-two configuration and moved to one-of-one.
LayerZero’s verifier now refuses to sign on any channel where it’s the only required signer, and the company requires multiple independent RPC sources across providers and geographies.
By Aug. 4, it had moved default pathways on both versions of its endpoint to a minimum of three verifiers, while applications can still build custom setups at the protocol level.
LayerZero also said in May that letting its own verifier act alone on high-value transfers had been a mistake, and it maintained the incident touched about 0.14% of the applications on its network.
LayerZero customers moved faster than the courts
BitGo accounted for the largest migration, with WBTC making up about $7.4 billion of the Aug. 4 tally, and it named CCIP its exclusive cross-chain provider for WBTC and the default for future BitGo-issued assets.
Mantle, Kelp’s rsETH and Lombard added billions more, and Chainlink puts the total near $15 billion. Kelp says its own migration remains underway, so announced value and completed transfers are separate measures.
| Milestone | Associated asset value | Relative to $292M exploit | What it represents |
|---|---|---|---|
| Kelp exploit | $292M | 1.0Ă | Approximate value stolen |
| Early migration wave, May | >$3B | >10Ă | Projects announcing moves toward Chainlink |
| Migration wave, July | >$7B | >24Ă | Broader group of assets/projects changing infrastructure |
| Aug. 4 tally | ~$14.5B | ~49.7Ă | Associated asset value of announced LayerZero-to-Chainlink migrations |
| WBTC alone | ~$7.4B | ~25Ă | Largest single asset in Aug. 4 tally |
Wyoming’s Stable Token Commission fully moved its FRNT state-issued token off LayerZero in August and signed a multi-year deal making CCIP its exclusive cross-chain provider.
Commission CISO Keith Lawhorn said Sept. 14 that the review began because of the Kelp attack and found problems with access controls, private key management, and incident disclosures, findings LayerZero has partly disputed.
The standard he described was infrastructure that is secure by default, with safeguards built into the product for a public issuer to rely on.
A responsibility gap that reaches past bridges
Kelp chose how many verifiers its bridge required, and LayerZero ran the infrastructure its only verifier depended on. Each party controlled a layer that failed, and the smart contract accepted the configuration both had allowed.
The same arrangement appears wherever an automated protocol depends on an identifiable company for oracles, custody, cloud hosting, or sequencing, since smart contracts turn whatever those services attest into irreversible outcomes.
A self-service provider can argue that a customer picked its own settings from the tools on offer. Kelp’s allegation describes a provider that reviewed a client’s architecture, called it acceptable, and operated the component that later broke, a harder position to defend if the allegations hold up.
LayerZero remains a large network, spanning 96 chains and $9.5 billion in bridged volume for the past 30 days, according to DefiLlama.
| Infrastructure model | Customer controls | Provider controls | Responsibility question if something fails |
|---|---|---|---|
| Pure self-service | Architecture, thresholds, configuration | Software/tooling only | Did the customer knowingly choose the risky setup? |
| Guided integration | Final deployment choice | Documentation, implementation advice, configuration review | Did provider guidance materially influence the risky choice? |
| Provider-operated component | Which component to use | Runtime infrastructure, RPCs, signers, oracles, custody | Did the operated service itself fail despite correct customer use? |
| Secure-by-default model | Limited customization | Enforced minimum redundancy and hardened defaults | Did the provider’s minimum safeguards perform as promised? |
| Managed / institutional service | Business requirements | Configuration, monitoring, operational controls | Does provider assume more contractual or operational liability? |
If the court and the contracts behind the integration place responsibility for verifier choices on the application owner, configurable infrastructure keeps its place, with providers adding formal risk acknowledgments and hardened defaults like LayerZero’s.
The migration wave would settle into a one-time repricing, and LayerZero’s message volume and new asset launches would show whether its redesign restored confidence.
If Kelp substantiates its written-approval claims, approving custom security designs starts carrying legal exposure. Vendors could respond with warranties, indemnities and higher prices, or by refusing to sign off on nonstandard configurations.
More issuers adopting Wyoming’s secure-by-default standard would steer institutional assets toward a smaller group of approved providers, trading configuration risk for concentration risk.
Kelp’s bridge did exactly what its configuration told it to do, and LayerZero’s verifier signed exactly what its compromised infrastructure told it was true. A court in British Columbia will now decide who owed the safeguards the industry spent five months adding.
