Page record
- Title
- LayerZero
- Category
- Bridges and interop
- Version
- v0.2 draft
- Date
- 2026-10-06
- Status
- Draft, not filed
- Canon
- This page is canonical. PDF export is a rendering of this page, not a separate document.
- Proof
- None yet. Le Coin hashes a page only when the Principal publishes it.
Changelog.
- v0.2 (2026-10-06; replaces v0.1, sha256 479bc49a7f83924cd2b043217721bbfb13cbebc0033699e8c1650c1f00c722e2): attributed the KelpDAO attack to Mandiant and CrowdStrike, the firms LayerZero Labs retained, with the report's confidence levels (DPRK "with high confidence"; UNC4899/TraderTraitor "with medium confidence"), added zeroShadow's corroborating attribution, and stated that Le Coin has not independently verified it; dated the full incident report May 18, 2026 (published May 20); added the incident report as the source for the 116,500 rsETH figure; replaced an unsupported claim about the most common use with "Messages can carry arbitrary data"; re-cited the X-of-Y-of-N bullets to the Production DVN Configuration and Security Stack pages and added the optional threshold; added the LayerZero Foundation's "Fee Switch Referendum #3" post (December 18, 2025) as the source that ZRO holders vote; replaced "the docs we reviewed do not say" on the default migration with dated wording noting the two-DVN default presets still listed on October 6, 2026; cited the ZRO buybacks line; relabeled the learning hub from "The File" to "Library".
1. What it is
LayerZero is a messaging protocol that lets smart contracts on one blockchain send messages to contracts on another [1]. Messages can carry arbitrary data [1]; moving tokens between chains, through the Omnichain Fungible Token (OFT) standard, is one use [6]. LayerZero Labs owns the multisig that administers the Endpoint contracts and runs one of the verifier services [11]. The LayerZero Foundation runs ZRO token votes on a protocol fee [12][13].
Its central design choice is that each application picks its own security [1]. Older bridges typically relied on one fixed set of signers, so a failure there put every connected application at risk [1]. On LayerZero, each application chooses which independent verifiers must approve its messages, how many, and how long to wait for the source chain to settle [1][4].
That flexibility cuts both ways. In April 2026, an application that relied on a single verifier lost 116,500 rsETH after that verifier was fed false data [9][10]. The incident, and LayerZero's changes since, are covered in What changed.
LayerZero is one of the cross-chain routes listed for Robinhood Chain. Chainlink's CCIP, a different design for the same job, is covered in the Chainlink dive.
2. How it works
Endpoints
Every supported chain has a LayerZero Endpoint contract [2]. LayerZero describes the Endpoint as "immutable" and "permissionless": it cannot be upgraded, and anyone can use it [1][2]. Every message passes through it [2]. The Endpoint gives each message a unique ID and a nonce, records the hash of each verified message, and makes sure each one is delivered exactly once [2].
Applications built on LayerZero are called OApps [1]. An OApp chooses message libraries, which control how messages are emitted and checked [1][2].
Verifiers (DVNs)
Messages are checked by Decentralized Verifier Networks (DVNs) [3]. A DVN is any service that confirms a message's hash on the destination chain [3]. DVNs can use different methods, and "DVN Adapters" let applications plug in other systems, such as native chain bridges [3].
Each application sets an "X-of-Y-of-N" rule for each route [3][4]:
- X required DVNs, every one of which must sign each message [3][7].
- A threshold Y of optional DVNs that must also sign [3][7].
- A pool of N optional DVNs to draw from [7].
The destination accepts a message only when every required DVN has attested and the optional threshold, if any, is met [3][7].
Executors
Once a message is verified, someone has to deliver it on the destination chain [5]. Executors do this as a paid service, so users do not need gas on every chain [5]. Delivery is permissionless: if an executor fails, anyone can pay the gas and complete the delivery by hand [5][11].
Omnichain tokens (OFT)
The Omnichain Fungible Token (OFT) standard lets one token exist on many chains with a single overall supply [6]. A transfer burns or locks tokens on the source chain and mints or unlocks them on the destination [6]. New tokens usually burn and mint on every chain [6]. Existing tokens use an "OFT Adapter" that locks them on their home chain [6]. LayerZero's own threat model notes that a forged message can release collateral held in such a "lockbox" [7].
Defaults and the Labs multisig
An application that does not set its own configuration falls back on defaults [11]. These defaults cover block confirmations, message library and choice of DVNs [11]. A LayerZero Labs multisig owns the Endpoints and sets these defaults [11]. That multisig can connect new chains, add new verification libraries (append-only) and change defaults [11]. LayerZero Labs says the defaults are "intended to be for testing only" and that a properly configured application is unaffected by the multisig's powers [11].
3. What changed
| Date | Event | Source |
|---|---|---|
| Dec 2024 to Jun 2026 | Four ZRO votes on a protocol fee; all "Off" | [12] |
| Mar 6, 2026 | Attacker begins breach of LayerZero Labs systems | [10] |
| Apr 18, 2026 | KelpDAO rsETH loses 116,500 rsETH | [9][10] |
| Apr 19, 2026 | Labs DVN stops serving single-verifier setups | [11] |
| May 8, 2026 | LayerZero Labs apology and security update | [11] |
| May 18, 2026 | LayerZero Labs incident report (published May 20) | [10] |
The KelpDAO incident (April 18, 2026). KelpDAO's rsETH token used a 1-of-1 setup, with the LayerZero Labs DVN as its only verifier [9][10]. LayerZero Labs' report says the breach began on March 6, 2026, when an attacker socially engineered a Labs developer and moved into the company's cloud environment [10]. The attacker tampered with internal RPC nodes, the servers the DVN used to read blockchain data [10]. Those nodes gave correct answers to monitoring tools but false ones to the DVN [10]. A denial-of-service attack on an external RPC provider then forced the DVN to rely on the compromised nodes [10]. The DVN signed a forged message, and because no second verifier was required, the destination contract released 116,500 rsETH [10].
LayerZero Labs says the on-chain protocol worked as configured and no other application was affected [9][10]. LayerZero Labs retained the security firms Mandiant and CrowdStrike to investigate the incident and provide attribution. In LayerZero Labs' incident report, the two firms attribute the attack to North Korea (DPRK) "with high confidence" and assess "with medium confidence" that it is specifically associated with the group UNC4899, also known as TraderTraitor [10]. zeroShadow, a third firm retained by LayerZero Labs, "provided corroborating attribution," and two independent researchers named in the report also attribute it to UNC4899 [10]. Le Coin has not independently verified the attribution.
LayerZero Labs' changes. LayerZero Labs said on May 8, 2026 that it "made a mistake by allowing our DVN to act as a 1/1 DVN for high-value transactions" [11]. Since then [10][11]:
- Its DVN refuses to be the only required verifier on any route [10][11].
- Default settings are moving to 5-of-5 verifiers where possible, and no fewer than 3-of-3 [11].
- It is writing a second DVN client in Rust and has tightened how DVNs choose RPC sources [11].
- It rebuilt the affected cloud environment rather than patching it [10].
- It plans to raise its own multisig from 3-of-5 to 7-of-10 signers where its new OneSig multisig is available [11].
The developer docs now warn that "single-DVN production configurations are not safe" [7][8]. They give a step-by-step guide for moving to multiple verifiers [7][8].
Multisig signer. In the same May 8 post, LayerZero Labs disclosed that about three and a half years earlier a signer had used a multisig hardware wallet for a personal trade [11]. The signer was removed and wallets were rotated [11].
Fee switch. ZRO holders have voted four times on whether to turn on a protocol fee, up to the cost of verifying and executing each message [12][13]. Fees collected would be converted to ZRO and burned [12]. Every vote, the latest from June 20 to 27, 2026, ended "Off" [12].
4. What is open
Security is only as good as each app's settings. LayerZero's model puts the security choice on each application [1]. LayerZero Labs now polices its own DVN's participation, but the protocol "continues to enforce whatever each application configures" [10]. Users of a given token have to check that token's configuration to know what protects it. The Labs-recommended steps are to pin configurations, set block confirmations high enough to avoid reorganizations, and require at least two DVNs [11].
Dependence on defaults. Applications that rely on defaults are, in LayerZero Labs' words, "fully reliant on the LayerZero Labs multisig" [11]. The migration of defaults to 5-of-5 where possible, and no less than 3-of-3, was described as in progress in May 2026 [10][11]. As of October 6, 2026, LayerZero's Security Stack page still lists default presets with two required DVNs, and says defaults "may change without notice" [3]. We found no primary source saying the migration is complete.
Correlated verifiers. Two DVNs from the same operator, cloud or verification method can fail together [7]. LayerZero's own guidance ranks diversity by operator, infrastructure, method and jurisdiction [7]. Not every DVN is deployed on every chain, so some routes cannot yet use multiple independent verifiers [7][8].
Recovery and liability. The incident report (dated May 18, 2026) mentions token tracking and seizure efforts with zeroShadow and law enforcement [10]. The outcome, and how losses were handled between KelpDAO, its users and LayerZero Labs, are not covered in LayerZero's primary sources we reviewed. KelpDAO's own account was not reviewed for this draft.
Fee switch and ZRO. The protocol fee has never been switched on [12]. Whether and when it will be is a governance question with no date. The Foundation's site also describes ZRO buybacks [12], which this dive does not cover.
What this page leaves out. By Library policy, this dive carries no price, market value, dollar loss figures or usage-volume figures, including those in LayerZero's own posts. Those go stale, and News covers them.
Sources
- 1LayerZero Docs, "What is LayerZero?" https://docs.layerzero.network/v2/concepts/getting-started/what-is-layerzero
- 2LayerZero Docs, "LayerZero Endpoint." https://docs.layerzero.network/v2/concepts/protocol/layerzero-endpoint
- 3LayerZero Docs, "Security Stack (DVNs)." https://docs.layerzero.network/v2/concepts/modular-security/security-stack-dvns
- 4LayerZero Docs, "Message Channel Security." https://docs.layerzero.network/v2/concepts/protocol/message-security
- 5LayerZero Docs, "Executors." https://docs.layerzero.network/v2/concepts/permissionless-execution/executors
- 6LayerZero Docs, "Omnichain Tokens." https://docs.layerzero.network/v2/concepts/applications/oft-standard
- 7LayerZero Docs, "Production DVN Configuration." https://docs.layerzero.network/v2/concepts/modular-security/production-dvn-configuration
- 8LayerZero Docs, "Migrating from a Single-DVN Configuration." https://docs.layerzero.network/v2/get-started/migrating-from-single-dvn
- 9LayerZero Blog, "KelpDAO Incident Statement" (April 19, 2026). https://layerzero.network/blog/kelpdao-incident-statement
- 10LayerZero Blog, "LayerZero Labs KelpDAO Incident Report" (May 20, 2026), with linked full report dated May 18, 2026. https://layerzero.network/blog/layerzero-labs-kelpdao-incident-report and https://layerzero.network/publications/kelpdao-incident-report.pdf
- 11LayerZero Blog, "LayerZero Update" (May 8, 2026). https://layerzero.network/blog/an-overdue-apology
- 12LayerZero Foundation, "LayerZero Fee Switch Referendum." https://layerzero.foundation/fee-switch
- 13LayerZero Foundation, "Fee Switch Referendum #3" (December 18, 2025). https://info.layerzero.foundation/fee-switch-referendum-3-cbb4a1b904d3
Not financial advice.