Overview

LayerZero is a trustless omnichain interoperability protocol designed to address the issues of liquidity fragmentation in the blockchain industry as a whole. This is achieved with a lightweight message-passing protocol that provides authentic and guaranteed delivery.

 

How LayerZero Works

The core concept of LayerZero revolves around its user application (UA) configurable on-chain endpoint, which is responsible for running the User Level Network (ULN). LayerZero utilizes two key parties, the Oracle and the Relayer, to facilitate the transfer of messages between on-chain endpoints.

When a UA wants to send a message from chain A to chain B, the message is first routed through the endpoint on chain A. The endpoint then notifies the specified Oracle and Relayer about the message and its intended destination chain.

The Oracle, upon receiving the notification, fetches the block header from chain A and forwards it to the endpoint on chain B. Simultaneously, the Relayer retrieves the transaction proof associated with the message and submits it.

On the destination chain, the received block header and transaction proof are validated to ensure their authenticity and correctness. If the validation is successful, the message is then forwarded to the specified destination address, completing the transfer of the message from chain A to chain B.

The Value Proposition

With the proliferation of blockchains, users have been constrained by the isolation of each chain. This leads to fragmented liquidity and limited options for moving liquidity and state between different ecosystems. LayerZero aims to provide a powerful low-level communication primitive that enables the development of cross-chain applications without the need for trusted intermediaries or custodians.

LayerZero operates at the communication primitive level, facilitating diverse omnichain applications. While exchanges are one example of applications that can benefit from LayerZero, the protocol itself focuses on enabling seamless inter-chain transactions and communication. By offering trustless messaging capabilities between Layer 1 and Layer 2 chains, LayerZero establishes itself as the first trustless omnichain interoperability layer.

To tackle the issue of liquidity fragmentation across chains, LayerZero introduces a powerful low-level communication primitive that enables the development of a wide range of cross-chain applications without the need for trusted intermediaries or custodians. Unlike existing solutions such as decentralized exchanges (DEXs), LayerZero eliminates the trust problem associated with cross-chain transactions.

Traditional DEX implementations require users to convert their tokens into protocol-specific tokens and rely on an intermediate consensus layer to achieve transaction consensus. However, this introduces unnecessary overhead and reliance on side chains, compromising the core tenets of trustlessness in blockchain technology.

LayerZero revolutionizes the concept of trustless cross-chain transactions. Its communication protocol, called “valid delivery,” ensures that a transaction is delivered only when it is committed and valid on the sender chain, providing security guarantees. By combining independent entities—an Oracle providing block headers and a Relayer providing transaction proofs—LayerZero establishes a direct and secure communication channel between sender and recipient chains.

Operating through lightweight on-chain clients known as LayerZero Endpoints, the protocol enables direct cross-chain transactions between any chains that have implemented LayerZero. This creates a fully connected network where nodes on different chains can establish direct connections, facilitating seamless interaction and liquidity movement across chains.

LayerZero’s trustless approach to interoperability opens up new possibilities for large-scale applications, including cross-chain decentralized exchanges, multi-chain yield aggregators, and cross-chain lending. With LayerZero, users can consolidate liquidity, participate in decentralized finance (DeFi) applications, and access diverse ecosystems without relying on intermediaries or resorting to intermediate tokens.

Valid Delivery: Enabling Trustless Inter-Chain Communication

To ensure trustless inter-chain communication and validate transactions on different chains, LayerZero introduces the concept of valid delivery. Valid delivery serves as a communication primitive that enables cross-chain token transfers while providing specific guarantees:

• Every message (m) transmitted over the network is associated with a transaction (t) on the sender-side chain.
• Message (m) is delivered to the receiver only if the corresponding transaction (t) is valid and has been committed on the sender-side chain.

While existing exchanges and DEXs enable cross-chain token transfers, they introduce unnecessary complexity and costs, hindering the broad adoption of cross-chain applications. LayerZero seeks to overcome these limitations by providing a single trustless valid delivery mechanism without the need for a trusted intermediary. In their work, the LayerZero team implements a generic messaging protocol that ensures the trustless valid delivery of various user data, including tokens. This messaging primitive serves as a foundation for distributed exchanges and other decentralized finance (DeFi) applications, empowering them to facilitate cross-chain transactions. The flexibility provided by LayerZero’s low-level messaging protocol allows for the implementation of a wide range of previously unachievable functionalities in higher-level applications.

LayerZero V1

The core of LayerZero is its communication protocol enabling trustless valid delivery. The protocol incorporates several components to design a cost-effective smart contract-based light client endpoint.

LayerZero Endpoints serve as the user-facing interface to LayerZero, enabling users to interact with the protocol. Each chain in the LayerZero network features a LayerZero Endpoint, implemented as a set of on-chain smart contracts. The primary purpose of a LayerZero Endpoint is to facilitate message transmission using the protocol backend, ensuring trustless valid delivery.

A LayerZero Endpoint comprises four modules: Communicator, Validator, Network, and Libraries. The core functionality of the Endpoint is primarily encapsulated within the Communicator, Validator, and Network modules. Additional Libraries are added for each new chain supported by LayerZero, allowing for seamless integration without modifications to the core modules.

To enable inter-chain communication and support the LayerZero protocol, an Oracle service is utilized. The Oracle, an independent third-party service, reads a block header from one chain and transmits it to another chain. While any third-party service capable of providing this functionality could serve as the Oracle, the current industry leader for decentralized oracle networks, Chainlink, is expected to be utilized in practice for most implementations. On the other hand, the Relayer, functioning as an off-chain service, retrieves the proof for a specified transaction rather than block headers.

To ensure trustless valid delivery, it is crucial that the Oracle and Relayer are independent of each other for any given message sent via the LayerZero protocol. The protocol itself does not impose specific Relayer implementation requirements, allowing users of LayerZero to even implement their own Relayer service if desired. This design ensures that the Relayer and Oracle cannot collide.

Relayer

Relayers work together with Oracles to transmit messages between chains. By default, UAs will utilize LayerZero Relayer, and users do not have to run their own Relayer. A customer Relayer requires setting up a custom UA configuration.

Overview

Scope of Work

Relay proof across chains, and pay the cost for lzReceive execution.

Gas Composition

The receiving side smart contract overhead + proof cost + lzReceive. Plus, the gas varies from chain to chain.

lzReceive we will have a default configuration per chain.

Chain	Overhead	Max Proof Cost (Estimate)	default lzReceive
Ethereum	–	240303	–
Avalanche	–	265574	–
BSC	–	283471	–
Polygon	–	341630	–
Arbitrum	–	173074	–
Optimism	–	N/A	–
Fantom	–	Need Valid RPC	–

 

Market Risk

Charging native token A at the source chain, but paying native token B at the destination chain.

The business itself is long A / short B, can hedge the market risk with short A / long B in exchanges, or balance the book timely.

Develop a Relayer

To run your own Relayer, follow these high-level requirements for each chain:

• Deploy and maintain a contract that implements ILayerZeroRelayerV2 interface. A reference Relayer implementation can be found here.
• Make sure your Relayer contract has access to up-to-date gas price information for all destination chains in order to accurately estimate transaction delivery fees.
• Configure your application to use your custom Relayer contract by calling setConfig in the Endpoint contract. More information about setting a custom configuration can be found here.
• Have access to your own nodes RPC + WS (or rely on one or more providers).
• Maintain and balance wallets used for delivering messages/payloads.
• Create an off-chain service that listens to Packet event emitted by UltraLightNodeV2 on the source chain, waits for the configured number of confirmations, and calls  validateTransactionProof in UltraLightNodeV2 on the destination providing data from the event and the transaction proof. A reference implementation of transaction proof generation can be found here.

LayerZero Relayer

User Applications that opt into the default configuration will use the LayerZero Labs Relayer.

LayerZero Labs runs and maintains a Relayer as a production asset for the ecosystem.

Gas Convention

The LayerZero Relayer assumes only a base gas for destination contract calls, e.g. 200k gas for a call on Ethereum. It will only be enough for very simple applications.

If your app requires more gas, please use the adapter parameters specified here.

Max Proof Cost Estimate

Take a look at this link for in-depth details.

Oracle

Default Oracle Updates

By default, UAs opt into the LayerZero Protocol library updates. These updates generally bring improvements and changes to the reliability of the protocol’s generic messaging.

These libraries are append-only, meaning that previous versions will always be available for UAs that decide to not use the default config.

Opting Out of Defaults

For UAs that want to fully control or lock their Oracle properties, see UA Custom Configuration to learn more.

Locking UA configuration guarantees that only UA owners can change their LZ app configs; UAs that opt-in to LayerZero defaults accept LayerZero’s future changes to default configurations (i.e. best practice changes to block confirmations & proof libraries etc.)

Projects with custom configuration will not have any impact on their settings but are free to reconfigure settings back to Defaults or to any other Oracle at any given time.

Develop an Oracle

Performing the job of an Oracle means moving a piece of the message data from one chain and storing it in another.

Two of the primary requirements for operating an Oracle (per chain):

• Deploy and maintain balances in your own contract.
• Implement and operate a system that can submit data from Chain A to Chain B.

Users wishing to find out more about developing an Oracle should refer to the Oracle Section of the Documentation.

Google Cloud Oracle

The Google Oracle, as of 9/19/23, is the default Oracle configuration for LayerZero messaging.

For the full list of mainnet addresses, see this list.

TSS Oracle

For the full list of TSS addresses, see this list.

Chainlink Oracle

For the full list of Chainlink addresses, see this list.

These Chainlink nodes provide support and redundancy for the Chainlink Oracle.

• DexTrac
• Chainlayer
• LinkForest
• LinkPool

Overview of Polyhedra zkLightClient

Polyhedra Network is building the next generation of infrastructure for Web3 interoperability by leveraging advanced zero-knowledge proof (ZKP) technology, a fundamental cryptographic primitive that guarantees the validity of data and computations while maintaining data confidentiality. The Polyhedra Network team designed and developed Polyhedra zkLightClient technology, a cutting-edge solution built on LayerZero Protocol, providing secure and efficient cross-chain infrastructures for Layer-1 and Layer-2 interoperability.

zkLightClient on LayerZero

LayerZero is a protocol facilitating omnichain interoperability and cross-chain messaging. It empowers dApps developed using blockchain technology to seamlessly connect with over 30 supported blockchains. By leveraging the LayerZero protocol, dApp users can securely and efficiently interact with assets across different chains.

Additionally, Polyhedra’s zkLightClient technology is seamlessly integrated with LayerZero’s messaging protocol, enabling application developers to effortlessly utilize zero-knowledge-proof technology. With LayerZero’s comprehensive developer tools and strong community support, developers can easily create cross-chain applications on top of the protocol.

LayerZero’s ULNv2 validation library relies on the participation of two parties: the Oracle and the Relayer, for transferring messages between on-chain endpoints. When LayerZero transmits a message from chain A to chain B, the message follows a path from the endpoint on chain A to the ULNv2 validation library. The ULNv2 library informs the Oracle and Relayer about the message and its intended destination chain. Subsequently, the Oracle forwards the packet hash to the endpoint on chain B, while the Relayer submits the packet for on-chain verification against the hash and delivers the message accordingly.

To enhance security within the LayerZero messaging protocol, on-chain light clients enable the validator set of the source chain to validate events occurring on their chain and share them with the destination chain. Alongside other libraries, these light clients provide an additional layer of security. On-chain transaction verification has been excessively costly, ranging from $50 million to $100 million per day for each pairwise connection to Ethereum, primarily due to the requirement of extensive transaction logs, which are essential for proof but not for the application itself.

Polyhedra’s zkLightClient technology, integrated with LayerZero, leverages the compression capabilities of ZKP technology, significantly reducing on-chain verification overhead and latency. By utilizing efficient ZKP protocols, the zkLightClient technology diminishes the need for extensive transaction verification on-chain. Moreover, it enables the batching of multiple transaction verifications into a single zero-knowledge proof, further enhancing efficiency.

zkLightClient Addresses

To use the Polyhedra zkLightClient with your LayerZero UserApplication, configure your app with the Oracle addresses below.

• zkLightClient Addresses (Mainnets)
  • Ethereum：0x394ee343625B83B5778d6F42d35142bdf26dBAcD
  • BNB Smart Chain：0x76ce31EfB81a013b609CeeF1Cc4F4E5aEeA70B7f
  • Polygon：0x9D88a2f4253b106A1F8e169485490f7230b4276e
  • Core DAO: 0x6590C7e65EEC453a78199B0bE418dF7291DF9039
  • Avalanche：0xD59DdbF4c0E1ed3debD2f7afFc1fA9dEF198A652
  • Fantom：0x7cE1fab01F3cd7253731a9e11180d49ac960285C
  • Optimism：0x40b237EDdb5B851C60630446ca120A1D5c7B6253
  • Arbitrum One：0x2274D83ed2B4c1fCd6C1CCBF9b734F7e436DfD44
  • Moonbeam：0xE04E090a49aE0AF87583B808B05d2dc8c4d1E712
  • Gnosis Chain：0xFd1fabb34c4D6B5D30a1bFE2Fa76Cc15206fb368
  • Metis：0x057DCB38db5350Db12DCD94428c303D523f72153
  • Arbitrum Nova：0xD2C51b14cA69D7E557719A8534e1c5514f28DB3b
• zkLightClient Addresses (Testnets)
  • Ethereum Goerli Testnet: 0x55d193eF196Be455c9c178b0984d7F9cE750CCb4
  • BNB Smart Chain Testnet: 0x2C41853Ed4681A39c89c61Cdeb8c155561391215
  • Avalanche Fuji Testnet: 0x8517BA5E3eda338d9707a7B4a36033331e3d3B00
  • Optimism Goerli Testnet: 0x1853f53Aa7d9f6aF8537833c4255f928ab8F9D61
  • Arbitrum Goerli Testnet: 0xbFB5FEE3DCf2aF08F9f7a05049806fBC2E72A702

The LayerZero protocol

The LayerZero protocol facilitates the secure and reliable transmission of messages between different chains following a series of steps:

• Step 1: App A executes a series of actions as part of a transaction T. This transaction T is uniquely identified by its transaction identifier, t. Within the transaction, App A transmits a message over LayerZero, conditioned on the valid delivery of T. This message includes:
  • t: Unique transaction identifier for T.
  • dst: Global identifier pointing to a smart contract on Chain B.
  • payload: Data sent by App A to App B.
  • relayer args: Arguments describing payment information if App A intends to use the reference Relayer.
• Step 2: The Communicator module constructs a LayerZero packet, Packet(dst, payload), and sends it, along with t and relayer args, to the Validator module.
• Step 3: The Validator module forwards t and dst to the Network module, notifying it that the block header for the current block on Chain A needs to be sent to Chain B.

• Step 4: The Validator module also forwards Packet(dst, payload), t, and relayer args to the Relayer module, informing it to prefetch and eventually send the transaction proof for T to Chain B.
• Note that Steps 3 and 4 occur concurrently.
• Step 5: The Network module sends dst and the block ID of the current transaction (cur blk id) to the Oracle service. This instructs the Oracle to fetch the block header for the current block on Chain A and transmit it to Chain B.
  • Note that if multiple LayerZero transactions occur in the same block, this step is only executed once.
• Step 6: The Oracle reads the block header (blk hdr) from Chain A.
• Step 7: The Relayer reads the transaction proof associated with transaction T (proof(t)) from Chain A and stores it off-chain.
• Note that Steps 6 and 7 occur asynchronously with each other.
• Step 8: The Oracle verifies that the block corresponding to blk hdr is stably committed on Chain A, and then sends blk hdr to the Network module on Chain B.
  • The exact mechanism for determining block commitment varies per chain but typically involves waiting for a certain number of block confirmations.
• Step 9: The network module sends the block hash, represented as blk hdr hash, to the Validator module.
• Step 10: The Validator module forwards blk hdr hash to the Relayer module.
• Step 11: Upon receiving blk hdr hash, the Relayer module sends a list of Packet(dst, payload), t, and proof(t) tuples that match the current block.
  • In scenarios where multiple users simultaneously send messages between the same endpoints, there may be multiple packets and associated transaction proofs within the same block.
• Step 12: The Validator module utilizes the received transaction proofs and the block headers stored by the Network module to validate the validity and commitment of transaction T. If the block header and transaction proof do not match, the message is discarded. However, if they match, Packet(dst, payload) is forwarded to the Communicator module.
• Step 13: The Communicator module emits Packet(dst, payload) to App B, ensuring the delivery of the message.

How Trustless Valid Delivery is Achieved

LayerZero achieves trustless valid delivery by leveraging the independence between the Oracle and Relayer components, rather than relying on trust. This design choice allows LayerZero to be efficient, lightweight, and resilient against collusion.

• Trustlessness and Independence: LayerZero does not require users to trust the components of the protocol. Instead, it relies on the weaker condition of independence between the Oracle and the Relayer. As long as there is no malicious collusion between these two components, trustless valid delivery is guaranteed.
• Valid Delivery Protocol: The LayerZero protocol ensures that a message (m) is delivered by the Communicator to the user application only if the associated transaction proof (proof(t)) can be validated in Step 12. This validation is successful only when the block header provided by the Oracle and the transaction proof provided by the Relayer match.
• Validation Conditions: Valid delivery is guaranteed in two scenarios:
  • The block header provided by the Oracle and the transaction proof provided by the Relayer are both valid.
  • The block header provided by the Oracle and the transaction proof provided by the Relayer are both invalid but still match. This scenario can only occur if there is collusion between the Oracle and the Relayer, which is statistically improbable.
• Elimination of Collusion: LayerZero’s design eliminates the possibility of collusion between the Oracle and Relayer by ensuring independence between these components.

By providing trustless valid delivery, LayerZero offers an ideal solution for enabling cross-chain transactions without relying on intermediary entities or tokens. Its unique capability to guarantee trustless valid delivery positions LayerZero as the preferred method for cross-chain messaging, fostering user adoption and promoting seamless interoperability across different chains.

LayerZero Endpoints

In LayerZero, messages are sent and received by LayerZero Endpoints, which handle the transmission, verification, and receipt of messages.

A LayerZero Endpoint is implemented as a set of smart contracts on each chain within the LayerZero network. Its core functionality is divided into three modules: Communication, Validation, and Network. These modules operate in a manner akin to a network stack, where messages flow down the stack on the sender side (Communicator to Validator to Network) and up the stack on the recipient side.

In addition to the core modules, LayerZero Endpoints can be extended using Libraries, which are auxiliary smart contracts specifying how communication should be handled for a particular chain. Each chain in the LayerZero network has its own associated Library, and every Endpoint includes a copy of all the Libraries.

The presence of Libraries on both ends enables communication between any two chains within the LayerZero network. This design ensures that LayerZero forms a fully-connected network, empowering it to facilitate transactions and interactions between any pair of nodes across different chains.

These Endpoints consist of two components: a collection of versioned messaging libraries, and a proxy to route messages to the correct library version. When a message arrives at an endpoint, the endpoint selects the User Application configured library version to handle the message. The endpoint keeps all message states across versions and this allows libraries to be easily upgraded for fixes or optimizations.

Scalability costs of LayerZero Endpoints

Running smart contracts on Layer 1 chains, particularly as the amount of stored data increases, can be cost-prohibitive. To ensure the practicality of LayerZero Endpoints, the design of a lightweight client has been prioritized. This approach allows for cost adaptability, making the LayerZero Endpoint feasible and efficient even on Layer 1 chains with high operational costs.

Previous approaches, such as Golden Gate, which employed trustless cross-chain validation through cross-chain state machine replication (SMR), incurred substantial expenses, often amounting to millions of dollars per day when deployed on popular Layer 1 chains like Ethereum.

To address this challenge, LayerZero has devised an optimized solution by designing the most lightweight client possible for LayerZero Endpoints. The key insight is that replicating and storing block headers within the client is unnecessary. Instead, the protocol leverages off-chain entities, specifically the Oracle and Relayer, to handle the fetching of cross-chain headers and transaction proofs. This delegation of tasks significantly reduces the resource requirements of LayerZero Endpoints, resulting in a more lightweight nature.

LayerZero V2

LayerZero serves as the much-needed common language or the TCP/IP of blockchains, enabling seamless communication across different blockchain platforms. It is an open-source, immutable messaging protocol designed to foster the development of omnichain, interoperable applications. As a protocol, it enables developers to effortlessly transmit arbitrary data, external function calls, and tokens across various blockchains while maintaining complete autonomy and control over their applications.

One of the notable features of LayerZero is its adaptability, allowing developers and protocol teams to fine-tune configuration parameters to meet their specific needs. Despite this flexibility, LayerZero has faced criticism regarding its default configuration for decentralized systems.

LayerZero stands out as the ‘TCP/IP of blockchains’, offering a crucial protocol for enabling seamless interoperability and communication across various blockchain platforms.

To reiterate, LayerZero is not a messaging standard or a L1 blockchain, it is a protocol that prioritizes immutability, censorship resistance, and permissionlessness, embedding these values into its core architecture.

The current state of blockchain networks is often fragmented and lacks native interoperability, making tasks like token bridging between chains cumbersome and risky. LayerZero Labs aims to simplify and secure this process.

The idea that each Layer 1 (L1) or Layer 2 (L2) blockchain should specialize in its strengths and interoperate with others aligns with the philosophy of LayerZero Labs. This perspective fosters a more integrated and efficient blockchain environment.

LayerZero Labs is building towards a future where blockchains are not isolated entities but nodes in a larger Omnichain network. In this network, the role of each blockchain is redefined from being a competitor to a complement, focusing on its strengths and contributing to a more robust collective ecosystem.

Background

LayerZero was born as a messaging protocol instead of a bridge, eliminating the need for locking or wrapping tokens and aiming to unify liquidity across chains. The protocol went live on March 17, 2022, and since launch, it has delivered millions of messages over thousands of smart contracts, amounting to billions of dollars worth of assets across 40+ chains without suffering any vulnerability.

Chain A sends a message containing bytes to Chain B, and Chain B executes whatever instructions are contained in the bytes. For the case of a token transfer, this was materialized in the OFT (Omnichain Fungible Token) standard, which works by burning tokens on the source chain and sending a message that delivers a function call to ming the same number of tokens in the destination chain.

The protocol’s commitment to immutability, censorship resistance, and permissionlessness underpins its unique positioning in the market, differentiating it from other messaging standards or blockchains.

In its initial iteration, LayerZero introduced a suite of smart contracts known as “Endpoints,” providing a universal interaction interface for applications. These contracts are immutable but still allow for an append-only version of the validation library – since validation techniques will continue to evolve over time. Omnichian applications then interact with these endpoints by sending messages, which are simply arbitrary packets of data.

All of this workflow is orchestrated by two off-chain components: an oracle and a relayer. Oracles and relayers are entirely permissionless infrastructure that anybody can run and own without relying on any external party. They listen for events that happen on chain A, then hash those messages and pass them onto chain B, which verifies and executes the arbitrary message (it can be an asset transfer, a state mutation, a function invocation…).

Since the project’s inception, the thesis has been for the protocol to remain completely agnostic as to what the topology of oracles and relayers looks like – anybody can come in and run that infrastructure.

It’s important to note that LayerZero doesn’t fit into the traditional categories of centralized or decentralized; rather, it serves as a “build your own cross-chain infrastructure” sandbox. The emphasis is on permissionless customization, enabling users to configure the protocol according to their requirements. This versatility extends to aspects like security, oracles, block confirmations, and messaging libraries, all of which can be tailored to suit specific use cases.

The protocol’s ability to handle arbitrary data transmission and function calls across blockchains, while maintaining autonomy for applications, is what makes it possible to address the issue of liquidity fragmentation across chains.

An analogy can be made with TCP/IP, which is a set of rules that defines how two computers address each other and send data to each other. This set of rules is called a protocol.

In the past, there was no need for a common protocol, since it was not important for computers to communicate with each other. However, as computers became networked, the need arose for computers to agree on certain protocols. Hence, TCP/IP was conceptualized as a set of protocols that enable communication between computers. This is exactly what LayerZero is aiming to build in order to enable interoperability across chains.

As the protocol evolves into V2, it retains these core principles while introducing a decoupling of security and liveness, which still insists on message verification in the order of receipt, thus preserving the foundational properties of the system’s censorship-resistant nature.

State of LayerZero V2

LayerZero V2 achieves a fully connected mesh network by creating an infrastructure that enables every blockchain in the network to directly communicate with every other blockchain. This is a significant advancement in blockchain interoperability, as it allows for seamless interaction across different chains without the need for intermediary steps or bridges.

For this purpose, LayerZero employs a modular security model. This model allows for the immutable implementation of security, which can be extended to support new features and verification algorithms. It divides security into intrinsic and extrinsic components, with intrinsic security ensuring lossless, exactly-once, and eventual delivery of packets.

By addressing the interoperability challenge, LayerZero is not just a technical solution but a catalyst for a more cohesive landscape, potentially unlocking new possibilities for cross-chain applications.

The diagram below represents how the protocol integrity is divided into 4 categories: channel validity, channel liveness, data validity, and data liveness. The first two can be handled by the OMP (Omnichain Messaging Protocol), while the last two rely on the integrity of the underlying chain and cannot be secured by the OMP.

The intention of the design above is to ensure that intrinsic security works reliably and predictably over time, while the extrinsic security is modular and can be controlled by applications in order to continue evolving as technology advances. This allows applications to choose how much extrinsic security they require and how much they are willing to pay.

Similar to v1, an immutable contract called “endpoint” is deployed on each blockchain in the network. These endpoints are responsible for handling the core functions of the protocol, including packet transmission, ensuring censorship resistance, and exactly-once delivery.

The endpoints in LayerZero V2 serve as the fundamental nodes of the mesh network, establishing the primary interface between different blockchains. Each blockchain in the network has its own dedicated endpoint, and these endpoints function as gateways, facilitating the flow of information and transactions across the entire network.

The immutability of these endpoints is critical to the integrity and security of the mesh network, ensuring that once established, the core functionalities and security parameters cannot be altered maliciously or inadvertently.

The v2 approach is the commitment to redefine how blockchains can collaborate, moving from isolated systems to components of a broader interconnected network

Nevertheless, LayerZero V2 further enhances the capabilities of these endpoints through advanced features:

• Out-of-Order Lossless Delivery: A key feature of LayerZero endpoints is their ability to handle out-of-order, lossless packet delivery. This means that packets can be received in a different order than they were sent without losing any data. This feature is crucial in a mesh network where multiple paths and varying transmission times could lead to packets arriving out of sequence.

• Configurable Security Stack: Each endpoint maintains a configurable Security Stack. This stack specifies the security settings and verification mechanisms for each OApp (Omnichain Application) using the LayerZero protocol. The flexibility to configure individual security stacks for each application allows for a tailored security approach that can meet the unique requirements of different applications and blockchains.

• Append-Only MessageLib Registry: LayerZero V2 employs an append-only MessageLib Registry, where each MessageLib is a module responsible for the secure transmission and verification of messages. The append-only nature of this registry ensures that once a MessageLib is added, it cannot be altered or removed, contributing to the overall security and stability of the network.

A Decentralized Verified Network (DVN) plays a vital role in verifying the integrity of data transmitted across the network. This network of verifiers operates in a decentralized manner, making the system resilient to single points of failure and ensuring reliable cross-chain communication.

Any party can be a DVN: L2 native bridges, oracles, third-party bridges, or other verification systems such as ZK light clients. For instance, examples of third-party adapters include Axelar, Chainlink’s CCIP, Polyhedra, Nethermind, Obol, Tapioca, etc.

This is a key feature, since it enables a verification model where application developers can, for example, plug in Wormhole or Axelar’s validator sets. This makes this design strictly superior to those validator sets alone.

Since applications are responsible for their own extrinsic security, they can also choose their own Executor. These are entities that are responsible for quoting prices and gas as well as handling all of the complexities associated with user transactions. In exchange for this service they will charge a small fee on top of the gas cost.

Even though LayerZero will run an optional Executor out of the box, applications have an incentive to compete on both price and service. Considering that Executors are much simpler to run than Relayers, it is likely to see an increasing level of competition.

The strategic separation of execution and security functions in LayerZero V2 enhances the protocol’s resilience and reliability, providing a more robust foundation for secure cross-chain communication.

More importantly, LayerZero v2 works in such a way that, once a message is verified, anyone can execute a transaction. Applications can also choose whether to execute them in order – which might be important for a DeFi app – or in a way such that they can optimize for throughput (i.e. for gaming applications). Also, if one Executor goes down, it can be swapped by a replacement to ensure that liveness is not compromised (this would not be the case in v1 if the Relayer went down).

This way, the protocol separates the execution of feature logic from the core verification process. This separation ensures that the addition or modification of features does not compromise the security of the message transmission.

Protocol Design and Security Architecture

The principles or responsibilities of an Omnichain Messaging Protocol (OMP) like LayerZero can be condensed into two primary requirements: intrinsic security and universal semantics.

“Intrinsic security can and should be universally secured based on first principles.

In contrast, optimal, trustless communication across blockchains is impossible, and the continuous advancement in verification algorithms and blockchain design necessitates extensibility and configurability of extrinsic security.

This is true even in special cases such as L1–L2 rollups; the possibility
of hard forks necessitates L2 contract upgradability, thus making the L2 contract owner a trusted entity.” – LayerZero v2 Whitepaper

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 omnichain interoperability.

LayerZero’s design as an OMP is grounded in these principles, ensuring it provides a scalable, secure, and universally applicable solution for blockchain interoperability.

Core Protocol Design – The OApp Security Stack

The OApp security stack can be split into 4 components: immutable Endpoints for censorship resistance, append-only collection for on-chain verification modules, a permissionless set of Decentralized Verifier Networks (DVNs), and permissionless executors to execute feature logic in isolation to the cross-chain message verification context.

Together, these components form a two-layered architecture, where we differentiate between an execution and a verification layer.

Messages in LayerZero are composed of a payload and a path. These messages are serialized into packets before being transmitted across the mesh network.

• Packets are verified by the verification layer on the destination blockchain before they are committed into the lossless channel.
• Once verified, packets are read from the channel and delivered by executing the lzReceive callback on the destination OApp contract.

Channel liveness (eventual delivery) is guaranteed through permissionless execution in conjunction with Security Stack reconfiguration, ensuring that even if DVNs experience faults or executors stop delivering messages, the OApp can regain liveness by reconfiguring its Security Stack or having another party deliver the packets.

By minimizing and standardizing interactions between components, LayerZero reduces potential software bugs. Because of its modular and configurable nature, it facilitates rapid prototyping and expansion to new blockchain networks.

Packet Transmission

LayerZero’s packet transmission process showcases its robust design for cross-chain communication, emphasizing security, orderliness, and resistance to censorship.

Each step, from the initial sending to the final execution, is carefully coordinated to maintain the integrity of the messages and the reliability of the network.

Step 1 – Sending The Message

• Sender Contract initiates Transmission
  • Sender contract calls lzSend on the source chain’s LayerZero endpoin
  • Sender specifies the message payload and a path, which includes the sender’s application address, the source Endpoint ID, the recipient’s application address, and the destination Endpoint ID.
  • This path creates a unique, censorship-resistant communication channel for the message.
• Assignment of Nonce and GUID
  • The source Endpoint assigns an increasing nonce to the packet, ensuring uniqueness and orderly processing.
  • The nonce, combined with the path, is hashed to generate a Global Unique Identifier (GUID) for the packet.
  • The GUID plays a crucial role in tracking the packet’s status and coordinating actions across the network.
• Processing by Source MessageLib
  • The source Endpoint utilizes the configured MessageLib (e.g., Ultra Light Node) to encode the packet.
  • The MessageLib processes the packet according to the Security Stack settings, arranging for DVNs to verify the message at the destination and, if required, triggering actions via executors.
  • Identifiers for DVNs and executors, along with any necessary arguments, are compiled into an array called Message Options.

Step 2 – Independent Verification by DVNs

Configured DVNs independently verify the packet at the destination MessageLib. In the case of the Ultra Light Node, this typically involves storing the hash of the packet payload.

Step 3 – Commitment to the Endpoint

Once the required threshold of DVNs has verified the payload, a worker (like an executor, DVN operator, or user) commits the packet to the destination Endpoint.

The Endpoint ensures the payload verification aligns with the OApp’s configured Security Stack before committing it to the lossless channel.

Step 4 – Execution of Receiver Logic

An executor on the destination chain calls lzReceive to execute the logic of the Receiver OApp based on the packet’s content.

This step is designed to prevent censorship, with the system reverting if the channel cannot ensure lossless and exactly-once delivery.

• A packet is sent after the source transaction increments the nonce.
• A packet is verified after it is committed into the endpoint
• A packet is received after delivery (execution)

LayerZero Core Messaging API

Protocol Extensions

LayerZero’s design is remarkably adaptable, allowing for a range of extended functionalities through features like Message Options and lzCompose. These features enhance the protocol’s ability to handle diverse execution requirements and cross-chain interactions.

LayerZero’s ability to synergize with various blockchain technologies, rather than competing with them, sets a new precedent in the interoperability space,

LayerZero does not adhere to a single standard format for serializing arguments into Message Options. This flexibility means that developers aren’t required to write specialized code for each MessageLib.

To facilitate backward compatibility and ease of use, LayerZero defines three standardized formats for Message Options.

• Type 1 and 2: These types are designed for specifying arguments for a single executor to carry out commonly required functionalities.
• Type 3: This format is more versatile, encoding a list of (workerID, option) tuples. It allows passing an arbitrary number of arguments to an arbitrary number of workers.

Since all messages processed by an executor have already been verified by the verification layer, this setup ensures that executors can perform a wide range of actions without compromising the integrity of the message.

LayerZero introduces lzCompose, a standardized interface for cross-chain composition. This feature is significant, especially for unifying composition semantics across all blockchain types (EVM, MoveVM…). The main benefit is the universality of lzCompose, which allows for defining a single application architecture scalable to all existing and future blockchains.

When data is stored using lzCompose, the integrity and liveness of the data are “closed”. This means that any errors within the composed contracts only affect the closure, not the entire system. This isolation is particularly useful for managing potential attack surfaces like reentrancy, as it confines the impact of faults.

Application Level Security

It is not possible for OApss to use the Message Options interface to extend the verification scope to include additional data. However, it can be used to detect and filter out verified-yet-malicious messages (e.g. buggy messages that would trigger OApp-level faults).

This is achieved with an off-chain application-level security mechanism called PreCrime, which provides an additional layer of application-specific packet filtering on top of the existing LayerZero protocol.

This allows subsets of peers within an OApp (which could be some or all of an OApp’s contracts) to enforce security invariants after simulating the result of packet delivery. These checks are based on predetermined criteria relevant to the OApp’s functionality and security needs.

The results of these invariant checks are collated by an off-chain worker, and if any peer reports a violation of the set invariants, the off-chain worker halts the delivery of the corresponding packet.

As an example, consider the scenario of a token bridge spanning 3 chains (Chain A, Chain B, Chain C) with an initial token distribution where mintA = 10, mintB = 10, and mintC = 10.

Suppose Chain A is compromised and attempts to illegitimately mint additional tokens on Chain B without locking corresponding assets.

Pre-Crime detects this discrepancy by checking the total minted tokens (∑mint) against the total locked liquidity (∑lock) across all chains.

Upon identifying the breach (where ∑mint would exceed ∑lock due to the unauthorized minting on Chain B), Pre-Crime can intervene to prevent this malicious action.

This way, after detecting the violation, the receiver can skip the compromised nonce using the skip function, thus averting potential damage or faults at the OApp level.

Finally, it is worth noting that PreCrime does not enhance the core protocol security of LayerZero, nor does it protect against data integrity issues caused by malicious DVNs or blockchain-level faults. Its primary role is to act as an additional safeguard at the application level.

Future-Proof Architecture

LayerZero’s architecture is designed to ensure the immutability and continuous improvement of its components, providing a reliable and adaptable framework for user applications (UAs).

Immutable Endpoints

The LayerZero Endpoint serves as the sole interface for UAs, allowing them to configure the Messaging Library used for sending and receiving verified messages. This configuration guarantees the ordering of message delivery across all messaging libraries.

• When a message is sent, it passes through the Endpoint before being redirected to the UA-configured Messaging Library.
• Similarly, when receiving a message, it is first verified at the Messaging Library, then forwarded to the Endpoint, and finally delivered to the UA.

Perpetual Messaging

One of the key aspects of LayerZero’s architecture is the perpetuity of Messaging Libraries. Once deployed, they remain in service indefinitely. No entity, including the LayerZero Labs multi-sig, has the power to de-register or change the configuration of a UA’s Messaging Library. This ensures the uninterrupted flow of messaging for UAs, providing stability and reliability.

Continuous Improvement

LayerZero has the flexibility to deploy new Messaging Libraries that offer enhanced security and performance optimizations. For example, more efficient proof technologies can be integrated into new versions. Importantly, this evolution does not impact the UA interface, allowing for seamless migration to newer versions.

Applications on LayerZero

Multiple applications can be built on LayerZero’s infrastructure. Below you can find some examples of applications that can use LayerZero to implement cross-chain transactions:

• Cross-chain decentralized exchange: LayerZero enables the creation of a cross-chain decentralized exchange (DEX) or cross-chain bridge that operates exclusively with native assets. Unlike existing Des designs that rely on wrapped tokens or intermediary sidechains, a Dex built on LayerZero can establish liquidity pools on multiple chains. Users can deposit their native assets into one pool and withdraw native assets from another chain directly.
• Multi-chain yield aggregator: Existing yield aggregators typically operate within a single-chain ecosystem, limiting their access to yield opportunities. However, a yield aggregator built on LayerZero can tap into the best yield opportunities across different ecosystems. By utilizing cross-chain transactions, the aggregator can aggregate yields from multiple chains, enabling users to capitalize on market inefficiencies and gain exposure to a broader range of high-yield opportunities.
• Multi-chain lending: Currently, users face challenges when seeking to capitalize on opportunities in chains where they do not hold assets. With LayerZero, a lending protocol can be developed that allows users to keep their asset base on one chain, lend it out, and borrow directly in the desired asset on another chain. For instance, a user holding assets in Ethereum could lend them out and borrow assets directly in MATIC on Polygon, eliminating the need for intermediary costs like bridge and swap fees.

LayerZero Omnichain Contracts

OFT – Omnichain Fungible Token

Omnichain Fungible Tokens (OFTs) are tokens that follow a fungible token standard developed by LayerZero for cross-chain interoperability. Unlike traditional token transfer methods that rely on bridging and wrapping tokens, OFTs provide true composability across integrated blockchains within the LayerZero network.

With OFTs, tokens can be transferred directly between any integrated chain and can be used in decentralized applications (dApps) on those chains. This is made possible through the established contract-to-contract communication protocol of LayerZero. The process involves burning an OFT token on one chain, presenting the receipt to another chain, and minting an equivalent number of tokens there. This ensures a consistent token supply regardless of the chain on which the tokens reside.

The primary objective of OFTs is to create a seamless DeFi (Decentralized Finance) experience where users no longer need to worry about the specific blockchain they are using. All tokens, applications, and protocols can interact seamlessly, providing a more efficient and user-friendly DeFi ecosystem. This interoperability can be a significant boost for users, eliminating the need for multiple bridges, reducing costs, and enabling greater access to liquidity.

There are two versions of OFTs: OFT (v1) and OFTV2, each with specific use cases and differences:

• OFT (v1) was the initial implementation of the OFT standard and was designed to support Ethereum Virtual Machine (EVM) chains exclusively. It was used in projects such as Stargate’s token ($STG) and is suitable for applications that solely require support for EVM chains. If the developer’s intention is to focus on EVM chains both currently and in the future, then OFT (v1) is the appropriate choice.
• OFTV2 was developed to address the need for an Omnichain Fungible Token standard that supports both EVM and non-EVM chains. For example, if anyone wants to build a token that can be used on EVMs as well as non-EVM chains like Aptos or Solana, OFTV2 is the recommended version. OFTV2 incorporates features such as fees, shared decimals, and composability. This version is currently utilized in projects like BTCb.
  • It is possible to utilize an extension in order to turn an already deployed ERC20 into an OFTV2.

The main difference between OFT (v1) and OFTV2 lies in their compatibility with non-EVM chains. Non-EVM chains, such as Aptos or Solana, use Uint64 to represent token balances. OFTV2 accommodates this difference by utilizing Shared Decimals for value transfers, which normalizes the data type disparity. It is suggested to choose a smaller shared decimal point for all chains to allow for a larger token balance. For instance, if the decimal point is set to 18, the maximum number of tokens would be limited to approximately 18 * 10^18 tokens due to the constraint imposed by uint64.max.

Additionally, OFTV2 is recommended to be used with no more than 10 shared decimals. This limitation is in place to ensure efficient and effective token operations across chains.

OFTs address three obstacles currently hindering the full potential of multi-chain DeFi:

• Depeg risk: By facilitating direct token transfers between chains, OFTs mitigate the risks associated with bridging and wrapping tokens. Users can maintain the peg of their tokens while utilizing them on different chains, reducing the exposure to potential depegging issues.
• Bad UX: OFTs improve the user experience by enabling seamless token transfers and interactions across various chains. Users can access and utilize their tokens on different chains without the need for complex bridging processes, resulting in a smoother and more intuitive DeFi experience.
• Fragmented liquidity: The composability of OFTs across integrated blockchains allows liquidity to flow more freely. Rather than liquidity being fragmented and confined within specific chains, OFTs enable liquidity to be shared and utilized across multiple chains, enhancing overall market efficiency and accessibility.

ONFT – Omnichain Non-Fungible Token

There are two types of ONFT predominant standards:

• ONFT721 – to implement ERC721 omnichain NFTs
  • Proxy ONFT721 –  to turn an already deployed ERC721 into an ONFT721.
• ONFT1155 – to implement ERC1155 omnichain NFTs.
  • Proxy ONFT1155 – to turn an already deployed ERC1155 into an ONFT1155.

ColorTrace

ColorTrace was introduced on November 14, 2023.

It is a value attribution mechanism that can enhance transparency and equitable reward distribution for yield-bearing stablecoins, regardless if the yield comes from off-chain RWAs or on-chain sources like staking rewards.

Current decentralized finance (DeFi) applications often rely on fungible tokens (e.g., stablecoins) to provide an easy-to-use, reliable, and trustworthy payment mechanism. However, there exists a key deficiency with current fungible tokens: once they are issued (minted), there is no practical onchain algorithm to keep track of the entity (minter) that minted them.

This makes it impossible to:

• Track the origin of each token as they are transferred and redeemed.
• Proportionally reward minters for minting tokens.

LayerZero formalized this dilemma as the fungible token coloring problem of “coloring” fungible tokens to associate each token to the entity that originally minted it, and presented a novel algorithm to solve this problem.

ColorTrace, is the first to solve the fungible token coloring problem in O(1) storage complexity. This is achieved by requiring all transfers to recolor tokens such that the receiver wallet balance and sent tokens are of the same color. In addition to solving the fungible token coloring problem in a single-chain context, they solve the additional economic and safety challenges to extend ColorTrace to support provably-safe crosschain token transfers. The safety of crosschain transactions is guaranteed by the delta-zero invariant, a single invariant which they use to formally prove the safety and validity of ColorTrace’s crosschain recoloring methods.

A vault on the primary chain governs the association of underlying value to onchain colored tokens and token contracts deployed to a collection of independent blockchains conduct transactions and periodically synchronize token recolorings to the vault. ColorTrace is divided into a coloring layer and synchronization layer. The coloring layer implements O(1) token transfers with predictable gas consumption for all user-facing operations, but introduces entropy into the system in the form of token recolorings and chain-local ∆ imbalances (nonzero ∆θ ).

This divergence in the system is resolved by the synchronization layer, which implements safe and globally consistent synchronization of recolorings to the vault. Both the coloring and synchronization layers are provably safe by ensuring the net error in the system is zero via the delta-zero invariant.

ColorTrace addresses the token coloring problem, which involves tracking the origin of tokens for fair burning and attributing the number of colored tokens minted by each minter in proportion to the global token supply.

• Fair Token Burning: It ensures fair token burning by identifying the original minter of a redeemed token.
• Crosschain Transfers: It resolves complexities related to crosschain transfers caused by asynchrony between source and destination transactions.
• Remint operations: ColorTrace allows minters to synchronize changes in token circulation to the primary chain vault, addressing economic and ordering challenges associated with the remint operation.

Put together, this enables verified minters to mark their tokens and access rewards from on-chain reserves transparently and without disputes.

The implementation of ColorTrace goes beyond stablecoins, presenting a model for on-chain value tracking and equitable distribution that could revolutionize how value and rewards are attributed in decentralized networks.

The foundation of ColorTrace is “lossy coloring,” a solution for token coloring that serves as the basis for four algorithms: ColorFloat, ColorTrace, rho, and ColorAge. This is achieved in a highly efficient manner with O(1) complexity, avoiding the common scalability problems associated with traditional O(n) solutions.

Beyond stablecoins, ColorTrace’s on-chain value attribution can be applied to various use cases, such as on-chain referral programs and affiliate programs, fostering fairness and equity.

ColorTrace opens the potential for blockchain applications to integrate more deeply with fungible tokens and enables a more equitable Web3 ecosystem.

$USDV

Verified USD, or $USDV, is developed as the first omnichain tokenized treasury-backed stablecoin by the Verified USD Foundation. Its primary goal is to provide a stablecoin solution that is natively interoperable across multiple blockchain networks, facilitating DeFi and CeFi rewards for its active circulation.

• $USDV is pegged 1:1 with USD, fully backed by cash, overnight report and short term treasuries.
• $USDV can be minted by approved entities through agreements with the issuer. Once purchased, the stablecoin can freely flow across chains and there are no restrictions on who can hold or use $USDV.
• $USDV is neither a security nor a regulated stablecoin, It does not represent ownership, equity, or rights to the profit/losses in any company or legal entity.
• $USDC integrates with LayerZero’s OFT (Omnichain Fungible Token) for cross-chain interoperability and implements Colortrace

The problem to be solved is that much of the value of existing stablecoins is driven by market participants themselves, yet they are not fairly rewarded for it. Groups like Uniswap, Curve, Coinbase, and Binance have moved trillions of dollars of stablecoins and given immense utility to their underlying ecosystems and yet only one of those has ever been directly rewarded for it – Coinbase.

Circle entered into a custom agreement with Coinbase to share the yield of $USDC based on Coinbase’s contributions to the success of $USDC. For this, Coinbase currently earns almost $1B per year. However, more than $20B are in circulation, with the majority portion on EOAs. For the balance sitting in Uniswap, Curve, Coinbase, and Binance it’s easy to see how much each party has contributed, but for the more than $10B+ sitting in user wallets and EOAs it’s hard to know how much each group has contributed to that.

USDV’s design as an omnichain stablecoin not only provides a stable medium of exchange across multiple chains, but also exemplifies how traditional financial instruments like treasuries can be integrated on-chain to ensure a more fair attribution of yield.

The simple solution would be to create similar deals with all other major parties, but this is where the tricky part comes in. Imagine a world today where $24B of USDC sits in circulation, with the majority in EOAs. How much yield goes to each party? For the balance sitting in Uniswap, Curve, Coinbase, and Binance it’s easy to see how much each party has contributed, but for the more than $10B+ sitting in user wallets and EOAs it’s hard to know how much each group has contributed to that.

This is where Colortrace comes in to solve the problem of on-chain value attribution. It unlocks the ability for each entity to receive pro-rata attribution for the value they have created for the underlying ecosystem.

In the case of $USDV, this means that each token an entity has minted into circulation will be marked with their color and be attributed to them until it is redeemed for the underlying asset.

$USDV utilizes ColorTrace, which allows for the distribution of rewards from stablecoin underlying assets, redirecting value generation back to the ecosystem and enabling protocols to claim ownership of their success. Each bill is equally spendable and yet you know unique characteristics about each based on their markings, such as who held them before, where they were printed, etc.

$USDV initially backs its value with Matrixport’s Short-term Treasury Bill Token (STBT), a tokenized T-bill with maturities within 6 months and reverse repurchase agreements (Repo) subject to daily rebasing to maintain a value of 1 USD. It also provides transparency through Chainlink’s Proof-of-Reserve statements, giving users direct on-chain visibility into circulation and issuance.

$USDV is also integrated with LayerZero’s Omnichain Fungible Tokens (OFT) Standard, a widely adopted standard designed for seamless operation across multiple blockchain networks.

Motivation for Building LayerZero

The motivation behind building LayerZero stems from the fragmentation caused by the diverse range of blockchain platforms and the subsequent isolation of their ecosystems. While the industry puts an emphasis on the topic of decentralization, transparency, and immutability, the growth of specialized chains has created a need for interoperability solutions. Up until now, users and developers have been forced to split their resources, time, and liquidity between separate chains, hindering adoption.

LayerZero addresses this limitation by introducing trustless omnichain interoperability. By enabling direct transactions across all chains, LayerZero allows users to consolidate fragmented liquidity and fully maximize the potential of multiple applications on different chains. As a protocol, the objective is to leverage the three pillars of decentralization, transparency, and immutability to provide a foundation for cross-chain interactions without the need for compromising trust. For that, LayerZero eliminates the reliance on centralized exchanges or cross-chain bridges, providing users with efficient and direct transfers.

Why v2

Blockchain interoperability remains an evolving challenge as the diversity of chains continues to grow, further fragmenting the liquidity available across chains. LayerZero was conceptualized to be the first Omnichain Messaging Protocol (OMP) to achieve a fully-connected mesh network that scales across all blockchains and use cases.

Since the beginning, the expectation was that teams would want to run their own relay infrastructure and set up their custom oracle configuration with a provider of their choice. However, the job of the relayer is actually quite complex, as it must deal with 50+ chains, N2pathways for gas abstractions, 10s of billions RPC calls, 10s of millions of messages passed…

Even though in theory LayerZero was trustless and developers could plug in the Oracle and Relayer of their choice, the reality is that multiple times would end up relying on a default setup that required trust on entities like Chainlink, Polyhedra, Google Cloud, and LayerZero Labs itself.

Given all of the complexities associated with those operations, only a very small set of relayers were running, which was suboptimal to realize the protocol’s vision of becoming agnostic infrastructure.

Previously, in V1, relayers were responsible for both the security aspect—assuring the validity of messages on the destination chain—as well as executing the transaction, which created a dependency where the message could not be validated without the relayer’s execution function. This coupling could potentially cause issues with message delivery and verification order, which is critical for maintaining censorship resistance in governance-related transactions

The decoupling of security and liveness in LayerZero v2 provides greater control and reliability for both applications and users.

The transition to V2 introduces several key innovations, with a notable focus on enhancing security and flexibility. Version 2 brings a notable iteration by completely decoupling liveness (the execution component) from security, thereby eliminating associated risks from V1.

In order to achieve this, LayerZero V2 has been designed from the ground up to revolutionize the way developers handle generic data, function calls, and tokens across different blockchains. It introduces a clear separation between message verification and execution, providing developers with greater control over their application’s security configuration and independent execution.

One of the standout advancements in LayerZero V2 is the decoupling of liveness and security within the validation layer. This fundamental change enables V2 to establish security through a robust X of Y of N multisig framework, which also incorporates the concept of veto rights that applications can wield for additional safety measures. This strategic move empowers developers and protocol teams to configure security parameters more effectively, aligning with their specific requirements.

Any third-party validation network (Decentralized Verifier Network, or DVN), including validators, external messaging protocols, and native bridges, can now act as verifiers within this layer without being tied to execution. This framework, embedded within the protocol itself, simplifies the setup compared to V1, where setups with oracles were more complex.

Execution, which was previously managed by relayers, is now in the hands of end-users, who can execute transactions on-chain, ensuring that their actions—like casting votes—are registered without requiring intermediaries. This self-execution aspect enhances the permissionless nature of the transactions.

LayerZero plays the role of an universal language for blockchains, facilitating interoperability across the broad spectrum of diverse chains (EVMs, Solana, Move-based chains…)

This design allows for completely permissionless execution. As soon as the security portion is signed off, anyone can make sure that a transaction goes across. For instance, this provides a better UX when a third party executor intervenes (i.e. you are on Ethereum and have $ETH in your wallet but you want to bridge to Polygon and have someone abstract the complexity of the $MATIC requirement to pay for gas on the destination).

Oracles and relayers continue to play a crucial role as off-chain infrastructure, listening for events and transferring state or funds across chains; however, in V2, their role as infrastructure is decoupled from security validations, underlining the move towards a purer infrastructure model.

In addition to these security improvements, LayerZero V2 brings substantial enhancements in various aspects, including message throughput, programmability, and other contract-specific optimizations. These improvements collectively result in a more flexible, high-performing, and future-proof messaging protocol.

Solving the Trust Problem

Existing decentralized exchanges (DEXs) like Multichain and THORChain conduct transfers on-chain, which helps alleviate the trust problem. However, these implementations often involve converting user tokens into protocol-specific tokens that traverse an intermediate consensus layer to achieve transaction consensus. While this intermediate consensus layer is typically implemented securely, it still requires users to trust a sidechain to facilitate token transfers. This additional overhead is deemed unnecessary.

The figure above provides an illustration of LayerZero’s functionality in the context of building an exchange.

• Traditional centralized exchanges, depicted on the left side of the figure, rely on a central trusted authority to manage token deposits off-chain and issue coins on other chains upon user requests. Because of this, centralized exchanges traditionally offer valid delivery by acting as intermediaries in token transfers. Users deposit their tokens with the exchange, which then issues a non-cryptocurrency balance on different chains. This allows users to withdraw their balance from any supported chain. However, this approach introduces trust in the exchange, as a malicious or compromised exchange could withhold users’ balances, compromising their assets. Moreover, relying on centralized exchanges contradicts the core tenets of cryptocurrencies, which emphasize independence from centralized entities.
• Decentralized exchanges (Dexs), as shown in the center diagram, utilize smart contract-governed consensus protocols to automate coin minting on chain B. This eliminates the need for a centralized off-chain middleman. However, Dexs typically involve intermediate tokens and chains. They mint an intermediary or wrapped token on chain B, rather than the desired token the user wants. Consequently, the user must perform an additional transaction to exchange the intermediary or wrapped token for the desired token. This introduces unnecessary overhead and complexity, deviating from the ideal of a seamless single transaction. Furthermore, users must trust the intermediate consensus layer that confirms the transaction on the source chain and conveys the intent to mint the token on the destination chain.
• In contrast, an exchange built on LayerZero, as depicted on the right side of the figure, offers a more streamlined approach. Chain A can initiate a single cross-chain transaction that facilitates the local transaction on chain A and notifies the application on chain B to safely grant a token to the user. LayerZero acts as the intermediary, delivering messages between the two chains. This enables a clean and minimal single-transaction swap without involving any intermediate tokens.
• By building on LayerZero, the exchange protocol can be handled by smart contracts on both the source and destination chains within LayerZero’s framework. This architecture provides flexibility and follows the end-to-end principle, with the majority of the high-level exchange logic executed by the smart contracts on the respective chains.

LayerZero addresses the trust problem by enabling direct cross-chain transactions without relying on intermediaries or compromising the fundamental trustlessness of blockchain technology. LayerZero’s communication primitive, termed “valid delivery,” ensures that a message (m) is delivered if and only if the corresponding transaction (tA) on Chain A is committed and valid. This is achieved through the collaboration of two independent entities: an Oracle that provides the block header and a Relayer that provides the transaction proof associated with tA.

By combining these independent entities, LayerZero ensures that the transaction on the recipient chain (Chain B) is paired with a valid and committed transaction on the sender chain (Chain A), without involving any intermediary chains. This direct cross-chain communication protocol guarantees secure and trustless transactions between chains.

LayerZero operates through lightweight on-chain clients called LayerZero Endpoints. Each supported chain has its own LayerZero Endpoint, enabling cross-chain transactions with any other chain that also has a LayerZero Endpoint. This creates a fully connected network, allowing nodes on different chains to have direct connections with each other.

The ability to perform direct cross-chain transactions opens up new possibilities for large-scale applications that were previously infeasible. Examples include cross-chain decentralized exchanges, multi-chain yield aggregators, and cross-chain lending. LayerZero enables users to freely move liquidity between chains, consolidating liquidity pools and participating in various decentralized finance (DeFi) applications across different chains and ecosystems without relying on third-party systems or intermediate tokens.

Roadmap

LayerZero introduced a roadmap on December 15, 2023.

The roadmap details an upcoming V2 upgrade that maximizes network throughput and liveness, while making it easier for dApp developers to build through unified semantics and modular security.

With V2, app owners have complete control over their Security Stack with the ability to choose and combine third-party Decentralized Verifier Networks (DVNs). These are off-chain networks of verifiers that come to consensus and attest to the validity of messages. Any party can be a DVN- L2 native bridges, oracles, third party bridges, or other verification systems, such as ZK light clients.

V2 is currently live on testnets.

Sector Outlook

The sector outlook for cross-chain communication and messaging bridges is evolving rapidly. While the term “cross-chain bridge” has often been associated with token transfers, bridges can facilitate much more than simple token transfers between blockchains.

Arbitrary messaging bridges (AMBs) are emerging as a key component of the cross-chain ecosystem. These bridges enable the transfer of various types of data, including tokens, chain states, contract calls, NFTs, governance votes, and more, between different chains. This expanded functionality opens up new possibilities for cross-chain governance, token launches, gaming experiences, and other innovative applications.

In this sector, we can also find protocols like Multichain, Wormhole, Axelar, Hyperlane, deBridge, and Celer IM.

Competitive Landscape

LayerZero is a promising player in the Arbitrary Message Bridge (AMB) sector. The technology’s key strengths lie in its simplicity, lightweight clients, and potential adoption from protocols building cross-chain applications. Its architecture is designed with developers in mind, requiring them to only implement two functions – send and receive – for any applications that can be written in Solidity, Rust, etc. This allows high-throughput chains to interact without constraint and without the need for a middleman.

One unique feature of LayerZero is its use of lightweight clients. Running smart contracts on Layer 1 can be costly; LayerZero mitigates this issue by exporting storage and fetching transaction data to off-chain entities called Oracles and Relayers. This makes LayerZero’s Ultra Light Node endpoints small, cost-effective, and quick to incorporate new chains.

Instead of relying on wrapped or intermediary assets, the technology behind LayerZero centers around “Endpoints” found on supported chains, which are implemented as a series of smart contracts allowing different domains to communicate. LayerZero relies on two off-chain entities, an Oracle and a Relayer, to pass messages between endpoints on different domains. Oracles relay generic data, such as block headers, while relayers fetch proof of specified transactions. This ensures LayerZero’s decentralization, as anyone can become a relayer. However, LayerZero’s security could be compromised if Oracles and Relayers were to collude and agree on invalid data.

The transaction process on LayerZero only requires source gas in a single call. A transaction is broken up into multiple parts by the Oracle and Relayer, facilitated by a LayerZero Endpoint. Once the information is verified as correct, the message is translated and executed on the destination chain.

In terms of security features, LayerZero has a high degree of assurance due to the independence of Oracles and Relayers. The probability of a block header and transaction proof matching without prior knowledge is low, making collusion and attacks expensive and less likely. Furthermore, LayerZero’s simple and effective design enables security tracing down to the chains where its Endpoints reside.

V2

By design, LayerZero faces little to no competition, since it is an agnostic protocol that can grow in two ways:

• By increasing the number of chains it supports.
• By increasing the number of dApps that decide to go omnichain (be present on multiple chains while still supporting unified liquidity).

Put together, this can create a positive feedback loop such that the more chains the protocol can support, the more appealing it is for apps to integrate with LayerZero.

Other interoperability protocols would fall into either the verification or execution category, but LayerZero embraces all of them by design, since v2 decouples liveness from execution. It is important to note that this does not mean that LayerZero created a messaging protocol by simply chaining together multiple cross-chain messaging systems. It is the opposite, since it leverages foundational invariants that make it possible to connect chains across different compatibility groups, such as EVM chains, MoveVM chains, Solana…

Another key point is the developer experience. LayerZero Labs offers tools and libraries for teams to choose the level of security they wish based on their own preferences and costs. The fact that there is no one-size-fits-all makes it very attractive for developers to embrace, since they can benefit from both the flexibility and extensibility of the LayerZero protocol.

It is worth noting that, while LayerZero Labs offers default configurations to make the lives of developers easier, they are just an option or alternative that can be used. Every other cross-chain protocol only has defaults, whereas LayerZero gives developers the voice to change their configuration and parameters. In other words, the worst case for LayerZero is the best case for any other messaging protocol.

Defaults do not have any effect whatsoever on how the protocol works. They simply provide a standard implementation to get started.

AMB Comparative Analysis

The comparative analysis of arbitrary messaging bridges (AMBs) focuses on evaluating their design trade-offs, core features, strengths, and weaknesses. The analysis is divided into five categories, each with several metrics embedded within:

1. Bridge Design – Theoretical Security: This category examines the theoretical security of each AMB by analyzing aspects such as the consensus mechanism, minimum number of validators required for collusion, censorship resistance, and permissionlessness of the validator set.

2. Practical Security Measures: Here, the focus is on the practical security measures implemented by each AMB. The metrics include the number of audits conducted for each AMB (more audits indicate better security), and the presence of open bug bounty programs with Immunefi, specifying the maximum reward for critical vulnerability findings.

3. Protocol History: This category assesses the history and track record of each AMB. It considers the time since the launch of the AMB to gauge its longevity and relevance. Additionally, any major hacks experienced by the AMB are highlighted, and the response of the team and their ability to recover from such incidents are evaluated.

4. Connectivity and Usage: This section examines the connectivity of each AMB by looking at the number of blockchains supported. The more blockchains an AMB supports, the more options it provides to projects looking for cross-chain compatibility.

5. Token Bridge’s Performance: This category focuses on the performance of the token bridges associated with each AMB. Metrics such as capital efficiency, total transaction count, total bridged volume, and the highest Total Value Locked (TVL) at the peak are considered to assess the success and performance of the token bridges.

Messaging Bridge	Consensus Mechanism	Consensus Required for Message Censoring	Time Since Launch	Hacks
Axelar	Delegated PoS & Weighted Threshold Signature Scheme	16 Validators, lower for chains with lesser validators	17 months since Feb 2022	Nil
Nomad	Optimistic	1 Updated or Watcher Only Update can cause downtime issues at a channel level	18 months since Jan 2022	$190M smart contract hack
Wormhole	Multisig	7 Guardians	23 months since Aug 2021	$320M smart contract hack
LayerZero	Independent Oracle and Relayer	1 Oracle or Relayer Oracle and Relayer systems can be decentralized	16 months since March 2022	Nil
Celer IM	Specialized PoS or Optimistic-like model	7 validators at current staked value	15 months since April 2022	Nil
anyCall	Secure Multi-Party Computation & Equally-Weighted Threshold Signature Scheme	12 Validators	15 months since April 2022	$3M smart contract hack
Hyperlane	Delegated PoS & Sovereign Consensus	Validators can censor messages but stakes will be slashed for doing so	12 months since July 2022	Nil
deBridge	Threshold Signature Verification & Slashing and Delegated Staking	5	17 months since Feb 2022	Nil

Connectivity of Networks:

• Axelar: 23
• Nomad: 8
• Wormhole: 14
• LayerZero: 11
• Celer IM: 9
• anyCall: 11
• Hyperlane: 7
• deBridge: 7

LayerZero has a high potential for utility in various sectors. As a ground-level piece of infrastructure, it can be used by liquidity networks, multi-chain yield aggregators, multi-chain lending protocols, and other decentralized applications (dApps) for a wide array of crypto use cases. LayerZero Scan, a feature that ties cross-chain transactions together in a single database, offers users and developers easy access to transaction state, status, and timing information.

The AMB (Arbitrary Messaging Bridges) sector has already attracted major attention and funding from crypto giants such as Multicoin Capital, Binance Labs, A16z, and Sequoia among others. More specifically, LayerZero has already gained significant traction and has been adopted by major dApps like Stargate, Radiant, and Sushi. Besides, the protocol currently supports 11 different chains, including Ethereum, BNB Chain, Avalanche, and Polygon.

LayerZero Ecosystem

Chains

LayerZero currently supports a wide variety of chains, including Ethereum, BNB Chain, Arbitrum, Optimism, and many others.

A full list of the supported chains can be found here.

Business Model

LayerZero’s business model relies on being the operator at the communication primitive level, facilitating diverse omnichain applications.

Revenue is derived from the Relayer, which takes a relayer fee from every message that is transmitted. The fee obtained depends on the native gas paid on the particular chain.

As the number of chains that are integrated by LayerZero grows, more messages are sent, leading to increased fees.

Economics

Fee Breakdown

EVM

Sending a message requires paying native gas fees. The gas fee can be estimated by calling “estimateFees(“) to return a tuple containing the cross-chain message fee.

The “estimateFees()” function returns a dynamic fee based on Oracle and Relayer prices for the destination “chainId”, your “UserApplication” contract, and “payload parameters”.

In solidity, you can use the ILayerZeroEndpoint.sol interface to call the view function to get the send() fees.

Endpoint “estimateFees()”

The implementation of “lib.estimateFees()” illustrates how the total fee is calculated, which is the cumulative amount the oracle and relayer are collecting plus, potentially, a small protocol fee.

Offchain Fee Estimation Example:

Aptos

The fee can be estimated by calling the Endpoint’s quote_fee() to get the fee tuple (native_fee (in coin), layerzero_fee (in coin)).

$ZRO

The LayerZero protocol’s native token, $ZRO, supports governance, incentivizes ecosystem growth, and offers fee accrual control. The total fixed supply is 1 billion tokens, distributed across four key categories:

Community Allocation (38.3%): 383 million tokens reward early users, developers, and community contributors. This allocation includes:

• Retroactive Initiatives: 8.5% of the total supply, claimable by early participants.
• Future Initiatives: 15.3%, reserved for future distributions to users and builders.
• Ecosystem and Growth: 14.5%, managed by the LayerZero Foundation for growth initiatives, grants, and liquidity.

Strategic Partners (32.2%): 322 million tokens with a three-year vesting period (one-year lock, then monthly unlocks) for investors and advisors.

Core Contributors (25.5%): 255 million tokens for LayerZero Labs team members, following the same vesting schedule as Strategic Partners.

Tokens Repurchased (4.0%): 40 million tokens pledged to the Community bucket by LayerZero Labs.

Governance

$ZRO holders govern protocol fees. Every six months, an on-chain referendum allows holders to vote on activating or deactivating LayerZero’s fee switch. If activated, the protocol may charge fees for verification and execution of cross-chain messages, burning fees collected via a Treasury Contract.

Risks

In terms of security, it is worth noting that if the block header provided by the Oracle and the transaction proof provided by the Relayer are both invalid but still match, then there is a collusion between the Oracle and Relayer. This is statistically improbable since both entities are meant to be independent. However, by design, the possibility of collusion is not fully eliminated, since each User Application can define its own Oracle and Relayer. Because of this, if a User Application chooses to go against this assumption, there is nothing that LayerZero can do to stop this collusion.

If the Oracle and the Relayer both fall under the control of a malicious actor, they would be able to perform actions such as tricking the protocol into believing that tokens have been burned on the source chain in order to withdraw on the destination chain even if no actions have taken place on the source chain.

As a result, the security of LayerZero relies on the implicit assumption that the Oracle and the Relayer are independent entities and the protocol itself does not provide any security guarantees in that regard.

In practice, one can not make any assumptions about the security of the applications built using LayerZero — each application should be carefully reviewed to ensure the independence of their Oracle and Relayer setup.

Security

LayerZero offers several security features to ensure the integrity and trustworthiness of its cross-chain messaging protocol:

• Valid delivery: The valid delivery mechanism relies on the independence of the Oracle and Relayer. By requiring matching block headers and transaction proofs from these two independent entities, the protocol ensures the validity of a transaction. This adds a high level of security, as the statistical probability of matching without prior knowledge is low.
• High cost of attack: In the unlikely scenario of collusion between an Oracle and a Relayer, the impact is limited. The risk is siloed to specific applications using that particular Oracle-Relayer combination, reducing the potential reward for attackers. The attack surface is segmented, making it economically unfeasible to attack the entire system.
• Simple and effective design: LayerZero maintains a minimalistic approach, avoiding the addition of unnecessary complexity. The security of LayerZero relies on the underlying chains where its Endpoints reside, ensuring a straightforward and effective design.
• Risk sharding: User applications have the flexibility to choose different combinations of Oracle and Relayer, distributing the risk across multiple independent entities. This sharding mechanism mitigates the potential for collusion or bribery attempts.
• Risk shielding: Users can run their own relayers, eliminating the need to rely on external entities. This approach allows users to trustlessly depend on LayerZero by ensuring their own relayer is independent while also trusting the Oracle’s independence.
• Pre-Crime: LayerZero introduces a unique feature that allows relayers to prevent potential hacks before they occur. By forking the destination blockchain and running a transaction locally, relayers can verify if any malicious actions, as defined by each user application, have taken place. This adds an extra layer of security on top of audits and bug bounties for decentralized applications (dApps).
• Audits: LayerZero has undergone extensive formal audits conducted by reputable firms such as Quantstamp, Zokyo, Zellic, and Trail of Bits. These audits provide thorough security assessments and help identify and address potential vulnerabilities. Additionally, LayerZero hosts a substantial $15 million bug bounty program through ImmuneFi, actively encouraging security researchers to identify and report any vulnerabilities.

Audits

LayerZero has commissioned more than 35 audits, some of the recent ones include:

• 2023
  • LayerZero Audit 1.0 – October 22nd, 2021 – Zokyo
  • High 1 – 1 Resolved
  • Medium 5 – 3 Resolved, 2 Not valid
  • Low 3 – 3 Resolved
  • Informational 4 – 2 Resolved, 2 Not valid
  • LayerZero NativeOFTV2 Audit – June 16th, 2023 – Zellic
  • During their assessment of the scoped NativeOFTV2 contracts, no findings were discovered.
  • LayerZero Solidity Examples Audit – April 27th, 2023 – OtterSec
  • Informational 7
  • LayerZero Omnichain Governance Executor Audit – March 30th, 2023 – Paladin
  • Medium 1 – 1 Resolved
  • Low 3 – 3 Resolved
  • Informational 8 – 7 Resolved, 1 Acknowledged
  • LayerZero Solidity Examples Audit – March 21st, 2023 – Ottersec
  • Informational 5
  • LayerZero Omnichain Governance Executor Audit – March 20th, 2023 – Zellic
  • During their assessment of the scoped Omnichain governance Executor contracts, no security vulnerabilities were discovered.
  • LayerZero AASTG Claim Audit – March 8th, 2023 – Paladin
  • High 1 – 1 Resolved
  • Low 5 – 2 Acknowledged
  • Informational 4 – 4 Acknowledged
  • LayerZero sveSTG Audit – March 7th 2023 – Paladin
  • Medium 2 – 2 Resolved
  • Low 1 – 1 Acknowledged
  • Informational 2 – 2 Resolved
  • LayerZero Wrapped Asset Bridge Audit – February 28th, 2023 – Zellic
  • Medium 1
  • Low 1
  • LayerZero Solidity Examples Audit – January 24th, 2023 – Ottersec
  • Informational 2
  • LayerZero OFT Wrapper Audit – January 19th, 2023 – Zellic
  • Low 1 – 1 Resolved

Bug Bounty

LayerZero has a bug bounty program with Immunefi.

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps, smart contracts, and blockchains/DLTs, focusing on the impact of the vulnerability reported.

Bounties include:

• Critical
  • Group 1 – $250K to $15M
  • Group 2 – $25K tp $1.5M
• High
  • Group 1 – $25K to $250K
  • Group 2 – $10K to $25K
• Medium
  • Group 1 – $10K to $2K
  • Group 2 – $5K to $10K
• Low
  • Group 1 – $1K to $10K
  • Group 2 – $1K to $5K

Trust Assumptions

• Progressive decentralization: As the LayerZero network grows, the number of relayers is expected to increase, leading to a more decentralized messaging system. This progressive decentralization enhances the security and resilience of the network by distributing trust across multiple independent entities.
• Dependence on Relayer and Oracle: Users of LayerZero rely on the security and integrity of the Relayer and Oracle entities to facilitate the passage of messages between chains. The correct functioning and trustworthiness of these external parties are crucial for the secure operation of LayerZero.
• Operational risks: LayerZero’s functionality depends on the participation and performance of oracles and relayers, which introduces operational risks beyond the control of the LayerZero protocol itself. Factors such as availability, reliability, and security practices of these external entities can impact the overall performance and security of LayerZero.
• Reliance on chains’ security: LayerZero does not introduce an intermediary layer for cross-chain transactions but relies on the underlying chains’ security. If a chain where an Endpoint is located is subjected to a 51% attack or other security compromises, it may have implications for the operation of LayerZero. The protocol’s ability to handle such events is contingent on the robustness of the underlying chain’s security measures.

Best Practices

It is highly recommended that User Applications implement the ILayerZeroApplicationConfig interface. This will provide them with the forseResumeReceive function, which, in the worst case, can allow the owner/multi-sig to unblock the queue of messages if something unexpected happens.

Instant Finality Guarantee (IFG)

Reverting at the application level can be cumbersome and expensive. Instead, it is more efficient to design User Applications with Instant Finality Guaranteed such that if a transaction is accepted at the source, the transaction will be accepted at the remote. For example, Stargate achieves this with the Delta Algorithm, which is a credit management system that guarantees that if a swap is accepted at the source, then the destination must have enough assets to complete the swap.

Tracking the Nonce

User Applications should keep track of their own nonce by emitting events in order to correlate the send and receive transactions.

One Action Per Message

Developers are encouraged to do only one thing per message. The reason for that is because if the message was burned (misconfiguration, bad code…) the damage that is caused to the state will be minimal.

Store Failed Messages

If the message execution fails at the destination, it is a good practice to store it for a future retry. This is because, from LayerZero’s perspective, the message has been delivered. Therefore, it is much cheaper and easier for the program to recover from the last state at the destination chain.

It is also recommended to store a hash of the message payload instead of storing the whole message since this is much cheaper.

Gas for Message Types

If an application requires multiple message types to be sent across chains, User Applications should compute a rough gas estimate at the destination chain per each message type.

The reason for this is that the message might fail because of an out-of-gas exception at the destination if the application fails to instruct the relayer to put extra gas on contract execution.

Address Sanity Check

Address sizes should be checked according to the source chain (e.g. address size == 20 bytes on EMV chains) to prevent attack vectors from unauthenticated contract calls.

Message Encoding

Type-safe bytes codecs are recommended, limiting the use of custom codecs only when the user is comfortable with it and the application requires deep optimization.

LayerZero Integration Checklist

The checklist below is intended to help prepare a project that integrates LayerZero for an external audit or Mainnet deployment.

• Use the latest version of the solidity-examples package. Do not copy contracts from LayerZero repositories directly to your project.
• If your project requires token bridging, inherit your token from OFT or ONFT. For new tokens use OFT or ONFT, for bridging existing tokens use ProxyOFT or ProxyONFT.
• For bridging only between EVM chains use OFT and for bridging between EVM and non-EVM chains (e.g., Aptos) use OFTV2.
• Do not hardcode LayerZero chain Ids. Use admin-restricted setters instead.
• Do not hardcode address zero (address(0)) as zroPaymentAddress when estimating fees and sending messages. Pass it as a parameter instead.
• Do not hardcode useZero to false when estimating fees and sending messages. Pass it as a parameter instead.
• Do not hardcode zero bytes (bytes(0)) as adapterParamers. Pass them as a parameter instead.
• Make sure to test the amount of gas required for the execution at the destination. Use custom adapter parameters and specify minimum destination gas for each cross-chain path when the default amount of gas (200,000) is not enough. This requires whoever calls the send function to provide the adapter params with a destination gas >= amount set in the minDstGasLookup for that chain. So that your users don’t run into failed messages on the destination. It makes it a smoother end-to-end experience for all.
• Do not add required statements that repeat existing checks in the parent contracts. For example, lzReceive function in LzApp contract checks that the message sender is a LayerZero endpoint and the scrAddress is a trusted remote, do not perform the same checks in nonblockingLzReceive.
• If your contract derives from LzApp, do not call lzEndpoint.send directly, use _lzSend.
• For ONFTs that allow minting a range of tokens on each chain, make the variables that specify the range (e.g. startMintId and endMintId) immutable.

Team

LayerZero Lab’s LinkedIn indicates that there are 65 employees.

Some of the members include:

• Bryan Pellegrino, CEO and Co-Founder
  • Computer Science at the University of New Hampshire.
  • Currently also an Entrepreneur In Residence at Rho AI.
• Ryan Zarick, Co-Founder and CTO
  • Master of Science, Computer Science at the University of New Hampshire.
  • Previous experience as Co-Founder of Minimal AI and Coder Den.
• Richard Dietrich, Head of Talent
  • Bachelor of Science, Business Administration, at the University of the Pacific.
  • Previous experience as Recruiting Manager at Uber, Talent Acquisition at Chartboost.
• Irene Wu, Head of Strategy
  • Joint Concentration, Computer Science at Harvard University.
  • Currently also an Angel Investor.
  • Previous experience as an Investor at Insight Partners.
• Angus Buttar, Community Manager
  • Bachelor of Arts, Biological Natural Sciences at the University of Cambridge.
  • Previous experience as Life Sciences Associate at L.E.K Consulting.
• Carmen Cheng, Software Engineer
  • Master of Science, Big Data Technology at The Hong Kong University of Science and Technology.
  • Previous experience as Founder at Wolo Technology Limited, and Software Engineer at AQUMON.
• Austin C., BD, and Market Research
  • Bachelor of Science, Finance and Economics at NYU Stern School of Business.
  • Previous experience as Principal Investments at TPS Capital.

Project Investors

LazerZero had the following fundraises:

• Seed Round
  • Raised $2M in April 2021.
  • Participants unknown.
• Series A Round
  • Raised $6M in September 2021.
  • Co-led by Binance Labs and Multicoin Capital.
  • Participants include Sino Global Capital, Defiance, Delphi Digital, Robot Ventures, Spartan, Hypersphere Ventures, Protocol Ventures, Gen Block Capital, and Echelon Capital.
• Series A+ Round
  • Raised $135M in March 2022.
  • Co-led by Sequoia Capital, Andreessen Horowitz, and FTX Ventures.
• Series B Round
  • Raised $120M in April 2023.
  • Participants include Christie, Samsung, OpenSea, Circle Ventures, A16z, and others.

Additional Information

Glossary

This glossary defines and explains many LayerZero concepts and terminology.

• User Application (UA)
  • A User Application (UA) is any contract that uses LayerZero to  &  messages between blockchains. We define UA as a tuple (chainId, contractAddress)
  • the UA that send() the message at the source chain as srcU (srcChain, srcAddress)
  • the UA that lzReceive() at the destination chain as dstUA (dstChain, dstAddress)
  • In LayerZero’s perspective, srcUA and dstUA are different, though they might be the same entity.
• Ultra-Light Node (ULN)
  • ULN is a messaging protocol, first introduced in the LayerZero white paper, that allows lightweight cross-chain messaging with configurable trustlessness on the specification of Oracle and Relayer, the two roles that are relaying block information and transaction proof across chains.
• Oracle
  • A contract address that can be notified to move a block header.
• What is a Relayer?
  • Any process that delivers a transaction proof in the LayerZero system.
• Messaging Library
  • The contract that handles the message payload packing on the source chain and verification on the destination chain. Ultra-Light Node is an implementation of the Messaging Library.
• Proof Library
  • The contract that verifies the validity of a proof. Merkle Patricia Tree inclusion proof is an implementation of Proof Library.

FAQ

• How do I send a cross-chain message?
  • See example contracts here and details on sending messages here.
• What is a User Application?
  • A User Application (UA) is any contract that uses LayerZero to send & receive messages between blockchains.
• What is an Endpoint?
  • The deployed contract on which your User Application calls send() to transmit messages and set its own UA configuration. Here is the list of endpoint addresses with which you may interact with.
• What is an Ultra Light Node?
  • The UltraLightNode.sol is a smart contract at the heart of the message protocol, sitting behind the Endpoint, it enables all the features of LayerZero. In the future, UAs will benefit from new versions of the Ultra Light Node, the most recent version of the ULN is v2.
• What is an Oracle?
  • An Oracle is required by each User Application and assists in sending messages. User Applications use the default Oracle automatically so you don’t need to configure it, but you can if you want to.
• What is a Relayer?
  • User Applications use the LayerZero Relayer by default, without additional configuration. However, a Relayer is required by each User Application and plays a crucial role in delivering cross-chain messages. If desirable, User Applications may be configured to use a different relayer.

Community Links

• Website
• Documentation
• Medium
• LinkedIn
• Discord
• Telegram
• YouTube