Introduction
Cross-chain messaging protocols sit at an awkward place in the crypto stack. They are infrastructure — invisible when working, catastrophic when not — and they secure more value than most of the applications built on top of them. When a bridge fails, the failure mode is rarely subtle: an attacker mints assets on one chain without the corresponding lock on another, and the difference becomes someone’s loss.
The recent Kelp DAO incident on LayerZero is worth examining not because it exposed a novel vulnerability, but because it exposed something more uncomfortable: a configuration choice that nobody outside the integration was scrutinizing, paired with an operational lapse that any security review would have caught if it had been looking. LayerZero issued a public apology in November 2025 and acknowledged that the application had been configured with a single verifier, and that the key controlling that verifier had been used in a context it should never have touched.
The technical question — how does a message get from chain A to chain B and who decides it is valid — is the same question every cross-chain protocol answers, and each answer is a different trust model. LayerZero’s answer is unusually flexible: the application chooses. That flexibility is the protocol’s selling point and, in this case, the source of the failure. We want to walk through what the security stack actually is, how the Kelp configuration deviated from a defensible setup, what the operational failure tells us about key management practices among integrators, and what a more conservative default would look like.
This is a post-mortem, not a verdict on LayerZero as a protocol. The architectural questions it raises apply to every messaging layer that delegates verification choices downstream.
How LayerZero’s security stack actually works
LayerZero is best understood not as a bridge but as a generic messaging protocol. An application on one chain emits a message; the protocol delivers a payload to a counterpart contract on another chain; the counterpart decides what to do with it. The protocol itself does not custody assets. The applications that integrate it — token bridges, omnichain fungible token (OFT) deployments, governance relays — do.
The protocol separates three concerns that earlier bridge designs tended to bundle together.
Verification is the question of whether a message claimed to originate on chain A actually did. In LayerZero V2, this is handled by one or more Decentralized Verifier Networks (DVNs). A DVN is an off-chain service that watches the source chain, attests to messages it sees, and submits those attestations to the destination chain. Multiple DVNs can be configured per pathway, and the application sets a threshold: how many of the configured DVNs must agree before a message is considered verified.
Execution is the question of who pays the gas and triggers the destination-side delivery once verification is complete. Executors are economically incentivized but cannot forge messages — they can only deliver ones that have already been verified.
Application logic sits above both. The destination contract receives the verified payload and decides what to do — mint, burn, update state, forward to another contract.
The critical design choice is that the verifier configuration is per-application. Two different applications using LayerZero on the same chain pair can have entirely different security assumptions. One might require attestations from five independent DVNs; another might require one. The protocol does not enforce a minimum.
This is, in principle, defensible. Applications have different threat models and different cost tolerances. A high-throughput, low-value gaming bridge might reasonably accept a thinner verification set than a multi-billion-dollar liquid restaking token. The protocol leaves the choice to the integrator.
In practice, it means the security of any LayerZero pathway is exactly the security of the weakest verifier set chosen by the application using it — and that the choice is visible on-chain but rarely audited by anyone other than the integrator itself.
The single-verifier configuration
A defensible DVN configuration looks something like this: at least two operationally independent verifiers, each running infrastructure that does not share keys, hosting, monitoring stack, or operator with the others. A threshold requiring all configured verifiers to agree. Ideally, a third “optional” DVN with a higher threshold for high-value messages, or a timelock between verification and execution that gives an external party time to challenge.
The Kelp DAO pathway was not configured that way. By LayerZero’s own account, the application had a single DVN responsible for attesting messages on the affected route. That single signer was sufficient to verify any message claiming to originate from the source contract.
The implication of that configuration is worth stating plainly. Whoever controlled the signing key for that DVN could, in isolation, attest to any message of their choosing. They did not need to compromise a quorum. They did not need to coordinate with anyone. They needed only the key — and once the key signed an attestation that a particular cross-chain message had occurred, the destination contract had no way to distinguish it from a legitimate one.
This is structurally equivalent to a 1-of-1 multisig protecting whatever the destination contract is authorized to do. In the Kelp DAO case, the destination contract was authorized to issue restaked-asset representations on a remote chain. The 1-of-1 multisig, effectively, protected the issuance authority for those representations.
It is tempting to call this a vulnerability. It was not, in the technical sense. The contracts behaved exactly as configured. The verifier produced an attestation; the destination contract accepted it; the issuance happened. Every piece of code in the chain of custody did what it was supposed to do. The failure was upstream of the code — in the choice of how many independent attesters the application required.
Why applications choose thin configurations
It would be easy to attribute the configuration to negligence, and in some cases that may be accurate. But there are real reasons applications end up with thinner verifier sets than they should have.
The first is cost. Each additional DVN adds a per-message fee. For high-throughput applications, the difference between one and three verifiers compounds into meaningful operational expense.
The second is latency. Verifiers attest asynchronously, and the destination-side message is gated on the slowest one to reach threshold. More verifiers means more variance and a longer tail.
The third is operational simplicity. Each additional DVN is another counterparty, another monitoring surface, another point of potential downtime that can stall the entire pathway. Applications optimizing for uptime sometimes choose simpler configurations and accept the trust tradeoff, often without explicitly modeling it as a tradeoff.
The fourth, and most uncomfortable, is that the default configurations new integrators inherit are not always well-tuned to the value the integration will eventually secure. An application that launches with modest TVL and grows into a much larger one may carry forward a configuration that was reasonable at launch and is no longer reasonable at scale. Reviewing and tightening that configuration as a function of TVL is not a process most teams have institutionalized.
The operational failure: a key with two jobs
The configuration alone would have been a latent risk. What turned it into a realized loss was an operational failure that the public apology described in unusually direct terms: the wallet controlling the verifier was used by someone at LayerZero — or in the operating orbit of the verifier — to perform a personal trade. The trade flow exposed the wallet to a context it was not hardened against, and the signing capability was compromised.
We do not have a forensic public account of the exact compromise vector. What we do have is the category of failure, which is recognizable. A wallet that controls production infrastructure should never sign anything other than production messages. The moment it interacts with a frontend, a smart contract approval, a DEX swap, or any third-party transaction signing flow, it inherits the entire attack surface of that flow: phishing, malicious approval signatures, compromised frontends, supply-chain attacks against the wallet software itself.
The standard practice — well-documented across institutional custody, validator operations, and protocol engineering — is that signing keys for privileged infrastructure live in hardware modules dedicated to that single purpose, on machines that do not browse the internet, in workflows that do not involve any human-initiated transactions outside the production message format. A verifier signing key should look more like a validator key than a personal wallet.
That this principle was violated by personnel close to a protocol whose entire value proposition is messaging security is the part of the post-mortem that should give every cross-chain integrator pause. It is not because LayerZero’s team is uniquely careless — there is no public evidence of that, and the willingness to publish a candid account suggests the opposite — but because the principle is widely understood and was nonetheless violated. The gap between knowing a practice and institutionalizing it is wider than most organizations admit.
What the post-mortem disclosed and what it left open
The public apology acknowledged two things directly: that the verifier configuration was thinner than it should have been for the value at stake, and that the operational separation of the verifier key from personal activity broke down. Those are the structural admissions.
Several things remain less clear from public sources. The full scope of impacted users and the exact dollar value of the realized loss have been reported in ranges that vary across coverage. The remediation pathway — who absorbs the loss, what role the affected application’s treasury plays, and what protocol-level changes follow — is the kind of thing that typically resolves over weeks, not days. We are deliberately not assigning specific figures here; the qualitative shape of the incident matters more for the architectural analysis than the precise number does, and the number itself is the kind of claim that should not be made without a sourceable anchor.
What the exploit message actually did
The mechanical sequence of an exploit like this is straightforward once the verifier is compromised, and worth tracing because it illustrates how little additional surface is required.
The attacker, in control of the compromised signing key, constructs an attestation for a message that was never emitted on the source chain. The attestation is well-formed: it carries the signature the destination-side verification contract expects to see, and it references a source-chain transaction that either does not exist or whose payload has been altered. The attestation is submitted to the destination chain through normal channels.
The destination-side verification contract checks the signature against the configured DVN set. Because the configured set contains only the compromised key, and the signature is valid against that key, verification passes. The message is marked as verified.
An executor — possibly the attacker themselves, possibly an unwitting third party responding to the standard executor incentive — picks up the verified message and delivers it to the destination application contract. The application contract sees a verified message claiming to originate from its trusted source-chain counterpart, and acts on it: in the Kelp DAO case, by treating the message as evidence that assets had been deposited on the source chain and that corresponding representations should be issued on the destination chain.
The representations are then sold or swapped through whatever liquidity venues exist for them on the destination chain. By the time the discrepancy is noticed — by the application’s monitoring, by external observers comparing source-chain locked balances against destination-chain issued supply — the attacker has converted the unbacked issuance into liquid assets, and the loss has crystallized in the form of representations that no longer have collateral behind them.
The asymmetry to notice here is that the entire exploit path runs through standard protocol behavior. Nothing was hacked in the colloquial sense — no contract was tricked, no logic was broken. A message was signed by the key authorized to sign it. The system did exactly what it was configured to do. The failure was that the configuration treated a single key as sufficient evidence for a multi-million-dollar issuance authority.
What a defensible verifier architecture looks like
The reactive answer is “more verifiers”, and that is part of the answer, but only part. The deeper requirement is independence of failure modes — multiple verifiers whose simultaneous compromise requires more than running the same compromise twice.
A defensible configuration for an application securing meaningful value should, at minimum, exhibit several properties.
Operational independence between verifiers. Different organizations, different signing infrastructure, different key custody arrangements, different cloud providers or hosting environments. Two verifiers run by the same team on the same infrastructure are not two verifiers; they are one verifier with a redundant signature.
Threshold sized to the threat model, not the cheapest viable number. A threshold of 2-of-3 is meaningfully different from 1-of-2, and both are meaningfully different from 1-of-1. The choice should be a function of the value at risk on the pathway, not the default that minimizes per-message cost.
Heterogeneity of verifier implementation. Verifiers running identical software share bugs. A configuration that includes verifiers running different client implementations — analogous to how Ethereum’s consensus layer benefits from client diversity — is robust against software-level compromises that would take down a homogeneous set.
Timelocks and challenge windows for high-value messages. A short delay between verification and execution, during which an external watcher can flag inconsistencies between source-chain state and the claimed message, converts a single-shot exploit into a contested one. For applications where minutes of latency are acceptable, this is one of the cheapest defenses available.
Public, monitorable configurations. The DVN set and threshold for any LayerZero application are visible on-chain. They are rarely surfaced in user-facing documentation or in third-party dashboards. A norm where integrators publish and justify their security configuration, and where external researchers routinely audit it against the value at stake, would surface mismatches before exploits do.
Where this leaves the protocol layer
LayerZero, as a protocol, has consistently positioned the flexibility of its verifier configuration as a feature: applications can tune their security stack to their needs. The Kelp incident does not contradict that positioning, but it does sharpen a question the protocol layer cannot fully delegate.
If the configuration choice rests with the application, and applications systematically under-configure relative to the value they end up securing, then “flexibility” is a polite description of an externality. The integrator captures the cost savings of a thin configuration; the protocol’s reputation absorbs the consequences when the configuration fails. Whether the right correction is a protocol-level minimum, a recommended-default with prominent warnings on deviation, or a value-indexed configuration requirement is an open design question. Each has tradeoffs that cut against the protocol’s broader thesis of permissionless integration.
What seems harder to defend, after this incident, is the status quo: a configuration surface where the difference between a defensible setup and a single-key vulnerability is invisible to end users and largely invisible to the broader market until a compromise crystallizes it.
Implications and open questions
The Kelp DAO incident is most instructive as a case study in how cross-chain trust assumptions are actually distributed. The marketing surface of a messaging protocol describes a network — decentralized verifiers, separated concerns, threshold security. The realized surface, for any given application, is whatever subset of that network the application chose to use, and whatever operational practices the operators of that subset actually follow.
For integrators, the immediate lesson is that the security configuration of a cross-chain pathway is not a one-time setup decision. It is a parameter that should be reviewed as a function of the value flowing through it, and tightened — possibly significantly — as that value grows. The defaults under which a pathway is launched are almost never the defaults under which it should operate at scale.
For users of cross-chain applications, the harder lesson is that the trust surface is not visible from the application’s front-end. A token wrapped through one messaging protocol may sit behind a 5-of-7 verifier set; a token wrapped through nominally the same protocol may sit behind a 1-of-1. The user-visible interface is identical. The economic risk is not.
Several questions extend beyond this specific incident and are worth watching.
How will competing messaging protocols — those positioning around shared security, restaking-backed verification, or zero-knowledge proof systems that move verification on-chain — frame their differentiation in the wake of this? The marketing pressure to claim “no trusted verifiers” will increase. The technical claims will need to be examined carefully; many of them shift the trust assumption rather than eliminate it.
Will any meaningful share of LayerZero integrators publish their DVN configurations alongside their TVL, as a matter of routine disclosure? The information is on-chain, but normalization matters. A standard that surfaces the security parameter at the same level of prominence as a yield rate would change which configurations are tolerated by sophisticated capital.
How does the operational-security failure component generalize? The same class of mistake — a key with one job being used for a second — is a recurring failure mode across multisig signers, validator operators, and bridge teams. The fact that it persists despite being well-understood suggests the gap is institutional rather than informational, and the question of what institutional structures actually prevent it remains largely unanswered in the crypto industry.
The simplest reading of the Kelp DAO incident is that a single point of failure failed. The more useful reading is that single points of failure are still being deployed in production, by sophisticated teams, securing meaningful value, in 2025 — and that the architecture making that possible is a feature, not a bug, of the messaging layer they run on. Whether that feature continues to be defensible is, after this incident, an open question rather than a settled one.
들어가며
크로스체인 메시징 프로토콜은 크립토 스택 안에서 다소 어정쩡한 자리를 차지한다. 이들은 인프라다 — 정상적으로 작동할 때는 눈에 띄지 않고, 고장 날 때는 치명적인. 그리고 그 위에서 돌아가는 애플리케이션들보다 훨씬 많은 가치를 보호하고 있다. 브릿지가 실패하면, 그 실패 방식은 좀처럼 조용하지 않다. 공격자가 한 체인에서는 자산을 잠그지도 않고 다른 체인에서 그에 상응하는 자산을 발행하고, 그 차이는 누군가의 손실이 된다.
최근 LayerZero에서 발생한 Kelp DAO 사건은 새로운 취약점이 드러나서가 아니라 더 불편한 무언가가 드러났기 때문에 면밀히 살펴볼 가치가 있다. 바로 통합팀 외에는 아무도 들여다보지 않았던 하나의 설정 선택과, 제대로 된 보안 검토가 이루어졌다면 진작 포착했을 운영상의 실수가 맞물렸다는 점이다. LayerZero는 2025년 11월 공개 사과문을 발표하며, 해당 애플리케이션이 단일 검증자로 구성되어 있었고 그 검증자를 제어하는 키가 절대 닿아서는 안 될 컨텍스트에서 사용되었음을 인정했다.
체인 A에서 체인 B로 메시지를 전달하는 주체는 누구이며 그것이 유효하다고 판단하는 것은 누구인가 — 이 기술적 질문은 모든 크로스체인 프로토콜이 각자의 방식으로 답해야 하는 것이고, 각각의 답은 서로 다른 신뢰 모델을 의미한다. LayerZero의 답은 유달리 유연하다: 애플리케이션이 선택한다. 그 유연성이 이 프로토콜의 셀링 포인트이자, 이번 사건에서는 실패의 근원이었다. 이 글에서는 실제 보안 스택이 어떻게 구성되어 있는지, Kelp DAO의 설정이 어떻게 합리적인 기준에서 벗어났는지, 이번 운영상의 실패가 통합 업체들의 키 관리 관행에 대해 무엇을 시사하는지, 그리고 보다 보수적인 기본값이 어떤 모습이어야 하는지를 차례로 살펴보고자 한다.
이 글은 사후 분석이지, LayerZero 프로토콜 자체에 대한 판결이 아니다. 이 글이 제기하는 아키텍처적 질문들은 검증 선택을 하위 계층에 위임하는 모든 메시징 레이어에 동일하게 적용된다.
LayerZero의 보안 스택이 실제로 작동하는 방식
LayerZero는 브릿지가 아니라 범용 메시징 프로토콜로 이해하는 것이 적절하다. 한 체인의 애플리케이션이 메시지를 내보내면, 프로토콜이 다른 체인의 상대방 컨트랙트에 페이로드를 전달하고, 상대방이 그것으로 무엇을 할지 결정한다. 프로토콜 자체는 자산을 보관하지 않는다. 자산을 보관하는 것은 LayerZero를 통합한 애플리케이션들 — 토큰 브릿지, 옴니체인 대체가능토큰(OFT) 배포, 거버넌스 릴레이 등 — 이다.
이 프로토콜은 기존 브릿지 설계들이 묶어 처리하던 세 가지 관심사를 분리한다.
검증(Verification) 은 체인 A에서 발신되었다고 주장하는 메시지가 실제로 그곳에서 왔는지를 판단하는 문제다. LayerZero V2에서 이는 하나 이상의 탈중앙화 검증자 네트워크(DVN, Decentralized Verifier Networks) 가 처리한다. DVN은 소스 체인을 감시하고, 확인한 메시지에 대해 증명을 제출하며, 그 증명을 목적지 체인에 전달하는 오프체인 서비스다. 경로별로 여러 DVN을 구성할 수 있고, 애플리케이션은 임계값을 설정한다: 메시지가 검증된 것으로 인정받으려면 구성된 DVN 중 몇 개가 동의해야 하는지.
실행(Execution) 은 검증이 완료된 후 누가 가스를 지불하고 목적지 체인의 전달을 트리거하는지의 문제다. 실행자는 경제적 인센티브를 받지만 메시지를 위조할 수 없다 — 이미 검증된 메시지만 전달할 수 있다.
애플리케이션 로직 은 그 위에 위치한다. 목적지 컨트랙트는 검증된 페이로드를 받아 무엇을 할지 결정한다 — 발행, 소각, 상태 업데이트, 다른 컨트랙트로 전달 등.
핵심 설계 선택은 검증자 구성이 애플리케이션별로 이루어진다는 점이다. 동일한 체인 쌍에서 LayerZero를 사용하는 두 개의 서로 다른 애플리케이션은 전혀 다른 보안 가정을 가질 수 있다. 하나는 다섯 개의 독립적인 DVN의 증명을 요구할 수 있고, 다른 하나는 하나만 요구할 수도 있다. 프로토콜은 최솟값을 강제하지 않는다.
이는 원칙적으로 정당화될 수 있다. 애플리케이션마다 위협 모델이 다르고 비용 허용 범위도 다르다. 처리량이 많고 가치가 낮은 게이밍 브릿지는 수십억 달러 규모의 유동성 리스테이킹 토큰보다 얇은 검증 세트를 합리적으로 수용할 수 있다. 프로토콜은 그 선택을 통합 업체에게 맡긴다.
그러나 현실에서는, LayerZero 경로의 보안이 정확히 그 경로를 사용하는 애플리케이션이 선택한 가장 약한 검증자 세트의 보안과 같다는 의미이며, 그 선택은 온체인에서 확인할 수 있지만 통합 업체 자신 외에는 좀처럼 감사받지 않는다는 뜻이기도 하다.
단일 검증자 구성
방어 가능한 DVN 구성은 대략 이런 모습이다: 키, 호스팅, 모니터링 스택, 운영자 중 어느 것도 공유하지 않는 적어도 두 개의 운영상 독립된 검증자, 그리고 구성된 모든 검증자의 동의를 요구하는 임계값. 이상적으로는 고가치 메시지에 대해 더 높은 임계값을 가진 세 번째 “선택적” DVN, 또는 외부 당사자가 이의를 제기할 시간을 주는 검증과 실행 사이의 타임락.
Kelp DAO 경로는 그렇게 구성되지 않았다. LayerZero 자체의 설명에 따르면, 해당 애플리케이션은 영향을 받은 경로에서 메시지를 증명할 단일 DVN만 두고 있었다. 그 단일 서명자 하나만으로 소스 컨트랙트에서 발신되었다고 주장하는 모든 메시지를 검증하기에 충분했다.
이 구성의 함의는 명확하게 진술할 필요가 있다. 그 DVN의 서명 키를 제어하는 사람은 누구든 단독으로 원하는 메시지에 대해 증명할 수 있었다. 쿼럼을 탈취할 필요가 없었다. 누구와 협력할 필요도 없었다. 오직 키만 필요했고 — 그 키가 특정 크로스체인 메시지가 발생했다는 증명에 서명하면, 목적지 컨트랙트는 그것을 합법적인 메시지와 구분할 방법이 없었다.
이는 구조적으로 목적지 컨트랙트가 수행할 권한을 가진 모든 것을 보호하는 1-of-1 멀티시그와 동일하다. Kelp DAO의 경우, 목적지 컨트랙트는 원격 체인에서 리스테이킹 자산 표현을 발행할 권한을 가지고 있었다. 실질적으로, 1-of-1 멀티시그가 그 표현의 발행 권한을 보호하고 있었던 셈이다.
이를 취약점이라 부르고 싶은 유혹이 있다. 기술적 의미에서 그것은 취약점이 아니었다. 컨트랙트들은 정확히 구성된 대로 작동했다. 검증자가 증명을 생성했고, 목적지 컨트랙트가 이를 수락했으며, 발행이 이루어졌다. 보관 체인의 모든 코드가 의도한 대로 동작했다. 실패는 코드의 상위 단계에 있었다 — 애플리케이션이 요구한 독립적 증명자의 수에 대한 선택에서.
애플리케이션이 얇은 구성을 선택하는 이유
이 구성을 부주의로 돌리기 쉽고, 어떤 경우에는 그것이 정확할 수도 있다. 하지만 애플리케이션이 마땅히 갖춰야 할 것보다 얇은 검증자 세트로 끝나는 데는 실질적인 이유들이 있다.
첫 번째는 비용이다. 추가 DVN은 메시지당 수수료를 추가한다. 처리량이 높은 애플리케이션에서는 검증자 하나와 셋의 차이가 상당한 운영 비용으로 누적된다.
두 번째는 레이턴시다. 검증자들은 비동기적으로 증명하고, 목적지 측 메시지는 임계값에 가장 늦게 도달하는 것에 의해 차단된다. 검증자가 많을수록 편차가 커지고 꼬리가 길어진다.
세 번째는 운영의 단순성이다. 추가 DVN은 하나의 거래상대방이 추가되고, 하나의 모니터링 표면이 추가되며, 전체 경로를 정체시킬 수 있는 잠재적 다운타임의 지점이 하나 더 생기는 것이다. 가동 시간을 최적화하는 애플리케이션들은 때로 더 단순한 구성을 선택하고 신뢰 트레이드오프를 감수하는데, 종종 그것을 명시적으로 트레이드오프로 모델링하지 않은 채.
네 번째이자 가장 불편한 이유는, 신규 통합 업체들이 물려받는 기본 구성이 결국 해당 통합이 보호하게 될 가치에 항상 잘 맞춰져 있지는 않다는 점이다. 적당한 TVL로 시작해 훨씬 큰 규모로 성장하는 애플리케이션은, 출시 당시에는 합리적이었지만 규모가 커진 현재에는 더 이상 합리적이지 않은 구성을 그대로 유지할 수 있다. TVL에 따라 그 구성을 검토하고 강화하는 것은 대부분의 팀이 제도화하지 않은 프로세스다.
운영상의 실패: 두 가지 역할을 맡은 키
구성 자체만으로는 잠재적 위험에 그쳤을 것이다. 그것을 현실화된 손실로 바꾼 것은 공개 사과문이 이례적으로 직접적인 언어로 서술한 운영상의 실패였다: 검증자를 제어하는 지갑이 LayerZero 내부 또는 해당 검증자와 관련된 누군가에 의해 개인 트레이드를 수행하는 데 사용되었다. 그 거래 흐름이 지갑을 보안이 강화되지 않은 컨텍스트에 노출시켰고, 서명 능력이 탈취되었다.
정확한 탈취 경로에 대한 공개적인 포렌식 설명은 없다. 우리가 알고 있는 것은 실패의 유형이며, 이는 낯설지 않다. 프로덕션 인프라를 제어하는 지갑은 프로덕션 메시지 외에는 어떠한 것에도 서명해서는 안 된다. 프론트엔드와 상호작용하거나, 스마트 컨트랙트 승인을 하거나, DEX 스왑을 하거나, 또는 제3자 트랜잭션 서명 흐름에 관여하는 순간, 그 흐름의 전체 공격 표면을 상속받는다: 피싱, 악의적인 승인 서명, 탈취된 프론트엔드, 지갑 소프트웨어 자체에 대한 공급망 공격.
표준 관행 — 기관 수탁, 밸리데이터 운영, 프로토콜 엔지니어링 전반에 걸쳐 잘 문서화된 — 은 권한 있는 인프라의 서명 키가 그 단일 목적에만 사용되는 하드웨어 모듈에, 인터넷 브라우징을 하지 않는 기기에, 그리고 프로덕션 메시지 형식 이외의 인간이 발생시킨 트랜잭션을 포함하지 않는 워크플로에 존재해야 한다는 것이다. 검증자 서명 키는 개인 지갑이라기보다는 밸리데이터 키에 가까운 형태여야 한다.
메시징 보안을 전체 가치 제안으로 삼는 프로토콜과 가까운 인력이 이 원칙을 위반했다는 사실이 모든 크로스체인 통합 업체로 하여금 다시 한번 생각하게 해야 하는 부분이다. 이는 LayerZero 팀이 유달리 부주의하다는 뜻이 아니다 — 그에 대한 공개적인 증거는 없으며, 솔직한 공개 설명을 발표하려 한 의지가 오히려 반대를 시사한다 — 그러나 이 원칙은 널리 알려져 있음에도 불구하고 위반되었다. 어떤 관행을 아는 것과 그것을 제도화하는 것 사이의 간극은 대부분의 조직이 인정하는 것보다 훨씬 넓다.
사후 분석이 공개한 것과 열린 채로 남은 것
공개 사과문은 두 가지를 직접적으로 인정했다: 검증자 구성이 위험에 처한 가치에 비해 취약했다는 것, 그리고 검증자 키의 개인 활동으로부터의 운영상 분리가 무너졌다는 것. 이것이 구조적 인정이다.
공개 자료에서 몇 가지는 여전히 불분명하다. 영향을 받은 사용자의 전체 범위와 실현된 손실의 정확한 달러 금액은 여러 보도에서 편차가 있는 범위로 보고되었다. 손실을 누가 부담하고, 피해를 입은 애플리케이션의 트레저리가 어떤 역할을 하며, 어떤 프로토콜 수준의 변화가 뒤따르는지와 같은 보상 경로는 보통 며칠이 아니라 몇 주에 걸쳐 해결되는 종류의 것이다. 여기서 의도적으로 구체적인 수치를 언급하지 않는다; 아키텍처 분석에서는 사건의 질적 형태가 정확한 숫자보다 더 중요하고, 그 숫자 자체는 출처를 명확히 확인할 수 없다면 주장해서는 안 되는 종류의 것이기 때문이다.
익스플로잇 메시지가 실제로 한 일
검증자가 탈취되면 이런 익스플로잇의 기계적 순서는 간단명료하며, 추가로 필요한 공격 표면이 얼마나 적은지를 보여주기 때문에 추적해볼 가치가 있다.
탈취된 서명 키를 손에 넣은 공격자는 소스 체인에서 전혀 발신된 적 없는 메시지에 대한 증명을 구성한다. 증명은 잘 형성되어 있다: 목적지 측 검증 컨트랙트가 기대하는 서명을 담고 있고, 존재하지 않거나 페이로드가 변조된 소스 체인 트랜잭션을 참조한다. 증명은 정상적인 채널을 통해 목적지 체인에 제출된다.
목적지 측 검증 컨트랙트는 구성된 DVN 세트에 대해 서명을 확인한다. 구성된 세트에는 탈취된 키 하나만 포함되어 있고, 서명이 그 키에 대해 유효하기 때문에 검증을 통과한다. 메시지는 검증된 것으로 표시된다.
실행자 — 공격자 본인일 수도 있고, 표준 실행자 인센티브에 반응하는 아무것도 모르는 제3자일 수도 있다 — 가 검증된 메시지를 집어 목적지 애플리케이션 컨트랙트에 전달한다. 애플리케이션 컨트랙트는 신뢰하는 소스 체인 상대방으로부터 발신된 것으로 검증된 메시지를 보고 그에 따라 행동한다: Kelp DAO의 경우, 소스 체인에 자산이 예치되었다는 증거로 해당 메시지를 처리하고 목적지 체인에서 그에 상응하는 표현을 발행해야 한다.
그 표현들은 목적지 체인에 존재하는 유동성 창구를 통해 매도되거나 스왑된다. 불일치가 감지될 때쯤 — 애플리케이션의 모니터링에 의해, 또는 소스 체인의 잠긴 잔액과 목적지 체인의 발행 공급량을 비교하는 외부 관찰자에 의해 — 공격자는 이미 담보 없는 발행분을 유동 자산으로 전환했고, 손실은 더 이상 담보가 없는 표현의 형태로 굳어진다.
여기서 주목해야 할 비대칭성은 전체 익스플로잇 경로가 표준 프로토콜 동작을 통해 실행된다는 점이다. 통상적인 의미에서 해킹된 것은 없다 — 어떤 컨트랙트도 속임을 당하지 않았고, 어떤 로직도 깨지지 않았다. 메시지는 서명할 권한이 있는 키에 의해 서명되었다. 시스템은 정확히 구성된 대로 했다. 실패는 단일 키를 수백만 달러 규모의 발행 권한에 대한 충분한 증거로 취급한 구성에 있었다.
방어 가능한 검증자 아키텍처의 모습
즉각적인 답은 “검증자를 더 늘려라”이고, 그것이 답의 일부이긴 하지만 일부에 불과하다. 더 근본적인 요구 사항은 실패 모드의 독립성이다 — 동시에 탈취되려면 같은 탈취를 두 번 반복하는 것 이상이 필요한 여러 검증자.
의미 있는 가치를 보호하는 애플리케이션을 위한 방어 가능한 구성은 최소한 다음과 같은 여러 속성을 갖추어야 한다.
검증자 간 운영상의 독립성. 서로 다른 조직, 서로 다른 서명 인프라, 서로 다른 키 보관 방식, 서로 다른 클라우드 제공업체 또는 호스팅 환경. 동일한 팀이 동일한 인프라에서 운영하는 두 검증자는 두 개의 검증자가 아니다; 그것은 중복 서명이 있는 하나의 검증자다.
비용 최소화가 아닌 위협 모델에 맞는 임계값. 2-of-3 임계값은 1-of-2와 의미 있게 다르고, 둘 다 1-of-1과 의미 있게 다르다. 그 선택은 메시지당 비용을 최소화하는 기본값이 아니라 경로에서 위험에 처한 가치의 함수여야 한다.
검증자 구현의 다양성. 동일한 소프트웨어를 실행하는 검증자들은 버그를 공유한다. 서로 다른 클라이언트 구현을 실행하는 검증자들을 포함한 구성 — 이더리움의 합의 레이어가 클라이언트 다양성으로부터 이점을 얻는 방식과 유사하게 — 은 동질적인 세트 전체를 무너뜨릴 수 있는 소프트웨어 수준의 탈취에 강하다.
고가치 메시지를 위한 타임락 및 이의 제기 창. 검증과 실행 사이의 짧은 지연 시간 동안 외부 감시자가 소스 체인 상태와 청구된 메시지 사이의 불일치를 플래그할 수 있어, 단발성 익스플로잇을 분쟁 가능한 것으로 전환한다. 몇 분의 레이턴시가 허용되는 애플리케이션에서 이것은 가장 저렴하게 이용 가능한 방어책 중 하나다.
공개적이고 모니터링 가능한 구성. 어떤 LayerZero 애플리케이션의 DVN 세트와 임계값은 온체인에서 확인할 수 있다. 하지만 사용자 대면 문서나 제3자 대시보드에 표시되는 경우는 드물다. 통합 업체들이 보안 구성을 게시하고 이유를 설명하며, 외부 연구자들이 위험에 처한 가치에 대해 정기적으로 감사하는 규범이 있다면, 익스플로잇이 드러내기 전에 불일치를 포착할 것이다.
프로토콜 레이어에 남겨진 것
LayerZero는 프로토콜로서 검증자 구성의 유연성을 지속적으로 기능으로 포지셔닝해왔다: 애플리케이션이 필요에 맞게 보안 스택을 조정할 수 있다. Kelp 사건이 그 포지셔닝을 부정하지는 않지만, 프로토콜 레이어가 완전히 위임할 수 없는 질문을 날카롭게 만든다.
구성 선택이 애플리케이션에 달려 있고, 애플리케이션이 결국 보호하게 되는 가치에 비해 체계적으로 과소 구성한다면, “유연성”은 외부 효과에 대한 점잖은 표현이 된다. 통합 업체는 얇은 구성으로 비용 절감의 이점을 누리고, 구성이 실패할 때 프로토콜의 명성이 그 결과를 흡수한다. 올바른 수정이 프로토콜 수준의 최솟값인지, 이탈에 대한 눈에 띄는 경고가 있는 권장 기본값인지, 아니면 가치에 따른 구성 요건인지는 열린 설계 질문이다. 각각은 프로토콜의 허가 없는 통합이라는 폭넓은 테제에 반하는 트레이드오프를 가지고 있다.
이번 사건 이후 방어하기 더 어려워 보이는 것은 현상 유지다: 방어 가능한 설정과 단일 키 취약점 사이의 차이가 최종 사용자에게 보이지 않고, 탈취가 가시화하기 전까지는 더 넓은 시장에서도 대체로 보이지 않는 구성 표면.
시사점과 열린 질문들
Kelp DAO 사건은 크로스체인 신뢰 가정이 실제로 어떻게 분산되어 있는지에 대한 사례 연구로서 가장 교훈적이다. 메시징 프로토콜의 마케팅 표면은 네트워크를 묘사한다 — 탈중앙화된 검증자들, 분리된 관심사들, 임계값 보안. 실현된 표면은 어떤 주어진 애플리케이션에 대해 해당 애플리케이션이 사용하기로 선택한 그 네트워크의 부분 집합이며, 그 부분 집합의 운영자들이 실제로 따르는 운영 관행이다.
통합 업체들에게 즉각적인 교훈은, 크로스체인 경로의 보안 구성이 일회성 설정 결정이 아니라는 것이다. 그것은 그 경로를 통해 흐르는 가치의 함수로 검토되어야 하고, 그 가치가 성장함에 따라 — 어쩌면 상당히 — 강화되어야 하는 매개변수다. 경로가 출시될 때의 기본값은 규모에서 운영되어야 할 때의 기본값이 거의 아니다.
크로스체인 애플리케이션 사용자들에게 더 어려운 교훈은 신뢰 표면이 애플리케이션의 프론트엔드에서 보이지 않는다는 것이다. 하나의 메시징 프로토콜을 통해 래핑된 토큰은 5-of-7 검증자 세트 뒤에 있을 수 있고, 명목상 같은 프로토콜을 통해 래핑된 토큰은 1-of-1 뒤에 있을 수 있다. 사용자에게 보이는 인터페이스는 동일하다. 경제적 위험은 그렇지 않다.
이 특정 사건을 넘어 확장되며 주목할 가치가 있는 몇 가지 질문들이 있다.
공유 보안, 리스테이킹 기반 검증, 또는 검증을 온체인으로 이동시키는 영지식 증명 시스템을 중심으로 포지셔닝하는 경쟁 메시징 프로토콜들은 이 사건 이후 어떻게 차별화를 표현할까? “신뢰하는 검증자 없음”을 주장하려는 마케팅 압력이 증가할 것이다. 기술적 주장들은 면밀히 검토되어야 할 것이다; 그 중 많은 것들이 신뢰 가정을 제거하는 것이 아니라 이동시킬 뿐이다.
LayerZero 통합 업체들 중 의미 있는 비율이 TVL과 함께 DVN 구성을 일상적인 공시 사항으로 게시하게 될까? 그 정보는 온체인에 있지만 규범화가 중요하다. 수익률 수치와 같은 수준의 중요성으로 보안 매개변수를 표시하는 표준이 있다면 어떤 구성이 정교한 자본에 의해 용인될지가 달라질 것이다.
운영 보안 실패 요소는 어떻게 일반화되는가? 한 가지 역할을 맡은 키가 두 번째 역할에 사용되는 이 동일한 류의 실수는 멀티시그 서명자, 밸리데이터 운영자, 브릿지 팀 전반에 걸쳐 반복되는 실패 모드다. 그것이 잘 알려져 있음에도 불구하고 계속 발생한다는 사실은 그 간극이 정보적이기보다는 제도적임을 시사하며, 실제로 그것을 방지하는 제도적 구조에 대한 질문은 크립토 산업에서 여전히 대체로 답해지지 않았다.
Kelp DAO 사건의 가장 단순한 해석은 단일 실패 지점이 실패했다는 것이다. 더 유용한 해석은 단일 실패 지점이 2025년에도 여전히 정교한 팀들에 의해, 의미 있는 가치를 보호하며, 프로덕션에 배포되고 있다는 것 — 그리고 그것을 가능하게 하는 아키텍처가 그것들이 실행되는 메시징 레이어의 버그가 아닌 기능이라는 것이다. 그 기능이 이번 사건 이후에도 계속 방어될 수 있는지는 해결된 것이 아닌 열린 질문이다.
はじめに
クロスチェーンメッセージングプロトコルは、クリプトのスタック上で微妙な立ち位置を占めている。正常に動いているときは誰の目にも触れないインフラでありながら、一度失敗すれば壊滅的な結果をもたらす——しかもその上に構築されたアプリケーションの大半よりも多くの価値を守っているのだ。ブリッジが破綻するとき、その失敗の様態はほとんど常に明白だ。攻撃者が送信元チェーンでの対応するロックなしに宛先チェーンで資産をミントし、その差分が誰かの損失として結晶化する。
今回の LayerZero 上でのKelp DAOインシデントを検証する価値があるのは、新種の脆弱性が露わになったからではない。それよりもずっと居心地の悪い何かが露わになったからだ——インテグレーション当事者以外には誰も精査していなかった設定上の選択と、セキュリティレビューがあれば確実に捕捉できた運用上の失態が組み合わさった形で。LayerZero は 2025 年 11 月に公開の謝罪声明を発表し、当該アプリケーションが単一のベリファイアで設定されていたこと、そのベリファイアを制御する鍵が本来触れてはならないコンテキストで使用されていたことを認めた。
「チェーン A からチェーン B にメッセージをどう届けるか、そしてその正当性を誰が判断するか」という技術的な問いは、すべてのクロスチェーンプロトコルが答えを出すべき問いであり、その答えがそれぞれ異なるトラストモデルとなる。LayerZero の答えは際立って柔軟だ——アプリケーションが選ぶ。その柔軟性がプロトコルの売りであり、今回の失敗の根源でもある。本稿では、セキュリティスタックの実態、Kelp の設定がどのように防衛可能な構成から逸脱していたか、運用上の失態が示すインテグレーター側の鍵管理の問題、そしてより保守的なデフォルトがどのようなものかを順を追って解説する。
これは事後分析であり、LayerZero というプロトコルへの評決ではない。本稿が提起するアーキテクチャ上の問いは、検証の選択をダウンストリームに委譲するすべてのメッセージングレイヤーに等しく当てはまる。
LayerZero のセキュリティスタックの実像
LayerZero は、ブリッジではなく汎用メッセージングプロトコルとして理解するのが正確だ。あるチェーン上のアプリケーションがメッセージを発行し、プロトコルがペイロードを別チェーン上の対応するコントラクトへ届け、受信側コントラクトがそれをどう扱うかを決める。プロトコル自体は資産をカストディしない。資産をカストディするのは、それをインテグレートするアプリケーション——トークンブリッジ、オムニチェーン・ファンジブル・トークン（OFT）の展開、ガバナンスリレーなど——だ。
プロトコルは、初期のブリッジ設計が一体化しがちだった三つの関心事を分離している。
検証（Verification） は、チェーン A を発信元と主張するメッセージが実際にそうであるかを問う。LayerZero V2 では、これは一つ以上の**分散型ベリファイアネットワーク（DVN）**が担う。DVN はオフチェーンのサービスであり、送信元チェーンを監視し、目にしたメッセージを証明し、その証明を宛先チェーンに提出する。パスウェイごとに複数の DVN を設定でき、アプリケーションはしきい値を設定する——何個の DVN が合意すればメッセージが検証済みとみなされるかを決めるのだ。
実行（Execution） は、検証完了後に誰がガスを払い宛先側への配信をトリガーするかを問う。エグゼキューターは経済的インセンティブを持つが、メッセージを偽造することはできない。すでに検証済みのメッセージを届けることしかできない。
アプリケーションロジック はその両者の上位に位置する。宛先コントラクトが検証済みのペイロードを受け取り、何をするかを決める——ミントする、バーンする、状態を更新する、別のコントラクトに転送するなど。
重要な設計上の選択は、ベリファイアの設定がアプリケーション単位だということだ。同じチェーンペアで LayerZero を使う二つのアプリケーションが、まったく異なるセキュリティ前提を持つことができる。一方は五つの独立した DVN からの証明を要求し、もう一方は一つだけで足りるかもしれない。プロトコルは最低数を強制しない。
これは原則としては正当化できる。アプリケーションごとに脅威モデルもコスト許容度も異なる。スループットが高く価値の低いゲームブリッジが、数十億ドル規模の液体リステーキングトークンよりも薄いベリファイアセットを合理的に受け入れることもある。プロトコルはその選択をインテグレーターに委ねている。
しかし実際には、任意の LayerZero パスウェイのセキュリティは、それを使うアプリケーションが選んだ最も弱いベリファイアセットのセキュリティにそのまま等しい——そして、その選択はオンチェーンで可視であるにもかかわらず、インテグレーター自身以外にはほとんど監査されていない。
単一ベリファイア構成
防衛可能な DVN 構成は、おおむね次のようなものだ。少なくとも二つの運用上独立したベリファイアがあり、それぞれが鍵、ホスティング、監視スタック、オペレーターのいずれも共有しないインフラで動いている。設定されたすべてのベリファイアの合意を必要とするしきい値。理想を言えば、高額のメッセージには三つ目の「オプション」DVN とより高いしきい値を設け、あるいは検証から実行までの間に外部の第三者が異議を申し立てられるタイムロックを挟む。
Kelp DAO のパスウェイはそのように設定されていなかった。LayerZero 自身の説明によれば、当該アプリケーションは影響を受けたルートでのメッセージ証明を担う DVN が一つしかなかった。この単一の署名者だけで、ソースコントラクトから発信されたと主張するいかなるメッセージも検証できてしまった。
この設定の意味するところを率直に述べておきたい。その DVN の署名鍵を制御する者は、単独で任意のメッセージを証明できた。クォーラムを突破する必要はなかった。誰かと協調する必要もなかった。必要なのは鍵だけであり、その鍵が特定のクロスチェーンメッセージを証明する署名を出してしまえば、宛先コントラクトにはそれを正規のものと区別する手段がなかった。
これは構造的に、宛先コントラクトが実行を許可されていることを守る 1-of-1 マルチシグと等価だ。Kelp DAO のケースでは、宛先コントラクトはリモートチェーン上でリステーキング資産の表現を発行する権限を持っていた。実質的に、1-of-1 マルチシグがその発行権限を守っていたのだ。
これを脆弱性と呼びたくなるかもしれないが、技術的な意味ではそうではない。コントラクトは設定通りに動いた。ベリファイアが証明を生成し、宛先コントラクトがそれを受け入れ、発行が行われた。カストディチェーンのすべてのコードが、あるべき動作をした。失敗はコードの上流にあった——アプリケーションが要求する独立した証明者の数という選択の中に。
なぜアプリケーションは薄い構成を選ぶのか
この設定を怠慢のせいにするのは簡単であり、場合によってはそれが正しいこともある。しかし、アプリケーションが本来あるべき水準より薄いベリファイアセットになってしまう現実的な理由がある。
一つ目はコストだ。DVN を追加するたびにメッセージごとの手数料が増える。スループットの高いアプリケーションでは、一つと三つの差が積み重なって無視できない運用コストになる。
二つ目はレイテンシだ。ベリファイアは非同期に証明を行い、宛先側のメッセージはしきい値に達するのが最も遅いものに律速される。ベリファイアが増えるほど分散が大きくなり、テールが長くなる。
三つ目は運用の単純さだ。ベリファイアが増えるほど、カウンターパーティが増え、監視対象が増え、パスウェイ全体を止めかねないダウンタイムのリスクも増える。稼働率を重視するアプリケーションは、より単純な構成を選んでトラストのトレードオフを受け入れることがある——多くの場合、それをトレードオフとして明示的に認識することすらなく。
四つ目は、最も居心地が悪いが、新しいインテグレーターが引き継ぐデフォルト設定が、そのインテグレーションが最終的に守ることになる価値に対して常に適切に調整されているわけではないという点だ。小さな TVL でローンチしたアプリケーションが大きく成長した場合、ローンチ時には合理的だったが現在の規模ではもはや合理的でない設定を引きずり続けることがある。TVL の増加に応じてその設定を見直し締め直すプロセスを制度化しているチームは多くない。
運用上の失態：二つの役割を持つ鍵
設定だけであれば潜在的なリスクにとどまったはずだ。それを現実の損失に変えたのは、公開の謝罪声明が異例なほど率直な言葉で説明した運用上の失態だった——ベリファイアを制御するウォレットが、LayerZero 内部あるいはベリファイアの運用に関わる誰かによって個人的なトレードに使われたというものだ。そのトレードのフローがウォレットをハード化されていないコンテキストにさらし、署名機能が侵害された。
正確な侵害経路についての公開フォレンジック報告はない。わかっているのは失敗の類型であり、それは見覚えのあるものだ。本番インフラを制御するウォレットは、本番メッセージ以外の何にも署名すべきではない。フロントエンド、スマートコントラクトの承認、DEX スワップ、あるいはいかなるサードパーティのトランザクション署名フローとも一切関わった瞬間に、そのフロー全体のアタックサーフェス——フィッシング、悪意のある承認署名、侵害されたフロントエンド、ウォレットソフトウェア自体へのサプライチェーン攻撃——を引き受けることになる。
標準的な実践——機関カストディ、バリデータ運用、プロトコルエンジニアリングの分野で広く文書化されている——は、特権インフラの署名鍵はその単一目的のために専用化されたハードウェアモジュールに置き、インターネットを閲覧しないマシンで管理し、本番メッセージフォーマット以外の人間が起点となるトランザクションを一切含まないワークフローで運用するというものだ。ベリファイアの署名鍵は、個人のウォレットよりもバリデータの鍵に近い存在であるべきだ。
メッセージングセキュリティをまさに価値提案の核心とするプロトコルに近い人物によって、この原則が破られたという事実は、すべてのクロスチェーンインテグレーターにとって立ち止まるべき理由となる。LayerZero のチームが特別に不注意だということではない——そのような公的な証拠はなく、率直な説明を公表する意思はむしろその逆を示唆している——しかし、その原則が広く理解されていながらも破られたという点が問題だ。実践を「知っている」ことと「制度化する」ことの間の溝は、多くの組織が認めるより深い。
事後開示が明らかにしたことと残された疑問
公開の謝罪声明が直接認めたのは二点だ。ベリファイアの設定が賭かっている価値に対して薄すぎたこと、そしてベリファイア鍵の個人的な活動からの運用上の分離が崩れたこと。これらが構造的な自認だ。
公開情報からは依然として不明瞭な点がいくつかある。影響を受けたユーザーの全容と実現した損失の正確な金額は、報道によって幅のある数字で示されている。損失を誰が吸収するか、影響を受けたアプリケーションの treasury がどのような役割を果たすか、プロトコルレベルでどのような変更が続くか、といった補償のパスウェイは、日単位ではなく週単位で解決するものが通例だ。本稿では意図的に具体的な数字を示さない。アーキテクチャ分析において重要なのは正確な数字よりもインシデントの定性的な形であり、数字自体はソースを引用できない形での主張を避けるべき種類のものだ。
エクスプロイトのメッセージが実際に行ったこと
ベリファイアが侵害されれば、このようなエクスプロイトの機械的なシーケンスは単純明快だ。アーキテクチャ上の何が問題だったかを明確にする意味で、順を追って見ていこう。
侵害された署名鍵を手にした攻撃者は、送信元チェーンで実際には発行されなかったメッセージに対する証明を作成する。その証明は正当な形式を持つ——宛先側の検証コントラクトが期待する署名が付与され、存在しないか改竄されたペイロードを持つソースチェーントランザクションを参照している。証明は通常のチャネルを通じて宛先チェーンに提出される。
宛先側の検証コントラクトは、設定された DVN セットに対して署名を照合する。設定セットには侵害された鍵しか含まれていないため、その鍵に対して署名が有効であれば検証は通過する。メッセージは検証済みとしてマークされる。
エグゼキューター——攻撃者自身の場合もあれば、通常のエグゼキューターインセンティブに応じた無関係の第三者の場合もある——が検証済みのメッセージを受け取り、宛先のアプリケーションコントラクトに配信する。アプリケーションコントラクトは、信頼された送信元チェーン側のカウンターパートから発信されたと検証済みのメッセージを受け取り、それに従って動作する。Kelp DAO のケースでは、送信元チェーンで資産が預け入れられた証拠としてメッセージを扱い、宛先チェーンで対応する表現を発行した。
発行された表現は、宛先チェーン上でそれらに対して存在する流動性ベニューを通じて売却またはスワップされる。乖離が発覚するまでに——送信元チェーンのロック残高と宛先チェーンの発行済み供給量を比較するアプリケーションの監視や外部のオブザーバーによって——攻撃者はバックのない発行を流動性資産に変換しており、損失は担保を持たない表現という形で結晶化している。
ここで注目すべき非対称性は、エクスプロイトのパス全体が標準的なプロトコルの動作を通じて実行されるという点だ。俗な意味でハックされたものは何もない——コントラクトは騙されず、ロジックは破られていない。署名することを許可された鍵によってメッセージに署名された。システムは設定通りに動いた。失敗は、単一の鍵を数百万ドル規模の発行権限の十分な証拠として扱う設定にあった。
防衛可能なベリファイアアーキテクチャの姿
反射的な答えは「ベリファイアを増やす」であり、それは答えの一部ではある。しかし、より深い要件は失敗モードの独立性——複数のベリファイアが同時に侵害されるには、同じ侵害を二度繰り返す以上のことが必要となる構成——だ。
意味のある価値を守るアプリケーションの防衛可能な構成は、少なくとも以下のいくつかの性質を備えているべきだ。
ベリファイア間の運用上の独立性。 異なる組織、異なる署名インフラ、異なる鍵カストディの取り決め、異なるクラウドプロバイダーまたはホスティング環境。同じチームが同じインフラ上で運用する二つのベリファイアは、二つのベリファイアではない。冗長な署名を持つ一つのベリファイアだ。
脅威モデルに基づいたしきい値——最安値ではなく。 2-of-3 のしきい値は 1-of-2 と意味が大きく異なり、いずれも 1-of-1 とは意味が大きく異なる。その選択は、メッセージあたりのコストを最小化するデフォルトではなく、パスウェイ上のリスクにさらされている価値の関数であるべきだ。
ベリファイア実装の多様性。 同一ソフトウェアで動くベリファイアはバグを共有する。イーサリアムのコンセンサスレイヤーがクライアント多様性の恩恵を受けるのと同様に、異なるクライアント実装を持つベリファイアを含む構成は、均質なセットを一掃してしまうようなソフトウェアレベルの侵害に対して堅牢だ。
高額メッセージに対するタイムロックとチャレンジウィンドウ。 検証と実行の間に短い遅延を設けることで、外部のウォッチャーが送信元チェーンの状態と主張されたメッセージとの不整合をフラグ立てできる時間を確保し、一撃必殺のエクスプロイトを争いある形に変える。数分のレイテンシが許容されるアプリケーションにとって、これは最もコストの低い防御の一つだ。
公開かつ監視可能な構成。 任意の LayerZero アプリケーションの DVN セットとしきい値はオンチェーンで可視だ。しかしユーザー向けのドキュメントやサードパーティのダッシュボードで表面化されることはほとんどない。インテグレーターが自身のセキュリティ設定を公開して正当化し、外部のリサーチャーが賭かっている価値に対してそれを定期的に監査するという規範が生まれれば、エクスプロイトよりも先に不整合が浮き彫りになる。
これがプロトコルレイヤーに何を残すか
LayerZero はプロトコルとして、ベリファイア設定の柔軟性をフィーチャーとして一貫して打ち出してきた——アプリケーションはセキュリティスタックを自分たちのニーズに合わせて調整できると。Kelp インシデントはそのポジショニングを否定するものではないが、プロトコルレイヤーが完全には他に委ねられない問いを鋭くする。
設定の選択がアプリケーション側にあり、アプリケーションが最終的に守る価値に対して体系的に過少設定する傾向があるなら、「柔軟性」は外部性の礼儀正しい表現だ。インテグレーターは薄い設定によるコスト削減を享受し、設定が失敗したときの帰結はプロトコルの評判が吸収する。プロトコルレベルの最低値を設けるか、逸脱には目立つ警告付きの推奨デフォルトを設けるか、価値に連動した設定要件を設けるかは、開かれた設計上の問いだ。それぞれの選択肢が、パーミッションレスなインテグレーションというプロトコルの広いテーゼと相反するトレードオフを孕んでいる。
このインシデントの後、より擁護が難しくなったのは現状維持だろう——防衛可能な設定と単一鍵の脆弱性の差が、エンドユーザーには見えず、侵害が現実のものとなるまで市場全体にもほとんど見えない設定サーフェス。
示唆と残された問い
Kelp DAO インシデントが最も示唆に富む教材である理由は、クロスチェーンのトラスト前提が実際にどのように分配されているかを示すケーススタディとしてだ。メッセージングプロトコルのマーケティング上の表面は、ネットワークを描く——分散されたベリファイア、分離された関心事、しきい値セキュリティ。しかし任意のアプリケーションにとっての現実の表面は、そのアプリケーションがそのネットワークのどのサブセットを使うことを選んだか、そしてそのサブセットのオペレーターが実際にどのような運用プラクティスに従っているかに等しい。
インテグレーターにとっての直接の教訓は、クロスチェーンパスウェイのセキュリティ設定は一度きりのセットアップ決定ではないということだ。それはそこを流れる価値の関数として見直され、その価値が成長するにつれて——場合によっては大幅に——締め直されるべきパラメータだ。パスウェイがローンチされるときのデフォルトは、スケールした後に運用されるべきデフォルトとほぼ一致しない。
クロスチェーンアプリケーションのユーザーにとっての厳しい教訓は、トラストサーフェスがアプリケーションのフロントエンドからは見えないということだ。あるメッセージングプロトコルを通じてラップされたトークンが 5-of-7 のベリファイアセットの後ろにあるかもしれず、名目上は同じプロトコルを通じてラップされた別のトークンが 1-of-1 の後ろにあるかもしれない。ユーザーに見える UI は同一だ。経済的なリスクはそうではない。
この特定のインシデントを超えて広がる、注目に値するいくつかの問いがある。
共有セキュリティ、リステーキングを活用した検証、あるいは検証をオンチェーンに移すゼロ知識証明システムをポジショニングの中心に据える競合メッセージングプロトコルは、このインシデントを受けてどのように差別化を打ち出すだろうか。「信頼されたベリファイアなし」を主張するマーケティング圧力は高まるだろう。技術的な主張は慎重に検討される必要がある——その多くはトラストの前提を排除するのではなく移し替えているだけだ。
LayerZero インテグレーターの中に、DVN 構成を TVL と並べてルーティンな開示として公表するところが意味のある割合で出てくるだろうか。その情報はオンチェーンにあるが、規範化が重要だ。セキュリティパラメータを利回りと同じ水準の目立つ形で表示する標準があれば、洗練された資本が許容する設定が変わるだろう。
運用セキュリティの失敗という側面はどこまで一般化できるか。一つの鍵が二つの仕事に使われるという同じ類の失態は、マルチシグの署名者、バリデータのオペレーター、ブリッジチームに繰り返し見られる失敗モードだ。十分に理解されているにもかかわらずそれが続くという事実は、ギャップが情報的というより制度的なものであることを示唆しており、実際にそれを防ぐ制度的な構造が何かという問いは、クリプト業界においてほとんど未回答のまま残っている。
Kelp DAO インシデントの最も単純な読み方は、単一障害点が失敗したというものだ。より有益な読み方は、単一障害点が 2025 年に至っても本番環境に展開され続けている——洗練されたチームによって、意味のある価値を守りながら——という事実であり、それを可能にするアーキテクチャは、それらが稼働するメッセージングレイヤーのバグではなくフィーチャーだということだ。そのフィーチャーが引き続き擁護できるかどうかは、このインシデントの後、解決済みの問いではなく開かれた問いとなった。
引言
跨链消息传递协议在加密基础设施栈中处于一个尴尬的位置：它们是基础设施——运转正常时无人察觉，出现故障时则是灾难性的——而它们所保护的价值，往往超过了建立在其之上的大多数应用。当一座桥发生故障，失败的方式很少是悄无声息的：攻击者在一条链上铸造资产，而对应的另一条链上根本没有相应的锁仓操作，这中间的差额就变成了某些人的损失。
最近发生在 LayerZero 上的 Kelp DAO 事件值得深入审视，原因并不在于它暴露了什么新型漏洞，而在于它揭示了一些更令人不安的东西：一个集成方自行决定的配置选项，几乎没有外部人士加以审查；加之一个操作上的失误，任何认真进行的安全审查都本可发现。LayerZero 于 2025 年 11 月发布公开致歉，承认该应用被配置为只使用单一验证者，而控制该验证者的私钥被用于了一个本不应触碰的场景。
一条消息如何从链 A 传递到链 B，又由谁来判定其有效性——这是每个跨链协议都必须回答的问题，而每一种答案都对应着不同的信任模型。LayerZero 给出的答案异常灵活：由应用自己决定。这种灵活性既是该协议的卖点，也是这次事故的根源。我们希望系统梳理：安全机制实际上是如何运作的，Kelp 的配置在哪些地方偏离了合理标准，这次操作失误揭示了集成方在密钥管理实践上存在哪些问题，以及一个更为保守的默认配置应当是什么样的。
这是一篇事后复盘，而非对 LayerZero 协议本身的定罪。它所提出的架构问题，适用于每一个将验证选择下放给下游应用的消息传递层。
LayerZero 安全机制的实际运作方式
理解 LayerZero，最好将其视为一个通用消息传递协议，而非一座桥。一条链上的应用发出一条消息；协议将一段载荷传递给另一条链上的对应合约；对应合约决定如何处理这段载荷。协议本身不托管资产，而是由集成它的应用来负责——包括代币桥、全链同质化代币（OFT）部署，以及治理中继等。
该协议将早期桥设计通常打包在一起的三个关注点分离了开来。
验证解决的是：一条声称来自链 A 的消息是否真的来自链 A。在 LayerZero V2 中，这一职责由一个或多个去中心化验证者网络（DVN）承担。DVN 是一种链下服务，负责监听源链、对所见消息进行证明，并将证明提交到目标链。每条路径可以配置多个 DVN，应用方设定一个阈值：需要多少个已配置的 DVN 达成共识，消息才算通过验证。
执行解决的是：验证完成后，由谁来支付 gas 并触发目标侧的交付。执行者受经济激励驱动，但无法伪造消息——他们只能传递已经过验证的消息。
应用逻辑则位于两者之上。目标合约收到经过验证的载荷后，自行决定如何处理——铸造、销毁、更新状态，或转发给另一个合约。
其中最关键的设计选择在于：验证者配置是以应用为单位的。在同一链对上使用 LayerZero 的两个不同应用，可以拥有完全不同的安全假设。一个应用可能要求来自五个独立 DVN 的证明，另一个应用可能只要求一个。协议本身不强制设定最低要求。
从原理上讲，这种设计是站得住脚的。不同应用面临的威胁模型不同，对成本的承受能力也不同。一个高吞吐量、低价值的游戏桥，选择较薄的验证集合情有可原；而一个锁仓数十亿美元的流动性再质押代币，则不能如此。协议将选择权留给集成方。
但在实践中，这意味着任何一条 LayerZero 路径的安全性，恰好等于使用它的应用所选择的最弱验证者集合的安全性——而这一选择虽然在链上可见，却鲜有人主动审计，通常只有集成方自己才会关注。
单一验证者配置
一个合理的 DVN 配置大致应当如下：至少两个在运营上相互独立的验证者，各自运行的基础设施在密钥、托管、监控体系和运营方上互不重叠；阈值要求所有已配置的验证者均达成共识；理想情况下，针对高价值消息还应设置第三个”可选”DVN，并设定更高的阈值，或在验证与执行之间加入时间锁，为外部方提供发起质疑的时间窗口。
而 Kelp DAO 的路径并非如此配置。据 LayerZero 自己的陈述，该应用在受影响的路由上只配置了一个 DVN 负责消息证明。这单一的签名者就足以验证任何声称来自源合约的消息。
这种配置的含义，值得直说：掌控该 DVN 签名密钥的任何人，都可以单独对任意自选消息进行证明。他们不需要攻破多数门槛，不需要与任何人协调，只需要那把密钥——一旦该密钥为某条跨链消息的发生签署了证明，目标合约就无法将其与真实消息区分开来。
这在结构上等同于用一个 1-of-1 多签来保护目标合约所被授权执行的一切操作。在 Kelp DAO 的案例中，目标合约被授权在远程链上发行再质押资产的凭证代币。而这个 1-of-1 多签，实际上保护的正是这些凭证代币的发行权。
将此称为”漏洞”固然诱人，但从技术角度看它并非如此。合约完全按照配置运行：验证者生成证明，目标合约接受证明，发行随即发生。整条信任链上的每一段代码都做了它应该做的事。失败发生在代码之上——在于应用要求多少个独立证明者这一选择本身。
应用为何会选择薄弱的配置
将这种配置归咎于疏忽是件容易的事，有时这种判断也许准确。但应用最终采用比应有更薄弱的验证者集合，确实有其现实原因。
其一是成本。每增加一个 DVN，就会增加每条消息的手续费。对于高吞吐量应用而言，一个验证者与三个验证者之间的差额，会累积为可观的运营开销。
其二是延迟。验证者以异步方式进行证明，目标侧消息的放行取决于最慢的那个验证者何时达到阈值。验证者越多，延迟的方差越大，尾部耗时越长。
其三是操作简便性。每增加一个 DVN，就意味着多一个交易对手方、多一个需要监控的点，以及多一个可能发生宕机从而阻塞整条路径的风险敞口。以追求高可用性为优先目标的应用，有时会选择更简单的配置并接受相应的信任权衡——而往往并未将其显式地建模为一种权衡。
其四，也是最令人不安的一点：新集成方所继承的默认配置，并不总是与该集成方最终所保护的价值相匹配。一个在 TVL 尚小时上线的应用，随着规模增长，可能一直沿用当初在合理范围内的配置，而这套配置在当前规模下早已不再合理。将随着 TVL 增长而复审并收紧配置的流程制度化，并非多数团队已经建立的习惯。
操作失误：一把密钥两份职责
单一验证者的配置只是一种潜在风险，真正让风险变为实际损失的，是一次操作失误——LayerZero 在公开致歉中用相当直接的措辞描述了这一点：控制验证者的钱包被 LayerZero 内部或其验证者运营生态圈中的某人用于执行个人交易。这次交易行为将该钱包暴露在其原本未被加固以抵御的场景中，签名能力随即遭到入侵。
目前没有关于确切入侵途径的公开取证记录。但我们所掌握的失败类别是清晰可辨的。一个控制生产基础设施的钱包，绝不应该签署任何生产消息以外的内容。一旦它与前端页面、智能合约授权、DEX 兑换，或任何第三方交易签名流程产生交互，就会继承该流程的全部攻击面：网络钓鱼、恶意授权签名、被入侵的前端，以及针对钱包软件自身的供应链攻击。
业界的标准做法——在机构托管、验证者运营和协议工程领域均有充分记录——是：特权基础设施的签名密钥必须存放在专用于该单一用途的硬件模块中，运行于不访问互联网的机器上，且其工作流程中不涉及任何在生产消息格式之外由人工发起的交易。验证者签名密钥的管理方式应更接近验证者密钥，而非个人钱包。
这一原则之所以令人警醒，在于它被一个将消息安全性作为核心价值主张的协议的相关人员所违反——并非因为 LayerZero 团队具有独特的粗心，并没有任何公开证据支持这一点，而且愿意发布坦诚陈述的做法恰恰说明了相反的情况——而在于这一原则广为人知，却依然被违反。知道一项实践与将其制度化之间的差距，比大多数组织愿意承认的要宽得多。
事后复盘所披露的与尚未厘清的
公开致歉直接承认了两点：验证者配置相对于所涉及的价值而言过于薄弱；验证者密钥与个人活动之间的操作隔离发生了断裂。这是结构性的承认。
从公开资料来看，仍有若干问题尚不明朗。受影响用户的完整范围及实际损失的确切金额，在各方报道中出入较大。补救路径——损失由谁承担、受影响应用的国库扮演何种角色、协议层面将做出哪些改变——此类问题通常需要数周而非数日才能落定。我们在此刻意不援引具体数字：对于架构分析而言，事件的定性轮廓比精确数字更为重要，而在没有可引用来源的情况下，这类数字不应轻易断言。
利用消息实际做了什么
一旦验证者遭到入侵，此类漏洞的机械执行过程便相当直接，值得逐步梳理，因为它清晰地展示了实施攻击所需的额外条件有多么少。
攻击者掌控了被入侵的签名密钥后，为一条从未在源链上发出的消息构造了一份证明。该证明格式完全合规：它携带着目标侧验证合约预期见到的签名，并引用了一笔要么根本不存在、要么载荷已被篡改的源链交易。这份证明通过正常渠道被提交到目标链。
目标侧验证合约将签名与已配置的 DVN 集合进行比对。由于配置的集合中只有那一把被入侵的密钥，而签名对该密钥有效，验证因此通过。消息被标记为已验证。
一名执行者——可能是攻击者本人，也可能是受标准执行者激励机制驱动的无辜第三方——提取了这条已验证的消息并将其传递给目标应用合约。应用合约收到一条声称来自其可信源链对应方的已验证消息，随即对其作出响应：在 Kelp DAO 的案例中，将该消息视为资产已在源链存入的证据，并在目标链上发行相应的凭证代币。
这些凭证代币随后通过目标链上现有的任何流动性场所被出售或兑换。待差异被察觉——无论是被应用的监控系统发现，还是被外部观察者通过对比源链锁仓余额与目标链发行量而发现——攻击者已将无抵押品支撑的发行转化为流动资产，损失以缺乏抵押品背书的凭证代币形式固化。
这里有一个值得关注的不对称性：整个漏洞利用路径完全运行于标准协议行为之内。没有任何合约遭到欺骗，没有任何逻辑被破坏，没有任何东西被”黑掉”——通俗意义上的”黑入”根本未曾发生。消息由被授权签名的密钥签署，系统严格按照配置执行。失败在于：配置将单一密钥视为足以支撑数百万美元发行权限的充分证明。
合理的验证者架构应当是什么样的
被动式的答案是”增加验证者数量”，这是答案的一部分，但仅仅是一部分。更深层的要求是故障模式的独立性——多个验证者同时遭到入侵，所需的代价必须远超将同一入侵手法重复执行两次。
对于保护有实际价值的应用而言，一个合理的配置至少应当具备以下几项属性。
验证者之间的运营独立性。 不同的组织、不同的签名基础设施、不同的密钥托管安排、不同的云服务商或托管环境。由同一团队在同一套基础设施上运行的两个验证者，并不构成两个验证者，它们本质上是一个验证者加上冗余签名。
阈值应匹配威胁模型，而非追求最低可行数量。 2-of-3 的阈值与 1-of-2 存在本质区别，两者与 1-of-1 更是天壤之别。这一选择应当是路径上风险价值的函数，而非最小化每条消息成本的默认选项。
验证者实现的异构性。 运行相同软件的验证者共享相同的漏洞。配置中包含运行不同客户端实现的验证者——类似于以太坊共识层从客户端多样性中获益的逻辑——能够抵御可能击垮同质化集合的软件级入侵。
针对高价值消息的时间锁与质疑窗口。 在验证与执行之间设置短暂延迟，在此期间外部监控者可以标记源链状态与声称消息之间的不一致，从而将一次单边利用转变为有争议的过程。对于能够接受分钟级延迟的应用而言，这是成本最低的防御手段之一。
公开且可监控的配置信息。 任何 LayerZero 应用的 DVN 集合与阈值均在链上可查。但它们鲜少出现在面向用户的文档或第三方数据面板中。如果集成方能够以惯例形式公开并说明其安全配置，外部研究者也能常态化地将其与所保护的价值进行核对，许多不匹配问题就能在漏洞发生之前被发现。
这对协议层意味着什么
LayerZero 作为协议，始终将其验证者配置的灵活性定位为一项特性：应用可以根据自身需求调整安全机制。Kelp 事件并不与这一定位相矛盾，但它确实将协议层无法完全下放的一个问题推向了更清晰的聚焦点。
如果配置选择权归属于应用，而应用系统性地低于其最终所保护的价值进行配置，那么”灵活性”不过是对一种外部性的礼貌措辞。集成方享受了薄弱配置所带来的成本节省，而配置失败所造成的后果，则由协议的声誉来承担。正确的纠偏方式究竟是协议层面的最低标准、附有偏离警告的推荐默认值，还是与价值挂钩的配置要求，目前仍是一个开放的设计问题，每种方案都与该协议无许可集成的核心理念存在一定张力。
在这次事件之后，似乎更难以为现状辩护的是：在这个配置界面上，一个合理设置与单密钥漏洞之间的差异，对终端用户而言几乎不可见，对更广泛的市场而言也基本透明——直到一次入侵将其清晰呈现。
启示与待解问题
Kelp DAO 事件最具教益之处，在于它作为一个案例，揭示了跨链信任假设在现实中是如何分布的。一个消息传递协议的营销叙事描绘的是一张网络——去中心化验证者、关注点分离、阈值安全。而对于任何具体应用而言，其实际所拥有的，只是该应用选择使用的那个网络子集，以及该子集运营者实际遵循的操作规范。
对于集成方而言，眼前的教训是：跨链路径的安全配置不是一次性的设置决策，而是一个应随流经其中的价值而动态复审的参数——并在价值增长时加以收紧，有时需要大幅收紧。路径上线时的默认设置，几乎从来都不是其大规模运行时应当保持的默认设置。
对于跨链应用的用户而言，更难接受的教训是：信任面从应用前端根本看不出来。通过某个消息协议封装的代币，背后可能有 5-of-7 的验证者集合；通过名义上相同的协议封装的另一个代币，背后可能只有 1-of-1。用户看到的界面毫无差别，经济风险却截然不同。
以下几个问题超越了这次具体事件本身，值得持续关注。
在此事件之后，那些以共享安全、再质押驱动的验证或零知识证明系统（将验证迁移至链上）为卖点的竞争性消息协议，将如何构建自身的差异化叙事？“无需信任任何验证者”的营销压力将会上升，而相关技术主张需要被仔细审视——其中许多不过是将信任假设转移了位置，而非真正消除。
LayerZero 集成方中，是否会有相当比例的项目将 DVN 配置与 TVL 数据一同公开，作为常规披露的一部分？这些信息在链上可查，但规范化才是关键。如果有一种标准能够将安全参数与收益率以同等显著性呈现，将会改变哪些配置能够被成熟资本所容忍。
操作安全失误这一组成部分如何具有普遍性？同一类失误——一把密钥承担了第二项职责——在多签签名者、验证者运营者和桥接团队中反复出现。尽管这类问题广为人知却依然存在，说明这一差距是制度性而非信息性的。而究竟什么样的制度结构能够真正防止此类问题，在加密行业中至今仍是一个基本悬而未决的问题。
对 Kelp DAO 事件最简单的解读是：一个单点故障发生了失败。更有价值的解读是：在 2025 年，单点故障依然被部署在生产环境中，由专业团队运营，保护着真实价值——而使这一切成为可能的架构，是其所运行的消息传递层的一项特性，而非缺陷。这项特性在这次事件之后是否仍能被合理捍卫，已从一个既定结论，变成了一个悬而未决的问题。
Introducción
Los protocolos de mensajería cross-chain ocupan un lugar incómodo en el stack cripto. Son infraestructura: invisibles cuando funcionan, catastróficos cuando fallan, y protegen más valor que la mayoría de las aplicaciones construidas sobre ellos. Cuando un bridge falla, el modo de fallo rara vez es sutil: un atacante emite activos en una cadena sin el correspondiente bloqueo en otra, y la diferencia se convierte en la pérdida de alguien.
El reciente incidente de Kelp DAO en LayerZero merece analizarse no porque haya expuesto una vulnerabilidad novedosa, sino porque reveló algo más incómodo: una decisión de configuración que nadie fuera de la integración estaba escrutando, combinada con un error operativo que cualquier revisión de seguridad habría detectado de haberla buscado. LayerZero emitió una disculpa pública en noviembre de 2025 y reconoció que la aplicación había sido configurada con un único verificador, y que la clave que controlaba ese verificador había sido utilizada en un contexto que nunca debería haber tocado.
La pregunta técnica —cómo viaja un mensaje de la cadena A a la cadena B y quién decide si es válido— es la misma que responde todo protocolo cross-chain, y cada respuesta constituye un modelo de confianza distinto. La respuesta de LayerZero es inusualmente flexible: la aplicación elige. Esa flexibilidad es el argumento de venta del protocolo y, en este caso, el origen del fallo. Queremos recorrer en detalle qué es realmente el stack de seguridad, cómo la configuración de Kelp se alejó de un esquema defendible, qué nos dice el fallo operativo sobre las prácticas de gestión de claves entre los integradores, y cómo sería un default más conservador.
Esto es un post-mortem, no un veredicto sobre LayerZero como protocolo. Las preguntas arquitectónicas que plantea aplican a cualquier capa de mensajería que delegue las decisiones de verificación hacia abajo.
Cómo funciona realmente el stack de seguridad de LayerZero
LayerZero se entiende mejor no como un bridge sino como un protocolo de mensajería genérico. Una aplicación en una cadena emite un mensaje; el protocolo entrega un payload a un contrato homólogo en otra cadena; ese contrato decide qué hacer con él. El protocolo en sí no custodia activos. Las aplicaciones que lo integran —bridges de tokens, despliegues de tokens fungibles omnichain (OFT), relés de gobernanza— sí lo hacen.
El protocolo separa tres preocupaciones que los diseños anteriores de bridge tendían a fusionar.
La verificación responde si un mensaje que afirma originarse en la cadena A realmente lo hizo. En LayerZero V2, esto está a cargo de una o más Redes de Verificadores Descentralizados (DVNs, por sus siglas en inglés). Una DVN es un servicio off-chain que monitorea la cadena de origen, atestigua los mensajes que observa y envía esas atestaciones a la cadena de destino. Se pueden configurar múltiples DVNs por ruta, y la aplicación establece un umbral: cuántas de las DVNs configuradas deben coincidir antes de que un mensaje se considere verificado.
La ejecución responde quién paga el gas y dispara la entrega en la cadena de destino una vez completada la verificación. Los ejecutores tienen incentivos económicos, pero no pueden falsificar mensajes: solo pueden entregar los que ya han sido verificados.
La lógica de la aplicación se sitúa por encima de ambas capas. El contrato de destino recibe el payload verificado y decide qué hacer: acuñar, quemar, actualizar estado, reenviar a otro contrato.
La decisión de diseño crítica es que la configuración del verificador es por aplicación. Dos aplicaciones distintas que usan LayerZero en el mismo par de cadenas pueden tener supuestos de seguridad completamente diferentes. Una podría requerir atestaciones de cinco DVNs independientes; otra podría requerir una sola. El protocolo no impone un mínimo.
Esto es, en principio, defendible. Las aplicaciones tienen modelos de amenaza distintos y distintas tolerancias al coste. Un bridge de gaming de alto rendimiento y bajo valor podría razonablemente aceptar un conjunto de verificación más delgado que un token de restaking líquido de varios miles de millones de dólares. El protocolo deja la elección en manos del integrador.
En la práctica, significa que la seguridad de cualquier ruta de LayerZero es exactamente la seguridad del conjunto de verificadores más débil elegido por la aplicación que la usa, y que esa elección es visible on-chain pero rara vez auditada por alguien que no sea el propio integrador.
La configuración con un único verificador
Una configuración DVN defendible tiene más o menos este aspecto: al menos dos verificadores operativamente independientes, cada uno con infraestructura que no comparte claves, hosting, stack de monitoreo ni operador con los demás. Un umbral que exige que todos los verificadores configurados estén de acuerdo. Idealmente, una tercera DVN “opcional” con un umbral más alto para mensajes de alto valor, o un timelock entre verificación y ejecución que le dé tiempo a un tercero para impugnar.
La ruta de Kelp DAO no estaba configurada así. Según el propio relato de LayerZero, la aplicación contaba con una única DVN responsable de atestiguar mensajes en la ruta afectada. Ese único firmante era suficiente para verificar cualquier mensaje que afirmara originarse en el contrato fuente.
La implicación de esa configuración merece plantearse sin rodeos. Quien controlara la clave de firma de esa DVN podía, en solitario, atestiguar cualquier mensaje a su elección. No necesitaba comprometer un quórum. No necesitaba coordinar con nadie. Solo necesitaba la clave —y una vez que la clave firmara una atestación de que un determinado mensaje cross-chain había ocurrido, el contrato de destino no tenía forma de distinguirla de una legítima.
Esto es estructuralmente equivalente a un multisig 1-de-1 que protege todo lo que el contrato de destino está autorizado a hacer. En el caso de Kelp DAO, el contrato de destino estaba autorizado a emitir representaciones de activos bajo restaking en una cadena remota. El multisig 1-de-1, en la práctica, protegía la autoridad de emisión de esas representaciones.
Es tentador llamar a esto una vulnerabilidad. No lo era, en sentido técnico. Los contratos se comportaron exactamente como estaban configurados. El verificador produjo una atestación; el contrato de destino la aceptó; la emisión ocurrió. Cada pieza de código en la cadena de custodia hizo lo que se suponía que debía hacer. El fallo fue anterior al código: en la decisión de cuántos atestadores independientes requería la aplicación.
Por qué las aplicaciones eligen configuraciones delgadas
Sería fácil atribuir la configuración a negligencia, y en algunos casos puede ser acertado. Pero existen razones reales por las que las aplicaciones terminan con conjuntos de verificadores más delgados de lo que deberían.
La primera es el coste. Cada DVN adicional añade una tarifa por mensaje. Para aplicaciones de alto rendimiento, la diferencia entre uno y tres verificadores se acumula hasta convertirse en un gasto operativo significativo.
La segunda es la latencia. Los verificadores atestiguan de forma asíncrona, y el mensaje en la cadena de destino queda bloqueado hasta que el más lento alcance el umbral. Más verificadores significa más varianza y una cola más larga.
La tercera es la simplicidad operativa. Cada DVN adicional es una contraparte más, una superficie de monitoreo más, otro posible punto de inactividad que puede paralizar toda la ruta. Las aplicaciones que optimizan la disponibilidad a veces eligen configuraciones más simples y aceptan la cesión de confianza, frecuentemente sin modelarla explícitamente como tal.
La cuarta, y más incómoda, es que las configuraciones por defecto que heredan los nuevos integradores no siempre están bien calibradas para el valor que la integración acabará asegurando. Una aplicación que se lanza con un TVL modesto y crece hasta alcanzar uno mucho mayor puede arrastrar una configuración que era razonable en el lanzamiento y ya no lo es a escala. Revisar y reforzar esa configuración en función del TVL no es un proceso que la mayoría de los equipos haya institucionalizado.
El fallo operativo: una clave con dos trabajos
La configuración por sí sola habría sido un riesgo latente. Lo que lo convirtió en una pérdida realizada fue un fallo operativo que la disculpa pública describió en términos inusualmente directos: la wallet que controlaba el verificador fue utilizada por alguien en LayerZero —o en el entorno operativo del verificador— para realizar una operación personal. El flujo de esa operación expuso la wallet a un contexto para el que no estaba blindada, y la capacidad de firma quedó comprometida.
No disponemos de un análisis forense público del vector de compromiso exacto. Lo que sí tenemos es la categoría del fallo, que es reconocible. Una wallet que controla infraestructura de producción nunca debería firmar nada que no sean mensajes de producción. En el momento en que interactúa con un frontend, una aprobación de contrato inteligente, un swap en un DEX o cualquier flujo de firma de transacciones de terceros, hereda toda la superficie de ataque de ese flujo: phishing, firmas de aprobación maliciosas, frontends comprometidos, ataques a la cadena de suministro del propio software de la wallet.
La práctica estándar —bien documentada en custodia institucional, operaciones de validadores e ingeniería de protocolos— es que las claves de firma para infraestructura privilegiada residan en módulos de hardware dedicados a ese único propósito, en máquinas que no navegan por internet, en flujos de trabajo que no incluyen ninguna transacción iniciada por humanos fuera del formato de mensaje de producción. Una clave de firma de verificador debería parecerse más a una clave de validador que a una wallet personal.
Que este principio fuera violado por personal cercano a un protocolo cuya propuesta de valor entera es la seguridad de la mensajería es la parte del post-mortem que debería hacer reflexionar a todo integrador cross-chain. No porque el equipo de LayerZero sea singularmente descuidado —no hay evidencia pública de eso, y la disposición a publicar un relato sincero sugiere lo contrario— sino porque el principio es ampliamente conocido y, aun así, fue violado. La brecha entre conocer una práctica e institucionalizarla es más amplia de lo que la mayoría de las organizaciones admite.
Lo que el post-mortem reveló y lo que dejó sin responder
La disculpa pública reconoció dos cosas directamente: que la configuración del verificador era más delgada de lo que debería haber sido para el valor en juego, y que la separación operativa de la clave del verificador respecto a la actividad personal se quebró. Esas son las admisiones estructurales.
Varias cosas siguen siendo menos claras en las fuentes públicas. El alcance total de los usuarios afectados y el valor exacto en dólares de la pérdida realizada han sido reportados en rangos que varían entre las distintas coberturas. La vía de compensación —quién absorbe la pérdida, qué papel juega el tesoro de la aplicación afectada y qué cambios a nivel de protocolo se derivan— es el tipo de cuestión que normalmente se resuelve en semanas, no en días. Deliberadamente no asignamos cifras específicas aquí; la forma cualitativa del incidente importa más para el análisis arquitectónico que el número preciso, y ese número es el tipo de afirmación que no debería hacerse sin una fuente verificable.
Lo que hizo el mensaje del exploit
La secuencia mecánica de un exploit como este es sencilla una vez que el verificador está comprometido, y vale la pena trazarla porque ilustra cuánta superficie adicional se necesita realmente.
El atacante, con el control de la clave de firma comprometida, construye una atestación para un mensaje que nunca fue emitido en la cadena de origen. La atestación tiene el formato correcto: lleva la firma que el contrato de verificación del lado destino espera ver, y referencia una transacción de la cadena de origen que o bien no existe o cuyo payload ha sido alterado. La atestación se envía a la cadena de destino a través de los canales habituales.
El contrato de verificación del lado destino comprueba la firma contra el conjunto de DVNs configurado. Como ese conjunto contiene únicamente la clave comprometida, y la firma es válida frente a esa clave, la verificación pasa. El mensaje queda marcado como verificado.
Un ejecutor —posiblemente el propio atacante, posiblemente un tercero involuntario que responde al incentivo estándar del ejecutor— recoge el mensaje verificado y lo entrega al contrato de aplicación de destino. El contrato de aplicación recibe un mensaje verificado que afirma originarse en su contraparte de confianza en la cadena de origen, y actúa en consecuencia: en el caso de Kelp DAO, tratando el mensaje como prueba de que se habían depositado activos en la cadena de origen y que las representaciones correspondientes debían emitirse en la cadena de destino.
Las representaciones se venden o intercambian a través de los venues de liquidez disponibles para ellas en la cadena de destino. Para cuando se detecta la discrepancia —por el monitoreo de la aplicación, por observadores externos que comparan los saldos bloqueados en la cadena de origen con el suministro emitido en la cadena de destino— el atacante ya ha convertido la emisión sin respaldo en activos líquidos, y la pérdida ha cristalizado en forma de representaciones que ya no tienen colateral detrás.
La asimetría a destacar aquí es que toda la ruta del exploit discurre a través del comportamiento estándar del protocolo. Nada fue hackeado en el sentido coloquial: ningún contrato fue engañado, ninguna lógica fue quebrada. Un mensaje fue firmado por la clave autorizada a firmarlo. El sistema hizo exactamente lo que estaba configurado para hacer. El fallo fue que la configuración trató una única clave como evidencia suficiente para una autoridad de emisión de varios millones de dólares.
Cómo es una arquitectura de verificadores defendible
La respuesta reactiva es “más verificadores”, y eso es parte de la respuesta, pero solo una parte. El requisito más profundo es la independencia de los modos de fallo: múltiples verificadores cuyo compromiso simultáneo exija algo más que repetir el mismo ataque dos veces.
Una configuración defendible para una aplicación que asegura valor significativo debería, como mínimo, exhibir varias propiedades.
Independencia operativa entre verificadores. Organizaciones distintas, infraestructura de firma distinta, disposiciones de custodia de claves distintas, proveedores de nube o entornos de hosting distintos. Dos verificadores gestionados por el mismo equipo en la misma infraestructura no son dos verificadores; son uno con una firma redundante.
Umbral dimensionado al modelo de amenaza, no al número mínimo viable. Un umbral de 2-de-3 es significativamente distinto de 1-de-2, y ambos son significativamente distintos de 1-de-1. La elección debería ser función del valor en riesgo en la ruta, no del default que minimiza el coste por mensaje.
Heterogeneidad en la implementación de los verificadores. Los verificadores que ejecutan software idéntico comparten bugs. Una configuración que incluye verificadores con distintas implementaciones de cliente —análogo a cómo la capa de consenso de Ethereum se beneficia de la diversidad de clientes— es robusta frente a compromisos a nivel de software que dejarían fuera a un conjunto homogéneo.
Timelocks y ventanas de impugnación para mensajes de alto valor. Un breve retardo entre verificación y ejecución, durante el cual un observador externo puede señalar inconsistencias entre el estado de la cadena de origen y el mensaje afirmado, convierte un exploit de un solo disparo en uno contestado. Para aplicaciones donde unos minutos de latencia son aceptables, esta es una de las defensas más baratas disponibles.
Configuraciones públicas y monitoreables. El conjunto DVN y el umbral de cualquier aplicación LayerZero son visibles on-chain. Rara vez se presentan en la documentación de cara al usuario ni en dashboards de terceros. Una norma por la que los integradores publiquen y justifiquen su configuración de seguridad, y en la que investigadores externos la auditen rutinariamente frente al valor en juego, sacaría a la luz las discrepancias antes de que lo hagan los exploits.
Qué implica esto para la capa de protocolo
LayerZero, como protocolo, ha posicionado consistentemente la flexibilidad de su configuración de verificadores como una característica: las aplicaciones pueden ajustar su stack de seguridad a sus necesidades. El incidente de Kelp no contradice ese posicionamiento, pero sí agudiza una pregunta que la capa de protocolo no puede delegar por completo.
Si la decisión de configuración recae en la aplicación, y las aplicaciones sistemáticamente infraconfiguran en relación al valor que terminan asegurando, entonces “flexibilidad” es una descripción elegante de una externalidad. El integrador captura el ahorro de coste de una configuración delgada; la reputación del protocolo absorbe las consecuencias cuando esa configuración falla. Si la corrección adecuada es un mínimo a nivel de protocolo, un default recomendado con advertencias prominentes ante desviaciones, o un requisito de configuración indexado al valor, es una pregunta de diseño abierta. Cada opción tiene sus contrapartidas frente a la tesis más amplia del protocolo sobre la integración sin permisos.
Lo que parece más difícil de defender, tras este incidente, es el statu quo: una superficie de configuración donde la diferencia entre un setup defendible y una vulnerabilidad de clave única es invisible para los usuarios finales y en gran medida invisible para el mercado en general hasta que un compromiso la cristaliza.
Implicaciones y preguntas abiertas
El incidente de Kelp DAO es más instructivo como caso de estudio sobre cómo se distribuyen realmente los supuestos de confianza cross-chain. La superficie de marketing de un protocolo de mensajería describe una red: verificadores descentralizados, responsabilidades separadas, seguridad por umbral. La superficie realizada, para cualquier aplicación concreta, es el subconjunto de esa red que la aplicación eligió usar, y las prácticas operativas que los operadores de ese subconjunto siguen en la práctica.
Para los integradores, la lección inmediata es que la configuración de seguridad de una ruta cross-chain no es una decisión de configuración que se toma una sola vez. Es un parámetro que debe revisarse en función del valor que fluye a través de ella, y reforzarse —posiblemente de forma significativa— a medida que ese valor crece. Los defaults con los que se lanza una ruta casi nunca son los defaults con los que debería operar a escala.
Para los usuarios de aplicaciones cross-chain, la lección más dura es que la superficie de confianza no es visible desde el frontend de la aplicación. Un token envuelto a través de un protocolo de mensajería puede estar respaldado por un conjunto de verificadores 5-de-7; un token envuelto a través del nominalmente mismo protocolo puede estar respaldado por uno 1-de-1. La interfaz visible para el usuario es idéntica. El riesgo económico no lo es.
Varias preguntas van más allá de este incidente específico y merecen seguimiento.
¿Cómo enmarcarán su diferenciación, a raíz de esto, los protocolos de mensajería competidores —los que se posicionan en torno a seguridad compartida, verificación respaldada por restaking o sistemas de pruebas de conocimiento cero que llevan la verificación on-chain—? La presión de marketing para reclamar “sin verificadores de confianza” aumentará. Las afirmaciones técnicas deberán examinarse con cuidado; muchas de ellas desplazan el supuesto de confianza en lugar de eliminarlo.
¿Publicará alguna fracción significativa de los integradores de LayerZero sus configuraciones DVN junto a su TVL, como práctica habitual de divulgación? La información está on-chain, pero la normalización importa. Un estándar que ponga en primer plano el parámetro de seguridad al mismo nivel de prominencia que una tasa de rendimiento cambiaría qué configuraciones tolera el capital sofisticado.
¿Cómo generaliza el componente de fallo en seguridad operativa? La misma clase de error —una clave con un trabajo siendo usada para un segundo— es un modo de fallo recurrente entre firmantes de multisigs, operadores de validadores y equipos de bridges. El hecho de que persista a pesar de ser bien conocido sugiere que la brecha es institucional más que informativa, y la pregunta sobre qué estructuras institucionales lo previenen realmente sigue sin respuesta en gran medida en la industria cripto.
La lectura más simple del incidente de Kelp DAO es que un punto único de fallo falló. La lectura más útil es que los puntos únicos de fallo siguen desplegándose en producción, por equipos sofisticados, asegurando valor real, en 2025 —y que la arquitectura que lo hace posible es una característica, no un bug, de la capa de mensajería sobre la que operan. Si esa característica sigue siendo defendible es, tras este incidente, una pregunta abierta y no un asunto zanjado.