Evercrest Technologies, the developer behind KelpDAO, has filed a notice of civil claim in the Supreme Court of British Columbia against LayerZero Labs Ltd., LayerZero Labs Canada Inc., and co-founder Bryan Pellegrino. The lawsuit alleges negligent misrepresentation, negligence, and defamation stemming from an April exploit that resulted in the loss of $292 million from the restaking protocol. Evercrest seeks aggravated and punitive damages, citing specific communications where LayerZero allegedly endorsed the vulnerable bridge configuration it later criticized.
The filing details that KelpDAO’s bridges operated on a 1-of-1 setup, relying solely on LayerZero’s verifier network to confirm token locks across chains. According to the claim, LayerZero instructed Evercrest in February and March 2024 that this default configuration was safe, stating there was "[n]o problem" using it. The exploit reportedly began with malware installed on a LayerZero developer’s computer on March 6, which tampered with nodes to feed false data to the verifier. On April 18, the attacker disabled third-party nodes, causing the system to mint unbacked tokens after falsely registering 116,500 rsETH as locked on Unichain. Evercrest claims LayerZero warned another developer, USDT0, about similar risks but failed to provide comparable warnings to KelpDAO. The defamation allegations arise from LayerZero’s post-exploit statements claiming the single-verifier setup contradicted their recommended multi-DVN model, despite later admitting they made a mistake by allowing their DVN to act as a 1-of-1 for high-value transactions.
This litigation highlights the critical tension between technical integration guidance and post-incident accountability within cross-chain infrastructure. By alleging that LayerZero explicitly approved the 1-of-1 verifier configuration while simultaneously warning other partners about similar defaults, the claim challenges the consistency of security protocols offered by major interoperability providers. If proven, such discrepancies could expose infrastructure firms to significant liability for losses incurred by protocols that relied on vendor-endorsed configurations, potentially reshaping how developers assess trust in third-party verification networks.
The case also underscores the operational risks inherent in centralized or semi-centralized verifier models, even when marketed as secure defaults. The alleged sequence—where malware compromised internal developer machines before external nodes were disabled—points to vulnerabilities in supply chain security and node management practices. For institutional adoption, the outcome may influence due diligence standards regarding who bears responsibility for bridge architecture decisions: the protocol developer implementing the code or the infrastructure provider supplying the verification layer. This distinction is vital for establishing clear compliance frameworks and risk allocation in decentralized finance ecosystems.
