Introduction
In May 2026, Kelp DAO’s omnichain deployment was drained of roughly $292M in a single coordinated exploit. Within days, LayerZero — the messaging layer Kelp relied on for cross-chain state — issued a public statement acknowledging fault in how the application’s security stack had been configured. The acknowledgment was unusual. Messaging protocols typically frame themselves as neutral pipes whose security is the integrator’s responsibility. Here, the protocol’s own statement conceded that a configuration considered acceptable at deployment time was, in hindsight, insufficient — and that the burden of recognizing this had been distributed in a way that failed.
We want to take this incident seriously as a case study, not a morality play. The interesting questions are not whether someone was careless. They are structural: what does the “default” security model of an omnichain messaging protocol actually guarantee? How does configurability — sold as a feature — interact with the operational reality that most integrators will accept defaults? What does a single-verifier setup look like in practice, and why did the failure mode it implies remain abstract until $292M moved? And finally, what does it mean that a key operational compromise, by reports, traced back to a hardware wallet that had been used in a personal context — a detail that sounds almost mundane until placed against the scale of the loss?
This piece walks the incident from architecture down to keystroke, then back up to what it implies for cross-chain design broadly. The point is not to relitigate fault. It is to identify which assumptions about omnichain security need to be revisited by anyone running a protocol with mint authority on more than one chain.
The architecture, in plain terms
LayerZero is a general-purpose messaging layer. An application contract on chain A calls into a LayerZero endpoint, the message is observed off-chain, and a corresponding contract on chain B is told to act on it. Between observation and execution sit two roles that together constitute the protocol’s trust model: a DVN (Decentralized Verifier Network) component, which attests that the message on chain A actually happened, and an Executor, which delivers the validated message to chain B.
In LayerZero v2, an application chooses its own DVN configuration. It can pick a single DVN, a set of DVNs with an N-of-M threshold, or layer in “required” and “optional” DVNs with separate quorum rules. The protocol ships with default configurations that integrators can adopt verbatim, modify, or replace. Critically, the choice is made per-application and per-pathway (per source-destination chain pair). A protocol live on six chains has, in effect, dozens of small policy decisions encoded in its endpoint configurations.
For Kelp’s omnichain setup, the relevant configuration was, at the time of the exploit, a single-verifier arrangement on at least one pathway. That is: a single DVN’s attestation was sufficient for a cross-chain message — typically a mint or unlock instruction — to be executed on the destination chain. There was no second independent verifier whose disagreement could halt the message. If the one verifier signed off, the message went through.
This is not, on its face, a bug. LayerZero permits this configuration. Several large integrators historically ran similar setups, particularly on lower-throughput pathways where adding additional DVNs introduced cost and operational overhead. The configuration is a tradeoff: cheaper, simpler, faster — and with no fault tolerance against compromise of that one party.
Anatomy of the exploit
The mechanics, as reconstructed from public statements and the protocol’s own post-incident communications, follow a clean pattern.
Compromising the single verifier
The attacker did not break LayerZero’s contracts. They did not exploit a Solidity bug in Kelp’s vault. They obtained the ability to make the single configured DVN sign attestations for messages that had never been emitted on the source chain. In effect: a forged cross-chain message, signed by the one party whose signature the destination contract had been told to trust.
Once that primitive existed, the rest of the exploit was straightforward. The attacker crafted messages instructing the destination chain to release or mint assets to addresses they controlled. The DVN signed. The Executor delivered. The destination contract, doing exactly what it was designed to do, honored the signed message and moved the funds.
Public reporting and LayerZero’s own statement attribute the verifier compromise to a chain of operational failures that culminated in attacker control of signing keys. Importantly, this was not a cryptographic break. The signing scheme worked as designed; the wrong party had the key.
Why the destination contract did not catch it
A second independent DVN, had one been required, would have had no reason to attest to a message that did not exist on the source chain. Its disagreement would have prevented quorum. The destination contract would have refused to act.
This is the structural point. The destination contract has no view into chain A. It only knows what its configured verifiers tell it. If you configure one verifier, you have delegated to that single party the authority to define ground truth for your application. That is not a messaging layer; that is a trusted oracle.
The “decentralized” in DVN refers to the broader marketplace of verifiers, not to the verification of any individual message. A single-DVN configuration is, from the application’s perspective, a single-oracle configuration. Whatever its branding, it carries single-oracle risk.
What “default security” actually means
A recurring theme in LayerZero’s documentation and developer relations posture has been the existence of “default” DVN configurations — sets of well-known verifiers, with sensible quorums, that an integrator can adopt without bespoke configuration work. The intent is good: lower the floor, so the median integrator ships with a reasonable setup rather than rolling their own.
But “default” in a configurable system means something specific, and the gap between that meaning and how integrators perceive it is where incidents incubate.
Defaults are not enforced
A default is a starting point, not a constraint. Once an integrator deploys, they can change their DVN configuration at any time, through governance or operational keys depending on how they wired access. There is no protocol-level invariant that says “an application cannot reduce its security below threshold X.” If the application owner can rewrite the config, the config is only as strong as the keys controlling it.
This matters because configurations drift. A team may begin with a robust multi-DVN setup, then strip it down on a less-trafficked pathway to save cost, then forget the asymmetry exists when the pathway later carries significant value. Or — as appears to have happened here — a configuration that was reasonable for a small deployment is never re-evaluated as the deployment grows.
Defaults are pathway-specific
Cross-chain applications often have many pathways: chain pairs across which messages can flow. Configurations are per-pathway. A protocol can be robustly configured on its primary Ethereum-Arbitrum pathway and underconfigured on a tertiary chain that nonetheless shares mint authority. An attacker only needs to find the weakest pathway. The strength of the strongest pathway is irrelevant.
This is the cross-chain equivalent of a classic security maxim: an attacker attacks the weakest configured path, not the average one. In a protocol with N pathways, the security of the system is bounded by the worst configuration across all N.
Defaults shift responsibility ambiguously
When a messaging protocol provides defaults but allows overrides, the responsibility for the resulting configuration is split in a way that becomes contested in the aftermath of an incident. LayerZero’s public acknowledgment that they share fault is unusual precisely because the conventional framing — “you chose your verifiers” — was available. The fact that they did not lean fully on that framing suggests an internal recognition that providing a configuration option that can produce catastrophic outcomes, without making the implications loud, is its own kind of failure.
This is a useful precedent. Modular, configurable security stacks are not a way to outsource judgment to the integrator. They are a way to distribute it. When the distribution is poorly calibrated — when the integrator does not have the information or expertise to make the choice well — the protocol shares in the resulting outcome.
The operational layer: keys, devices, and the personal-institutional boundary
Beneath the architectural story sits an operational one that has received less attention but is, in some ways, more instructive. According to reporting on the incident, the compromise of the signing key chain involved a hardware wallet that had at some point been used in a personal trading context before being employed in operational signing for the verifier infrastructure.
We are deliberately cautious about the specifics here, because the public record on operational details is thin and partially second-hand. But the broad pattern — a device or seed crossing the boundary between personal and institutional use — is so common in crypto operations, and the failure mode it implies is so well understood, that the incident is worth examining as an instance of a known class of risk.
Why the boundary matters
A hardware wallet’s security guarantees are about isolation: the seed never leaves the device, and signing requires physical confirmation. Those guarantees hold against remote software attacks. They do not hold against:
- The same seed being imported into another wallet, on another device, by the same user, “just to check a balance” or sign one transaction.
- The seed being entered into a phishing UI that mimics a legitimate signing interface.
- The device’s recovery phrase being written down and stored in a location accessible to a household-level attacker.
- A computer used to interact with the device being compromised in ways that affect transaction construction even when signing itself remains hardware-bound.
Each of these failure modes is more likely when the device is part of someone’s personal life — when they use it for retail trading, NFT mints, airdrop claims, or speculative interactions with unaudited contracts — than when it is purpose-built and lives in a constrained operational workflow.
Operational discipline at the verifier layer
Verifier infrastructure for an omnichain protocol is, functionally, validator infrastructure. It signs statements that move real value. The operational discipline expected of it should resemble what is expected of a chain validator or a multisig signer for a treasury, not what is acceptable for a personal hot wallet.
That discipline implies, at minimum: dedicated devices that are never used for any other purpose; air-gapped or HSM-backed key storage where the signing workflow permits; clear procedures for key rotation and revocation; segregation of duties so that no single operator can both authorize and execute a signing event; and routine attestation that these controls are in place.
When a single verifier is the entire security model of a downstream protocol, the operational standards for that verifier must reflect that fact. A configuration that delegates ground truth to one party is, implicitly, a contract that the one party will operate at validator-grade discipline.
The compounding failure
What makes this incident structurally interesting is that two distinct failures compounded multiplicatively rather than additively.
A single-verifier configuration is bad. An operational compromise of a signing key is bad. Either one alone is not catastrophic: a robust multi-DVN configuration tolerates one compromised verifier, and a single verifier whose keys remain secure does not produce an incident.
It is the intersection — the same protocol that chose a single-verifier configuration also happened to be the one whose verifier’s keys were compromised — that produces $292M. In a world with N applications each making independent configuration choices and M verifiers each with independent operational practices, you only need one (application, verifier) pair to coincide in failure for an incident of this magnitude to occur.
This is the structural risk that single-verifier configurations represent: not that they will fail, but that the failure-set across the ecosystem grows linearly in the number of such configurations, and the consequences of any single failure are total.
Comparable incidents and the cross-chain risk surface
Cross-chain bridges and messaging protocols have, collectively, been the largest single source of crypto losses since 2021. Ronin, Wormhole, Nomad, Multichain, Harmony Horizon — each was different in mechanism but united by a structural property: the security of the bridge was bounded by some small committee, multisig, or trusted set, while the value moved through it was unbounded.
LayerZero’s design was a deliberate response to this pattern. By making the verifier set configurable per-application, it sought to push the choice — and the corresponding accountability — toward the integrator, on the theory that integrators would calibrate to their own value-at-risk. In principle this is correct. A small application with limited TVL might reasonably accept a leaner configuration than a yield-bearing protocol with billions in deposits.
In practice, the calibration is hard to do well from inside an integrator team. The integrator has to reason about a security stack they did not design, evaluate verifier operators whose internal practices they cannot audit, and re-evaluate the configuration as their own protocol’s value-at-risk evolves. Few teams have the standing capacity to do this rigorously. The result is that configurations tend to be set once at launch and rarely revisited until something forces the revisit.
What this incident does not show
It is worth being clear about what the Kelp exploit does and does not prove.
It does not prove that LayerZero’s core architecture is broken. The architecture worked exactly as specified: a single configured verifier had unilateral attestation authority, that verifier signed, and the message was executed. The system did what it was told.
It does not prove that DVN-based verification is fundamentally weaker than alternative messaging models. Light-client-based bridges, optimistic bridges with fraud proofs, and committee-based bridges all have their own failure modes, and the empirical record across categories is mixed.
What it shows is narrower and more useful: that the configurability surface of modern messaging protocols includes settings whose downside is catastrophic, and that the social infrastructure around those settings — defaults, documentation, integrator education, ongoing review — has not kept pace with the value those configurations gate.
Implications and open questions
A few threads are worth pulling forward for anyone building, integrating with, or holding exposure to omnichain protocols.
The first is the question of enforced minimums. Should a messaging protocol allow an integrator to configure a single-verifier setup at all, given the failure mode that implies? Arguments exist on both sides. Permissionless flexibility is part of the value proposition. But a protocol that allows a configuration whose failure mode it later acknowledges as unacceptable is implicitly making a policy choice. Some plausible interventions: making single-verifier configurations require explicit opt-in flags rather than being silently available; surfacing the configuration choice prominently in block explorers and dashboards so that downstream users can see it; tying default configurations to TVL thresholds so that scaling protocols are nudged toward additional verifiers as value grows.
The second is the auditing layer. Cross-chain configurations are not, today, part of the standard scope of smart contract audits. An auditor evaluates the application’s Solidity, possibly the integration with the messaging endpoint, but rarely the DVN configuration itself, the operational practices of the configured DVNs, or the pathways the application has live across all chains. This gap is wide. A protocol can pass three audits and still ship a configuration that an experienced bridge engineer would flag in minutes. Building “cross-chain configuration review” into the audit standard — perhaps as a separate sub-discipline — is a plausible response.
The third is verifier accountability. If a DVN’s signature is, in some configurations, sufficient to move hundreds of millions of dollars, then the DVN is functionally a financial institution. Its operational practices, key management, personnel screening, and incident response are all matters of public interest. Voluntary disclosure of these practices, ideally on a comparable basis across verifiers, would let integrators make informed choices and would let users evaluate the configurations their protocols have selected. This is the kind of disclosure regime that exists, in various forms, around chain validators. It does not yet exist meaningfully around DVNs.
The fourth is the personal-institutional boundary in crypto operations broadly. This incident, if the operational details hold up, is another data point in a long pattern: the people running consequential crypto infrastructure are often the same people running personal crypto activity, on overlapping hardware and overlapping mental models. The industry has not built strong norms — or strong institutional incentives — for separating these. As more value flows through infrastructure operated by small teams, the cost of the missing separation grows.
The final and most uncomfortable question is what proportion of currently-deployed omnichain applications carry analogous configurations. We do not know. The configurations are public on-chain and could in principle be enumerated. To our knowledge, no comprehensive public registry exists. If single-verifier setups are common across protocols with non-trivial TVL — which seems plausible given that defaults at deployment time often involved lean configurations on secondary pathways — then this incident is a sample, not an outlier. The expected number of similar incidents over the coming year, conditional on the configuration prevalence, is bounded below by zero and not, as far as we can tell, by anything else.
What we would watch for in the months following this incident: whether LayerZero ships protocol-level changes that constrain the configurability surface; whether comparable messaging protocols (Wormhole, Axelar, Hyperlane) face pressure to publish equivalent risk disclosures; whether at least one major integrator publishes its current DVN configuration with a rationale and a review cadence; and whether the audit industry begins treating cross-chain configuration as in-scope by default. Any of these would be a sign that the lesson is being absorbed structurally. None of them, on their own, would be sufficient.
들어가며
2026년 5월, Kelp DAO의 옴니체인 배포 환경이 단 한 번의 조직적인 익스플로잇으로 약 2억 9,200만 달러를 탈취당했다. 며칠 후 LayerZero — Kelp가 크로스체인 상태 동기화를 위해 의존했던 메시징 레이어 — 는 애플리케이션의 보안 스택이 설정된 방식에 대한 책임을 일부 인정하는 공개 성명을 발표했다. 이례적인 인정이었다. 메시징 프로토콜은 통상적으로 자신을 중립적인 파이프로 규정하고, 보안은 통합 주체의 책임이라고 선을 긋는다. 그런데 이번에는 프로토콜 측 성명이 스스로 인정했다 — 배포 당시 허용 가능하다고 판단했던 설정이 돌아보면 부족했으며, 이를 인지하고 시정해야 할 부담이 잘못 분산된 구조였다는 것을.
이 사건을 교훈극이 아닌 사례 연구로 진지하게 다뤄볼 필요가 있다. 핵심 질문은 누군가가 부주의했느냐가 아니다. 질문은 구조적이다. 옴니체인 메시징 프로토콜의 ‘기본값’ 보안 모델은 실제로 무엇을 보장하는가? 기능으로 판매되는 설정 자유도는, 대부분의 통합 주체가 기본값을 그대로 받아들인다는 현실과 어떻게 충돌하는가? 단일 검증자 구성이 실제로는 어떤 모습이며, 그 함의하는 실패 양상이 왜 2억 9,200만 달러가 움직이기 전까지 추상적인 논의로만 머물렀는가? 그리고 마지막으로, 핵심적인 운영 침해가 개인 용도로 사용됐던 하드웨어 지갑에서 비롯됐다는 보도는 — 언뜻 평범해 보이는 세부사항이지만 손실 규모와 대조해보면 — 무엇을 의미하는가?
이 글은 사건을 아키텍처 수준에서 키스트로크 수준까지 분해한 뒤, 다시 올라와 크로스체인 설계 전반에 대한 시사점을 도출한다. 목적은 잘못을 재판하는 것이 아니다. 둘 이상의 체인에서 발행 권한을 보유한 프로토콜을 운영하는 누구라도 반드시 재검토해야 할 옴니체인 보안에 관한 전제들을 짚어내는 것이다.
아키텍처, 쉽게 풀어서
LayerZero는 범용 메시징 레이어다. 체인 A의 애플리케이션 컨트랙트가 LayerZero 엔드포인트를 호출하면, 메시지가 오프체인에서 관찰되고, 체인 B의 대응 컨트랙트가 이에 따라 행동하도록 지시받는다. 관찰과 실행 사이에는 프로토콜의 신뢰 모델을 구성하는 두 역할이 존재한다. DVN(탈중앙 검증자 네트워크) 컴포넌트는 체인 A에서 메시지가 실제로 발생했음을 증명하고, Executor는 검증된 메시지를 체인 B에 전달한다.
LayerZero v2에서 애플리케이션은 DVN 구성을 직접 선택한다. 단일 DVN, N-of-M 임계값을 가진 DVN 집합, 또는 별도의 쿼럼 규칙을 갖는 ‘필수’ 및 ‘선택적’ DVN의 조합을 선택할 수 있다. 프로토콜은 통합 주체가 그대로 채택하거나 수정 또는 교체할 수 있는 기본 구성을 제공한다. 중요한 점은, 이 선택이 애플리케이션별로 그리고 경로별로(소스-목적지 체인 쌍별로) 이루어진다는 것이다. 여섯 개 체인에서 운영되는 프로토콜은 사실상 엔드포인트 구성에 수십 개의 소규모 정책 결정을 인코딩하고 있다.
Kelp의 옴니체인 구성에서 익스플로잇 당시 해당 경로의 구성은 단일 검증자 구조였다. 즉, 단 하나의 DVN 증명만으로도 크로스체인 메시지 — 통상적으로 발행 또는 잠금 해제 명령 — 가 목적지 체인에서 실행되기에 충분했다. 메시지를 차단할 수 있는 독립적인 두 번째 검증자가 없었다. 그 하나의 검증자가 승인하면, 메시지는 통과했다.
표면적으로는 버그가 아니다. LayerZero는 이 구성을 허용한다. 여러 대형 통합 주체들도 역사적으로 유사한 구성을 운영했는데, 특히 추가 DVN이 비용과 운영 부담을 수반하는 낮은 처리량의 경로에서 그러했다. 이 구성은 하나의 트레이드오프다 — 더 저렴하고, 더 단순하고, 더 빠르지만, 그 하나의 당사자가 침해될 경우 어떠한 내결함성도 없다.
익스플로잇 해부
공개 성명과 프로토콜의 사후 소통을 바탕으로 재구성된 메커니즘은 깔끔한 패턴을 따른다.
단일 검증자 침해
공격자는 LayerZero의 컨트랙트를 직접 공격하지 않았다. Kelp 볼트의 Solidity 버그를 악용하지도 않았다. 공격자가 획득한 것은 설정된 단일 DVN으로 하여금 소스 체인에서 전혀 발생하지 않은 메시지에 대한 증명에 서명하게 만드는 능력이었다. 사실상 위조된 크로스체인 메시지가 — 목적지 컨트랙트가 신뢰하도록 설정된 바로 그 당사자의 서명을 받아 — 통과된 것이다.
이 기본 요소가 갖춰지자, 나머지 익스플로잇은 단순했다. 공격자는 목적지 체인에 자신이 통제하는 주소로 자산을 출금하거나 발행하도록 지시하는 메시지를 조작했다. DVN이 서명했다. Executor가 전달했다. 목적지 컨트랙트는 설계된 그대로 서명된 메시지를 처리하고 자금을 이동시켰다.
공개 보도와 LayerZero의 성명은 검증자 침해를 공격자가 서명 키를 통제하게 된 일련의 운영 실패로 귀인한다. 중요한 것은, 이것이 암호학적 취약점 공격이 아니었다는 점이다. 서명 체계는 설계대로 작동했다. 잘못된 당사자가 키를 가지고 있었을 뿐이다.
목적지 컨트랙트가 이를 포착하지 못한 이유
두 번째 독립적인 DVN이 요구됐다면, 소스 체인에 존재하지 않는 메시지를 증명할 이유가 없었을 것이다. 그 이견은 쿼럼 달성을 막았을 것이다. 목적지 컨트랙트는 실행을 거부했을 것이다.
이것이 구조적 핵심이다. 목적지 컨트랙트는 체인 A의 상태를 볼 수 없다. 설정된 검증자들이 전달하는 내용만 알 수 있다. 검증자를 하나만 설정한다면, 애플리케이션의 진실을 정의하는 권한을 그 단일 당사자에게 위임한 것이다. 그것은 메시징 레이어가 아니다. 신뢰 기반 오라클이다.
DVN에서 ‘탈중앙’이란 더 넓은 검증자 시장을 가리키는 것이지, 개별 메시지 검증의 탈중앙화를 뜻하지 않는다. 단일 DVN 구성은 애플리케이션 관점에서 단일 오라클 구성이다. 브랜딩이 무엇이든, 그것은 단일 오라클 리스크를 내포한다.
‘기본값 보안’이 실제로 의미하는 것
LayerZero의 문서와 개발자 대응에서 반복되어 온 주제 중 하나는 ‘기본’ DVN 구성의 존재였다 — 합리적인 쿼럼을 갖춘 잘 알려진 검증자 세트로, 통합 주체가 별도 설정 작업 없이 그대로 채택할 수 있는 것이다. 의도는 좋다. 최소 수준을 높여서, 평균적인 통합 주체가 자체 구성을 처음부터 만드는 것보다 합리적인 구성으로 출시하도록 하는 것이다.
그러나 설정 가능한 시스템에서 ‘기본값’은 구체적인 의미를 가지며, 그 의미와 통합 주체가 인식하는 방식 사이의 간극에서 사고가 잉태된다.
기본값은 강제되지 않는다
기본값은 출발점이지 제약이 아니다. 통합 주체가 배포한 후에는 거버넌스나 운영 키를 통해 DVN 구성을 언제든지 변경할 수 있다 — 접근 권한을 어떻게 연결했는지에 따라. “애플리케이션의 보안 수준을 임계값 X 이하로 낮출 수 없다”는 프로토콜 수준의 불변 조건은 존재하지 않는다. 애플리케이션 소유자가 설정을 다시 쓸 수 있다면, 설정은 그것을 통제하는 키만큼만 강하다.
이것이 중요한 이유는 구성이 drift하기 때문이다. 팀은 견고한 다중 DVN 구성으로 시작했다가, 비용 절감을 위해 트래픽이 적은 경로에서 이를 축소하고, 나중에 그 경로가 상당한 가치를 담게 됐을 때 그 비대칭성이 존재한다는 사실을 잊어버릴 수 있다. 혹은 — 이번 사건에서 발생한 것으로 보이듯 — 소규모 배포에 적합했던 구성이 배포가 성장해도 재검토되지 않는다.
기본값은 경로별로 다르다
크로스체인 애플리케이션에는 메시지가 흐를 수 있는 다양한 경로(체인 쌍)가 있다. 구성은 경로별이다. 프로토콜은 주요 이더리움-아비트럼 경로에서는 견고하게 구성되어 있으면서, 그럼에도 발행 권한을 공유하는 세 번째 체인 경로에서는 취약하게 구성되어 있을 수 있다. 공격자는 가장 약한 경로를 찾기만 하면 된다. 가장 강한 경로의 강도는 무관하다.
이것은 고전적인 보안 격언의 크로스체인 버전이다. 공격자는 평균 경로가 아닌 가장 약하게 구성된 경로를 공격한다. N개의 경로를 가진 프로토콜에서 시스템의 보안은 N개 전체 중 최악의 구성에 의해 제한된다.
기본값은 책임을 모호하게 분산시킨다
메시징 프로토콜이 기본값을 제공하되 재정의를 허용할 때, 결과적인 구성에 대한 책임은 사고 이후 논쟁의 여지가 있는 방식으로 분할된다. LayerZero가 공개적으로 책임의 일부를 인정한 것은 이례적인데, “당신이 검증자를 선택했다”는 기존의 프레이밍이 충분히 가능했기 때문이다. 그들이 이 프레이밍에 전적으로 기대지 않았다는 사실은, 재앙적인 결과를 낳을 수 있는 설정 옵션을 그 함의를 명확히 알리지 않은 채 제공하는 것 자체가 일종의 실패라는 내부 인식을 시사한다.
이것은 유용한 선례다. 모듈식의 설정 가능한 보안 스택은 통합 주체에게 판단을 외주화하는 방법이 아니다. 그것은 판단을 분산하는 방법이다. 그 분산이 잘못 조율될 때 — 통합 주체가 선택을 잘 할 정보나 전문성을 갖추지 못했을 때 — 프로토콜은 결과에 대한 책임을 함께 진다.
운영 레이어: 키, 기기, 그리고 개인-기관 경계
아키텍처 이야기 아래에는 덜 주목받았지만 어떤 면에서는 더 교훈적인 운영 이야기가 있다. 사건에 대한 보도에 따르면, 서명 키 체인의 침해에는 검증자 인프라의 운영 서명에 사용되기 전에 개인 트레이딩 맥락에서 사용된 바 있는 하드웨어 지갑이 관련되어 있었다.
여기서는 의도적으로 세부사항에 대해 신중한 입장을 취한다. 운영 세부사항에 관한 공개 기록이 빈약하고 부분적으로 간접적인 내용이기 때문이다. 그러나 더 넓은 패턴 — 기기나 시드가 개인과 기관 사용 사이의 경계를 넘나드는 것 — 은 크립토 운영에서 너무나 흔하고, 그것이 함의하는 실패 양상도 잘 알려져 있어, 이 사건은 알려진 종류의 리스크의 사례로 검토할 가치가 있다.
왜 경계가 중요한가
하드웨어 지갑의 보안 보장은 격리에 관한 것이다. 시드는 기기 밖으로 나가지 않고, 서명에는 물리적 확인이 필요하다. 이 보장은 원격 소프트웨어 공격에는 유효하다. 다음의 경우에는 유효하지 않다.
- 동일한 사용자가 “잔고 확인” 또는 한 번의 트랜잭션 서명을 위해 다른 기기의 다른 지갑으로 동일한 시드를 가져오는 경우.
- 시드가 합법적인 서명 인터페이스를 모방한 피싱 UI에 입력되는 경우.
- 기기의 복구 구문이 가정 수준의 공격자가 접근 가능한 위치에 기록되어 보관되는 경우.
- 서명 자체는 하드웨어에 묶여 있어도, 기기와 상호작용하는 데 사용된 컴퓨터가 트랜잭션 구성에 영향을 미치는 방식으로 침해되는 경우.
이 실패 양상들은 각각, 기기가 누군가의 개인 생활의 일부일 때 — 소매 거래, NFT 민팅, 에어드롭 청구, 감사받지 않은 컨트랙트와의 투기적 상호작용에 사용할 때 — 목적 전용으로 제한된 운영 워크플로에 묶여 있을 때보다 발생할 가능성이 높다.
검증자 레이어에서의 운영 기율
옴니체인 프로토콜의 검증자 인프라는 기능적으로 밸리데이터 인프라다. 실제 가치를 이동시키는 진술에 서명한다. 여기에 기대되는 운영 기율은 체인 밸리데이터나 트레저리 멀티시그 서명자에게 기대되는 것과 유사해야 하며, 개인 핫 월렛에 허용되는 수준이어서는 안 된다.
그 기율이 최소한 의미하는 것은 다음과 같다. 절대 다른 용도로 사용되지 않는 전용 기기; 서명 워크플로가 허용하는 경우 에어갭 또는 HSM 기반 키 보관; 키 로테이션 및 폐기에 대한 명확한 절차; 단일 운영자가 서명 이벤트를 승인하고 실행 모두를 할 수 없도록 하는 직무 분리; 그리고 이러한 통제가 실제로 유지되고 있다는 정기적인 확인.
단일 검증자가 다운스트림 프로토콜의 전체 보안 모델인 경우, 그 검증자의 운영 기준은 그 사실을 반영해야 한다. 진실의 권한을 한 당사자에게 위임하는 구성은 암묵적으로, 그 당사자가 밸리데이터급 기율로 운영할 것이라는 계약이다.
복합적 실패
이 사건을 구조적으로 흥미롭게 만드는 것은 두 가지 별개의 실패가 덧셈이 아닌 곱셈으로 복합됐다는 점이다.
단일 검증자 구성은 나쁘다. 서명 키의 운영 침해는 나쁘다. 그러나 각각 단독으로는 재앙이 아니다. 견고한 다중 DVN 구성은 침해된 단일 검증자를 허용하고, 키가 안전하게 유지되는 단일 검증자는 사고를 일으키지 않는다.
바로 그 교차점 — 단일 검증자 구성을 선택한 바로 그 프로토콜이 검증자의 키가 침해된 것과 우연히 겹쳤다는 사실 — 이 2억 9,200만 달러를 만들어낸다. 각각 독립적인 구성 선택을 하는 N개의 애플리케이션과 각각 독립적인 운영 관행을 가진 M개의 검증자가 있는 세계에서, 이 규모의 사고를 만들기 위해서는 단 하나의 (애플리케이션, 검증자) 쌍이 실패에서 겹치기만 하면 된다.
이것이 단일 검증자 구성이 나타내는 구조적 리스크다. 그것들이 반드시 실패할 것이라는 게 아니라, 그러한 구성의 수가 늘어날수록 생태계 전반의 실패 집합이 선형으로 증가하며, 단 하나의 실패가 가져오는 결과는 전적이라는 것이다.
유사 사례들과 크로스체인 리스크 표면
크로스체인 브릿지와 메시징 프로토콜은 2021년 이후 크립토 손실의 가장 큰 단일 원인이었다. Ronin, Wormhole, Nomad, Multichain, Harmony Horizon — 각각 메커니즘은 달랐지만 하나의 구조적 속성으로 연결되어 있었다. 브릿지의 보안은 소규모 위원회, 멀티시그, 또는 신뢰받는 집합에 의해 제한된 반면, 그것을 통해 이동하는 가치는 무제한이었다.
LayerZero의 설계는 이 패턴에 대한 의도적인 대응이었다. 검증자 집합을 애플리케이션별로 설정 가능하게 만들어, 선택과 그에 따른 책임을 통합 주체에게 넘기고자 했다 — 통합 주체들이 자신의 가치-위험에 맞게 조정할 것이라는 이론 아래. 원칙적으로 이는 옳다. TVL이 제한된 소규모 애플리케이션은 수십억의 예치금을 보유한 수익 창출 프로토콜보다 간소한 구성을 합리적으로 수용할 수 있다.
실제로는, 통합 주체 팀 내부에서 이 조정을 잘 수행하기가 어렵다. 통합 주체는 자신이 설계하지 않은 보안 스택을 이해해야 하고, 내부 관행을 감사할 수 없는 검증자 운영자를 평가해야 하며, 자체 프로토콜의 가치-위험이 진화함에 따라 구성을 재검토해야 한다. 이를 엄밀하게 수행할 상시 역량을 갖춘 팀은 드물다. 결과적으로 구성은 출시 시점에 한 번 설정되고, 무언가가 재검토를 강제할 때까지 거의 재검토되지 않는다.
이 사건이 보여주지 않는 것
Kelp 익스플로잇이 무엇을 증명하고 무엇을 증명하지 않는지 명확히 할 필요가 있다.
LayerZero의 핵심 아키텍처가 근본적으로 결함이 있다는 것을 증명하지 않는다. 아키텍처는 정확히 명세대로 작동했다. 설정된 단일 검증자가 일방적인 증명 권한을 가졌고, 그 검증자가 서명했으며, 메시지가 실행됐다. 시스템은 지시받은 대로 작동했다.
DVN 기반 검증이 대안적 메시징 모델보다 근본적으로 취약하다는 것도 증명하지 않는다. 라이트 클라이언트 기반 브릿지, 사기 증명을 활용한 옵티미스틱 브릿지, 위원회 기반 브릿지 모두 각자의 실패 양상을 가지고 있으며, 카테고리 전반에 걸친 실증적 기록은 혼재되어 있다.
이 사건이 보여주는 것은 더 좁고 더 유용하다. 현대 메시징 프로토콜의 설정 가능한 표면에는 다운사이드가 재앙적인 설정들이 포함되어 있으며, 그 설정들을 둘러싼 사회적 인프라 — 기본값, 문서, 통합 주체 교육, 지속적 검토 — 가 그 설정들이 통제하는 가치의 성장 속도를 따라가지 못했다는 것이다.
시사점과 미해결 질문들
옴니체인 프로토콜을 구축하거나, 통합하거나, 또는 이에 노출된 누구에게나 앞으로 당겨볼 몇 가지 실마리가 있다.
첫 번째는 강제된 최솟값의 문제다. 단일 검증자 구성이 함의하는 실패 양상을 고려할 때, 메시징 프로토콜이 애초에 그 설정을 허용해야 하는가? 양쪽 모두 논거가 있다. 무허가적 유연성은 가치 제안의 일부다. 그러나 나중에 허용 불가로 인정한 실패 양상을 가진 구성을 허용하는 프로토콜은 암묵적으로 정책적 선택을 하고 있는 것이다. 몇 가지 가능한 개입들이 있다. 단일 검증자 구성이 기본적으로 조용히 사용 가능한 대신 명시적인 옵트인 플래그를 요구하도록 만들기; 블록 탐색기와 대시보드에서 구성 선택을 눈에 띄게 표시하여 다운스트림 사용자가 볼 수 있도록 하기; 기본 구성을 TVL 임계값에 연동하여 성장하는 프로토콜이 가치가 증가함에 따라 추가 검증자 방향으로 유도되도록 하기.
두 번째는 감사 레이어다. 크로스체인 구성은 오늘날 스마트 컨트랙트 감사의 표준 범위에 포함되지 않는다. 감사인은 애플리케이션의 Solidity를, 경우에 따라서는 메시징 엔드포인트와의 통합을 평가하지만, DVN 구성 자체, 설정된 DVN들의 운영 관행, 또는 애플리케이션이 모든 체인에 걸쳐 활성화한 경로들은 거의 다루지 않는다. 이 간극은 크다. 프로토콜은 세 번의 감사를 통과하고도 경험 있는 브릿지 엔지니어라면 몇 분 만에 지적할 구성을 출시할 수 있다. ‘크로스체인 구성 검토’를 감사 기준에 — 별도의 세부 분야로서 — 포함시키는 것이 타당한 대응이다.
세 번째는 검증자 책임이다. DVN의 서명이 일부 구성에서 수억 달러를 이동시키기에 충분하다면, 그 DVN은 기능적으로 금융 기관이다. 그것의 운영 관행, 키 관리, 인사 검증, 그리고 사고 대응은 모두 공공의 관심사다. 이러한 관행의 자발적 공개 — 이상적으로는 검증자들 간에 비교 가능한 기준으로 — 는 통합 주체가 정보에 입각한 선택을 하고 사용자가 자신의 프로토콜이 선택한 구성을 평가할 수 있도록 해줄 것이다. 이것은 체인 밸리데이터 주변에 다양한 형태로 존재하는 공시 체계다. DVN에 대해서는 아직 의미 있게 존재하지 않는다.
네 번째는 크립토 운영 전반에서의 개인-기관 경계 문제다. 이 사건은 — 운영 세부사항이 사실로 확인된다면 — 오래된 패턴의 또 하나의 데이터 포인트다. 중요한 크립토 인프라를 운영하는 사람들은 종종 같은 하드웨어와 같은 멘탈 모델로 개인 크립토 활동도 함께 운영한다. 이 업계는 이 둘을 분리하기 위한 강한 규범도, 강한 제도적 인센티브도 구축하지 못했다. 소규모 팀이 운영하는 인프라를 통해 더 많은 가치가 흐를수록, 이 분리의 부재가 초래하는 비용은 커진다.
마지막이자 가장 불편한 질문은 현재 배포된 옴니체인 애플리케이션 중 유사한 구성을 가진 것이 얼마나 되느냐다. 우리는 모른다. 구성은 온체인에서 공개되어 있어 원칙적으로 열거 가능하다. 우리가 아는 한, 포괄적인 공개 레지스트리는 존재하지 않는다. 비트코인이 아닌 상당한 TVL을 보유한 프로토콜들 사이에 단일 검증자 구성이 일반적이라면 — 배포 당시 기본값이 종종 보조 경로에서 간소한 구성을 포함했다는 점을 고려하면 충분히 가능해 보이는 — 이 사건은 이상치가 아니라 표본이다. 구성 유병률을 조건으로 한 향후 1년 내 유사 사건의 기댓값은 아래로는 0에 의해 제한되며, 위로는 우리가 아는 한 아무것도 제한하지 않는다.
이 사건 이후 몇 달 동안 주목할 것들이 있다. LayerZero가 설정 가능한 표면을 제한하는 프로토콜 수준의 변경을 출시하는지; 유사한 메시징 프로토콜들(Wormhole, Axelar, Hyperlane)이 동등한 리스크 공시를 공개하라는 압력에 직면하는지; 적어도 하나의 주요 통합 주체가 현재의 DVN 구성을 근거와 검토 주기와 함께 공개하는지; 그리고 감사 업계가 크로스체인 구성을 기본적으로 감사 범위에 포함하기 시작하는지. 이 중 어느 하나라도 실현된다면 교훈이 구조적으로 흡수되고 있다는 신호다. 그러나 그 어느 것도, 단독으로는, 충분하지 않을 것이다.
はじめに
2026年5月、Kelp DAOのオムニチェーン展開が、単一の組織的なエクスプロイトによっておよそ2億9,200万ドルを失った。数日後、Kelpがクロスチェーン状態管理に用いていたメッセージングレイヤーであるLayerZeroは、アプリケーションのセキュリティスタック設定に問題があったことを認める声明を公表した。この認め方は異例だった。メッセージングプロトコルは通常、自らを中立的なパイプとして位置づけ、セキュリティは統合する側の責任だと主張するものだ。しかし今回、プロトコル自身の声明は、デプロイ時に許容可能とされていた設定が、振り返れば不十分だったこと、そしてその事実を認識すべき責任が、機能しない形で分散されていたことを認めた。
このインシデントを、道徳的な教訓としてではなく、ケーススタディとして真剣に掘り下げたい。問題は誰かが不注意だったかどうかではない。問いはより構造的なものだ。オムニチェーン・メッセージングプロトコルの「デフォルト」のセキュリティモデルは、実際のところ何を保証しているのか。機能として売り込まれる設定の柔軟性は、ほとんどの統合側がデフォルトをそのまま受け入れるという運用の現実と、どのように相互作用するのか。単一の検証者を使う設定は実際にはどのようなものか。そして、2億9,200万ドルが動くまで、その失敗シナリオはなぜ抽象論にとどまり続けたのか。さらに、報告によれば、ある重要な運用上の侵害が、個人的な用途で使われていたハードウェアウォレットに端を発するとされているが、この一見些末なディテールが、損失規模を前にすると何を意味するのか。
本稿はインシデントをアーキテクチャからキーストロークの水準まで分解し、そこからクロスチェーン設計全体への示唆へと立ち戻る。目的は責任の所在を問い直すことではない。複数のチェーンにわたってミント権限を持つプロトコルを運用するすべての関係者が、オムニチェーン・セキュリティについてどの前提を見直すべきかを明らかにすることだ。
アーキテクチャを平易に説明する
LayerZeroは汎用のメッセージングレイヤーだ。チェーンA上のアプリケーションコントラクトがLayerZeroのエンドポイントを呼び出すと、そのメッセージはオフチェーンで観測され、チェーンB上の対応するコントラクトに対してアクションを起こすよう指示が送られる。観測と実行のあいだに、プロトコルのトラストモデルを構成する二つの役割が置かれている。DVN（Decentralized Verifier Network）コンポーネントはチェーンA上でメッセージが実際に発生したことを証明し、Executorは検証済みのメッセージをチェーンBに届ける。
LayerZero v2では、アプリケーションが独自にDVN設定を選択できる。単一のDVNを選ぶことも、N-of-MしきいのDVNセットを選ぶことも、「必須」と「任意」のDVNを別々のクォーラムルールで組み合わせることもできる。プロトコルはそのままデプロイに使えるデフォルト設定を提供しており、統合側はそれをそのまま採用することも、変更することも、自前のものに置き換えることもできる。重要なのは、この選択がアプリケーションごと、かつパスウェイ（送信元チェーンと送信先チェーンのペア）ごとに行われる点だ。六つのチェーンで稼働するプロトコルは、事実上、数十に及ぶ小さなポリシー判断をエンドポイント設定にエンコードしていることになる。
Kelpのオムニチェーン設定において、エクスプロイト当時、少なくとも一つのパスウェイが単一の検証者による構成だった。つまり、単一のDVNの証明があれば、クロスチェーンメッセージ——通常はミントやアンロックの指示——が送信先チェーンで実行されるという設定だ。メッセージを止めることのできる独立した第二の検証者は存在しなかった。その一つの検証者が承認すれば、メッセージは通過した。
これはそれ自体がバグというわけではない。LayerZeroはこの設定を許可している。追加のDVNがコストや運用上のオーバーヘッドをもたらすスループットの低いパスウェイでは、歴史的に多くの大手統合側が同様の設定で運用していた。この設定はトレードオフだ。安価で、シンプルで、高速である一方、その唯一の当事者が侵害された場合のフォールトトレランスはゼロになる。
エクスプロイトの解剖
公式声明とプロトコル自身のインシデント後のコミュニケーションから再構成した経緯は、明快なパターンをたどっている。
単一の検証者を侵害する
攻撃者はLayerZeroのコントラクトを破ったわけではない。KelpのボールトにあるSolidityのバグを突いたわけでもない。攻撃者が手に入れたのは、送信元チェーンで一度も発行されていないメッセージに対して、設定された唯一のDVNに署名させる能力だった。要するに、送信先コントラクトが信頼するよう指定された唯一の当事者によって署名された、偽造のクロスチェーンメッセージだ。
このプリミティブが手に入ってしまえば、残りのエクスプロイトは単純だった。攻撃者は送信先チェーンに対して、自分が管理するアドレスへ資産を解放またはミントするよう指示するメッセージを作成した。DVNが署名した。Executorが配信した。送信先コントラクトは、設計どおりに署名済みメッセージを受け入れ、資金を移動した。
LayerZero自身の声明を含む公開報告は、検証者の侵害を、攻撃者が署名鍵を掌握するに至った一連の運用上の失敗に帰因させている。重要なのは、これは暗号学的な突破口ではないことだ。署名スキームは設計どおりに機能した。鍵を持っていたのが間違った当事者だったのだ。
送信先コントラクトがそれを検知できなかった理由
もし独立した第二のDVNが必要とされていたなら、そのDVNは送信元チェーンに存在しないメッセージを証明する理由を持たなかっただろう。その不同意がクォーラムの成立を妨げ、送信先コントラクトは動かなかったはずだ。
ここに構造的な核心がある。送信先コントラクトはチェーンAを直接見ることができない。設定された検証者が伝えることしか知らない。検証者を一つだけにするということは、その単一の当事者にアプリケーションの真実を定義する権限を委ねることにほかならない。それはもはやメッセージングレイヤーではなく、信頼されたオラクルだ。
DVNの「分散型」という部分は検証者の広範なマーケットプレイスを指しているのであって、個々のメッセージの検証が分散されているわけではない。アプリケーションの観点からすると、単一DVN設定は単一オラクル設定と同義だ。どのようなブランディングが施されていようと、単一オラクルリスクを帯びている。
「デフォルトのセキュリティ」が実際に意味すること
LayerZeroのドキュメントや開発者向けコミュニケーションに繰り返し登場するテーマが、「デフォルト」のDVN設定の存在だ。信頼できる検証者をセンシブルなクォーラムで組み合わせたもので、統合側は独自の設定作業なしにそのまま採用できる。意図は良い。底上げをして、平均的な統合側が一から作り直すのではなく、それなりに合理的な設定でデプロイできるようにすることだ。
しかし、設定可能なシステムにおける「デフォルト」は特定の意味を持ち、その意味と統合側の認識のあいだにある乖離こそが、インシデントを孵化させる温床となる。
デフォルトは強制されない
デフォルトは出発点であり、制約ではない。統合側がデプロイした後は、ガバナンスや運用鍵を通じて、いつでもDVN設定を変更できる。「アプリケーションはセキュリティをしきい値X以下に下げられない」というプロトコルレベルの不変条件は存在しない。アプリケーションのオーナーが設定を書き換えられるなら、設定の強度はそれを制御する鍵の強度にしか依存しない。
これが重要なのは、設定は時間とともにずれていくからだ。あるチームが堅牢な複数DVN設定から始めた後、コスト削減のためにトラフィックの少ないパスウェイでそれを削ぎ落とし、そのパスウェイが後に多大な価値を運ぶようになったとき、その非対称性が存在することを忘れている——という事態は起こりうる。あるいは、今回起きたように見えることだが、小規模なデプロイには合理的だった設定が、デプロイの規模が成長しても一度も見直されないことがある。
デフォルトはパスウェイに固有だ
クロスチェーン・アプリケーションにはしばしば多くのパスウェイがある。メッセージが流れうるチェーンのペアだ。設定はパスウェイごとに存在する。あるプロトコルは主要なEthereum-Arbitrumパスウェイでは堅牢に設定されていながら、ミント権限を共有するサードチェーンでは設定が不十分である可能性がある。攻撃者は最も弱いパスウェイを見つければいいだけだ。最も強いパスウェイの堅牢さは関係ない。
これはセキュリティの古典的な格言のクロスチェーン版だ。攻撃者が狙うのは最も弱く設定されたパスであり、平均的なパスではない。N個のパスウェイを持つプロトコルでは、システムのセキュリティはN全体にわたる最悪の設定に上限を規定される。
デフォルトは責任を曖昧に分散させる
メッセージングプロトコルがデフォルトを提供しつつオーバーライドを許容するとき、結果として生まれる設定への責任は、インシデントの後に争われるような形で分割される。LayerZeroが故意を認めた今回の公式声明が異例なのは、まさに「あなた方が検証者を選んだ」という従来の言い訳が使えたからだ。彼らがその言い訳に完全に頼らなかったという事実は、壊滅的な結果を招きうる設定オプションを、その含意を明確に示さずに提供することは、それ自体一種の失敗であるという内部的な認識を示唆している。
これは有益な先例だ。モジュール化された設定可能なセキュリティスタックは、判断を統合側に外部委託する手段ではない。判断を分散させる手段だ。その分散が不適切に調整されたとき——統合側が適切な選択をするために必要な情報や専門知識を持っていないとき——プロトコルはその結果に連帯責任を負う。
運用レイヤー：鍵、デバイス、個人と組織の境界線
アーキテクチャの物語の下には、あまり注目されていないが、ある意味でより示唆に富む運用上の物語がある。インシデントに関する報告によれば、署名鍵チェーンの侵害には、ある時点で個人的なトレードの用途に使われた後、検証者インフラの運用署名に転用されたハードウェアウォレットが関与していた。
公開記録における運用上の詳細は薄く、一部は二次情報に基づいているため、ここでは具体的な点については意図的に慎重を期す。しかし、デバイスやシードが個人用途と組織用途の間の境界を越えるというパターンは、クリプト分野の運用において非常に一般的であり、それが意味する失敗のシナリオも十分に理解されているため、このインシデントは既知のリスクカテゴリの一例として検討する価値がある。
なぜ境界線が重要か
ハードウェアウォレットのセキュリティ保証は分離性にある。シードはデバイスの外に出ず、署名には物理的な確認が必要だ。これらの保証はリモートのソフトウェア攻撃に対して有効だ。しかし以下には対応していない。
- 「残高を確認するだけ」や一回の取引のために、同じユーザーが別のデバイスにある別のウォレットへ同じシードをインポートする場合。
- 正規の署名インターフェースを模倣したフィッシングUIにシードが入力される場合。
- デバイスのリカバリーフレーズが書き留められ、家庭内の攻撃者がアクセス可能な場所に保管される場合。
- デバイスと連携するコンピューターが、署名自体はハードウェアに束縛されていても、トランザクションの構築に影響を与える形で侵害される場合。
これらの失敗シナリオはいずれも、そのデバイスが個人の生活の一部として使われている場合——リテールトレード、NFTミント、エアドロップ請求、未監査のコントラクトとの投機的なやりとりに用いられる場合——に、専用化されて制約された運用ワークフローの中に置かれている場合より、起きやすくなる。
検証者レイヤーにおける運用の規律
オムニチェーン・プロトコルの検証者インフラは、機能的にはバリデータインフラだ。実際の価値を動かすステートメントに署名する。期待される運用規律は、チェーンのバリデータやトレジャリーのマルチシグ署名者に期待されるものに近くなければならず、個人のホットウォレットに許容されるものであってはならない。
その規律が意味することは、少なくとも以下の通りだ。他の一切の目的に使用されない専用デバイス。署名ワークフローが許す限り、エアギャップまたはHSMに支えられた鍵保管。鍵のローテーションと失効のための明確な手順。署名イベントを単独で承認・実行できる担当者が存在しない職務分離。これらの統制が整備されていることの定期的な証明。
単一の検証者が下流プロトコルのセキュリティモデル全体を担うとき、その検証者の運用水準はその事実を反映していなければならない。真実の定義を一者に委ねる設定は、暗黙のうちに、その一者がバリデータレベルの規律で運用するという契約を含んでいる。
複合的な失敗
このインシデントを構造的に興味深くしているのは、二つの別々の失敗が加算的ではなく乗算的に複合したことだ。
単一の検証者設定は悪い。署名鍵の運用上の侵害も悪い。しかしどちらか一方だけでは壊滅的ではない。堅牢な複数DVN設定は一つの侵害された検証者を許容するし、鍵が安全に保たれた単一の検証者はインシデントを生まない。
2億9,200万ドルを生み出したのは、その交差点だ。単一の検証者設定を選んだプロトコルが、たまたまその検証者の鍵が侵害されたプロトコルでもあったということだ。N個のアプリケーションがそれぞれ独立した設定を選び、M個の検証者がそれぞれ独立した運用慣行を持つ世界では、この規模のインシデントが発生するためには、（アプリケーション、検証者）ペアのうち一組が失敗において一致するだけでいい。
これが単一の検証者設定が代表する構造的なリスクだ。それが失敗するという話ではなく、エコシステム全体でこうした設定の数が増えるにつれ、失敗の確率の集合が線形に成長し、個々の失敗の結果が全損になることだ。
類似インシデントとクロスチェーンのリスク面
クロスチェーンのブリッジとメッセージングプロトコルは、2021年以降、クリプト損失の最大の単一源となっている。Ronin、Wormhole、Nomad、Multichain、Harmony Horizon——それぞれメカニズムは異なるが、ブリッジのセキュリティが何らかの小さな委員会、マルチシグ、または信頼されたセットによって上限を規定される一方、そこを流れる価値は無制限だったという構造的な性質において共通していた。
LayerZeroの設計は、このパターンへの意図的な応答だった。検証者セットをアプリケーションごとに設定可能にすることで、選択——そして対応する説明責任——を統合側へ押し付けようとした。統合側がリスク許容度に見合った設定を行うという理論に基づいている。原則としてこれは正しい。TVLが限られた小さなアプリケーションは、数十億の預け入れを持つ利回りを生むプロトコルよりも、より簡素な設定を合理的に受け入れられるかもしれない。
実際には、統合側チームの内側からこの調整をうまく行うのは難しい。統合側は自分たちが設計していないセキュリティスタックについて推論し、内部実態を監査できない検証者オペレーターを評価し、自分たちのプロトコルのリスク許容度が進化するにつれて設定を再評価しなければならない。これを厳密に行う常設の能力を持つチームはほとんどない。結果として、設定はローンチ時に一度決められ、何かが再評価を強いるまでほとんど見直されない傾向がある。
このインシデントが示さないこと
Kelpのエクスプロイトが何を証明し、何を証明しないのかを明確にしておく価値がある。
LayerZeroのコアアーキテクチャが壊れていることを証明するわけではない。アーキテクチャは仕様通りに動いた。設定された単一の検証者が一方的な証明権限を持ち、その検証者が署名し、メッセージが実行された。システムは指示された通りのことをしたのだ。
DVNベースの検証が代替メッセージングモデルより根本的に脆弱であることを証明するわけでもない。ライトクライアントベースのブリッジ、不正証明付きのオプティミスティックブリッジ、委員会ベースのブリッジにはそれぞれ独自の失敗シナリオがあり、カテゴリをまたいだ実績は一様ではない。
示されているのはより限定的で、より有用なことだ。現代のメッセージングプロトコルの設定可能な面には、失敗すれば壊滅的な設定が含まれており、その設定をめぐる社会的インフラ——デフォルト、ドキュメント、統合側への教育、継続的なレビュー——が、その設定がゲートする価値の成長に追いついていないということだ。
示唆と未解決の問い
オムニチェーン・プロトコルの構築、統合、または投資に関わるすべての人にとって、掘り下げる価値のある論点がいくつかある。
第一は、強制的な最低基準の問いだ。 メッセージングプロトコルは、その失敗シナリオを考慮すると、そもそも統合側に単一の検証者設定を許可すべきか？両論がある。無許可の柔軟性は価値提案の一部だ。しかし、自ら後に許容できないと認めた失敗シナリオを持つ設定を許可するプロトコルは、暗黙にポリシー上の選択を行っている。考えられる介入策としては、単一の検証者設定をデフォルトで利用可能にするのではなく、明示的なオプトインフラグを要求すること、その設定の選択をブロックエクスプローラーやダッシュボードで目立つ形で表示してダウンストリームのユーザーが確認できるようにすること、価値が増大するにつれてスケーリングするプロトコルが追加の検証者に向かうよう、TVLしきい値に連動させたデフォルト設定を用意することなどが挙げられる。
第二は、監査レイヤーの問いだ。 クロスチェーンの設定は今日、スマートコントラクト監査の標準的なスコープには含まれていない。監査者はアプリケーションのSolidityを、場合によってはメッセージングエンドポイントとの統合を評価するが、DVN設定自体、設定されたDVNの運用慣行、またはアプリケーションが全チェーンに展開しているパスウェイを評価することはほとんどない。このギャップは大きい。プロトコルは三つの監査を通過しながら、経験豊富なブリッジエンジニアなら数分でフラグを立てるような設定を出荷できる。「クロスチェーン設定レビュー」を監査標準に組み込むこと——おそらく独立したサブディシプリンとして——は、もっともな対応だ。
第三は、検証者の説明責任の問いだ。 DVNの署名が、ある設定では数億ドルを動かすのに十分であるとすれば、そのDVNは機能的に金融機関だ。その運用慣行、鍵管理、人員スクリーニング、インシデント対応はすべて公共的関心の問題だ。これらの慣行の自発的な開示、理想的には検証者間で比較可能な形での開示は、統合側が情報に基づいた選択をできるようにし、ユーザーが自分のプロトコルが選択した設定を評価できるようにするだろう。これはチェーンのバリデータをめぐって様々な形で存在する種類の開示体制だ。DVNをめぐっては、まだ実質的には存在しない。
第四は、クリプト運用全般における個人と組織の境界線の問いだ。 このインシデントは、運用上の詳細が確認されるならば、長いパターンにおけるもう一つのデータポイントだ。重要なクリプトインフラを運用している人々は、しばしば重複したハードウェアと重複したメンタルモデルの上で、個人的なクリプト活動も行う同じ人々だ。この業界は、それらを分離するための強固な規範——あるいは強固な制度的インセンティブ——を構築できていない。より多くの価値が小規模なチームによって運用されるインフラを流れるようになるにつれ、この欠如したる分離のコストは増大する。
最後の、そして最も不快な問いは、現在デプロイされているオムニチェーン・アプリケーションのうち、類似した設定を持つものがどれほどの割合を占めるか、だ。我々には分からない。設定はオンチェーンで公開されており、原理的には列挙可能だ。我々の知る限り、包括的な公開レジストリは存在しない。もし単一の検証者設定が、非trivialなTVLを持つプロトコル全体で一般的であれば——デプロイ時のデフォルトがサブチェーンのパスウェイでは簡素な設定だったことが多いことを考えると、それは十分ありうる——このインシデントは外れ値ではなく、サンプルだ。設定の普及率を条件とした場合、今後一年間の類似インシデントの期待数の下限はゼロであり、上限は我々の知る限り何によっても規定されない。
このインシデントの後、数ヶ月の間に注視すべきことがある。LayerZeroが設定可能な面を制限するプロトコルレベルの変更を出荷するかどうか。同等のメッセージングプロトコル（Wormhole、Axelar、Hyperlane）が同等のリスク開示を公表するよう圧力をかけられるかどうか。少なくとも一つの主要な統合側が、根拠とレビューサイクルとともに現在のDVN設定を公開するかどうか。そして、監査業界がクロスチェーン設定をデフォルトでスコープ内として扱い始めるかどうか。これらのどれかが実現すれば、教訓が構造的に吸収されつつあるサインだ。しかしそれらのいずれも、それ単体では十分ではない。
引言
2026年5月，Kelp DAO的全链部署在一次协同攻击中遭到洗劫，损失约2.92亿美元。事发数日内，Kelp用于跨链状态同步的消息传输层LayerZero发表公开声明，承认该应用安全配置存在问题。这份声明颇为罕见。消息协议通常将自身定位为中立的数据通道，安全责任由集成方承担。而这次，协议方主动承认：部署时被认为可以接受的配置，事后来看是不够的——而识别这一问题的责任被分散到了一种最终导致失败的方式上。
我们希望将这次事件作为一个案例认真研究，而不是简单地做道德评判。真正值得追问的不是谁粗心大意，而是结构性的问题：全链消息协议的”默认”安全模型究竟提供什么保障？可配置性——这个被当作卖点的特性——与大多数集成方会沿用默认配置的现实之间，存在怎样的张力？单一验证者设置在实践中是什么样的，为何它隐含的失败模式在2.92亿美元转移之前始终停留在抽象层面？最后，有报道指出，此次关键的操作层面失陷源于一个曾在个人场景中使用过的硬件钱包——这个细节听起来几乎平淡无奇，直到与损失规模放在一起才显出其分量。
本文从架构层到击键操作，逐层拆解这次事件，再回溯到它对跨链设计的整体启示。目的不是重新追责，而是找出哪些关于全链安全的假设，需要每一个在多条链上持有铸币权限的协议重新审视。
架构，用白话说
LayerZero是一个通用消息传输层。链A上的应用合约调用LayerZero端点，消息在链下被观察到，随后链B上的对应合约收到指令并执行。在观察与执行之间，有两个角色共同构成协议的信任模型：DVN（去中心化验证者网络）组件，负责证明链A上的消息确实发生过；以及Executor（执行者），负责将已验证的消息投递到链B。
在LayerZero v2中，应用可以自行选择DVN配置。可以选择单一DVN、带N-of-M阈值的DVN集合，或者设置”必选”和”可选”DVN，并配以独立的法定人数规则。协议提供默认配置，集成方可以直接采用、修改或替换。关键在于，这一选择是按应用、按路径（即按源链-目标链对）分别设置的。一个在六条链上运行的协议，实际上在其端点配置中编码了数十个独立的策略决定。
在Kelp的全链部署中，事发时至少在某条路径上采用的是单一验证者配置。也就是说：单个DVN的证明即足以让跨链消息——通常是铸币或解锁指令——在目标链上被执行。没有第二个独立验证者的异议能够阻止消息通过。只要那一个验证者签名，消息就会被执行。
这本身并非漏洞。LayerZero允许这种配置。历史上，不少大型集成方在低流量路径上运行过类似设置，因为增加额外DVN会带来成本和运营开销。这是一种权衡：更便宜、更简单、更快速——但对该单一方的失陷毫无容错能力。
漏洞解剖
根据公开声明和协议自身的事后沟通，攻击过程的机制呈现出清晰的规律。
攻破单一验证者
攻击者没有破解LayerZero的合约，也没有利用Kelp金库中的Solidity漏洞。他们获得了让唯一配置的DVN为从未在源链发出的消息签署证明的能力。实质上：一条伪造的跨链消息，由目标合约被告知要信任的那一方签名。
一旦这一原语成立，后续的攻击便顺理成章。攻击者构造消息，指示目标链向其控制的地址释放或铸造资产。DVN签名，Executor投递，目标合约按其设计行事，接受了已签名的消息并转移了资金。
公开报道和LayerZero的声明将验证者失陷归因于一系列操作层面的失误，最终导致攻击者控制了签名密钥。重要的是，这不是密码学层面的攻破。签名方案按设计正常运作；只是错误的人持有了密钥。
为何目标合约未能拦截
如果当时要求第二个独立DVN，它就没有理由为一条在源链上根本不存在的消息作证。它的异议将阻止达到法定人数，目标合约也会拒绝执行。
这是结构性的关键所在。目标合约对链A没有任何感知，它只能依赖其配置的验证者告诉它什么。如果你只配置一个验证者，就等于将定义应用”事实真相”的权力委托给了这单一一方。这不是消息传输层，这是一个受信任的预言机。
DVN中的”去中心化”指的是更广泛的验证者市场，而非对任一条具体消息的验证行为。单一DVN配置从应用角度看就是单一预言机配置。无论品牌如何包装，它承担的是单一预言机风险。
“默认安全”究竟意味着什么
LayerZero的文档和开发者关系立场中有一个反复出现的主题：存在”默认”DVN配置——由知名验证者组成、具有合理法定人数的集合——集成方可以直接采用，无需定制配置。这一初衷是好的：拉高基准线，让普通集成方默认拥有合理的配置，而不是自己拼凑。
但在可配置系统中，“默认”有其特定含义，而这个含义与集成方的理解之间的落差，正是事故滋生之处。
默认配置不是强制约束
默认只是起点，而非限制。集成方一旦完成部署，就可以随时通过治理或操作密钥修改其DVN配置（具体取决于访问控制的接线方式）。协议层面没有任何不变量规定”应用不得将安全性降至X阈值以下”。如果应用所有者可以改写配置，那么配置的强度只取决于控制它的密钥的强度。
这一点很重要，因为配置会随时间漂移。一个团队可能以健全的多DVN配置起步，然后为了节省成本在流量较低的路径上将其精简，之后随着该路径承载的价值增加，却忘记了这种不对称性的存在。或者——正如此次事件中似乎发生的——在小规模部署时合理的配置，从未随着部署规模的增长而被重新评估。
默认配置是路径特定的
跨链应用通常有许多路径：消息可以流通的链对。配置是按路径设置的。一个协议可以在主要的以太坊-Arbitrum路径上配置得很健全，却在一条三级链的路径上配置不足，而这条路径同样共享铸币权限。攻击者只需找到最薄弱的路径。最强路径的强度无关紧要。
这是经典安全格言在跨链场景下的等价表述：攻击者攻击配置最薄弱的路径，而非平均水平的路径。在拥有N条路径的协议中，系统安全性受所有N条路径中最差配置的约束。
默认配置以模糊方式转移责任
当消息协议提供默认配置但允许覆盖时，最终配置的责任以一种在事后颇具争议的方式被分割。LayerZero公开承认共同承担责任是不寻常的，恰恰因为常规说法——“你自己选的验证者”——本可以拿来用。他们没有完全依赖这一说辞，这表明一种内部认知：提供一个可能导致灾难性后果的配置选项，却没有清晰地揭示其影响，本身就是一种失职。
这是一个有价值的先例。模块化、可配置的安全栈并不是将判断外包给集成方的方式，而是将其分散的方式。当这种分散校准不当——当集成方没有足够的信息或专业能力做出正确选择——协议就要共同承担由此产生的后果。
操作层：密钥、设备与个人-机构边界
在架构层故事之下，有一个操作层故事受到的关注较少，但在某种程度上更具启示意义。据对此次事件的报道，签名密钥链的失陷涉及一个硬件钱包，该钱包在被用于验证者基础设施的操作签名之前，曾在某个时间点用于个人交易。
我们在此刻意对具体细节保持谨慎，因为操作层面的公开记录稀少且部分来自二手信息。但这种宽泛的模式——设备或助记词跨越个人与机构边界——在加密行业的运营中极为普遍，其隐含的失败模式也已有充分认识，因此这次事件值得作为一类已知风险的典型案例加以审视。
为何边界至关重要
硬件钱包的安全保障在于隔离：助记词永不离开设备，签名需要物理确认。这些保障能抵御远程软件攻击，但无法抵御以下情况：
- 同一个用户将相同的助记词导入另一台设备上的另一个钱包，只是为了”查一下余额”或签一笔交易。
- 助记词被输入到伪装成合法签名界面的钓鱼页面。
- 设备的恢复短语被写下来，存放在家庭级攻击者可以接触到的地方。
- 用于与设备交互的电脑遭到入侵，在签名本身仍由硬件完成的情况下影响交易的构造过程。
当设备成为某人个人生活的一部分——用于零售交易、NFT铸造、空投领取或与未经审计合约的投机性交互——上述每一种失败模式的发生概率都更高；而专用设备在受限的操作流程中使用时则不同。
验证者层的操作纪律
全链协议的验证者基础设施，功能上等同于验证者基础设施——它签署的声明会驱动真实价值的流动。对其的操作纪律期望，应当类似于对链验证者或国库多签签名者的要求，而非个人热钱包所能接受的标准。
这种纪律至少意味着：专用设备，绝不用于任何其他用途；在签名流程允许的情况下，采用气隙或HSM支持的密钥存储；明确的密钥轮换和撤销程序；职责分离，确保没有任何单一操作员能够同时授权并执行签名事件；以及定期证明这些控制措施到位。
当单一验证者是下游协议的全部安全模型时，该验证者的操作标准必须反映这一事实。将事实真相委托给单一一方的配置，隐含地要求那一方以验证者级别的纪律运营。
复合失败
使这次事件在结构上引人深思的，是两种截然不同的失败以乘法而非加法的方式叠加。
单一验证者配置是糟糕的。签名密钥的操作层面失陷是糟糕的。但任何单独一个都不是灾难性的：健全的多DVN配置可以容忍单个验证者被攻破；密钥保持安全的单一验证者则不会产生事件。
正是这两者的交叉——选择了单一验证者配置的协议，恰好遇上了其验证者密钥被攻破——才产生了2.92亿美元的损失。在一个有N个应用各自独立做出配置选择、M个验证者各自独立进行操作管理的世界里，只需要一对（应用，验证者）同时发生失败，就足以引发这种规模的事件。
这就是单一验证者配置代表的结构性风险：不是它们一定会失败，而是随着此类配置数量的线性增长，整个生态系统的失败集也在线性扩大，而任何单次失败的后果都是全损。
可比事件与跨链风险面
自2021年以来，跨链桥和消息协议整体上已成为加密行业最大的单一损失来源。Ronin、Wormhole、Nomad、Multichain、Harmony Horizon——每一个在机制上各有不同，但在结构属性上如出一辙：桥的安全性受限于某个小型委员会、多签或受信任集合，而流经其中的价值却是无上限的。
LayerZero的设计正是对这一模式的刻意回应。通过使验证者集合可按应用配置，它试图将选择——以及相应的责任——推向集成方，其理论依据是集成方会根据自身的风险敞口来校准。原则上这是正确的。TVL有限的小型应用，相比拥有数十亿存款的收益协议，合理地接受更精简的配置。
实践中，从集成方团队内部出发，这种校准很难做好。集成方必须对一套自己未曾设计的安全栈进行推理，评估其内部实践无法审计的验证者运营方，并随着自身协议风险敞口的演变重新评估配置。很少有团队具备持续严格执行这一工作的能力。结果是配置往往在上线时设置一次，此后鲜有重新审视，直到某件事迫使重新审视。
这次事件没有证明什么
有必要明确这次Kelp漏洞证明了什么，没有证明什么。
它没有证明LayerZero的核心架构存在缺陷。架构完全按规范运作：单一配置的验证者拥有单方面的证明权，它签了名，消息被执行。系统做了它被告知要做的事情。
它没有证明基于DVN的验证在根本上弱于其他消息模型。轻客户端桥、带欺诈证明的乐观桥和委员会制桥各有其失败模式，各类别的实证记录参差不齐。
它所揭示的是更窄、也更有用的东西：现代消息协议的可配置性表面包含了一些下行后果是灾难性的设置，而围绕这些设置的社会基础设施——默认值、文档、集成方教育、持续审查——没有跟上这些配置所把守的价值的增长速度。
影响与未解问题
以下几条线索值得任何构建、集成或持有全链协议敞口的人深入思考。
第一是强制最低标准的问题。 鉴于单一验证者配置所隐含的失败模式，消息协议是否应该允许集成方选择这种配置？双方各有论据。无许可的灵活性是价值主张的一部分。但一个允许某种配置、事后又承认该配置结果不可接受的协议，是在隐性地做出政策选择。一些可行的干预措施：要求单一验证者配置通过显式选项标志才能启用，而非默默地保持可用；在区块浏览器和仪表盘中突出显示配置选择，让下游用户能够看到；将默认配置与TVL阈值挂钩，在协议规模扩大时引导其增加验证者数量。
第二是审计层。 跨链配置目前不在智能合约审计的标准范围内。审计员评估应用的Solidity代码，可能还包括与消息端点的集成，但很少覆盖DVN配置本身、已配置DVN的操作实践，或应用在所有链上激活的路径。这一空白很大。一个协议可以通过三次审计，却仍然部署了一个经验丰富的桥工程师几分钟内就能发现问题的配置。将”跨链配置审查”纳入审计标准——或许作为一个独立的子学科——是一种合理的应对。
第三是验证者问责。 如果DVN的签名在某些配置下足以转移数亿美元，那么DVN在功能上就是一个金融机构。其操作实践、密钥管理、人员审查和事件响应都是公共利益所在。主动披露这些实践——理想情况下在验证者之间具有可比性——将让集成方能够做出知情选择，也让用户能够评估其协议所选择的配置。这种披露制度在链验证者领域以各种形式存在，但在DVN领域尚无实质性先例。
第四是加密运营中普遍存在的个人-机构边界问题。 此次事件——如果操作细节属实——是一个长期模式中的又一个数据点：运营关键加密基础设施的人，往往与从事个人加密活动的人是同一批人，使用重叠的硬件和重叠的思维模型。行业尚未建立强有力的规范——或强有力的机构激励——来分离这两者。随着越来越多的价值流经小型团队运营的基础设施，缺失这种分离的代价也在不断增大。
最后一个也是最令人不安的问题，是当前部署的全链应用中有多大比例持有类似的配置。我们不知道。这些配置在链上是公开的，原则上可以被枚举。据我们所知，目前不存在全面的公开注册表。如果在TVL不可忽视的协议中，单一验证者配置很普遍——考虑到部署时的默认配置通常在次级路径上偏精简，这似乎是合理的——那么这次事件是一个样本，而非离群值。在未来一年内，类似事件的预期数量，以配置普遍性为条件，下限为零，据我们所知，上限则没有任何约束。
在此次事件发生后的数月内，以下动向值得关注：LayerZero是否会推出限制配置灵活性的协议层变更；可比的消息协议（Wormhole、Axelar、Hyperlane）是否面临发布等效风险披露的压力；是否至少有一家大型集成方公布其当前DVN配置，附带理由说明和审查周期；以及审计行业是否开始默认将跨链配置纳入审计范围。上述任何一项都将表明教训正在被系统性吸收。但仅凭其中任何一项，都远远不够。
Introducción
En mayo de 2026, el despliegue omnichain de Kelp DAO fue vaciado de aproximadamente 292 millones de dólares en un único exploit coordinado. En cuestión de días, LayerZero —la capa de mensajería en la que Kelp se apoyaba para gestionar el estado entre cadenas— emitió un comunicado público reconociendo su responsabilidad en la forma en que se había configurado el stack de seguridad de la aplicación. El reconocimiento fue inusual. Los protocolos de mensajería suelen presentarse como tuberías neutrales cuya seguridad es responsabilidad del integrador. En este caso, el propio comunicado del protocolo admitía que una configuración considerada aceptable en el momento del despliegue resultó, en retrospectiva, insuficiente —y que la carga de detectarlo se había distribuido de una manera que terminó fallando.
Queremos analizar este incidente con seriedad, como caso de estudio, no como un relato moralizador. Las preguntas interesantes no son si alguien actuó con descuido. Son estructurales: ¿qué garantiza realmente el modelo de seguridad “por defecto” de un protocolo de mensajería omnichain? ¿Cómo interactúa la configurabilidad —vendida como virtud— con la realidad operacional de que la mayoría de los integradores aceptan los valores por defecto? ¿Qué aspecto tiene en la práctica una configuración con un único verificador, y por qué el modo de fallo que implica siguió siendo abstracto hasta que se movieron 292 millones de dólares? Y, finalmente, ¿qué significa que un compromiso operacional clave se haya originado, según los informes, en una hardware wallet que había sido usada en un contexto personal —un detalle que suena casi mundano hasta que se pone en perspectiva con la magnitud de la pérdida?
Este artículo recorre el incidente desde la arquitectura hasta la pulsación de teclas, y luego vuelve a ascender para examinar lo que implica para el diseño cross-chain en términos más amplios. El objetivo no es repartir culpas. Es identificar qué supuestos sobre la seguridad omnichain deben ser revisados por cualquiera que opere un protocolo con autoridad de minteo en más de una cadena.
La arquitectura, en términos claros
LayerZero es una capa de mensajería de propósito general. Un contrato inteligente en la cadena A llama al endpoint de LayerZero, el mensaje es observado fuera de la cadena, y un contrato en la cadena B recibe la instrucción de actuar en consecuencia. Entre la observación y la ejecución intervienen dos roles que constituyen juntos el modelo de confianza del protocolo: un componente DVN (Red de Verificadores Descentralizados), que certifica que el mensaje en la cadena A realmente ocurrió, y un Executor, que entrega el mensaje validado a la cadena B.
En LayerZero v2, cada aplicación elige su propia configuración de DVN. Puede elegir un único DVN, un conjunto de DVNs con un umbral N-de-M, o añadir DVNs “requeridos” y “opcionales” con reglas de quórum independientes. El protocolo incluye configuraciones por defecto que los integradores pueden adoptar tal cual, modificar o reemplazar. De forma crítica, la elección se toma por aplicación y por ruta (por par cadena-origen/cadena-destino). Un protocolo activo en seis cadenas tiene, en la práctica, decenas de pequeñas decisiones de política codificadas en sus configuraciones de endpoint.
Para el despliegue omnichain de Kelp, la configuración relevante era, en el momento del exploit, un esquema de verificador único en al menos una ruta. Es decir: la attestation de un único DVN era suficiente para que un mensaje cross-chain —típicamente una instrucción de minteo o desbloqueo— se ejecutara en la cadena de destino. No había un segundo verificador independiente cuyo desacuerdo pudiera detener el mensaje. Si ese único verificador daba el visto bueno, el mensaje pasaba.
Esto no es, en sí mismo, un bug. LayerZero permite esta configuración. Varios grandes integradores han operado históricamente con configuraciones similares, especialmente en rutas de bajo tráfico donde añadir DVNs adicionales introducía costes y complejidad operacional. La configuración es un compromiso: más barata, más simple, más rápida —y sin tolerancia a fallos ante el compromiso de esa única parte.
Anatomía del exploit
La mecánica del ataque, reconstruida a partir de declaraciones públicas y las propias comunicaciones post-incidente del protocolo, sigue un patrón limpio.
Comprometer el verificador único
El atacante no vulneró los contratos de LayerZero. No explotó ningún bug de Solidity en el vault de Kelp. Obtuvo la capacidad de hacer que el único DVN configurado firmara attestations para mensajes que nunca habían sido emitidos en la cadena de origen. En efecto: un mensaje cross-chain falsificado, firmado por la única parte en cuya firma el contrato de destino había sido instruido a confiar.
Una vez que ese primitivo existía, el resto del exploit era trivial. El atacante construyó mensajes ordenando a la cadena de destino liberar o mintear activos hacia direcciones bajo su control. El DVN firmó. El Executor entregó. El contrato de destino, haciendo exactamente lo que fue diseñado para hacer, honró el mensaje firmado y movió los fondos.
Los informes públicos y el propio comunicado de LayerZero atribuyen el compromiso del verificador a una cadena de fallos operacionales que culminó en que el atacante tomara control de las claves de firma. Es importante destacar que no se trató de una ruptura criptográfica. El esquema de firma funcionó como fue diseñado; simplemente la parte equivocada tenía la clave.
Por qué el contrato de destino no lo detectó
Un segundo DVN independiente, de haberse requerido, no habría tenido ningún motivo para certificar un mensaje que no existía en la cadena de origen. Su desacuerdo habría impedido alcanzar el quórum. El contrato de destino se habría negado a actuar.
Este es el punto estructural. El contrato de destino no tiene visibilidad sobre la cadena A. Solo sabe lo que sus verificadores configurados le dicen. Si configuras un único verificador, le has delegado a esa sola parte la autoridad de definir la verdad objetiva para tu aplicación. Eso no es una capa de mensajería; es un oráculo de confianza.
Lo “descentralizado” del DVN se refiere al mercado más amplio de verificadores, no a la verificación de ningún mensaje individual. Una configuración con un único DVN es, desde la perspectiva de la aplicación, una configuración de oráculo único. Independientemente de su denominación, conlleva el riesgo de un oráculo único.
Qué significa realmente la “seguridad por defecto”
Un tema recurrente en la documentación de LayerZero y en su posicionamiento hacia los desarrolladores ha sido la existencia de configuraciones DVN “por defecto” —conjuntos de verificadores reconocidos, con quórums razonables, que un integrador puede adoptar sin trabajo de configuración personalizado—. La intención es buena: elevar el suelo, para que el integrador mediano publique una configuración razonable en lugar de construir la suya desde cero.
Pero “por defecto” en un sistema configurable significa algo específico, y la brecha entre ese significado y cómo lo perciben los integradores es donde se incuban los incidentes.
Los valores por defecto no se imponen
Un valor por defecto es un punto de partida, no una restricción. Una vez que un integrador despliega, puede cambiar su configuración DVN en cualquier momento, a través de gobernanza o claves operacionales según cómo haya configurado el acceso. No existe ningún invariante a nivel de protocolo que diga “una aplicación no puede reducir su seguridad por debajo del umbral X.” Si el propietario de la aplicación puede reescribir la configuración, esta es tan sólida como las claves que la controlan.
Esto importa porque las configuraciones se degradan con el tiempo. Un equipo puede comenzar con una configuración multi-DVN robusta, luego simplificarla en una ruta menos transitada para ahorrar costes, y después olvidar que esa asimetría existe cuando la ruta acaba acumulando valor significativo. O —como parece haber ocurrido aquí— una configuración razonable para un despliegue pequeño nunca se reevalúa a medida que el despliegue crece.
Los valores por defecto son específicos por ruta
Las aplicaciones cross-chain suelen tener muchas rutas: pares de cadenas a través de los cuales pueden fluir mensajes. Las configuraciones son por ruta. Un protocolo puede estar bien configurado en su ruta principal Ethereum-Arbitrum y con una configuración insuficiente en una cadena terciaria que, no obstante, comparte autoridad de minteo. Un atacante solo necesita encontrar la ruta más débil. La solidez de la ruta más fuerte es irrelevante.
Este es el equivalente cross-chain de un axioma clásico de seguridad: el atacante ataca la ruta configurada más débil, no el promedio. En un protocolo con N rutas, la seguridad del sistema está acotada por la peor configuración entre todas las N.
Los valores por defecto distribuyen la responsabilidad de forma ambigua
Cuando un protocolo de mensajería provee valores por defecto pero permite modificarlos, la responsabilidad por la configuración resultante queda repartida de una manera que se vuelve disputada tras un incidente. El reconocimiento público de LayerZero de que comparte responsabilidad es inusual precisamente porque el argumento convencional —“tú elegiste tus verificadores”— estaba disponible. El hecho de que no se aferrasen completamente a ese argumento sugiere un reconocimiento interno de que ofrecer una opción de configuración que puede producir resultados catastróficos, sin hacer evidentes sus implicaciones, es también una forma de fallo.
Esto sienta un precedente útil. Los stacks de seguridad modulares y configurables no son una forma de externalizar el juicio al integrador. Son una forma de distribuirlo. Cuando esa distribución está mal calibrada —cuando el integrador no tiene la información ni la experiencia para tomar la decisión correctamente— el protocolo comparte las consecuencias.
La capa operacional: claves, dispositivos y la frontera entre lo personal y lo institucional
Por debajo de la historia arquitectónica existe una historia operacional que ha recibido menos atención pero que es, en ciertos aspectos, más instructiva. Según los informes sobre el incidente, el compromiso de la cadena de claves de firma involucró una hardware wallet que en algún momento había sido utilizada en un contexto de trading personal antes de ser empleada para la firma operacional de la infraestructura de verificadores.
Somos deliberadamente cautos sobre los detalles aquí, porque el registro público sobre los aspectos operacionales es escaso y parcialmente de segunda mano. Sin embargo, el patrón general —un dispositivo o semilla cruzando la frontera entre uso personal e institucional— es tan común en las operaciones cripto, y el modo de fallo que implica está tan bien documentado, que merece examinar este incidente como una instancia de una clase de riesgo conocida.
Por qué importa esa frontera
Las garantías de seguridad de una hardware wallet se basan en el aislamiento: la semilla nunca abandona el dispositivo, y firmar requiere confirmación física. Esas garantías protegen contra ataques remotos por software. No protegen contra:
- La misma semilla siendo importada a otra cartera, en otro dispositivo, por el mismo usuario, “solo para revisar un saldo” o firmar una transacción.
- La semilla siendo introducida en una interfaz de phishing que imita una interfaz de firma legítima.
- La frase de recuperación del dispositivo siendo anotada y almacenada en un lugar accesible a un atacante del entorno doméstico.
- Un ordenador utilizado para interactuar con el dispositivo siendo comprometido de formas que afectan a la construcción de transacciones incluso cuando la firma en sí permanece vinculada al hardware.
Cada uno de estos modos de fallo es más probable cuando el dispositivo forma parte de la vida personal de alguien —cuando lo usa para trading minorista, minteos de NFT, reclamaciones de airdrops o interacciones especulativas con contratos no auditados— que cuando está construido específicamente para ese fin y opera dentro de un flujo de trabajo operacional restringido.
Disciplina operacional en la capa de verificadores
La infraestructura de verificadores para un protocolo omnichain es, funcionalmente, infraestructura de validador. Firma declaraciones que mueven valor real. La disciplina operacional que se le exige debería parecerse a la que se espera de un validador de cadena o de un firmante multisig de una tesorería, no a lo que resulta aceptable para una hot wallet personal.
Esa disciplina implica, como mínimo: dispositivos dedicados que nunca se usan para ningún otro propósito; almacenamiento de claves con air-gap o respaldado por HSM donde el flujo de trabajo de firma lo permita; procedimientos claros para la rotación y revocación de claves; segregación de funciones para que ningún operador individual pueda tanto autorizar como ejecutar un evento de firma; y verificación rutinaria de que estos controles están en vigor.
Cuando un único verificador es el modelo de seguridad completo de un protocolo de destino, los estándares operacionales de ese verificador deben reflejar ese hecho. Una configuración que delega la verdad objetiva a una sola parte es, implícitamente, un contrato de que esa parte operará con una disciplina equiparable a la de un validador.
El fallo compuesto
Lo que hace que este incidente sea estructuralmente interesante es que dos fallos distintos se combinaron de forma multiplicativa en lugar de aditiva.
Una configuración de verificador único es problemática. El compromiso operacional de una clave de firma es problemático. Cualquiera de los dos por separado no es catastrófico: una configuración multi-DVN robusta tolera un verificador comprometido, y un verificador único cuyas claves permanecen seguras no produce un incidente.
Es la intersección —el mismo protocolo que eligió una configuración de verificador único resultó ser también aquel cuyas claves del verificador fueron comprometidas— lo que produce los 292 millones de dólares. En un mundo con N aplicaciones tomando decisiones de configuración independientes y M verificadores con prácticas operacionales independientes, basta con que un par (aplicación, verificador) coincida en el fallo para que se produzca un incidente de esta magnitud.
Este es el riesgo estructural que representan las configuraciones de verificador único: no que vayan a fallar, sino que el conjunto de fallos posibles en el ecosistema crece linealmente con el número de tales configuraciones, y las consecuencias de cualquier fallo individual son totales.
Incidentes comparables y la superficie de riesgo cross-chain
Los bridges cross-chain y los protocolos de mensajería han sido, colectivamente, la mayor fuente individual de pérdidas en cripto desde 2021. Ronin, Wormhole, Nomad, Multichain, Harmony Horizon —cada uno fue diferente en su mecanismo, pero todos comparten una propiedad estructural: la seguridad del bridge estaba acotada por algún pequeño comité, multisig o conjunto de confianza, mientras que el valor que circulaba a través de él era ilimitado.
El diseño de LayerZero fue una respuesta deliberada a ese patrón. Al hacer que el conjunto de verificadores fuera configurable por aplicación, buscaba trasladar la elección —y la responsabilidad correspondiente— hacia el integrador, bajo la teoría de que estos calibrarían según su propio valor en riesgo. En principio, esto es correcto. Una aplicación pequeña con TVL limitado podría razonablemente aceptar una configuración más austera que un protocolo con rendimiento y miles de millones en depósitos.
En la práctica, esa calibración es difícil de realizar bien desde dentro de un equipo integrador. El integrador tiene que razonar sobre un stack de seguridad que no diseñó, evaluar operadores de verificadores cuyas prácticas internas no puede auditar, y reevaluar la configuración a medida que el valor en riesgo de su propio protocolo evoluciona. Pocos equipos tienen la capacidad permanente para hacer esto con rigor. El resultado es que las configuraciones tienden a establecerse una vez en el lanzamiento y rara vez se revisan hasta que algo fuerza esa revisión.
Lo que este incidente no demuestra
Vale la pena ser precisos sobre lo que el exploit de Kelp demuestra y lo que no.
No demuestra que la arquitectura central de LayerZero esté rota. La arquitectura funcionó exactamente como se especificó: un único verificador configurado tenía autoridad de attestation unilateral, ese verificador firmó y el mensaje fue ejecutado. El sistema hizo lo que se le dijo.
No demuestra que la verificación basada en DVN sea fundamentalmente más débil que modelos alternativos de mensajería. Los bridges basados en clientes ligeros, los bridges optimistas con pruebas de fraude y los bridges basados en comités tienen todos sus propios modos de fallo, y el historial empírico entre categorías es mixto.
Lo que demuestra es algo más acotado y más útil: que la superficie de configurabilidad de los protocolos de mensajería modernos incluye ajustes cuyo peor caso es catastrófico, y que la infraestructura social en torno a esos ajustes —valores por defecto, documentación, formación de integradores, revisión continua— no ha seguido el ritmo del valor que esas configuraciones custodiann.
Implicaciones y preguntas abiertas
Vale la pena seguir algunos hilos para cualquiera que construya, integre o tenga exposición a protocolos omnichain.
El primero es la cuestión de los mínimos obligatorios. ¿Debería un protocolo de mensajería permitir que un integrador configure un único verificador, dado el modo de fallo que eso implica? Existen argumentos en ambas direcciones. La flexibilidad sin permisos es parte de la propuesta de valor. Pero un protocolo que permite una configuración cuyo modo de fallo reconoce posteriormente como inaceptable está tomando implícitamente una decisión de política. Algunas intervenciones plausibles: exigir que las configuraciones de verificador único requieran flags explícitos de opt-in en lugar de estar silenciosamente disponibles; hacer visible la elección de configuración en block explorers y dashboards para que los usuarios del protocolo puedan verla; vincular las configuraciones por defecto a umbrales de TVL de modo que los protocolos en crecimiento sean empujados hacia verificadores adicionales a medida que el valor aumenta.
El segundo es la capa de auditoría. Las configuraciones cross-chain no forman hoy parte del alcance estándar de las auditorías de contratos inteligentes. Un auditor evalúa el Solidity de la aplicación, posiblemente la integración con el endpoint de mensajería, pero raramente la configuración DVN en sí, las prácticas operacionales de los DVNs configurados, o las rutas que la aplicación tiene activas en todas las cadenas. Esta brecha es amplia. Un protocolo puede pasar tres auditorías y aun así desplegar una configuración que un ingeniero de bridges experimentado señalaría en minutos. Incorporar la “revisión de configuración cross-chain” al estándar de auditoría —quizás como una sub-disciplina separada— es una respuesta plausible.
El tercero es la rendición de cuentas de los verificadores. Si la firma de un DVN es, en algunas configuraciones, suficiente para mover cientos de millones de dólares, entonces el DVN funciona como una institución financiera. Sus prácticas operacionales, gestión de claves, selección de personal y respuesta a incidentes son asuntos de interés público. La divulgación voluntaria de estas prácticas, idealmente de forma comparable entre verificadores, permitiría a los integradores tomar decisiones informadas y a los usuarios evaluar las configuraciones que sus protocolos han seleccionado. Este es el tipo de régimen de divulgación que existe, en diversas formas, en torno a los validadores de cadena. Aún no existe de forma significativa en torno a los DVNs.
El cuarto es la frontera personal-institucional en las operaciones cripto en general. Este incidente, si los detalles operacionales se confirman, es otro punto de datos en un patrón largo: las personas que operan infraestructura cripto de consecuencias son con frecuencia las mismas que llevan a cabo actividad cripto personal, en hardware superpuesto y con modelos mentales superpuestos. La industria no ha construido normas sólidas —ni incentivos institucionales sólidos— para separar ambas esferas. A medida que más valor fluye a través de infraestructura operada por equipos pequeños, el coste de esa separación ausente crece.
La pregunta final y más incómoda es qué proporción de las aplicaciones omnichain actualmente desplegadas tienen configuraciones análogas. No lo sabemos. Las configuraciones son públicas en la cadena y podrían en principio ser enumeradas. Que sepamos, no existe ningún registro público comprehensivo. Si las configuraciones de verificador único son comunes entre protocolos con TVL no trivial —lo cual parece plausible dado que los valores por defecto en el momento del despliegue a menudo implicaban configuraciones austeras en rutas secundarias— entonces este incidente es una muestra, no una anomalía. El número esperado de incidentes similares en el próximo año, condicionado a la prevalencia de esas configuraciones, está acotado por cero por abajo y, hasta donde podemos ver, por nada por arriba.
Lo que observaríamos en los meses siguientes a este incidente: si LayerZero lanza cambios a nivel de protocolo que restrinjan la superficie de configurabilidad; si protocolos de mensajería comparables (Wormhole, Axelar, Hyperlane) enfrentan presión para publicar divulgaciones de riesgo equivalentes; si al menos un integrador importante publica su configuración DVN actual con una justificación y una cadencia de revisión; y si la industria de auditoría comienza a tratar la configuración cross-chain como parte del alcance estándar. Cualquiera de estos sería una señal de que la lección se está asimilando de forma estructural. Ninguno de ellos, por sí solo, sería suficiente.