LayerZero V2 Deep Dive (2024)

Mark Murdock

Published in

LayerZero Official

32 min read

Jan 30, 2024

Explaining LayerZero

Depending on who you are — your job, your portfolio, your education, your predilection for memes — how you understand LayerZero will likely differ. It’s the same way with most crypto primitives. For instance, a financial manager, an Uber driver, and your grandmother will likely have different definitions for what Bitcoin is. In that example, Bitcoin is probably something akin to digital gold, an investment, or darknet money that is used by criminals, respectively.

With that in mind, having a single definition for LayerZero seemingly defeats the purpose. Here are a few different ways to explain LayerZero, curated to a few of the most likely readers of this piece:

For the whitepaper enthusiasts:

Utilizing an immutable endpoint, append-only verification modules, and fully configurable verification infrastructure, LayerZero provides the security, configurability, and extensibility necessary to achieve omnichain interoperability. LayerZero enforces strict application-exclusive ownership of protocol security and costs through its novel trust-minimized modular security framework designed to support all blockchains and use cases universally. Omnichain applications (OApps) built on the LayerZero protocol achieve frictionless blockchain-agnostic interoperation through LayerZero’s universal network semantics.

For the nerds:

LayerZero is a verification agnostic transport layer that enables smart contracts on different blockchains to interoperate. It is a fully connected mesh network not bound to any infrastructure or blockchain. LayerZero is an “omnichain” protocol enabling developers to build unified applications with modular security parameters.

For the web3 developers:

LayerZero is an immutable, permissionless, and censorship-resistant protocol connecting previously siloed blockchains. Using LayerZero, developers can send arbitrary messages across chains while preserving complete control over their application’s security. LayerZero enables developers to create and configure unified applications, tokens, and data primitives, regardless of chain. This concept of unified cross-chain development is encapsulated in the word “omnichain” and is what LayerZero envisions the future of crypto moving towards.

For the technology enthusiasts:

LayerZero is to blockchains what TCP/IP is to the internet. Where TCP/IP allows different computers running different operating systems on different networks to communicate (resulting in a connected internet), LayerZero enables smart contracts coded in different languages on different blockchains to communicate. This allows developers to create applications that exist universally across blockchains.

For your TradFi friend who you thought understood but clearly didn’t:

Imagine your Windows computer couldn’t send an email to your boss’s Mac, or your Android phone couldn’t send a text message to your mother’s iPhone. We take this for granted, but it’s all powered by a communication protocol named TCP/IP that glues the Internet together. LayerZero is that communication protocol, but for blockchains. Before LayerZero, Ethereum couldn’t communicate with Bitcoin, and neither blockchain could communicate with Solana. With LayerZero, developers and users can interact with applications and tokens that exist on many blockchains through a single protocol, similar to how Mac, Linux, and Windows users can all communicate across the same Internet (early alpha: LZ + Solana, coming in 2024).

For the dinner table at Thanksgiving:

LayerZero is like the Internet, which opened up communication to the world — email, social media, zoom calls, etc. LayerZero will do that, but for crypto — meaning finance will be open, with anybody able to move value, take out loans, trade assets, etc, without going through an intermediary like a bank or a potential censor like a government.

Core Principles

It is important to remember why we are here — to build an open and just digital economy for all people, for all time. Crypto is a space that should be permissionless, allowing anyone to interact with applications. Crypto should be censorship-resistant, facilitating the movement of data packets without judgment. Crypto should exist forever, leaving behind systems that are immutable and provable, unchanging. In general, it is pertinent that the protocol to connect crypto is designed to combat corruption so that whatever we are building in this space may stay parallel to the legacy system rather than become part of it.

LayerZero’s design mirrors these core principles.

Immutable

Endpoints (the interface for interacting with LayerZero) exist as immutable smart contracts on each chain LayerZero supports. These are non-upgradeable and cannot be changed by any party, providing a safe and predictable interface to interact with. Every piece of core protocol code is non-upgradable. Neither LayerZero Labs nor anyone else besides the owner of the omnichain application has the ability to change an application’s security configuration (unless Defaults or a delegate is selected to do so).

Censorship-Resistant

Individual messages can only be executed once all previous messages have been verified, meaning no individual message can ever be censored on any pathway. There is no ability for the LayerZero protocol to selectively deliver messages once they’re successfully submitted on the source chain. If a transaction is successfully submitted on the source chain, it is guaranteed to be delivered to the destination chain.

Permissionless

LayerZero is a pure protocol. Anyone can run the infrastructure that verifies and executes messages sent via LayerZero. If every developer and infrastructure provider stopped performing services, anybody could come in to join the protocol and pick up right where they left off. Furthermore, anyone may build on top of LayerZero and interact with those applications.

V2 Architecture

The core design of LayerZero V2 can be bucketed into three categories: protocol, standards, and infrastructure.

Protocol → These aspects of LayerZero protocol remain the same across every supported blockchain. In the V2 whitepaper, the protocol of LayerZero is what is deemed “intrinsic” — these are the contracts that will last forever (immutable), that anybody may build on top of (permissionless) and that enforces how transactions are ordered (censorship-resistant). The protocol comprises two entities, Endpoints and MessageLibs.

Endpoints: These are immutable smart contracts on each chain LayerZero supports. The Endpoint is the core of the LayerZero protocol. Once implemented, no entity cannot change endpoints, as they are immutable and non-upgradable. Endpoints offer a standardized interface for applications to manage security configurations and send/receive messages — the two most important things an application will want to control when building on top of LayerZero.
Message Libraries: Each MessageLib is registered to an Endpoint and is how an application’s security configuration and data packet sending/receiving process is enforced. In other words, the MessageLib is how an Endpoint is fed information about the message being sent between blockchains — it is where the verification and communication of messages occurs. Notably, MessageLibs are append-only additions to Endpoints. This means they cannot be removed (still immutable) while allowing the protocol to upgrade verification methods when necessary. Developers building on LayerZero will never be forced to accept or update to a new MessageLib. To analogize here, consider LayerZero Endpoints as a blockchain and new MessageLibs as smart contracts. Just like how Uniswap updates its contracts through new product releases (UniswapV1, UniswapV2 and UniswapV3) and people can still use the old contracts, LayerZero may publish new MessageLibs, and people may still choose to use the older libraries.

Standards → These enable the concept of “unified semantics” — where an application/token works the same across every LayerZero-supported blockchain. Unified semantics enable developers to easily build interfaces that interact with applications across tens of blockchains without having to rewrite code for new environments. LayerZero standards include how omnichain smart contracts are written, how data packets are structured, and how logic is composed. Anything a developer might need to launch an omnichain product from scratch can be found as audited, reusable, and battle-tested standards.

Contract Standards: LayerZero offers developers out-of-the-box message handling and configuration for applications (OApp) and tokens (OFT). OApp and OFT are extensions of existing contract standards — for example, OFT extends ERC-20s — and maximally cut down development time for building cool things. In the case of OApp and OFT, both contract standards allow developers to create universal applications and tokens that work the same across all LayerZero-supported chains. ONFT contract standards are already available in V1 and will be available in V2 later this year.
Message Packets: This is how information is passed between chains. Each cross-chain message requires information to be formatted in a specific manner so that destination-chain activities may occur without issue. The Message Packet for LayerZero requires a nonce, source ID, sender address, destination ID, receiving address, a unique identifier, and the message payload. The nonce, source/destination IDs and unique identifier prevent replay attacks and misrouting, while also helping track the message across chains. The payload field carries the actual information or command that needs to be carried out on the destination chain. With this information correctly formatted, any generic message can be passed between chains, allowing for the transfer of data, assets, and/or external contract calls. This Message Packet format extends across any blockchain environment (EVM and non-EVM, public chains and private chains). Most of this formatting relating to packet data, such as nonce management, is handled directly by Endpoints.

Design Patterns: LayerZero comes with a built-in set of design patterns, which can be thought of as omnichain building blocks. Developers building on LayerZero can use these design patterns to create almost anything they want. At the moment, there are four basic design patterns:

AB: a one-way data transfer from source to destination.
ABA: a nested send call from Chain A to Chain B back to Chain A.
Composed AB: a message is transferred from Chain A to Chain B and calls an external contract on Chain B.
Composed ABA: moves data from source to destination, executes a contract call, and then sends it back to the source chain. (shown below.)
Composed ABC: moves data from source to destination, executes a contract call, and sends information to a third chain.
See Also
Discover thousands of collaborative articles on 2500+ skills
Batch Send: a single call that goes out to multiple destination chains.

While these design patterns may not seem like a big deal, design patterns are the legos for building omnichain applications and help developers create slick user experiences. For example, tokens can be bridged and swapped through a composed AB in a single transaction that only requires gas on the source chain.

Infrastructure → The infrastructure layer of LayerZero is built to be permissionless: anybody can run the entities necessary to both verify and execute transactions. The infrastructure stack is also built to be completely modular — applications can choose what type of verification method it wants to use, along with what entities they want to pay for execution.

Decentralized Verifier Networks (DVNs): DVNs verify cross-chain messages. This permissionless role empowers any entity capable of verifying cross-chain data packets to join LayerZero as a DVN. Any native bridge, third-party bridge, middle chain, oracle, or other verification method may be used as a DVN inside V2, thereby avoiding vendor lock-in at the security level. As V2 has a modular design, application owners can combine DVNs to maximize verification for characteristics like security, cost, speed, or any parameter an application might want. Currently, 15+ DVNs are available, including DVNs run by Google Cloud and Polyhedra’s zklight client running DVNs and adapter DVNs for Axelar and CCIP. Again, as this is a permissionless role, any entity may set up a DVN and/or create an Adapter for a third-party bridge.

Executors: Any entity can run an Executor, as it is an entirely permissionless role. The Executor ensures the smooth execution of a message on the destination chain by offering gas abstraction to the end-user. Executors do this by quoting end-users on the source chain in the source chain gas token while executing the transaction automatically on the destination chain. Much like applications can select a DVN set, they can also configure their application to choose a certain Executor or group of Executors. Applications also have the ability to build and run their own executor (as they can for DVNs) or operate without an Executor and have end-users manually invoke lzReceive via LayerZero Scan.
Security Stack: An application’s “Security Stack” references its unique configuration of DVNs, Executors, and other security preferences (like what chains are enabled and how many block confirmations DVNs must wait to verify a message). The Security Stack enables “application-owned security” and differentiates LayerZero from many other interop solutions. Instead of locking developers into a single shared security model or a single set of validators, Security Stacks allow developers to select how their cross-chain messages are verified and change that configuration if a new DVN comes to market or a certain DVN hits liveness obstacles.

V2 vs V1

The goal of V2 is not to completely overhaul a system. Instead, it is to take the V1 design and emphasize focus on the core principles of LayerZero: permissionless, censorship-resistant, and immutable.

The following five changes from V1 to V2 improve the developer experience and harden LayerZero’s core principles.

V2 vs V1 highlights:

Decoupling Execution from Verification: Previously, the Relayer was accountable for verification and execution. In V2, the Executor is separated from the verification process. Where the Relayer entity was a hypothetical bottleneck in V1 if it were to experience downtime (as of now, this has not been an issue), in V2, there will be no liveness issues. In V2, execution is a permissionless role outside the protocol and verification process.
X of Y of N: This modular approach to verification empowers applications to neither overpay nor underpay for security, depending on their use case. X of Y of N allows applications to combine DVNs however they like. For instance, a “1 of 3 of 5” combination of DVNs would include one required DVN and two arbitrary DVNs out of a total of five to verify a message before moving on to execution. This means that if two DVNs outside the required DVN were unresponsive out of five, message flow could continue, greatly aiding liveness. (Editor’s note: The 2/2 multisig meme put forward around V1 by critics is wrong, as the Oracle is modular. However, with X of Y of N, that meme can be declared officially dead.)
Horizontal Composability: Previously, applications were forced to compose omnichain transactions vertically, leading to transactions failing in their entirety if the final leg of a transaction failed. With horizontal composability, each leg of a transaction is saved locally on the destination chain. For example, only once the swap from source to destination is successful is the composed logic on the destination side executed (for example, logging the swap details on a separate contract). If that logging failed, it wouldn’t break the transaction, and the swap would still be successful, whereas the entire swap would have reverted with vertical composability.
Unordered Delivery: Previously, all messages were verified and executed in order. V2 allows developers to choose whether to execute transactions in or out of order. With out-of-order transaction execution, LayerZero’s throughput matches the destination chain while maintaining censorship resistance.
Enhanced Programmability: V2’s improved protocol contract interfaces, path-specific libraries, new design patterns, and horizontal composability redefine application interaction, fostering flexibility and uninterrupted cross-chain transactions.

Let’s expand on X/Y/N and Security Stacks, as these are probably the most important concepts to understand when building on V2.

X of Y of N allows an application developer to designate a quorum of DVNs to check the integrity of a cross-chain message before signing off on a message’s validity. For example, “1 of 9 of 15” requires consensus from the following DVNs for a message to be verified:

9 from a selected pool of 15 DVNs, and
1 required DVN

Regarding the required signer aspect of X of Y of N — this allows applications to harden their verification significantly by running their own DVN and requiring themselves to sign off on each transaction. That way, even if other DVNs collude to sign a malicious transaction, their application would be safe.

X of Y of N is the core of the Security Stack, allowing applications to select, combine, and/or remove DVNs to verify messages however they deem fit. This lets applications improve security as new verification methods enter the market or reconfigure DVNs if risks arise.

Security Stacks should generally be configured based on a project’s use case. For example, a cross-chain lending dApp may configure its Security Stack to the most decentralized set of DVNs possible and set a high number of blocks for confirmation, while a financial institution building an ecosystem of subnets may choose to run its own DVNs in its Security Stack with very minimal confirmation time. For inexpensive use cases or testing, developers can set a 1/1/1 quorum. However, if someone were to build an application that moved millions in value across chains sporadically, a quorum of 5/20/25 DVNs might be used.

Security Stack flexibility benefits the developer because it future-proofs an OApp by not locking it into a single verification method. If, for example, a DVN were to go down due to a hack or government subpoena, an OApp could change its Security Stack to require a signature from a different DVN.

This unbiased stance on verification is a design choice that differs from most other messaging protocols, which often offer only a single security configuration. Outside of IBC, Hyperlane, and a few others… most cross-chain protocols adopt a shared approach to security, continually updating a single, monolithic end-to-end security model (like a validator set, oracle, middlechain, etc) to include new chains.

A one-size-fits-all approach to security will often lead to applications under or overpaying for security. For example, an omnichain NFT project has much lower security needs than an omnichain money market. However, if both are built on a middle-chain-enabled cross-chain protocol, they pay the same amount for security. In addition, using a single monolithic protocol leads to a one-size-fits-all approach to extensibility, as each verification method may only support a limited number of chains. With a modular set of DVNs, LayerZero allows developers to configure security parameters that best suit their application rather than forcing them to fit an application into a rigid, monolithic architecture.

In building out Security Stacks, a diverse range of opinions is expected regarding the security of an application. There will be some proponents that say a Security Stack with just one DVN is enough (those would be developers currently building on single middle-chains), while others might say that anything less than a 1 required, 4/5 Security Stack is insecure. Whatever might be said, LayerZero protocol is unopinionated — it is only the transport layer and will stay verification agnostic.

With Security Stacks, LayerZero is the antithesis of vendor lock-in, as it allows developers to choose, modify, and combine different types of verification methods based on their specific use case.

V2 Transaction Lifecycle

For this example, let us assume that an application (OApp) has configured its Security Stack on the LayerZero Endpoint for both the source and destination blockchains. It has also selected its preferred version of MessageLib.

Step 1a: Sending the Message

The source chain OApp calls `lzSend` on the source LayerZero Endpoint, providing the message payload and its unique path.
The path is designed to be secure and resistant to censorship, constructed from the sender and recipient application addresses and their respective Endpoint IDs.

Step 1b: Encoding and Emitting the Packet:

The source Endpoint assigns a unique, sequentially increasing nonce to the packet.
It combines the nonce with the path to create a Global Unique Identifier (GUID) for tracking the packet.
The Endpoint selects the correct source MessageLib (like ULN) based on the Security Stack to encode the packet.
The packet is encoded with necessary information, including payment for DVNs to verify the message and Executors for triggering offchain actions.

Step 2: Verification by DVNs:

Configured DVNs independently verify the packet on the destination side using the destination MessageLib.
After the packet is verified by the sufficient number of DVNs required by the Security Stack, it is committed to the destination Endpoint by an appropriate worker (a DVN, executor, or user).

Step 3: Receipt and Execution:

Endpoint ensures payload verification aligns with the OApp-configured Security Stack before committing to the channel.
An executor invokes the `lzReceive` function to process the received packet with the Receiver OApp’s logic.
This step ensures the message is delivered exactly once and without loss. If the system cannot guarantee this, the process is reverted to prevent any possibility of censorship.

V2 Use Cases

LayerZero is a big idea — anything that can be programmed as a smart contract on a single chain can now be natively programmed across multiple chains (which leads to far more expressive applications being built than what currently exists on the single-chain market).

Since inception, many products have been built on LayerZero, including borrow/lend dApps, cross-chain identity dApps, bridges, NFT marketplaces, enterprise projects, NFT projects, meme tokens, and data products. Over 40,000 OApp contracts are deployed on LayerZero V1, 100s of teams are using LayerZero to power OFTs, and dozens of teams have built full-scale applications as groupings of OApps.

For developers, LayerZero composability extends DeFi beyond single-chain limitations, paving the way for a more interconnected and versatile financial ecosystem. With LayerZero, the scope of applications built in DeFi expands as developers leverage more assets and blockchains. Furthermore, with the ability to run a DVN, application developers can harden security by decreasing reliance on other parties.

For users, V2 simplifies cross-chain transactions, allowing them to interact with multiple blockchains without even knowing — as they only have to pay for gas on the source chain. This streamlined experience can be adopted across every DeFi vertical — from DEXs to yield farms to NFT marketplaces — reducing the complexity for end-users. The endgame for retail DeFi is to completely abstract the chain away from users, and LayerZero OApp and OFT contracts are tools to facilitate this.

To give a concrete idea of what can be built with V2, here are a few examples of applications leveraging LayerZero V2…

Clusters (Identity): Clusters is a cross-chain, multi-wallet name service protocol addressing issues like address fragmentation, wallet management complexity, and domain squatting. It serves as a unified identity layer, enabling users to maintain a consistent identity across multiple chains — very similar to what ENS does, but for many chains, natively. Clusters ensures that actions and configurations associated with a user’s identity are consistently reflected across all integrated blockchains, thereby streamlining user interaction with various decentralized applications (dApps) and services. On the backend, LayerZero is used as the messaging layer to move actions and state changes across chains to help Clusters maintain accuracy across millions of names and billions of wallet addresses. (alpha 2.0.)
Abracadabra (Stablecoin): Magic Internet Money (MIM) introduces an omnichain “beaming” service for transferring MIM tokens across 11 blockchains. Utilizing LayerZero’s Omnichain Fungible Token (OFT) standard, MIM beaming offers fast, secure, and efficient token transfers. This service extends MIM’s functionality, enabling cross-chain interactions like borrowing from different chains, executing cross-chain liquidations, and more. A nominal beaming fee of 1 USD, charged in the native gas token of the origin chain, contributes to DAO profitability. Abracadabra also runs its own DVN (MIMnet), which will be a required signer for MIM transfers once it transitions to V2. Since launching on V1, Abracadabra has facilitated two million transfers on LayerZero.
Tapioca (Lending Market): Tapioca DAO is an omnichain lending & borrowing platform offering a native omnichain CDP stablecoin, USDO. The primary vision behind Tapioca is to reunify currently fragmented liquidity in DeFi by creating a natively omnichain borrowing, lending, and stablecoin protocol, where the user experience is identical to a user borrowing and lending on the same chain. Additionally, to complete the full finance stack, Tapioca users can employ cross-chain leverage with Tapioca through recursive messages. From a verification perspective, Tapioca operates a DVN that is a required signer in its own Security Stack. An example of this setup is shown below:

V2 Trust Assumptions

There is no such thing as a perfect system. Anybody claiming to have created something perfect in crypto should be met with scrutiny, as blockchains themselves are inherently limited to a core trade-off between speed, scale, and security.

This section discusses the trust assumptions, or security considerations, that a developer may encounter when building on top of LayerZero. Not all of these are protocol risks — many are practical risks that address social or application-level security. That being said, in good faith, we will address all types of trust assumptions here.

(Editor’s note: No pictures from here on out. Only niche interop analysis.)

Smart Contract Risk: Endpoints and MessageLibs are the basis for cross-chain communication for LayerZero. If these contracts contain a bug, then the core protocol is at risk.

This is the case with any protocol that utilizes smart contracts. While not a perfect measurement, looking at time-in-market for source code is usually a good indicator that a contract can be trusted. With that in mind, V1 Endpoints have been live for 1.5 years without error, facilitating over $40 billion in value transfer and over 100 million messages. With the launch of V2, these numbers are reset to existing V2 testnet volume and transactions, so it will take time to build the time-in-market trust back up, much like Uniswap upgrades take time to surpass their priors (Uniswap V2 trading quantity was higher than V3 for roughly six months). Of course, time-in-market is not the only metric for smart contract risk. Audits are also a good indicator. With V2, all contracts have been audited, and there is a $2.5 million bug bounty for whitehats. The V1 bug bounty of $15 million is currently the largest in the world.

Malicious Developers: Developers are responsible for setting their own Security Stacks. This allows them to point to malicious DVNs and/or change a configuration at a whim if a governance or internal security process is not set up to prevent them from doing so.

Yes, developers can deploy or do malicious things on LayerZero. This is a byproduct of permissionless building and a tradeoff that’s well worth it. Ethereum, the internet, cash, etc., are all permissionless systems that allow people to do any number of things (both good and bad). To argue against this is to insult any developer’s intellect or free will. The argument that “devs can rug” is true for all applications built on permissionless blockchains. That being said, it is noted that best practice for developers is to be clear about their Security Stack and how it can be changed. For DAOs, a Security Stack could be selected and hardcoded via DAO vote, it could be time-locked and changed monthly, or a delegate could be charged with setting the Security Stack best suited to the DAO (with a time delay and with veto power from a security council). Similar setups can be used for businesses building on LayerZero. However, enterprise clients will likely want to run their own DVNs, so it should not be as big of an issue in that vertical.

Diversity of DVNs: While the protocol is unopinionated, the DVNs verifying messages are not. Therefore, if there is a limited set of DVNs and applications choose to not run their own DVNs, then messages sent across the network might be censored in some way, similar to how some Ethereum validators do not include OFAC-sanctioned transactions.

A wide, varied group of DVNs is the goal for LayerZero. This diversity has multiple layers. DVNs should give developers a range of verification methods when building omnichain applications: bridges, oracles, chains, attestation services, restaking mechanisms, etc. For LayerZero to be a healthy protocol, a diverse group of entities needs to run DVNs: from enterprise solutions that connect to private chains to degenerate solutions that pick up any transaction in DeFi. On top of verification and entity diversification, it would also be nice to have a distributed set of DVNs running out of different jurisdictions to further harden the verification layer of LayerZero in the case of state-level attacks. At V2 launch, 15+ DVNs are live, from enterprises like Google Cloud to crypto-native solutions like Polyhedra zklightclient. This number should scale as V2 gains traction. With 60 chains and millions of messages to verify, more groups should be incentivized to run a DVN.

DVNs and Good Faith Attestation: Similar to the above bullet, it must be noted that there is a trust assumption that DVNs will not collude.

LayerZero assumes developers will choose a Security Stack that minimizes collusion risk. LayerZero simply creates a marketplace for these ideas to be pitted against each other in terms of cost and security tradeoff (and application demand) — with the ultimate security of being able to run your own. For example, DVNs can have slashing mechanics and/or staking if it wants to, but LayerZero will not enforce this.
Understanding why DVNs act in good faith can be broken into three arguments: 1) A good reputation is worth more than colluding to confirm a malicious transaction for enterprise DVNs. 2) Some DVNs already implement a transparent mechanism for incentivizing good behaviour (slashing, etc). 3) Fees make it worth running a DVN. On the reputation side, DVNs like Google Cloud, Animoca, Blockdaemon, and Gitcoin are likely too big, too ingrained in the broader crypto ecosystem and likely carry too much reputational risk to collude. On the transparency side, decentralized DVNs, like Axelar and CCIP, have their own validator sets that can be openly audited and checked — and also natively implement slashing to punish bad actors. On the fees side, with 50+ chains to service and historical message volume recently crossing 100,000,000, DVNs should be sufficiently incentivized to run just in terms of fees.
Overall, protocols should look to use DVNs that will not collude. For example, a DVN setup of Google Cloud and Axelar is a very hard Security Stack, as it includes verification from a centralized and a decentralized entity, minimizing collision risk (and more DVNs can be added to this setup later on). Developers need to be careful in selecting their Security Stack, as it is possible that DVNs will attempt to collude at some point in the protocol’s future. Any application should consider collusion risk and plan accordingly by running their own DVN, reaching out to DVN teams to perform due diligence, and/or choosing a DVN combination where it is impossible to collude.

Executor x Liveness: In theory, anybody may execute transactions in V2. Liveness should never be an issue, as an end-user or application can manually execute transactions on LayerZero Scan if the configured Executor goes offline. However, if, in practice, configured Executors go down frequently, there are short-term liveness concerns for applications building on LayerZero.

As already mentioned, permissionless execution should alleviate liveness concerns in theory. However, in practice, running an Executor is challenging work. As stated in the V2 launch video, running an automated executor requires billions of RPC calls per month and providing gas abstraction across 50+ chains, which in and of itself requires holding 50+ gas tokens and rebalancing those gas assets as needed. That said, an app can build and configure a smaller version of an Executor that runs across a limited chain pairing (e.g. Fantom <> Ethereum) — though even then, it is still complex to write due to re-orders, liveness, availability, resiliency against failures, race conditions, properly pricing gas cost, among other things. Overall, ensuring that multiple Executors are available is helpful for the protocol’s long-term liveness if an OApp’s selected Executor goes down. To that end, there are now open-source implementations of Executors available in our documentation.

Defaults: When developers begin experimenting with LayerZero, they can opt into LayerZero Labs’ default Security Stack or set their own Security Stack. The default Security Stack is set by and can be changed by LayerZero Labs at any time. Any application that abdicates its security choice to LayerZero Labs’ defaults, therefore, abdicates its security to a centralized third party. The current default setting is Google Cloud and LayerZero Labs.

Defaults in and of themselves are not bad — it is very much like holding crypto on an exchange or custodian. This may be ideal for small applications or large enterprise solutions (as something like Coinbase is for new entrants and institutional holders of BTC). However, for crypto-native applications, opting into defaults is likely not ideal because if LayerZero Labs is hacked or turns malicious, then the default Security Stack could also be changed to be malicious. Defaults are intended for developers to test LayerZero. The end-game for most applications should be to configure their own Security Stack and not to use defaults in the first place — and/or for reputable orgs (like foundations or large applications) to publish their own ‘default’ settings for applications to use.

Endpoint Deployments: LayerZero Labs is the only entity that can deploy canonical, socially accepted endpoints. If LayerZero Labs were to shut down, that would stop the current iteration of LayerZero from extending to new chains.

Since Endpoints are immutable, any Endpoint or MessageLib deployed will stay deployed and be active in perpetuity. Applications can build on this infrastructure forever, even if no new Endpoints are created. However, to expand to new networks in lieu of LayerZero Labs shutting down, some sort of workaround would need to be put into place. To clarify, other teams can deploy Endpoints — but they are not considered socially canonical, as they do not connect to other LayerZero Endpoints (breaking the whole interoperability thesis). However, if LayerZero Labs were to go down, another team could deploy Endpoints and attempt to garner social consensus for their own mesh. One solution often floated around would be allowing permissionless endpoint deployment. This, however, is a design decision that increases complexity, introduces spam risk, and will likely be very troublesome for DAO governance (in selecting canonical bridges for assets).

The cross-chain world is filled with bridges, liquidity networks, and token standards. Here’s a brief outline of where LayerZero fits.

Security Stacks: Bridges as DVNs

Much like Bitcoin is built on the idea of self-custody (ownership over the security of your commodity), LayerZero is built on the idea of Security Stacks (ownership over the security of your application).

In V2, any entity that can verify a message — be it a native bridge, third-party bridge, validator set, oracle, multisig, light client, zk prover, etc. — may be used as a DVN by an application building on top of LayerZero.

This section of the article will make the case that many of the most popular third-party bridges are actually just decentralized verifier networks (DVNs) that can be used as Adapter DVNs built by application owners to verify messages in V2.

In other words, many existing bridges will likely end up as DVNs competing to verify messages inside LayerZero.

For more context, third-party bridges are cross-chain protocols competing against each other to build the most robust, industry-trusted mechanism for verifying messages between certain subsets of chains. Examples of third-party bridges include CelerIM, Axelar, deBridge, CCIP, Synapse, Wormhole, Router, IBC, etc. The designs for third-party bridges often revolve around shared security and can be generally bucketed into three categories. Middlechains like Axelar and Synapse validate messages as a hub and emit messages to spokes. There are guardian third-party bridges that attest to the validity of messages through reputational multi-sigs — like Wormhole and Avalanche Bridge. You can think of them as oracles or attestation services that sign off on cross-chain messages for a fee. The last type of third-party bridge is of a somewhat more vague bucket, which we call trust-minimized systems. These involve either zk proofs, light clients, or optimistic proofs, which can be boiled down to only having to trust one thing: math, chain consensus, and a single honest watcher, respectively.

No third-party bridge has quite cracked the code on the “best” form of security. Middlechains compete to build the most unhackable hubs. Guardians compete to bring in the most reputable players in crypto to attest to cross-chain transactions. Trust-minimized systems use the finest tools that math, blockchains, and game theory have to offer.

While each of these entities can send/receive arbitrary data across chains, that is not what third-party bridges are exceptional at. These third-party bridges are actually excellent at verification — at proving that this message happened over here and can be sent over there.

With the new V2 design, these third-party bridges, as DVNs, get to focus on what they do best — signing off on valid cross-chain transactions — and applications select the third-party bridges they want based on use-case preferences. This design should be a win-win, as third-party bridge designers no longer need to worry about execution and/or transmission of cross-chain messaging, and applications are no longer locked into a single verification method when building something that exists on multiple blockchains.

By allowing third-party bridges to do what they do best (verify things), LayerZero can focus on the main idea: unified semantics — allowing developers to compose contracts in the same way, regardless of chain. Every data packet sent and every endpoint interacted with on the LayerZero protocol is identical. LayerZero is built to allow developers to pick and choose from every type of verification method available on the market. It is a permissionless, censorship-resistant, and immutable structure that can be filled with any type (or combination) of verification method. This is powerful, as it future-proofs LayerZero against advancements in verification techniques while allowing for universal blockchain composability through a standardized messaging design.

One Messaging Layer, Many Liquidity Networks

Any type of liquidity network can be recreated on LayerZero.

Another bucket of “bridges” are cross-chain protocols that allow for the transfer of tokens across chains. These are called liquidity networks. Examples include Across, Hop, Portal, Connext, Stargate, Allbridge, DLN, UniswapX, Hyphen, Catalyst, and cBridge, among others. Most liquidity networks are designed around a basic intent structure: a user has asset X on Chain A and wants asset X on Chain B. A liquidity network matches an intent with a solving mechanism that is either onchain (liquidity pools/wrapped assets), offchain (often dubbed relayers), or a mixture of both. These solving mechanisms essentially take the user’s token on Chain A and unlock/fill the same amount of tokens on Chain B. They charge a small fee for this service. The competition amongst liquidity networks can be found in bridge price execution, fees, number of tokens offered to users, and transfer time.

Something interesting about liquidity networks is that the verification method used underneath the liquidity network is somewhat arbitrary. Like how multiple AMMs can be built on top of Ethereum, many liquidity networks can technically be built on the same verification network. UniswapX emphasizes this point — it spent an entire whitepaper only talking about the liquidity aspects of the protocol (fillers, dutch-auction, optimistic execution, etc.) while not naming the underlying verification network it might use! All the whitepaper says is that a “settlement oracle” is necessary, which could be “a canonical bridge… light client bridge, or a third party bridge.” Anything passing a message between chains can be the settlement oracle here! This character trait is not unique to UniswapX. Other liquidity network designs like DLN and cBridge and Wormhole’s Portal and Catalyst could likely use other third-party bridges (aka DVNs) for settlement.

What these liquidity networks need is not necessarily a single third-party bridge — rather, they need a verification method they can trust depending on the chain pairing and use case. With V2, LayerZero could theoretically support each liquidity network for messaging (settlement) while allowing them to choose unique verification methods (Security Stacks).

LayerZero V2 offers a single messaging framework for many different types of liquidity networks to be built using different Security Stack configurations. This broadens the scope of what can be made and should result in fun experimentation. For example, a cross-chain AMM might select a Security Stack based on trade size, with the idea that different trade volumes will be settled by different Security Stacks (essentially bridge aggregation through Security Stack optionality).

Universal Contract Standards

The modular blockchain thesis, the L2 scaling thesis, the omnichain thesis — all of these ideas require universal token and contract standards so that the world of 1000s of chains can operate without fragmentation and context switching depending on each new chain/asset/VM pairing. Omnichain Fungible Tokens (OFTs) and Omnichain Applications (OApps) aim to be those standards — extending developer capability without compromising security.

OFTs extend traditional token standards like ERC-20, empowering developers to create tokens that operate seamlessly across multiple blockchains. This universality eliminates silos, enabling tokens to move between chains. The potential adoption of OFTs as a standard means that developers no longer need to deploy separate, chain-specific tokens, which can divide liquidity and community while introducing different trust assumptions. Instead, OFTs offer a unified token presence across all LayerZero-supported blockchains, ensuring that token ecosystems remain cohesive and robust, regardless of the chain. OFTs work across multiple token standards (ERC20 being the most popular), add no fees outside those tacked on by applications, and allow for a universal supply to be tracked at all times (transparency). As with applications, OFT token issuers maintain complete control over their contracts and Security Stacks. (Note: ONFTs will also be live on V2 but are now in beta due to contracts being audited. The same logic for OFTs can be easily extended to ONFTs.)

The omnichain applications (OApp) contract standard provides a universal, blockchain-agnostic developer interface. With OApps, developers can now build an application once and deploy it across any number of chains without rewriting code. This cuts development time and opens up the entire blockchain ecosystem to their application rather than a fraction of it. This also allows developers to access the combined users and liquidity of any LayerZero-supported blockchain. In addition, multiple OApps can be combined, creating genuine full-stack, cross-chain financial applications (imagine a DeFi app that allows for borrowing on any chain, swapping on any chain, etc.).

With V2, LayerZero should have a good chance of becoming the single framework for cross-chain tokens and governance, as it offers a universal messaging solution with a modular verification layer.

In other words, a token or governance setup can use ANY type of verification method — or combination of verification methods — to move data to a destination chain using V2, with the only trust assumption being the sanctity of LayerZero Endpoints (a trust assumption that cannot be escaped with any other solution, either).

Overall, the case can — and maybe should — be made that OFTs and OApps become the de facto contract standards for all tokens and contracts moving forward for teams building on LayerZero-supported chains. Here are a few reasons why:

Interoperability by Default: OFTs and OApps are built for a multi-chain world. They inherently adopt cross-chain communication, making them future-proof as crypto continues to evolve into an industry with 1000s of chains. Adopting these standards allows projects to plan for years instead of months.
Modular Security: Both OFTs and OApps benefit from LayerZero’s modular security framework, which enables application-specific customization of security parameters. This means developers are not forced into a one-size-fits-all security model but can tailor security to the unique needs of their application or token, enhancing both flexibility and resilience.
Simplicity and User Experience: For users, the complexity of blockchain interactions fades into the background with OFTs and OApps. They offer a simplified, consistent user experience that abstracts away the technicalities of chain-specific operations.
Universal Composability: There are many cross-chain contract standards on the market. Solidifying OFT and OApp as industry norms increases composability while decreasing fragmentation — without locking protocols into a single security strategy.

LayerZero’s architecture — modular at the verification level while static at the transport layer — strikes a crucial balance of current performance and future-proofed design.

The technology is here for us to build an open and just digital economy for all people, for all time. As an industry, crypto has to work together to bring that vision to fruition. By nature of that shared goal, our technologies must be permissionless.

For that vision to succeed, this philosophy must be upheld at every level of the stack. LayerZero defends these values down to the packet level.

When features are mutable, values can always be changed. Promises aren’t permanent. Decisions aren’t durable. Upgrades are risks. Eventually, systems are corrupted.

Permanence and provability must be hard coded.

That’s why LayerZero is here. That’s why LayerZero exists.

LayerZero is built so you don’t have to trust others. It’s built so you can trust yourself.

Thanks for reading. A big shout out to Tapioca Matt, Paladin Marco, LI.FI Arjun, Sandman, Catalyst Jim, and BlockWorks Ren for feedback on this piece. Handshakes all around to the LZ team as well, especially BP, MP, and RMT.

For more information on V2, check out this thread, read this article, or check out our docs.

To learn more about LayerZero in general, check out the website. For additional information, the LayerZero Labs team is available to answer general questions on Discord and Telegram. You can also follow LayerZero Labs on X to receive the most up-to-date information.

For specific inquiries:

Infrastructure providers looking to run an Executor DVN should fill out this form!
Developers looking to build an OApp or OFT should fill out this form!