I often get asked why I work at @LayerZero_Labs.
To me, LayerZero is the most scalable, secure, and efficient cross-chain smart contract protocol currently available.
First some context. Before LayerZero, to send anything to a new chain, most dApps used some type of monolithic bridge:
- Centralized Provider: a centralized entity, manually delivering messages to the destination chain.
- Collection of Signers: a collection of different signers which verify the message before delivering.
- Middlechain Bridge: a blockchain which routes all messages through the hub chain, inheriting the security of the middlechain.
(Note: I'll define each of these "security mechanisms" as verifier networks).
While each verifier network came with trade-offs, all suffered from one common problem: a single verifier network determined which messages would be delivered on the destination chain.
If that security ever failed, due to centralization, a backdoor in the signer software, the middlechain lacking node client diversity, or upgradeable contracts, every application built on top of that verifier network suddenly had their security fail too.
No matter which verifier network you pick, the reality is that you now depend entirely on that sole network to verify your messages correctly.
Being locked into a single verifier network means that in the best case, your application needs to fully redeploy to avoid being exposed to a security vulnerability.
In the worst case, not just your application, but every application and user interacting with that verifier network faces cataclysmic losses (source: the rekt leaderboard and the socket hack just a few months ago).
How does LayerZero solve this?
LayerZero is an immutable, censorship-resistant, and permissionless smart contract protocol that enables anyone on a blockchain to send, verify, and execute messages on a supported destination network.
Reason 1: Immutable Contracts
To send and receive messages on a target blockchain, a non-upgradeable LayerZero Endpoint contract must be deployed to that chain.
This Endpoint contract acts as the entry and exit point for the protocol, enabling applications and users to:
- Send messages from the source blockchain (Endpoint.send).
- Configure application security (Endpoint.setConfig).
- Configure execution settings (Endpoint.setConfig).
- Quote cross-chain transaction gas costs (Endpoint.quote).
- Receive messages on the destination chain (Endpoint.lzReceive).
- Debug and retry failed messages (Endpoint.lzReceive).
and a handful of other utilities.
The LayerZero Endpoint provides users a predictable, immutable interface for sending arbitrary data, external function calls, and tokens.
Anytime you need to send or receive messages, all you need to do is interact with the LayerZero Endpoint contract on that chain.
Reason 2: Modular Security
LayerZero allows applications to configure any number and type of decentralized verifier networks (DVNs) to verify their cross-chain messages.
Instead of every application depending on the same verifier network, each application now has a unique verifier configuration called a Security Stack, allowing developers to maintain access controls on arguably the most important part of their application.
New verifier networks can be added at anytime using these access controls, future-proofing cross-chain applications to the latest and greatest verification techniques (for example, @PolyhedraZK's zkLightClient).
This means that dApps don't need to accept a one-size-fits-all model for cross-chain messaging, and instead actually can control how messages are verified on the destination chain.
Teams are starting to realize that this means they can build omnichain dApps with variable security based on their use cases, message volume, domains, etc. In terms of cross-chain messaging, it's a new frontier for devs to explore.
Reason 3: Permissionless Execution
Because anyone can interact with the LayerZero Endpoint on the destination chain, LayerZero offers permissionless message execution.
Once a message has been verified by an application's chosen decentralized verifier networks (DVNs), that message can be executed by calling the Endpoint's lzReceive method.
In most cases, this execution is done automatically by an application's configured Executor, a production asset run in the ecosystem which automatically delivers messages after verification.
This Executor fully abstracts gas on the destination chain, allowing users to pay for gas only using the source chain's gas token, and add specific execution options for the cross-chain message.
Anyone can develop and run their own Executor, and should a configured Executor ever disappear, these messages can still be permissionlessly executed at anytime.
The Big Picture
When LayerZero talks about the idea of an omnichain application, we refer to this idea where your smart contracts can control how their messages are sent, verified, and executed on any blockchain in the network.
It's a fundamentally better system, where developers don't have to hand the keys away to the most critical component of their decentralized application.
Instead, use a smart contract protocol that gives you an easy, secure, and future-proof interface to send anything between blockchains.
Want to get started?
Head to our docs (link in bio), or leave a comment / DM!
And remember, LayerZero is permissionless, censorship-resistant, and immutable.
ZRO Updates
More ZRO has been bought back and locked up than sold into the market. Institutions and buybacks have taken 19.77% of supply in 18 months, while 63.8% of ZRO unlocked to investors still hasn't moved. $112.7M has gone into ZRO buybacks since September 2025, one of the largest programs in crypto.
ZRO is the only asset in the LayerZero ecosystem. All economic value from Zero, LayerZero, and Stargate flows back to it.
Every token expresses a view. ZRO's first was that there'd be many chains, no single winner, and value would accrue to whatever connected them. Now LayerZero has moved $267B across 165 chains.
The next view is bigger. Money and markets are the two largest waves finance will ever see, and both are already onchain. Zero was built for this moment. Coming this fall.
Over the last 30 days, @LayerZero_Core facilitated:
-> $8.2B in volume
-> 87,684 unique wallets
-> 153 destination chains
Cross-chain interoperability is bigger than most people realize.
Full dashboard next week.
We’re sharing our completed post-mortem on the April 18th incident, prepared with @Mandiant and @CrowdStrike. We are publishing both an executive summary and the full report at the link below.
Over the past four weeks, we’ve worked with hundreds of partners to help them understand their current security posture, and harden it where appropriate. We’ll continue this work, alongside taking additional proactive steps for the benefit of not only our partners, but also the ecosystem as a whole.
We want to extend our thanks to our partners for their support and patience this past month. There’s a reason that over $12 billion has moved across the network in the past four weeks, and why the world’s most valuable asset issuers have stood by our side: they believe in us, in what the LayerZero protocol has to offer, and in the value of modular, isolated, application-controlled security.
The work continues. And we look forward to continue showing up for the applications that trust us with their business, as well as the broader ecosystem.
https://t.co/7bILN6dPJz
Those admins don’t have any control over signer properties nor do they have the ability to change security properties of the DVN.
They’re specifically a gas abstraction service to deliver signed hex data from the DVN quorum, and the admin role is superseded by the signers at any time.
A ton of this is just completely untrue.
1) Kelp originally used the defaults which were MultiDVN or DeadDVN and manually migrated to a 1/1 config later
2) Almost 100% of the volume on a 1/1 config was rsETH
3) Not using a 1/1 for production applications is mentioned many times in the documentation.
The defaults Kelp is referencing in their screenshot were multiDVN or DeadDVN, which force-rejects an application using the defaults at all and requires them to manually set configuration.
rsETH was originally configured to use the default LayerZero configuration of a multiDVN setup of LayerZero Labs + Google:
Here are the exact transactions where that happens
Ethereum → Arbitrum:
https://t.co/C2uCxmpBCX
at 2024-02-06 03:09:47 UTC
Ethereum → Optimism:
https://t.co/vuQWxeyUUA
at 2024-02-06 03:09:59 UTC
KelpDAO then manually changed these to 1/1 configs:
For the original Feb 6 Ethereum routes to Arbitrum/Optimism, KelpDAO’s Ethereum contract switched from defaults to manual OApp-scoped config on 2024-04-01:
Send-side manual config:
https://t.co/HKCE8C8n7F
2024-04-01 07:12:11 UTC
Receive-side manual config:
https://t.co/FZTiol0qAp
2024-04-01 07:12:23 UTC
From this point on, Kelp began deploying all of their configurations as 1/1 configs. Here is Kelp’s deployment on Unichain:
Unichain → Ethereum was opened on 2025-04-01 18:55:41 UTC.
Pathway-open / setPeer tx:
https://t.co/0MlFpIxCfA
The manual ULN config followed 6 seconds later in https://t.co/0di0j78zYc.
During this time the Unichain -> Ethereum and Ethereum -> Unichain defaults were set to DeadDVN which is a contract which makes it impossible for any application to transact without manually configuring their DVNs, this was not possible on the defaults of this pathway.
Here is the code in the DeadDVN (https://t.co/mAge3W6NhP) that specifically prohibits this.
(Screenshot 1)
This is called out many many times in the docs:
1. Integration Checklist — "Do" list
- Last edited: 2025-11-26 (Nazreen)
- Content: "Do: … Use more than one DVN for each production pathway instead of relying on a single DVN."
- File: v2/tools/integration-checklist.mdx:244
- URL: https://t.co/h9GHby9ynE
2. Integration Checklist — "Don't" list
- Last edited: 2025-11-26 (Nazreen)
- Content: "Don't: … Configure only one DVN for a pathway and treat it as production‑ready."
- File: v2/tools/integration-checklist.mdx:251
- URL: https://t.co/h9GHby9ynE
3. Integration Checklist — Defaults are not safe
- Last edited: 2025-09-25 (Tino Martínez Molina)
- Content: "Do not assume defaults are safe for production. Always check explicitly: getSendLibrary, getReceiveLibrary, and getConfig. If these resolve to defaults, confirm whether the defaults are valid for the intended pathway. Unintentional fallbacks to defaults are a common cause of blocked or failing pathways."
- File: v2/tools/integration-checklist.mdx:126-128
- URL: https://t.co/a6SdjYCbOu
4. Integration Checklist — Default fallback warning
- Last edited: 2026-02-26 (migration; same wording predates it)
- Content: "Warning: If no configuration is set, the OApp will fallback to the default settings set by LayerZero Labs."
- File: v2/tools/integration-checklist.mdx:222-238
- URL: https://t.co/h9GHby9ynE
5. ONFT Quickstart — Production guidance
- Last edited: 2025-02-20 (Radek Sienkiewicz)
- Content: "DVN Settings: Use multiple DVNs in production to ensure message verification is robust."
- File: v2/developers/evm/onft/quickstart.mdx:700
- URL: https://t.co/b8nO2yrEiX
6. ONFT Quickstart — Strong recommendation to configure
- Last edited: 2025-03-10 (Radek Sienkiewicz)
- Content: "We strongly recommend reviewing these settings carefully and configuring your security stack according to your needs and preferences."
- File: v2/developers/evm/onft/quickstart.mdx:366
- URL: https://t.co/WcNuXHLbiG
7. Starknet FAQ — "Should I use multiple DVNs?"
- Last edited: 2026-01-21 (Nazreen)
- Content:
▎ Should I use multiple DVNs?
▎ Recommended for production. Multiple DVNs provide:
▎ - Increased security (multiple independent verifiers)
▎ - Resilience (no single point of failure)
▎ - Trust minimization
- File: v2/developers/starknet/troubleshooting/faq.mdx:290-296
- URL: https://t.co/vtSZUFLZPJ
Here are the exact recommendations we gave KelpDAO when asked about DVNs (typically 2/3)
(Screenshot 2)
Other LayerZero applications speaking on exactly what is advised by the team
https://t.co/0ulWmlTZ2y
https://t.co/vQ2B8YQrw9
For how much volume was actually configured on 1/1 here is the exact data.
(Screenshot 3)
We will publish a complete post-mortem as soon as the external security firms have completed it.
Thanks to @LayerZero_Core, who has been actively engaging with Aave and the broader DeFi United movement since the moment the rsETH incident occurred.
Their contribution advances our plan to restore rsETH's backing and normalize market conditions.
Of the “47% of LZ apps run 1-of-1 DVN” number floating around yesterday, only 10 of the ~1,100 have done $1m lifetime.
Less than 1%.
And 5 of those 10 are rsETH, the other 5 you have never heard of.
Don’t take everything at face value.
What’s happening right now on our side
- Working with industry recovery group
- Working with external security groups
- Working with all relevant external law enforcement agencies
- DVN is live, Stargate just went through additional hardening pass
- Spending 100% of cycles hardening security across every possible vector for applications. We will be able to say a lot more on here but right now security is the #1 priority across the board
- Expect more updates on all fronts, will start streaming more steady state of information now that initial investigations are largely resolved
layerzero is the best bridge in the space
offering true decentralization lets users make bad config decisions
but decentralization is the only thing that matters. all the thoughtless multisig bridges died long ago
primo & co are among the few good guys shipping infra left