LayerZero White Paper: Trustless Cross-Chain Interoperability Protocol

Original Title: "LayerZero: Trustless Omnichain Interoperability Protocol"

Original Authors: Ryan Zarick, Bryan Pellegrino, Caleb Banister

Compiled by: 0xMeta

Abstract

The widespread use of blockchain has provided developers with various platforms to run their smart contracts based on application functionality, throughput demands, security, and cost requirements. However, this freedom has resulted in severe fragmentation. Each chain is isolated, forcing users to isolate their liquidity and limiting options for moving liquidity and state between walled ecosystems.

This paper introduces the first trustless omnichain interoperability protocol, LayerZero, which provides a powerful communication primitive as a foundational layer upon which a diverse set of cross-chain applications can be built. Using this new primitive, developers can create seamless cross-chain applications, such as cross-chain DEXs or multi-chain yield aggregators, without relying on trusted custodians or intermediary transactions.

In short, LayerZero is the first trustless system to enable direct transactions across all chains. It allows transactions to flow freely between chains, providing users with the opportunity to consolidate decentralized liquidity while fully leveraging applications on individual chains. Through LayerZero, we provide the foundational network infrastructure for a future omnichain ecosystem.

1. Introduction

The three core pillars of the blockchain concept are decentralization, transparency, and immutability. No single entity controls the blockchain, and actions on the blockchain are verifiable and irreversible. These pillars create a foundation upon which an entity can act without trusting any other entity. This trust guarantee is one of the reasons why cryptocurrencies are more appealing than fiat currencies.

Figure 1: LayerZero enables cross-chain transactions

If all users and all applications coexisted on a unified blockchain, this paper would be meaningless. (Figure 1: LayerZero enables cross-chain transactions) However, the practicality of blockchains has led to a surge in diverse applications, each with unique complexities and demands. The need for multiple functionalities has abandoned the growth of specialized chains.

Each of these chains has facilitated tremendous growth of applications within its own ecosystem, but the isolation between these ecosystems has become a key limitation to adoption. Users and developers are forced to allocate time, resources, and liquidity across different chains. A natural consequence of the sheer number of layer 1 blockchains (up to 109 at the time of writing this paper[1]) is the need to extend the aforementioned three pillars to simultaneously encompass interactions across multiple chains. An example of the demand for inter-chain interaction is the transfer of tokens, which we will discuss later in this section.

In blockchain terminology, a unit of work is a transaction, which is immutable and irreversible. Transactions, organized into blocks, form the secure foundation of the blockchain system. However, transactions are always a single-chain concept; as described below, cross-chain interactions traditionally require third-party mechanisms outside of the normal blockchain cryptographic systems. In contrast, this paper describes the first messaging protocol that enables native cross-chain transactions: LayerZero.

To illustrate the powerful communication primitive provided by LayerZero, let’s consider the example of transferring tokens from one chain to another. Currently, to convert tokens between two chains, users must either use a centralized exchange or a cross-chain decentralized exchange (DEX) (also known as a cross-chain bridge), both of which require compromises. In the case of centralized exchanges, such as Binance.com[3], users must trust the exchange to track deposits and withdrawals of funds. This trust relationship is fundamentally at odds with the trustless nature of blockchain consensus and lacks the security of on-chain automated systems.

Using DEXs, such as AnySwap[2] or THOR-Chain[23], alleviates trust issues by transferring tokens on-chain, but existing DEX implementations involve converting user tokens into protocol-specific tokens, which achieve transaction consensus through an intermediary consensus layer. This intermediary consensus layer, while often implemented securely, does require users to trust a side chain to facilitate token transfers. As we demonstrate in this paper, this additional overhead is unnecessary. Despite high user demand, no solution exists that is both efficient and direct while still retaining the core reason we use blockchains: trustlessness. Stepping back, LayerZero’s direct cross-chain transactions provide developers with the tools to build such transactions.

It is important to note that LayerZero and the swap operations described above exist at two different levels of the implementation stack. LayerZero is a communication primitive that supports different omnichain applications, while a swap is an example of an application that would benefit from a reimplementation on top of LayerZero. Section 2 outlines the prospects of blockchain technology and further explores the example of swaps.

To properly explain LayerZero's capabilities and its role in the blockchain ecosystem, we first present the basic communication primitives required for formal cross-chain transactions, which we call valid delivery (Section 3). We then describe how LayerZero provides this primitive in a trustless manner, thereby maintaining the security guarantees of blockchains. LayerZero is the first trustless omnichain interoperability layer that supports direct messaging between layer 1 and layer 2 chains (Figure 1).

Figure 2: LayerZero ensures the validity of cross-chain communication by requiring two independent entities (Oracle and Relayer) to confirm the transaction.

A cross-chain transaction between Chain A and Chain B consists of a transaction tA on A, a communication protocol between A and B, and a message m. Valid delivery considers m delivered if and only if tA has been submitted and is valid. The key idea underpinning LayerZero is that if two independent entities confirm the validity of a transaction (in this case, tA), then Chain B can ascertain that tA is valid. Figure 2 illustrates this at a high level.

Assuming the two entities do not collude, if (1) one entity can generate a block header for the block containing tA on Chain A, (2) the other entity can independently generate a proof of tA on that block (transaction proof), and (3) the block header and transaction proof are indeed consistent, then the communication protocol can deliver m to the client on Chain B, ensuring that tA is stably submitted on Chain A. The LayerZero communication protocol described in Section 4 guarantees that transactions on the recipient chain will be paired with valid, submitted transactions on the sender chain, without involving any intermediary chains. We achieve this by combining two independent entities: an Oracle[7] that provides the block header and a Relayer that provides the proof associated with the aforementioned transaction.

The interface of LayerZero is a lightweight chain client, which we call a LayerZero endpoint. There exists a LayerZero endpoint on every (supported) chain, and any chain with a LayerZero endpoint can engage in cross-chain transactions involving any other chain with a LayerZero endpoint. Essentially, this creates a fully connected network where each node can directly connect to any other node. With a small amount of boilerplate code, any blockchain is supported. Section 5 demonstrates this process through a case study that examines how to implement LayerZero on the Ethereum blockchain.

The ability to conduct cross-chain transactions directly with any other chain on the network opens up opportunities for a previously unfeasible class of large-scale applications, such as cross-chain decentralized exchanges, multi-chain yield aggregators, and cross-chain lending. Section 6 explores several such applications in detail. Through LayerZero, users can freely move liquidity between chains, allowing a single liquidity pool to participate in multiple decentralized (DeFi) applications spanning different chains and ecosystems without relying on third-party systems or intermediary tokens.

2. Background

To lay the groundwork for LayerZero, we review relevant existing systems to illustrate why they fail to meet the needs of emerging applications. The discussion ultimately delves into the advantages of building cross-chain exchanges on top of LayerZero.

2.1 Related Work

This section builds an understanding of the key players in the cross-chain interaction space, why they fall short of achieving trustless valid delivery, and how LayerZero bridges the gap.

Ethereum[8] is the most popular platform for decentralized finance applications built through smart contracts. Ethereum extends its underlying blockchain with a Turing-complete programming language that enables a library of decentralized applications to leverage the underlying chain's powerful security properties through developer-friendly abstractions. However, the low transaction rate of the underlying blockchain (approximately 15-45 transactions per second) has proven to be a significant scalability bottleneck, limiting the popularity of applications built to run directly on the Ethereum blockchain.

Due to its programming model and popularity, many cross-chain communication technologies revolve around third-party chains interfacing with Ethereum. LayerZero provides the ability to transfer state directly to and from Ethereum without the need for intermediaries, allowing users and applications to leverage the stability and trustworthiness of the Ethereum chain without facing the costs and bottlenecks of the solutions described below.

Ethereum 2.0[22] is a set of upgrades aimed at enhancing Ethereum's scalability, security, and sustainability. Ethereum 2.0 introduces sharded chains that distribute the load instead of concentrating all transactions on the overloaded Ethereum main chain. The transition from proof of work (PoW) to proof of stake (PoS) eliminates the possibility of a 51% attack and reduces the energy required per transaction. These advancements largely align with the development of LayerZero and are sure to promote Ethereum's popularity, creating more demand for convenient and inexpensive cross-chain communication.

Polygon[17], formerly known as the Matic Network, is a layer 2 network that addresses Ethereum's throughput and sovereignty challenges. Despite being the most popular platform for blockchain development, Ethereum suffers from low throughput[10], making it unsuitable for certain applications. Polygon provides application-specific, Ethereum-compatible sidechains that combine the scalability and independence of independent chains with Ethereum's community and security. Specialized or throughput-intensive applications run on sidechains and are periodically integrated back into the main Ethereum chain. In contrast, LayerZero is a foundational platform that enables direct cross-chain communication, facilitating transfers back to the main Ethereum chain without the need for complex Polygon protocols.

Polkadot[26] is an early example of an open cross-chain ecosystem. In Polkadot, many domain-specific parallel chains ("parachains") are connected through a common relay chain that allows tokens and data to flow between them. However, cross-chain communication always traverses this relay chain, incurring additional costs. LayerZero provides the same underlying communication platform as Polkadot without the additional transactions required by on-chain intermediaries.

THORChain[23] is a DEX that uses paired liquidity pools to transfer tokens between third-party chains. Each liquidity pool binds a specific third-party currency with a native token called RUNE, which serves as a common exchange medium. Without this common medium, every paired currency would require a liquidity pool, meaning the number of liquidity pools would increase quadratically with the number of currencies. Unfortunately, while RUNE addresses this scalability issue, the lengthy overhead in the transaction process makes a simple operation quite complex. This is evident in the complexity of THORChain's trading algorithms. LayerZero provides direct cross-chain communication without the inherent scalability bottlenecks, cumbersome intermediary currencies, or heavyweight protocols of THORChain.

AnySwap[2] is a DEX similar to THORChain, focused on simple paired token swaps. AnySwap relies on an intermediary token, ANY, based on Fusion's distributed control rights management. Like THORChain, using the ANY intermediary token incurs unnecessary overhead, delays, and additional transfer fees.

Cosmos[5] is a blockchain network technology that allows arbitrary messages to be sent between supported chains. Cosmos includes a blockchain cross-chain communication (IBC[14]) protocol built on Tendermint BFT[21] to facilitate messaging between chains built on the Cosmos Hub. Cosmos differs from LayerZero in two key aspects: (1) IBC runs a complete light node on-chain, and (2) IBC only provides direct communication between chains with fast finality[24].

These limitations of IBC, combined with the use of intermediary chains to facilitate consensus, make it similar to Anyswap, THORChain, or Polkadot, rather than a universal communication layer like LayerZero. Cosmos also provides a DEX with similar properties to Anyswap or THORChain, called Gravity Bridge[12]. Compared to Cosmos and IBC, LayerZero offers trustless omnichain messaging and can scale to any chain, including those providing probabilistic finality, such as Ethereum and Bitcoin.

Figure 3. LayerZero is the building block for cross-chain applications. This graphic illustrates the architectural differences between centralized exchanges, decentralized exchanges, and cross-chain bridges built using LayerZero as the underlying communication primitive.

Chainlink[7,4] is a framework for building and connecting to a decentralized oracle network (DONs). While smart contracts are tamper-proof, their on-chain nature hinders access to essential connections critical for their broader application: smart contracts cannot obtain off-chain data necessary for executing contracts, such as stock prices, IoT device measurements, and outputs of secure off-chain computations. DONs extend the tamper-proof properties of smart contracts to the data sources and external resources upon which contracts depend, without trusting any central entity. In a DON, a user's smart contract issues an on-chain request to a Chainlink interface smart contract, which sends events to many independent oracle nodes.

Each oracle node queries multiple data sources to obtain the requested information, aggregates the data to filter out erroneous or malicious sources, and performs optional trust-minimized computations on the data. The oracle nodes respond to the Chainlink interface smart contract, which executes a second-level aggregation to filter out erroneous or malicious oracles. This dual-layer filtering guarantees trust in the final data without needing to trust any single oracle or data source. Thus, Chainlink provides a powerful information retrieval network and a secure off-chain computation solution that has been widely adopted in the industry. By leveraging the Chainlink DON framework, the LayerZero protocol gains the ability to ensure trustless messaging between different chains.

2.2 Practical Applications of LayerZero

Developers can use LayerZero to build complex cross-chain applications without sacrificing trustlessness or introducing complex intermediary chains/smart contracts. Figure 3 illustrates the capabilities of LayerZero when building exchanges.

A centralized exchange, as shown on the left, requires users to deposit their tokens with a central trusted third party, which then tracks deposits off-chain and grants coins on other chains based on user requests. Trusting this authority contradicts the very reason we use blockchains, which has led to the emergence of decentralized exchanges.

The center graphic illustrates how a typical decentralized exchange operates at a high level—by using a consensus protocol managed by a smart contract to facilitate the automatic minting of coins on Chain B, DEXs can overcome the necessity of centralized, trusted off-chain intermediaries.

However, a key limitation is that DEXs involve an intermediary token and intermediary chains, and only mint an intermediary token or wrapped token on Chain B, rather than the actual token the user desires. The user must then exchange the intermediary token (e.g., RUNE) or wrapped token (e.g., ANY) for the desired token in an additional transaction. This intermediary/wrapped token, the second transaction, and the intermediary chain are all unnecessary overhead for an ideal single seamless transaction.

The right side of Figure 3 shows what an exchange built on LayerZero looks like, where Chain A can initiate a single cross-chain transaction that facilitates a native transaction on Chain B and notifies applications on Chain B that they can safely grant tokens to the user. In this application, LayerZero achieves a clean, minimal, single-transaction swap without any intermediary tokens. The actual swap protocol is handled by smart contracts on both ends of the cross-chain transaction, with LayerZero passing messages between the two. This provides significant flexibility and adheres to the end-to-end principle[18], where most advanced swap logic is handled by smart contracts on the source and destination chains.

3. Valid Delivery

In this section, we describe the fundamental characteristics of trustless cross-chain communication. To formally describe the problem of verifying transactions across different chains, we define the concept of valid delivery. Valid delivery is a communication primitive that enables cross-chain token transfers by providing the following guarantees:

1. Every message m sent over the network is coupled with a transaction t on the sending chain.

2. The message m is delivered to the recipient only when the associated transaction t is valid and has been submitted on the sending chain.

Centralized exchanges guarantee valid delivery because the agreement between the customer and the exchange is that the customer will transfer their tokens from one chain to the exchange, and the exchange will issue some balance (non-cryptocurrency) upon receiving the tokens. This non-cryptocurrency balance can then be withdrawn from any available chain, a convenience made possible by the exchange maintaining extensive liquidity pools on each supported chain. The exchange acts as an intermediary in the transaction, and users must trust that they can maintain their transactions. However, malicious or compromised exchanges can take tokens from clients, issue balances, and then refuse to allow withdrawals from another chain, effectively stealing tokens from users.

Even if users are willing to trust cryptocurrency exchanges, there have been many successful hacks or attempts to compromise cryptocurrency exchanges in recent years[15], making it better to provide users with a solution that does not require any trusted intermediaries. At a higher level, one of the core functions of cryptocurrencies is that they are independent of central entities like banks, so relying on a central exchange contradicts their purpose.

An alternative to using centralized exchanges is decentralized exchanges, such as THORChain[23] or AnySwap[2]. All existing DEXs use an intermediary token, such as RUNE in THORChain or ANY in AnySwap, as transaction t. Because these intermediary tokens are controlled by the respective protocols of each DEX, DEXs can guarantee valid delivery since malicious users cannot forge intermediary tokens.

Existing DEX solutions are not ideal because they involve two intermediary transactions—one to convert the sender's tokens into the intermediary token and another to convert the intermediary token into the "real" token desired on the receiving chain. In addition, users must fully trust the intermediary consensus layer that confirms the transaction on the source chain and communicates the creation of tokens on the destination chain. While existing swaps can indeed achieve cross-chain token transfers, their cost comes with unnecessary complexity and expense. The drawbacks of this approach are evident, as cross-chain applications have not yet been widely adopted. The ideal solution to the cross-chain transaction problem is to use a single swap transaction across chains without involving any trusted intermediaries— in other words, trustless valid delivery.

In our work, we implement a universal messaging protocol that provides trustless valid delivery of arbitrary user data, not just tokens. Distributed exchanges or other DeFi applications will use our messaging primitive to achieve cross-chain transactions, and the flexibility provided by the underlying layer messaging protocol enables advanced applications to achieve broad functionality that was previously impossible.

4. Design

At the core of LayerZero is a communication protocol that provides trustless valid delivery. Our protocol is built upon a series of components introduced in Section 4.1. We discuss the communication flow of the delivery protocol in Section 4.2, describe how LayerZero achieves valid delivery without involving trusted intermediary services in Section 4.3, and introduce our new lightweight client design based on low-cost smart contracts in Section 4.4.

4.1 Components of LayerZero

LayerZero Endpoints are the user-facing interface of LayerZero. Each chain in the LayerZero network has a LayerZero endpoint, implemented as a series of smart contracts on-chain. The purpose of the endpoint is to allow users to send messages using the LayerZero protocol backend, ensuring valid delivery.

LayerZero endpoints are divided into four modules: Communicator, Validator, Network, and Libraries. The Communicator, Validator, and Network modules comprise the core functionality of the endpoint (Figure 4), while each new chain supported by LayerZero is added as an additional library. This design allows us to add support for new chains without modifying the three core modules. We explain the functionality of each module in Section 4.4.

Oracles are third-party services that provide a mechanism independent of other LayerZero components to read block headers from one chain and send them to another. In theory, this oracle can be any third-party service providing this mechanism, but in practice, we aim to use Chainlink[7,4], which is currently the industry leader in decentralized oracle networks.

Figure 4: Communication flow in a single LayerZero cross-chain transaction.

Relayers are off-chain services that function similarly to oracles, but instead of obtaining block headers, they obtain proofs of specified transactions.

To ensure valid delivery, the only requirement is that for any given message sent using the LayerZero protocol, the oracle and relayer must be independent of each other. The protocol itself does not require any specific relayer implementation; in theory, users of LayerZero can even implement their own relayer services. This design allows users to ensure that the relayer does not collude with the oracle, and this independence allows us to achieve trustless valid delivery, as shown in Section 4.3. In practice, LayerZero provides the relaying service, while the oracle is handled by Chainlink's decentralized oracle network and associated consensus mechanisms.

4.2 LayerZero Protocol

Figure 4 illustrates the steps involved in the valid delivery of a single LayerZero message. Each circled number in the figure represents a step in the protocol and corresponds to a paragraph in this section. This section presents an example of how a user application on Chain A sends a single message to a user application on Chain B via LayerZero. In Section 5, we describe how various components and protocol steps are implemented in the case of sending messages between two Ethereum virtual machines.

Step 1: A user application on Chain A (App A) can perform a series of operations as part of transaction T. We uniquely identify transaction T by the transaction identifier t, which may vary in format depending on the type of Chain A. One of the steps included in transaction T is to transmit a message via LayerZero, with valid delivery conditioned on T. For illustrative purposes, and without loss of generality, we assume that this hypothetical application A (App A) is using our reference relayer. App A sends a request to the LayerZero Communicator containing the following information:

t: The unique transaction identifier for T.

dst: The global identifier pointing to the smart contract on Chain B.

payload: Any data that App A wishes to send to App B.

relayer_args: Arguments describing payment information in case App A wishes to reference the relayer.

Step 2: The Communicator constructs a LayerZero packet containing dst and payload, referred to as Packet(dst, payload), and sends it along with t and relayer_args to the Validator.

Step 3: The Validator sends t and dst to the Network. This step notifies the Network that the block header for the current block on Chain A needs to be sent to Chain B.

Step 4: The Validator forwards Packet(dst, payload), t, and relayer_args to the Relayer, notifying the Relayer that the proof for transaction T needs to be fetched and ultimately sent to Chain B. This occurs simultaneously with Step 3.

Step 5: The Network sends the current transaction's dst and block ID (curblkid) to the Oracle. This eliminates the need to modify the Oracle to fetch the current block header on Chain A and send it to Chain B. In cases where multiple LayerZero transactions occur within the same block, Step 5 is executed only 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. Steps 6 and 7 occur asynchronously with respect to each other.

Step 8: The Oracle confirms that the block corresponding to blkhdr has been stably submitted to Chain A and then sends blkhdr to the Network on Chain B. The mechanism for determining when this occurs varies by chain but typically requires waiting for a certain number of block confirmations.

Step 9: The Network sends the block hash, designated as blkhdrhash, to the Validator.

Step 10: The Validator forwards blkhdrhash to the Relayer.

Step 11: Upon receiving blkhdrhash, the Relayer sends a list of any Packet(dst, payload), t, proof(t) tuples that match the current block. In cases where multiple users send messages between the same endpoints simultaneously, there may be multiple packets and associated transaction proofs in the same block.

Step 12: The Validator uses the received transaction proofs along with the block header stored by the Network to verify whether the associated transaction t is valid and has been submitted. If the block header and transaction proof do not match, the message is discarded. If they do match, then Packet(dst, payload) is sent to the Communicator.

Step 13: The Communicator sends Packet(dst, payload) to App B.

4.3 Achieving Trustless Valid Delivery

Trustlessness: The core idea behind LayerZero's design is that users do not need to trust the components of LayerZero. Instead of requiring trust as a strong condition, we only need a weaker independence condition between the oracle and relayer. This requirement for independence rather than trust is one aspect that allows LayerZero to be efficient and lightweight. As long as there is no malicious collusion between the oracle and relayer, LayerZero can guarantee valid delivery.

Valid Delivery: Through the LayerZero protocol shown in Section 4.2, the Communicator delivers message m to the user application if and only if the transaction proof associated with t can be verified in Step 12. This verification step will succeed if and only if the block header and transaction proof match, which will only occur in the following two scenarios:

1. Both the block header provided by the oracle and the transaction proof provided by the relayer are valid.

2. Both the block header provided by the oracle and the transaction proof provided by the relayer are invalid, but still match.

Scenario 2 can only occur if the oracle and relayer collude, as statistically, it is impossible to send a transaction proof that can be verified against a block header without knowing the specific block header, and vice versa. However, the design of LayerZero eliminates the possibility of collusion, as described in Section 1. Therefore, if a message is sent to the receiving user application, it is guaranteed to satisfy the properties of valid delivery.

As outlined in Section 3, a communication protocol capable of guaranteeing trustless valid delivery (i.e., achieving valid delivery without trusting intermediary entities or tokens) is the ideal solution for implementing cross-chain transactions. LayerZero is the first and only system to demonstrate this property. This fact will drive user adoption of LayerZero as the preferred method for cross-chain communication.

4.4 LayerZero Endpoint Design

LayerZero endpoints are currently implemented as a series of smart contracts on each chain included in the LayerZero network. The core functionality of LayerZero endpoints is encapsulated in three modules: Communication, Validation, and Network. These modules operate similarly to a network stack, sending messages from the sender to the stack—from the Communicator to the Validator to the Network—and then sending messages up at the receiver.

In addition to the core modules, LayerZero endpoints can be extended through Libraries, which are auxiliary smart contracts that define how communication should be handled for specific chains. Each chain in the LayerZero network has a corresponding Library, and each endpoint contains a copy of each Library. This modular design allows the LayerZero network to quickly and conveniently scale to include new chains as needed. Furthermore, communication between two chains only requires that their respective Libraries exist on both ends, making LayerZero a fully connected network capable of coordinating transactions between any pair of nodes.

4.5 Cost Scalability of LayerZero Endpoints

As many readers may point out, running smart contracts on a layer 1 chain can be prohibitively expensive, especially as the amount of stored data increases. To make LayerZero endpoints practical, it is necessary to design the lightest possible client. Previous work on trustless cross-chain validation through cross-chain state machine replication (SMR), such as Golden Gate[11], runs on popular layer 1 chains (like Ethereum) and can cost millions of dollars per day.

Figure 5: LayerZero packet layout for EVM endpoints.

To address this issue, we set out to design the lightest possible client. Our main observation is that it is unnecessary to replicate and store block headers in the client. Instead, we delegate the task of obtaining the necessary cross-chain headers and transaction proofs to off-chain entities: oracles and relayers. This results in LayerZero nodes being very lightweight, making them cost-effective even on expensive[20] chains like Ethereum.

5. Case Study: LayerZero on EVMs

In this section, we briefly describe the details of implementing LayerZero support on Ethereum Virtual Machines (EVMs)[13]. For brevity, we focus on aspects of the system whose implementation may vary by chain and highlight how our implementation addresses the specific needs of the Ethereum chain. As mentioned in Section 4.1, the current version of LayerZero relies on Chainlink to provide oracle services and encourages users to utilize our relayer service.

LayerZero Packets: The format of LayerZero packets varies depending on the source and destination chains. We illustrate the precise layout of LayerZero packets for EVM endpoints[19] in Figure 5. The function of each field is as follows:

Transaction Finality on the Sending Chain: To ensure the stability of message transactions on the source chain, we rely on the inherent properties of the decentralized oracle network— the oracle will only notify the destination of a specific block header after hearing a certain number of block confirmations, which is 15 in the case of Ethereum. Specifically, the execution of Step 8 of the LayerZero protocol (Section 4.2) only occurs after the oracle hears 15 block confirmations on Chain A.

LayerZero Endpoints: We implement LayerZero endpoints as a series of smart contracts, composed of the four main modules described in Section 4.4. For most existing blockchains, including the Ethereum blockchain, we are able to implement the Communicator, Validator, and Network as separate smart contracts. However, this design does not preclude the implementation of LayerZero endpoints on (future) chains with different requirements.

In this case study, the Library component of LayerZero endpoints is key to supporting the Ethereum blockchain. We implemented a Library to handle the construction of EVM-specific LayerZero packets as shown in Figure 5, and to encode and decode Ethereum smart contract address information.

Another responsibility of the Library is to handle the actual computations involved in validating transaction proofs. Our EVM Library processes Merkle-Patricia Tree verification[16] for transactions on EVM blocks, based on the open-source implementation of Golden Gate[11].

6. Applications on LayerZero

Cross-Chain Decentralized Exchanges: As briefly described in Section 2.2, LayerZero enables cross-chain DEXs (cross-chain bridges) that specifically handle native assets. Unlike existing DEX designs that issue tokens or rely on intermediary sidechains, a DEX can be built using LayerZero to send messages between chains, allowing liquidity pools to exist on both chains, where users simply deposit their native assets in one pool and then withdraw native assets from another pool. The messaging primitives provided by LayerZero are powerful enough to support direct connections (1:1 pricing), automated market making (ab=k pricing), and any other derivatives (e.g., derivatives similar to Curve DAO pricing[25]). The guarantees of valid delivery provided by LayerZero make a wide range of decentralized exchange applications possible.

Multi-Chain Yield Aggregators: Current yield aggregators typically operate within the confines of a single-chain ecosystem, with projects like Yearn Finance[27] using single-chain strategies to enable yield aggregation. A key weakness of these single-chain yield aggregation systems is that they cannot leverage yield opportunities outside the current ecosystem, potentially missing many optimal yields. A yield aggregator using LayerZero for cross-chain transactions would allow for the exploitation of the best opportunities across all ecosystems, increasing the chances of obtaining high-yield opportunities and enabling users to take advantage of market inefficiencies. Strictly speaking, multi-chain yield aggregation mechanisms are superior to single-chain yield aggregation mechanisms, as in the worst case, the strategy would downgrade to only utilizing opportunities on a single chain, while in the best case, it would have more opportunities to choose from.

Multi-Chain Lending: Today, users have no simple way to take advantage of opportunities on chains where they do not hold assets. For example, suppose a user with assets consolidated in ETH wants to take advantage of opportunities on Polygon[17]. Their options are: (1) transfer the entire asset base to another chain and convert it to the desired currency, or (2) lend their assets on Ethereum, borrow the desired assets, and then connect that asset to the target chain. LayerZero enables a lending protocol that allows users to maintain their entire asset base on Ethereum, lend it out, and then directly borrow in MATIC on Polygon. This eliminates intermediary costs such as cross-chain bridge and swap fees.

These three examples represent just a small fraction of the many possibilities supported by LayerZero. By leveraging LayerZero, developers will be able to write their applications without worrying about the semantic differences between intra-chain and inter-chain transactions, and users will be able to freely move liquidity between chains. We look forward to the community developing creative new applications under the power of trustless cross-chain transactions.

7. Conclusion

This paper presents the design and implementation of LayerZero, the first trustless omnichain interoperability platform that does not involve any intermediary transactions. We demonstrate that by leveraging two independent, trustless off-chain entities— the oracle and the relayer— LayerZero can achieve valid delivery without the need for expensive cross-chain state machine replication or intermediary tokens. The design of our protocol does not preclude the use of arbitrary relaying services, ensuring that there is no collusion between the relayer and the oracle. The LayerZero protocol supports native transactions between chains, while the novel design of LayerZero endpoints can be easily extended to support any chain.

Moreover, our endpoint design is lightweight enough to run on expensive layer 1 chains like Ethereum without incurring high costs. We presented a case study on how to implement LayerZero support on EVM-based chains, utilizing the reference relayer to integrate Chainlink's decentralized oracle network, enabling cross-chain transactions through LayerZero.

LayerZero serves as the backbone connecting various non-intersecting blockchain ecosystems, allowing liquidity, data, and ideas to flow frictionlessly between chains and communities.

References:

[1] All layer 1 blockchain protocols. https://blockchain-comparison.com/blockchain-protocols/. Accessed: 2021-5-13.

[2] Anyswap dex user guide. https://anyswap-faq.readthedocs.io/en/Latest/index.html. Accessed: 2021-5-13.

[3] Binance.com. https://www.binance.com/. Accessed: 2021-5-14.

[4] BREIDENBACH, L., CACHIN, C., CHAN, B., COVENTRY, A., ELLIS, S., JUELS, A., KOUSHANFAR, F., MILLER, A., MAGAURAN, B., MOROZ, D., NAZAROV, S., TOPLICEANU, A., TRAMER, F., AND ZHANG, F. Chainlink 2.0: Next steps in the evolution of decentralized oracle networks. White paper, ChainLink, 2021.

[5] What is cosmos? https://v1.cosmos.network/intro. Accessed: 2021-5-15.

[6] Dcrm - fusion.org. https://www.fusion.org/tech/dcrm. Accessed: 2021-5-13.

[7] ELLIS, S., JUELS, A., AND NAZAROV, S. Chainlink: A decentralized oracle network. White paper, ChainLink, 2017.

[8] Ethereum. https://ethereum.org/en/. Accessed: 2021-5-13.

[9] Ethereum 2.0 (eth2) vision. https://ethereum.org/en/eth2/vision/. Accessed: 2021-5-13.

[10] GALAL, H. S., ELSHEIKH, M., AND YOUSSEF, A. M. An efficient micropayment channel on ethereum. In Data Privacy Management, Cryptocurrencies and Blockchain Technology. Springer, 2019, pp. 211--218.

[11] Golden gate -- trustless-bridging ethereum (evm) blockchains -- part 1: Basics. https://loredanacirstea.medium.com/golden-gate-trustless-bridging-ethereum-evm-blockchains-part-1-basics-d016300ea0dd. Accessed: 2021-5-14.

[12] Announcing the gravity bridge. https://blog.althea.net/gravity-bridge/. Accessed: 2021-5-15.

[13] HILDENBRANDT, E., SAXENA, M., RODRIGUES, N., ZHU, X., DAIAN, P., GUTH, D., MOORE, B., PARK, D., ZHANG, Y., STEFANESCU, A., ET AL. Kevm: A complete formal semantics of the ethereum virtual machine. In 2018 IEEE 31st Computer Security Foundations Symposium (CSF) (2018), IEEE, pp. 204--217.

[14] Ibc overview --- cosmos sdk. https://docs.cosmos.network/master/ibc/overview.html. Accessed: 2021-5-15.

[15] LAZARENKO, A., AND AVDOSHIN, S. Financial risks of the blockchain industry: A survey of cyberattacks. In Proceedings of the Future Technologies Conference (2018), Springer, pp. 368--384.

[16] LU, Z., WANG, Q., QU, G., ZHANG, H., AND LIU, Z. A blockchain-based privacy-preserving authentication scheme for vanets. IEEE Transactions on Very Large Scale Integration (VLSI) Systems 27, 12 (2019), 2792--2801.

[17] Polygon: Ethereum's internet of blockchains. https://polygon.technology/lightpaper-polygon.pdf.

[18] SALTZER, J. H., REED, D. P., AND CLARK, D. D. End-to-end arguments in system design. ACM Transactions on Computer Systems (TOCS) 2, 4 (1984), 277--288.

[19] Solidity types. https://docs.soliditylang.org/en/v0.5.3/types.html. Accessed: 2021-5-14.

[20] SPAIN, M., FOLEY, S., AND GRAMOLI, V. The Impact of Ethereum Throughput and Fees on Transaction Latency During ICOs. In International Conference on Blockchain Economics, Security and Protocols (Tokenomics 2019) (Dagstuhl, Germany, 2020), V. Danos, M. Herlihy, M. Potop-Butucaru, J. Prat, and S. Tucci-Piergiovanni, Eds., vol. 71 of OpenAccess Series in Informatics (OASIcs), Schloss Dagstuhl--Leibniz-Zentrum fuer Informatik, pp. 9:1--9:15.

[21] Tendermint. https://tendermint.com/. Accessed: 2021-5-15.

[22] The eth2 upgrades. https://ethereum.org/en/eth2/. Accessed: 2021-5-13.

[23] Thorchain. https://thorchain.org. Accessed: 2021-5-13.

[24] VIRIYASITAVAT, W., DA XU, L., BI, Z., AND SAPSOMBOON, A. New blockchain-based architecture for service interoperations in internet of things. IEEE Transactions on Computational Social Systems 6, 4 (2019), 739--748.

[25] WARREN, W., AND BANDEALI, A. 0x: An open protocol for decentralized exchange on the ethereum blockchain. URL: https://github.com/0xProject/whitepaper (2017), 04--18.

[26] WOOD, G. Polkadot: Vision for a heterogeneous multi-chain framework. White paper, Polkadot, 2016.

[27] yearn.finance. https://yearn.finance/. Accessed: 2021-5-14.