We live in a multichain world with multiple L1s and L2s, each with its own series of tradeoffs and properties. However, as the number of chains continues to increase, liquidity gets spread across multiple places, forcing users to “bridge” their assets from one chain to another.
Bridges are one of the most targeted pieces of infrastructure by malicious actors. Not only do they hold large amounts of assets, but they also feature a large track record of vulnerabilities. According to the Rekt Leaderboard, six out of the top ten largest crypto hacks have involved bridge exploits, highlighting the importance of security in these systems. Data from DefiLlama reports that out of the 5.79 billion hacked in DeFi, 2.83 billion (49%) can be attributed to bridges.
Since its launch on March 17, 2022, LayerZero has successfully processed millions of messages involving billions of dollars worth of assets across over 40 blockchain networks, all without any security breaches. This is not due to the luck of the draw, but because LayerZero enables a solution that removes the need for assets to be held in bridges where they can be attacked.
Unlike traditional bridges that require locking or wrapping tokens, LayerZero functions as a messaging protocol focusing on unifying liquidity across different blockchain networks. At its core, it enables communication between different blockchains – not just asset transfers.
The way this works is by listening for events that happen on chain A, passing them onto chain B, verifying that the message is correct, and executing the instructions of that message (it can be an asset transfer, a state mutation, a function invocation…).
In the case of a simple cross-chain swap, where we want to exchange Token A on Chain X into Token B on Chain Z. It will burn Token A on Chain X and mint you Token B on Chain Z. No wrapped assets. No tokens are held on a bridge. This is facilitated with contract standards that offer out-of-the-box functionality for developers. For example, the OFT20 standard is an extension of ERC20 and helps to cut down development time.
It’s important to understand that LayerZero is not a messaging standard or an L1 blockchain. It is a protocol that prioritizes immutability, censorship resistance, and permissionlessness, embedding these values into its core architecture.
First, the core smart contracts of LayerZero cannot be modified, minimizing trust in a core team of developers. Once deployed, the rules of the game cannot be changed. Every piece of core protocol code is non-upgradable.
Second, LayerZero v2 differentiates between “verification” and “execution”, ensuring that the parties involved in each process are independent and there is no risk of collusion. This separation of functions is important in reducing the surface area for malicious actors to attack the system. Individual messages can only be executed once they have been verified.
Third, it is a permissionless protocol that anyone can access without asking for permission. By virtue of being a protocol, anyone can run the infrastructure that is required to verify and execute cross-chain messages. Imagine the hypothetical scenario where every project developer or infrastructure provider stopped running their services. In that event, anyone could step in and pick up where they left off.
Drawing a parallel with TCP/IP, the foundational protocol that enabled diverse computers to communicate over the internet, LayerZero aims to be the TCP/IP of blockchains.
Just as TCP/IP was crucial for the internet’s growth by standardizing communication between computers, LayerZero seeks to standardize cross-chain interactions, thereby addressing the challenge of liquidity fragmentation in the current multichain world.
LayerZero’s core proposition lies in its ability to function as an agnostic protocol, enabling application developers to facilitate message passing between separate chains.
This capability is pivotal for the creation of cross-chain applications, eliminating the reliance on trusted intermediaries or custodians. For example, a DeFi platform utilizing LayerZero could permit users to deposit collateral on one chain and take out a loan on another,
Adhering to the philosophy that each Layer 1 or Layer 2 blockchain should leverage its unique strengths and interoperate with others, the vision of LayerZero is to transition from a world of isolated chains to a world where chains are interconnected within a larger network – an Omnichain Network.
By unifying liquidity and facilitating seamless communication, each blockchain can complement each other, contributing to a more robust collective ecosystem.
In v1, the functionality of LayerZero was supported by two key off-chain components: oracles and relayers. These elements worked together to facilitate communication between blockchains. Oracles monitored activities on one chain and passed this information to another, while relayers were responsible for the actual data transfer and execution.
Since its inception, LayerZero v1 was designed with the expectation that teams would manage their own relay infrastructure and choose their custom oracle configuration. However, the reality proved more complex, with multiple teams choosing to trust the “default configuration”.
In fact, there is a lot of complexity involved with operating a relayer. For context, the role of the relayer involves dealing with over 50 chains, numerous pathways for gas abstractions, handling billions of RPC calls and millions of messages. It is already difficult enough to build a DeFi protocol, and managing the extra overhead of operating a relayer was too much work for DeFi projects. Often, teams defaulted to relying on trusted entities like Chainlink, Polyhedra, Google Cloud, and LayerZero Labs, despite LayerZero’s trustless design.
To understand the importance and reasons why LayerZero v2 has been developed, it is key to note the following: the original version (V1) of LayerZero saw relayers handling both security—validating messages on the destination chain—and executing transactions.
Even though this dual responsibility of relayers did not lead to any issues in a production setting, there was the hypothetical risk that the relayer might experience downtime. If that happened, then messages could not be executed.
LayerZero V2 marks a significant evolution, differentiating between verification and execution – each being managed by its own independent party. This concept is known as “the separation of liveness and execution from security”.
In v2, since message verification and execution are decoupled, there will be no liveness issues at the core protocol level, since execution is a permissionless role outside the protocol and verification process.
Decoupling liveness from security allows for a more robust security framework, utilizing a “multisig-like” approach with veto rights for added safety. This change gives developers and protocol teams more effective control over security configurations, aligning with their specific needs.
For context, critics in the past compared the oracle/relayer setup to a 2/2 multisig. Even though such a comparison is not accurate either, v2 introduces what’s called the “X of Y of N” approach.
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, the message flow could continue. This solves the hypothetical risk in v1 where the relayer could experience downtime.
In V2, the execution of transactions shifts to end-users, reinforcing the permissionless nature of transactions. The idea behind this self-execution model is to ensure that actions are registered without intermediaries while offering gas abstraction to the end user.
LayerZero serves as a universal language for blockchains, bridging liquidity across a wide array of diverse chains, including EVMs, Solana, and Move-based chains. This model is particularly user-friendly, as it can simplify complex processes like bridging assets between chains with different gas requirements and execution environments.
To understand the significance of this, think of use cases such as depositing collateral in one chain to mint a stablecoin or borrow on another (like Abracadabra and Tapioca), or accessing a name-service like ENS but that is accessible on multiple chains (like Clusters).
The protocol design has not fundamentally changed and continues to operate by listening for events and transferring state or funds across chains.
That being said, you should note for this to be functional, there are two components involved: the LayerZero protocol, and the associated infrastructure.
On the one hand, the LayerZero protocol remains the same across every supported chain and is deemed to be “intrinsic” — these are the contracts that will last forever (immutable), where anybody may build on top of (permissionless) and that enforce transactions to be verified and executed in a censorship-resistant manner.
On the other hand, there is a requirement for infrastructure to be used for both message verification and execution. This is the extrinsic component. This stack is permissionless and anyone can be an infrastructure provider. Therefore, it is up to individual applications to choose what type of verification method they feel comfortable with, and what type of entities they trust and want to pay for execution.
More importantly, by remaining an agnostic protocol, LayerZero can seamlessly integrate any chain, regardless of its specific requirements. This still remains a challenge for many interoperability protocols, which are often constrained by the execution environment, i.e., only support interoperability across EVM-compatible chains, only across L2s built on a specific stack, only L3s built on top of an L2, etc.
By design, LayerZero acknowledges that verification algorithms and blockchain designs will continue to evolve. Therefore, as an agnostic protocol, it must be flexible enough to be able to adapt to these changing conditions. This is achieved with append-only additions to Endpoints. Once added they cannot be removed. Hence, they remain immutable while still allowing the protocol to upgrade the verification methods when necessary.
Developers will never be forced to accept or update to a new MessageLib, just like you are never forced to use Uniswap v3 instead of the initial Uniswap v1 version.
At the heart of LayerZero V2 is a modular security model, that divides security into intrinsic and extrinsic components.
This ensures reliable intrinsic security over time while allowing applications to customize their level of extrinsic security based on their needs and budget.
Altogether, LayerZero V2’s protocol integrity is categorized into four areas: channel validity, channel liveness, data validity, and data liveness. The Omnichain Messaging Protocol (OMP) handles the first two, while the integrity of the underlying chain secures the latter two.
The protocol operates through immutable smart contracts called “Endpoints”. They are the primary interface between blockchains in the Omnichain network, acting as gateways for information and transaction flow. Endpoints are deployed on each chain, handling core protocol functions such as packet transmission and censorship resistance.
Once deployed on-chain, their code cannot be altered. They act as universal interfaces that enable cross-chain communication. While immutable, the functionality of Endpoints can be extended via append-only libraries, allowing developers to follow state-of-the-art standards at any point in time.
Remember that the original vision is to redefine blockchain communication, transitioning from isolated systems to an interconnected network. Because of that, the protocol must guarantee that endpoints can handle packets arriving out of sequence without data loss. This is crucial in a setting involving multiple heterogeneous chains with varying transmission times (note that each chain has its own specific block time and time to finality).
All of these properties are guaranteed by the protocol’s intrinsic security, represented by Endpoints and MessageLibs. However, to fully build a scalable, secure, and fast cross-chain application, there is a need for external infrastructure that can interact with the underlying protocol. This is where the concept of extrinsic security comes in.
On the extrinsic security side of things, we find different infrastructure components: a Decentralized Verification Network (DVN), an Executor, and a Security Stack.
DVNs are responsible for verifying cross-chain messages. This is a permissionless role, and any entity capable of verifying cross-chain data can join LayerZero and start participating as a DVN. These can be Layer 2 native bridges, oracles, third-party bridges, or any other verification system. Some names you may recognize that perform this function are Axelar, Chainlink, Gitcoin, Google Cloud, and Tapioca.
Once verified, the next step is execution. On that note, LayerZero V2 allows applications to select their own Executor, responsible for quoting prices and managing transaction complexities. The simplicity of running Executors compared to Relayers encourages competitive pricing and service quality.
Similar to DVNs, any entity can run an Executor, as it is also a permissionless role. They not only ensure that the execution of messages is smooth, but they also abstract away all the complexities associated with handling gas payments on different chains. 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.
From the above, you can observe how a strategic separation of execution and security bolsters the protocol’s resilience and reliability.
Once a message is verified, any party can execute the transaction.
Applications can choose execution order based on their priorities, like throughput optimization for gaming apps or sequential order for DeFi apps.
These principles address the fundamental deficiencies observed in existing cross-chain messaging services, such as monolithic security models and overspecialization, and provide a robust framework for secure and efficient interoperability.
It is worth noting that LayerZero assumes that developers will choose a Security Stack that suits their specific use case. As a protocol, it simply enables a competitive marketplace where the end goal is for an application to be able to run its entire infrastructure. However, until there is enough demand, they will manage their costs accordingly. Hence, there is a tradeoff between security and demand for an application – each application is responsible for what costs it wants to bear.
This flexibility ensures that feature additions or modifications do not compromise message transmission security.
Together, these components form a two-layered architecture, where we differentiate between an execution and a verification layer.
At a more granular level, LayerZero messages consist of two main parts: a payload and a path. Before these messages are sent across the network, they are converted into packets. This process is essential for ensuring that the information can be transmitted efficiently through the mesh network.
Once these packets reach their destination blockchain, they undergo a verification process. This is done by the verification layer specific to that blockchain.
After successful verification, the packets are committed to be lossless, ensuring that no data is lost during transmission.
The next step involves the delivery of these verified packets. This function is responsible for processing the incoming packets on the destination chain.
Note how this design ensures that even in scenarios where Decentralized Verified Networks (DVNs) encounter issues or executors cease to deliver messages, an Omnichain Application (OApp) can still regain its functionality. It can do this either by adjusting its Security Stack or by having another entity step in to deliver the packets.
LayerZero’s design includes a feature called PreCrime, which is an off-chain application-level security mechanism that adds an extra layer of packet filtering to the existing protocol.
OApps can use PreCrime to detect and filter out verified yet potentially harmful messages, such as those that could trigger faults at the OApp level.
PreCrime works by allowing subsets of peers within an OApp (which could include some or all of the OApp’s contracts) to enforce security invariants.
This is done by simulating the result of packet delivery and conducting checks based on criteria relevant to the OApp’s functionality and security needs. If any peer reports a violation of these invariants, an off-chain worker halts the delivery of the corresponding packet.
For example, in a token bridge scenario spanning three chains (Chain A, Chain B, Chain C), suppose Chain A is compromised and tries to mint additional tokens on Chain B without locking corresponding assets. PreCrime would detect this discrepancy by comparing the total minted tokens (∑mint) against the total locked liquidity (∑lock) across all chains. If it finds that ∑mint exceeds ∑lock due to unauthorized minting on Chain B, PreCrime intervenes to prevent this malicious action.
It’s important to note that PreCrime is not designed to enhance the core protocol security of LayerZero. It does not address data integrity issues that could arise from malicious DVNs or blockchain-level faults. Instead, its primary role is to provide an additional layer of safeguard at the application level, complementing the existing security measures within the LayerZero protocol.
This flexibility in the security stack is highly beneficial for developers. If, for example, a DVN experiences downtime or is hacked, 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.
LayerZero stands out in the interoperability space due to its agnostic design, which allows it to grow in two primary ways:
This creates a positive feedback loop: as LayerZero supports more chains, it becomes increasingly attractive for apps to integrate with it.
This appeal is further enhanced by LayerZero’s ability to connect chains across different compatibility groups, such as EVM chains, MoveVM chains, Solana, and others.
With V2, LayerZero becomes distinct from other interoperability protocols, which typically focus on either verification or execution. As a result of this upgrade, LayerZero has decoupled liveness from execution, embracing a broader range of functionalities. This decoupling is a deliberate design choice, not just a simple combination of existing cross-chain messaging systems.
A significant advantage of LayerZero is the developer experience it offers. LayerZero Labs provides tools and libraries that allow development teams to select their desired level of security based on their preferences and cost considerations. This flexibility and extensibility make LayerZero particularly attractive to developers, as they are not confined to a one-size-fits-all solution.
Additionally, while LayerZero Labs provides default configurations to simplify the development process, these are merely default options. Unlike other cross-chain protocols that offer only default settings, LayerZero empowers developers with the ability to customize their configurations and parameters.
For instance, outside of IBC, Hyperlane, and a few others… most cross-chain protocols rely on a shared security model that is inflexible, requiring updates to a single monolithic end-to-end security model (like a validator set, oracle, middle chain, etc) to include new chains.
This means that even in the worst-case scenario (a protocol using the default configuration), LayerZero offers what would be considered the best-case scenario in any other messaging protocol.
It’s important to note that these defaults do not impact the fundamental workings of the protocol. They serve as standard implementations for developers to get started, offering a baseline from which customization and extension are possible.
You can already appreciate that LayerZero’s design aims for antifragility and decentralization, avoiding control by a centralized entity like LayerZero Labs. This is reinforced by the immutability of its Endpoints.
In fact, the protocol currently operates similarly to standard web protocols like SMTP, FTP, and HTTP, which are free to use and build upon. LayerZero, in its current state, does not involve a token, allowing dApps to build on it freely, aligning with LayerZero Labs’ stance of not discussing token-related matters.
However, it has been confirmed by LayerZero Labs that a token will be introduced.
The developer documentation includes a section for estimating message fees, highlighting three types of fees: oracle fee, relayer fee, and LayerZero fee.
With the introduction of v2, these may evolve into Verifier fees, Executor fees, and LayerZero fees.
It’s reasonable to speculate that Verifier fees would be captured by the Decentralized Verified Network (DVN), Executor fees by the Executors, and the LayerZero fee potentially going to the protocol treasury, with token holders possibly claiming a share.
This fee structure fosters a competitive environment, driving down margins as more Verifiers and Executors join the network. As messages are relayed across chains, the protocol accumulates fees from all interactions, remaining agnostic to the content of the messages while Verifiers and Executors perform their roles.
While LayerZero’s potential monetization through $ZRO tokens deviates from traditional web protocols, there are compelling reasons for this approach.
Tokens can help secure public infrastructure and protect against malicious actors, with revenue flowing to token holders or the protocol treasury.
Unlike traditional web protocols governed by standards bodies, Web3 protocols can adopt community-based or decentralized governance, with token holders influencing upgrades and core protocol changes.
Monetizing the protocol through transaction fees also gives the protocol token intrinsic value, creating a cost barrier for acquiring significant governance stakes and preventing centralization. For instance, gaining control over Ethereum’s governance through token purchase is prohibitively expensive due to its high valuation and widespread token distribution.
Therefore, while Web3 protocols are open and permissionless, monetizing them can help govern fee distribution. Sharing fees with compliant applications can promote positive-sum behavior, incentivize rule compliance, and deter spam and bad actors, indirectly safeguarding the protocol.
With V2, LayerZero is poised to become a cornerstone in the blockchain interoperability landscape, akin to what TCP/IP is to the Internet.
This upgrade marks a significant leap towards creating a foundational infrastructure that standardizes and secures communication across diverse blockchain networks.
By decoupling liveness from execution, the protocol significantly bolsters its resistance to censorship. This development could set a new standard for immutable and permissionless protocols, suggesting that such systems should not only be decentralized but also potentially governed by a token.
Revelo Intel has never had a commercial relationship with LayerZero and this report was not paid for or commissioned in any way.
Members of the Revelo Intel team, including those directly involved in the analysis above, may have positions in the tokens discussed.
This content is provided for educational purposes only and does not constitute financial or investment advice. You should do your own research and only invest what you can afford to lose. Revelo Intel is a research platform and not an investment or financial advisor.
