The attack did not break cryptography. That is the detail worth staring at longest.
In April — the reporting never specifies the year, which is itself a yellow flag — 116,500 rsETH left a cross-chain bridge connecting KelpDAO's infrastructure to Unichain, Uniswap's OP Stack L2. At roughly $2,506 per rsETH (the implied unit price you get by dividing the disclosed loss figure), that is approximately $292 million. It did not leave because a hash function failed. It did not leave because a private key was brute-forced. It left because a single verification entity, one node in a system explicitly designed to allow redundancy, was configured as the only gatekeeper for a nine-figure asset.
One-of-one.
Based on my audit work through the 2017 ICO cycle and every bridge configuration I have personally walked since, the most expensive vulnerabilities are rarely exotic. They are defaults nobody questioned. This is one of them.
The flaw was a configuration. The lawsuit is about who wrote it.
That distinction is where the story stops being a post-mortem and becomes a precedent.
Context: A modular security stack and the responsibility vacuum it creates
LayerZero v2 is a message-passing protocol. Its architectural bet is modularity: instead of forcing every application onto one fixed security model, it lets each OApp — Omnichain Application — select its own Decentralized Verifier Networks (DVNs), Executors, and block confirmation thresholds. An OApp can run one DVN. It can run five. It can require any threshold signature it wants. The protocol provides the plumbing; the application supplies the security policy.
This is genuinely better than the alternative it replaced. Before modular verification stacks, cross-chain messaging was dominated by hard-coded multisig bridges, where a fixed set of signers held the fate of every asset routing through them. If those signers colluded or their keys leaked, the loss was total and undifferentiated. LayerZero's contribution was to push that decision down to the application layer, where it can be tuned per use case.
The cost of that flexibility is where the problem lives. When security policy is customizable, security responsibility becomes customizable too — and customizable responsibility has no owner by default.
KelpDAO issues rsETH, a liquid restaking token. Users deposit ETH, receive rsETH, and the token represents a claim on restaked positions underneath, layered with yield. To move rsETH across chains, you need a bridge. KelpDAO used LayerZero. The destination was Unichain. The bridge on the KelpDAO side ran a 1-of-1 DVN configuration — a single verifier, no redundancy, no threshold.
According to court filings in British Columbia, KelpDAO's parent, Evercrest Technologies, alleges that LayerZero reviewed and endorsed this configuration. The claim is not that LayerZero shipped broken code. The claim is that LayerZero gave a dangerous configuration its blessing and never warned about the single point of failure it represented.
LayerZero, per the same reporting, subsequently attributed the design choice to KelpDAO.
Three causes of action were filed in the BC Supreme Court: negligence, negligent misrepresentation, and defamation. The defamation count corresponds to the public attribution — the claim that LayerZero pinned the failure on its counterparty in public. The negligence count is the one that should keep every middleware executive awake.
Core: The technical truth of a 1-of-1 failure, and the legal truth that follows
The mechanism is not subtle. In a 1-of-1 DVN setup, a single verifier is the sole authority on whether a cross-chain message is authentic. If that verifier is compromised, coerced, or simply behaves maliciously, it can attest to any message it wants. There is no second opinion. There is no quorum to defeat. The attacker does not need to forge signatures across a distributed set; they need to control one endpoint, or find a permission flaw anywhere along the message-verification path that lets them impersonate it.
This is not a cryptographic failure. It is a redundancy failure — the same family as a single-source oracle manipulation or an n-of-n multisig that is really a 1-of-1 in disguise. The risk type has had consensus best practices for years.
Based on my experience auditing bridge configurations, the honest question is not whether a 1-of-1 DVN is dangerous — everyone who has read a LayerZero deployment doc knows it is. The honest question is who was supposed to say no, and whether anyone said anything at all.
Here is where the technical and legal analyses interlock with uncomfortable precision.
If configuration authority sits with the OApp owner — KelpDAO, in this case — then the infrastructure provider's liability narrows to the quality of its advice. That is a much smaller target. The provider is a toolmaker. The user chose the tool's settings. The failure is the user's.
If, however, the configuration was delivered as a default template, or if LayerZero's own review process actively signed off on the 1-of-1 as acceptable, then the provider moved from toolmaker to advisor. And once you are an advisor, the duty of care standard rises toward the level expected of professional service providers. An advisor who tells you a dangerous setting is fine owns part of what happens next.
The phrase "reviewed and endorsed" is the legal powder keg in this case. It drags the defendant from tool vendor into a consultant role, and consultants are held to a higher bar than vendors.
What the reporting does not provide is decisive. There is no disclosure of which DVN was used, no contract address, no on-chain trace of the stolen funds, no indication of whether the configuration was selected from a LayerZero default or assembled by KelpDAO's own engineers. There is no LayerZero response, no counterclaim, no case number, no filing date. The information set is single-sided: it is the plaintiff's account, restated by a news desk, with no named reporter and no independent verification.
I want to be clinical about this because the stakes invite over-reading. A lawsuit that has been filed is a fact. A lawsuit that has been won is not. Treat the complaint as an input, not a verdict.
The technical failure is documented well enough to reason about. The responsibility allocation is not. Those are two different problems, and conflating them is how bad analysis gets produced.
What I can say with confidence is structural. LayerZero's modular design is sound. It is also, by construction, a responsibility-distribution problem dressed as a security feature. Every OApp that has ever deployed with a low-threshold DVN configuration created a latent liability that nobody priced — not the app, not the infrastructure provider, and certainly not the user holding the bridged asset. The protocol's flexibility does not eliminate risk. It relocates it, quietly, into a configuration file that nobody in the marketing department reads.
The code speaks louder than the whitepaper here. The whitepaper promises customizable security. The configuration file says one verifier. Only one of those documents is load-bearing.
The economics of the aftermath compound the problem. In a bridge-mint architecture — which is the most plausible reading of how 116,500 rsETH left in one clean stroke — the extraction does not draw down a pooled custody balance. It mints new, unbacked rsETH against the same underlying restaking positions. That is a supply-circulation mismatch: the token count on the loose side exceeds the collateral on the disciplined side. rsETH holders now carry a claim whose backing depends on recovery, treasury compensation, or a socialized haircut.
Which brings us to the loss-allocation question no one has answered. Who eats the $292 million? The bridge? The issuer? The verifier? The holder? The lawsuit is, at minimum, an attempt to establish third-party liability before discussing who pays. Whether it succeeds is the whole ballgame.
Contrarian: The bull case for modularity is correct — and it is not a defense
The reflexive bull response to a story like this is that LayerZero's architecture is still superior to locked multisig bridges, and the failure is an implementation error, not a protocol error. That response is technically correct. It is also completely irrelevant to the legal question, and pretending otherwise is a category error.
The bull is right that modular verification is a better primitive than a fixed signer set. The bull is right that applying a single DVN is a configuration choice, not a protocol mandate. The bull is right that in a properly configured OApp, the failure mode described here does not exist.
None of that matters if a court finds that the infrastructure provider owed a duty of care to the application it advised. Duty of care does not check whether your architecture is elegant. It checks whether you exercised reasonable prudence given the knowledge you had. A provider that understands the risk profile of a 1-of-1 configuration, reviews it for a counterparty, and stays silent has a problem that no amount of architectural elegance erases.
Trust is a vulnerability vector — and it does not matter how sophisticated the trust is. What matters is whether the party extending it was warned.
There is a second contrarian angle, and it cuts against the plaintiff. A well-resourced protocol like KelpDAO is not a naive retail user. It employs people who understand cross-chain risk. If KelpDAO's own team selected a 1-of-1 DVN, either through negligence or through a preference for transaction cost, then the failure is one of risk management, not of vendor misrepresentation. Sophisticated counterparties are held to their own diligence standards. A court may well find that the party best positioned to know the residual risk is the one that bears it.
Both readings are coherent. The outcome depends entirely on facts the public does not yet have.
What is not debatable is the asymmetry at the heart of the arrangement. The app captures the yield. The infrastructure captures the fee. The user absorbed the risk. When the loss landed, nobody's balance sheet had reserved for it. That is not a bug in LayerZero. It is a bug in how the entire middle layer of Web3 has silently structured its liabilities.
Takeaway
The oldest misreading of this event is that it is a story about a bridge exploit. It is not. Bridge exploits are quarterly weather. This event is a story about whether the legal system will force infrastructure providers to own the consequences of the defaults and advice they supply — and that has not been tested at this scale before.
For anyone holding a bridged asset, the action is not to opine. The action is to audit. Pull up the LayerZero Scan for every cross-chain position you hold. Count the DVNs. Look at the threshold. If it says 1-of-1, you are not holding an exposure; you are holding a timer. Every artifact is a trace of failure, and the configuration file is the artifact most people never open.
The precedent is what to watch, not the verdict. If the BC court recognizes a duty of care running from middleware providers to the applications they advise, then every protocol shipping a default configuration template inherits a compliance cost that currently exists only in theory. If it does not, the industry gets a liability holiday — until the next jurisdiction, or the next $292 million, introduces itself.
Logic does not bleed, but it does break. The question the courtroom will answer is who is holding the pieces when it does.
