LayerZero: Trustless inter-chain transactions
Ryan Zarick

Bryan Pellegrino

Abstract

Layer 2

Scalable transactions on a single
Layer 1 chain

Layer 1

Core of cryptocurrency markets,
maintain distributed ledgers

LayerZero

Provides native, direct communication
between any other chains

Lightning Network, Raiden Network, Polygon, etc.

The proliferation of blockchains has given developers avariety of platforms on which to run their smart contracts based on application features and requirements forthroughput, security, and cost. However, a consequenceof this freedom is severe fragmentation; Each chain isisolated, forcing users to silo their liquidity and limiting options to move liquidity and state between walledecosystems.
This paper presents LayerZero, the first trustless interchain communication protocol, which provides a powerful, low level communication primitive upon which adiverse set of cross-chain applications can be built. Using this new primitive, developers can implement seamless inter-chain applications like a cross-chain DEX or
multi-chain yield aggregator without having to rely on
a trusted custodian or intermediate transactions. Simply
put, LayerZero is the first system to trustlessly enabledirect transactions across two chains. Allowing transactions to flow freely between chains provides opportunities for users to consolidate fragmented pockets of liquidity while also making full use of applications on separate
chains. With LayerZero, we provide the network fabricunderlying the fully-connected multi-chain ecosystem of
the future.

1

Caleb Banister

Bitcoin, Ethereum, Stellar, Dogecoin, etc.

Figure 1: LayerZero enables cross-chain transactions.

If all users and all applications coexisted in one unified
blockchain, then this paper would conclude here. However, the utility of the blockchain has led to a proliferation of diverse applications, with unique intricacies andrequirements. The demand for a diverse set of functionalities spurned the growth of specialized chains. Eachof these chains has fostered immense growth in applications within its own ecosystem, but the isolation between these ecosystems has emerged as a key limit toadoption. Users and developers are forced to split time,
resources, and liquidity between separate chains. A natural consequence of the sheer number of so-called Layer
1 blockchains (as many as 109 at the time of writing [1])is the need to extend the above-mentioned three pillars
to envelope interactions across multiple chains simultaneously. One example of an in-demand interaction between chains is the transfer of tokens, which we discusslater in this section.
In blockchain parlance, the unit of work is a transaction, immutable and irrevocable. Transactions, collated
into blocks, form the basis of security in a blockchain
system. However, transactions have always been asingle-chain concept; as described below, interacting
across chains has traditionally required a third-party
mechanism outside of the normal blockchain cryptosystem. In contrast, this paper describes the first messaging
protocol upon which native cross-chain transactions are
possible: LayerZero.
To illustrate the powerful communication primitive
LayerZero provides, we look at the example of trans-

Introduction

At the core of the blockchain concept are the three pillars
of decentralization, transparency, and immutability. No
single entity controls the blockchain, and actions on theblockchain 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
reason why, for example, cryptocurrencies are enticing
compared to fiat currency.
(2023-11-22) Version 1.1: Fix minor spelling typos.

1ferring tokens from one chain to another. Currently, toconvert between tokens of two chains, a user must leverage either a centralized exchange or a cross-chain decentralized exchange (DEX) (also known as a cross-chain
bridge), both of which require a compromise. In thecase of a centralized exchange, e.g., Binance.com [3],the user must trust the exchange that is tracking deposits
and funding withdrawals. This trust relationship is contrary to the fundamental trustlessness of blockchain consensus and lacks the security of an on-chain automatedsystem. Using a DEX, such as AnySwap [2] or THORChain [23], alleviates the trust problem by conducting
the transfer on-chain, but existing DEX implementations
involve converting the user token into a protocol-specifictoken that transits their intermediate consensus layer toachieve transaction consensus. This intermediate consensus layer, though usually implemented in a securemanner, does require the user to trust a side chain tofacilitate the token transfer. As we show in this paper,
this additional overhead is unnecessary. Despite heavy
user demand, no solution has emerged that is both efficient, direct, while still preserving the core reason for using blockchains in the first place: trustlessness. Taking
a step back, LayerZero’s direct cross-chain transactions
gives developers the tools to build just that.
It is important to note that LayerZero and the exchanges described above operate at two different levelsof the implementation stack. LayerZero is a communication primitive that enables diverse cross-chain applications, whereas an exchange is one example of an application that would benefit from re-implementation on top of
LayerZero. Section 2 outlines the blockchain technology
landscape and explores the exchange example further.
To properly explain the capabilities of LayerZero andits role in the blockchain ecosystem, we first present aformalization of the fundamental communication primitive required to enable inter-chain transactions, which
we term valid delivery (Section 3). We then describe
how LayerZero provides this primitive in a trustless manner, thus preserving the security promise of blockchain.
LayerZero is the first trustless inter-chain communication layer, and supports messaging directly between both
Layer 1 and Layer 2 chains (Figure 1).
A cross-chain transaction between chains A and B consists of a transaction tA on A, a communication protocol
between A and B, and a message m. Valid delivery statesthat m is delivered if and only if tA is committed andvalid. The key idea underpinning LayerZero is that if two
independent entities corroborate the validity of a transaction (in this case, tA ) then chain B can be sure that tA isvalid. Figure 2 illustrates this at a high level. Given two
entities that do not collude, if (1) one entity can produce
a block header for the block containing tA on chain A, (2)the other entity can independently produce the proof for

Chain A

Off-Chain
Relayer

User
Application
LayerZero
Endpoint

Chain B
User
Application

INDEPENDENT

smart contract

LayerZero
Endpoint
smart contract

OracleFigure 2: LayerZero ensures the validity of cross-chaincommunication by requiring that two independent entities, the Oracle and Relayer, corroborate the transaction.

tA on that block (transaction proof), and (3) the header
and transaction proof in fact agree, then the communication protocol can deliver m to the client on chain B
with the guarantee that tA is stably committed on chain
A. The LayerZero communication protocol, described in
Section 4, guarantees that the transaction on the recipient
chain will be paired with a valid, committed transaction
on the sender chain without involving any intermediarychains. 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 theaforementioned transaction.
The interface to LayerZero is a lightweight on-chain
client, which we call the LayerZero Endpoint. One
LayerZero Endpoint exists on each (supported) chain,
and any chain with a LayerZero Endpoint can conduct
cross-chain transactions involving any other chain witha LayerZero Endpoint. In essence, this creates a fullyconnected network where every node has a direct connection to every other node. With minor boilerplate code,
any blockchain is supported. Section 5 demonstrates thisprocess through a case study in implementing LayerZeroon the Ethereum blockchain.
The ability to perform cross-chain transactions directly with any other chain on the network opens theopportunity for a class of large-scale applications thatwere previously infeasible, such as cross-chain decentralized exchanges, multi-chain yield aggregators, andcross-chain lending. Section 6 examines several such applications in detail. Through LayerZero, users can freely
move liquidity between chains, allowing for a single poolof liquidity to take part in multiple decentralized finance(DeFi) applications across different chains and ecosystems without having to go through third party systems orintermediate tokens.
2

2

Backgroundthe community and security of Ethereum. Specialized or
throughput-intensive applications run on the sidechainsand periodically consolidate back to the main Ethereum
chain. In contrast, LayerZero is a lower-level platformthat enables direct inter-chain communication and canbe used to facilitate transfers back to the Ethereum chain
without the complexities of the Polygon protocol.
Polkadot [26] is an early example of the potentialof an open cross-chain ecosystem. In Polkadot, many
domain-specific, parallel chains (“parachains”) connect
via a common relay chain that enables tokens and data
to flow between them. However, inter-chain communication always crosses this relay chain, thus incurring additional costs. LayerZero provides the same low-levelcommunication platform of Polkadot, without involving
the extra transactions necessitated by the on-chain middleman.
THORChain [23] is a DEX that uses pairwise liquidity pools to transfer tokens between third-party chains.
Each liquidity pool binds a specific third-party currency
to a THORChain native token called RUNE, which acts
as a common interchange medium. Without this common
medium, all pairs of currencies would need a liquidity
pool, meaning that the number of pools would scale as
the square of the number of currencies. Unfortunately,while RUNE solves this scalability problem, it is a cumbersome overhead in the transaction process that makes
a simple operation quite complicated. This is evident
in the complexities of the THORChain transaction algorithm. LayerZero provides direct inter-chain communication without THORChain’s inherent scalability bottleneck, cumbersome intermediate currency, or heavyweight protocol.
AnySwap [2] is a DEX geared towards easy pairwise
token exchanges, similar to THORChain. AnySwap relies on an intermediate token, ANY, based on Fusion
distributed control rights management [6]. Like with
THORChain, the use of the ANY intermediate token
introduces undesirable overhead, delay, and additionaltransfer fees.
Cosmos [5] is a blockchain network technology thatallows arbitrary messages to be sent between supported
chains. Cosmos includes an Inter-Blockchain Communication (IBC [14]) protocol build on Tendermint BFT [21]to facilitate messaging between chains built on Cosmos
Hub. Cosmos differs from LayerZero in two key ways:(1) IBC is not trustless, and (2) IBC only provides directcommunication between fast-finality [24] chains. Theselimitations of IBC, combined with its use of an intermediate chain to facilitate consensus, make it similar to
Anyswap, THORChain, or Polkadot, rather than a general communication layer like LayerZero. Cosmos also
provides a DEX with similar properties to Anyswap or
THORChain, called the Gravity Bridge [12]. In con-

To lay the groundwork for LayerZero, we review relevant
existing systems to illustrate why they fall short of meeting the demands of emerging applications. The discussion culminates in an in-depth explanation of the advantages in building a cross-chain exchange atop LayerZero.

2.1

Related work

This section builds an understanding of the important
players in the cross-chain interaction space, why they fallshort of the ideals of trustless valid delivery, and how
LayerZero closes that gap.
Ethereum [8] is the most popular platform for decentralized finance applications built via smart contracts. Ethereum extends its underlying blockchain witha Turing-complete programming language that enables alibrary of decentralized applications to leverage the powerful security properties of the underlying chain througha developer-friendly abstraction. However, the lowtransaction rate of the underlying blockchain, approximately 15–45 transactions per second [9], has provento be a serious scalability bottleneck that limits the
popularity of the applications built to run directly on
the Ethereum blockchain. Because of its programming
model and popularity, many inter-chain communication
techniques revolve around interfacing third-party chainswith Ethereum. LayerZero provides the ability to directly transfer state to and from Ethereum without a middleman, allowing users and applications to leverage thestability and trustworthiness of the Ethereum chain without the cost and bottlenecks of the solutions described
below.
Ethereum 2.0 [22] is a set of proposed upgrades toaddress the scalability, security, and sustainability shortcomings in Ethereum. Ethereum 2.0 introduces shard
chains that distribute load instead of concentrating alltransactions on the overloaded Ethereum main chain.
Transitioning from proof-of-work to proof-of-stake both
eliminates the possibility of a 51% attack and reduces theenergy per transaction. These advancements are largely
orthogonal to LayerZero except that they are sure toboost the popularity of Ethereum, creating even more demand for convenient and cheap inter-chain communication.
Polygon [17], formerly Matic Network, is a Layer 2
network that addresses the throughput and sovereignty
challenges of Ethereum. Despite being the most popular platform for blockchain development, Ethereum isplagued by low throughput [10], making it unsuitablefor certain applications. Polygon provides applicationspecific, Ethereum-compatible sidechains that combine
the scalability and independence of separate chains with3

Centralized
Exchange

Decentralized
Exchange (DEX)$Intermediate chain

LayerZero fabric
ETH

BTC

Off-chain

Chain A

Exchange built
on LayerZero

Chain B

consensus protocol
Chain A

Chain B

Chain A

Chain B

Figure 3: LayerZero is a building block for cross-chain applications. This figure visualizes the architectural differences
between a centralized exchange, a decentralized exchange, and a cross-chain bridge built using LayerZero as its
underlying communication primitive.
A centralized exchange, shown on the left, requires
users to deposit their tokens with a central trusted authority, which then keeps track of that deposit off-chain andgrants coins on other chains as the user requests them.
Placing trust in this authority defeats the purpose of using blockchain to begin with, which has resulted in theemergence of distributed exchanges.

trast to Cosmos and IBC, LayerZero provides trustlessinter-chain messaging, and can be extended to run on
any chain, including those which provide probabilisticfinality, such as Ethereum and Bitcoin.
ChainLink [7, 4] introduces the basic design of adecentralized oracle network (DON). While smart contracts are tamperproof, their on-chain nature prevents
the basic connectivity crucial to their wide adoption: asmart contract cannot fetch off-chain data that is necessary to the execution of the contract, such as stock prices,
IoT device measurements, and world news. A DON extends the smart contracts’ tamperproof property to thedata sources that a smart contract depends on, without
placing trust in any central entity. In a DON, a user’ssmart contract makes an on-chain request to a ChainLink
interface smart contract, which posts an event to many
separate oracle nodes. Each oracle node queries multiple data sources for the requested information and aggregates it to filter erroneous or malicious sources. The
oracle nodes respond to the ChainLink interface contract,which performs a second level of aggregation to filter erroneous or malicious oracles. This dual-layer filtering
guarantees trust in the final data without requiring trust
in any individual oracle or data source. ChainLink provides a robust information-retrieval service that has become widely used across the industry. However, by itself
ChainLink is limited to data retrieval. The LayerZero
protocol leverages the ChainLink DON model as a component to provide the more powerful abstraction of trustless valid delivery of messages between chains.

2.2

The center diagram shows, on a high level, how atypical decentralized exchange works—by using a smart
contract–governed consensus protocol to facilitate theautomatic minting of coins on chain B, DEXs are able
to overcome the necessity for a centralized, trusted offchain middleman. However, one key limitation is that
DEXs involve an intermediate token and intermediatechain, and only mints an intermediary or wrapped token on chain B as opposed to the actual token the user
wants. The user must then exchange the intermediarytoken (e.g. RUNE) or wrapped token (e.g. ANY) for
the desired token in an additional transaction. This intermediary/wrapped token, second transaction, as well as
the intermediate chain are all unnecessary overheads towhat should ideally be a single seamless transaction. The
right side of Figure 3 shows what an exchange built on
LayerZero would look like, with chain A able to initiate a single cross-chain transaction that facilitates the local transaction on chain A and notifies the application on
chain B that they can safely grant a token to the user. In
this application, LayerZero enables a clean and minimal
single-transaction swap that does not include any intermediate tokens. The actual exchange protocol is handledby smart contracts on either side of the cross-chain transaction, with LayerZero delivering messages between the
two. This provides a great deal of flexibility, and follows the end-to-end principle [18] with the majority of
the high level exchange logic handled by smart contracts
on the source and the destination chains.

LayerZero in practiceDevelopers can use LayerZero to build complex crosschain applications without sacrificing trustlessness or introducing complex intermediate chains/smart contracts.
Figure 3 illustrates the functionality of LayerZero in thecontext of building an exchange.
4

3

Valid Delivery

token to the destination chain. While existing exchanges
do enable cross-chain token transfer, they do so at thecost of unnecessary complexity and cost. The downsidesof this are evident in that cross-chain applications havenot seen broad adoption. The ideal solution to the interchain transaction problem is one that uses a single oneswap transaction between chains without involving any
trusted middle entity—in other words trustless valid delivery. In our work, we implement a generic messaging
protocol that provides trustless valid delivery of arbitrary
user data, not just tokens. Distributed exchanges or other
DeFi applications would be implemented using our messaging primitive to provide cross-chain transactions, andthe degree of flexibility provided by a low-level messaging protocol enables higher-level applications to implement a wide range of previously-impossible functionality.

In this section, we describe the fundamental properties oftrustless inter-chain communication. To formally characterize the problem of validating a transaction on a different chain, we define the idea of valid delivery. Validdelivery is a communication primitive that enables crosschain token transfer by providing the following guarantees:
1. Every message m sent over the network is coupledwith a transaction t on the sender-side chain.
2. A message m is delivered to the receiver if and only
if the associated transaction t is valid and has beencommitted on the sender-side chain.
Centralized exchanges guarantee valid delivery, in thatthe agreement between the client and the exchange is thatthe client will transfer their token from one chain to theexchange, and the exchange will, upon receipt of that token, issue some balance (non-cryptocurrency). This noncryptocurrency balance can then be withdrawn from any
available chain, a convenience which is made possibleby broad pools of liquidity maintained by the exchange
on each of the supported chains. The exchange acts as
the middleman in this transaction and the user must trustthem to uphold their end of the bargain. However, a malicious or compromised exchange could take tokens fromthe client, issue balance, and then refuse to allow withdrawal of that balance from another chain, effectively
stealing tokens from the user. Even if the user is willingto trust the exchange, recent years have seen many successful attempts to hack or compromise cryptocurrency
exchanges [15], so users are better served with a solutionthat does not require any trusted middleman. At a higher
level, one of the core tenants of cryptocurrencies is their
independence from centralized entities like banks, so relying on a centralized exchange defeats their purpose.
An alternative to using an centralized exchange isa decentralized exchange such as THORChain [23] or
AnySwap [2]. All existing DEX use an intermediary token, such as RUNE in the case of THORChain or ANY
in the case of AnySwap, as the transaction t. Because
these intermediary tokens are governed by the respective protocols of each DEX, the DEX is able to guarantee valid delivery, as it is impossible for a malicious
user to fake the intermediary token. Existing DEX solutions are not ideal because they involve two intermediatetransactions—one to convert the sender’s token to an intermediary token and one to convert the intermediary token to the desired “real” token on the recipient chain. In
addition to this, it is necessary for the user to fully trust
the intermediate consensus layer that confirms the transaction on the source chain and conveys intent to mint the4

DesignThe core of LayerZero is a communication protocol thatprovides trustless valid delivery. Our protocol is built on
a series of components introduced in Section 4.1. We
discuss the communication flow of the transfer protocol
in Section 4.2, describe how LayerZero is able to achievevalid delivery without involving trusted intermediary services in Section 4.3, and present our novel design fora low-cost smart contract–based light client endpoint in
Section 4.4.

4.1

LayerZero components

LayerZero Endpoints are the user-facing interface toLayerZero. Each chain in the LayerZero network has
one LayerZero Endpoint implemented as a series of onchain smart contracts. An Endpoint’s purpose is to allow
the user to send a message using the LayerZero protocol
backend, guaranteeing for valid delivery.
A LayerZero Endpoint is split 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 coremodules. We explain the functions of each module in
Section 4.4.
The Oracle is an third party service that provides
a mechanism to, independently of the other LayerZero
components, read a block header from one chain andsend it to another chain. In theory, this Oracle can be
any third party service that provides this mechanism, but
in practice we expect to use ChainLink [7, 4], which is
5Chain A

proof(t)Relayer

Chain B

blk_hdrUser
Application

User
Application[(Packet(dst, payload),t, proof(t))]

Packet(dst, payload),tt, dst, payload,
relayer_args

Packet(dst,payload),t, relayer_args
dstCommunicator
Validator
Network

LayerZero
Endpoint

blk_hdr_hash

Communicator

Packet(dst,payload),t, relayer_args

Validator

dst, cur_blk_id

blk_hdr

OracleNetwork

Packet(dst, payload),t
blk_hdr_hash

LayerZero
Endpoint

Figure 4: The communication flow in a single LayerZero cross-chain transaction.
the current industry leader for decentralized oracle networks.
The Relayer is an off-chain service that is similar infunction to an Oracle, but instead of fetching block headers it fetches the proof for a specified transaction.
To ensure valid delivery, the only requirement is thatfor any given message sent using the LayerZero protocol, the Oracle and Relayer must be independent of eachother. The protocol itself does not require any specificimplementation of a Relayer, and in theory the users ofLayerZero could even implement their own Relayer service. This design allows users to be sure that the Relayer
cannot collude with the Oracle, and this independence
is what allows us to implement trustless validated delivery, as shown in Section 4.3. In practice, LayerZero provides the Relayer service while the Oracle is handled by
ChainLink’s decentralized oracle network and associatedconsensus mechanisms.

4.2

delivery conditioned on T . For illustration purposes, andwithout loss of generality, we assume that in this scenario App A is using our reference Relayer. App A sends
a request to the LayerZero Communicator containing thefollowing information:• t: The unique transaction identifier for T .
• dst: A global identifier pointing to a smart contract
on chain B.
• payload: Any data that App A wishes to send to
App B.
• relayer args: Arguments describing payment information in the event that App A wishes to use thereference 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 andrelayer args, to the Validator.
Step 3: The Validator sends t and dst to Network.
This step notifies Network that the block header for thecurrent block on chain A needs to be sent to chain B.
Step 4: Validator forwards Packet(dst, payload),t, and relayer args to the Relayer, notifying theRelayer that the transaction proof for T needs to beprefetched and eventually sent to chain B. This happens
concurrently with Step 3.
Step 5: Network sends dst and the block ID of thecurrent transaction (cur blk id) to the Oracle. This notifies the Oracle to fetch the block header for the current block on chain A and send it to chain B. In theevent that multiple LayerZero transactions occurred in
the same block, Step 5 is only executed once.
Step 6: Oracle reads the block header (blk hdr) fromchain A.

LayerZero protocol

Figure 4 illustrates the steps involved in the valid delivery
of a single LayerZero message. Each encircled numberin the figure represents a step of the protocol and corresponds to a paragraph in this section. This section walks
through the example of a user application on Chain A
sending a single message to a user application on Chain
B via LayerZero. In Section 5, we describe how the various components and protocol steps are implemented in
the case of sending messages between two Ethereum Virtual Machines.
Step 1: The user application on chain A (App A) executes some series of actions as part of transaction T . We
uniquely identify transaction T by the transaction identifier t—the format of this identifier may vary dependingon the type of chain A. A step included in transaction T is
the transmission of a message over LayerZero with valid
6

Step 7: The Relayer reads the transaction proof associated with transaction T (proof(t)) from chain A, andstores if off-chain. Steps 6 and 7 occur asynchronously
to each other.
Step 8: The Oracle confirms that the block corresponding to blk hdr is stably committed on chain A andthen sends blk hdr to Network on chain B. The mechanism for determining when this happens varies per chain,
but will typically involve waiting for some number ofblock confirmations.
Step 9: Network sends the block hash, specified as
blk hdr hash, to the Validator.
Step 10: The Validator forwards blk hdr hash to theRelayer.
Step 11: After receiving blk hdr hash, the Relayer sends a list of any Packet(dst, payload), t,
proof(t) tuples that match the current block. In theevent that 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 uses the received transaction
proofs in conjunction with the block headers stored by
Network to validate whether the associated transaction T
is valid and committed. If the block header and transaction proof do not match, then the message is discarded.
If they do match, then Packet(dst, payload) is sent
to the Communicator.
Step 13: The Communicator emits Packet(dst,payload) to App B.

4.3

2. The block header provided by the Oracle and thetransaction proof provided by the Relayer are both
invalid, but still match.
Scenario 2 can only happen if the Oracle and the Relayer collude, as it is statistically impossible to send atransaction proof that can be validated against a blockheader without knowledge of that specific block header,and vice versa. However, LayerZero’s design eliminates
the possibility of collusion, as outlined in Section 1.
Thus, if a message is delivered to the user application on
the receiver side, it is guaranteed to meet the propertiesof valid delivery.
As outlined in Section 3, a communication protocol which can guarantee trustless valid delivery, namely
valid delivery without placing trust in intermediary entities or tokens, is the ideal solution to enable cross-chaintransactions. LayerZero is the first and only system toprove this property. This fact will drive user adoption ofLayerZero as the preferred method of cross-chain messaging.

4.4

LayerZero EndpointA LayerZero Endpoint is currently implemented as a series of smart contracts on each chain included in the LayerZero network. The core functionality of a LayerZero
Endpoint is encapsulated in three modules: the Communication, Validation, and Network. These modules act
in a manner similar to a network stack, with messages
sent down the stack on the sender side—Communicator
to Validator to Network—then up the stack on the recipient side.
In addition to the core modules, LayerZero Endpoint
can be extended via Libraries, which are auxiliary smart
contracts that define how communication for a specificchain should be handled. Each chain in the LayerZero
network has an associated Library, and each Endpoint
includes a copy of every Library. This modular design
allows the LayerZero network to be quickly and easily
extended to include new chains on demand. In addition,communication between two chains only requires that
their respective libraries be present on both ends, making LayerZero a fully-connected network with the ability
to orchestrate transactions between any pair of nodes.

Achieving trustless valid delivery

Trustlessness: At the crux of LayerZero’s design is theidea that the user need not trust the components of LayerZero. Instead of requiring trust, which is a strong condition, we only require the weaker condition of independence between the Oracle and Relayer. This requirementof independence instead of trust is one aspect of what allows LayerZero to be efficient and lightweight. As longas there is no malicious collusion between the Oracle andRelayer, then LayerZero guarantees valid delivery.
Valid delivery: By the LayerZero protocol shown in
Section 4.2, a message m is delivered by the Communicator to the user application if and only if the transaction
proof for the transaction t associated with m can be validated in Step 12. This validation step will succeed if andonly if the block header and the transaction proof match,which will only occur in the following two scenarios:

4.5

LayerZero Endpoint cost scalability

As many readers will likely point out, running smart contracts on Layer 1 chains can be cost prohibitive, especially as the amount of stored data increases. To makethe LayerZero Endpoint practical, it was necessary for us
to design the most lightweight client possible. Previous
work on trustless cross-chain validation through crosschain state machine replication (SMR), such as Golden

1. The block header provided by the Oracle and thetransaction proof provided by the Relayer are both
valid.
7

0

78

31

Chain ID
Address (20 bytes)

User Arg 0 (32 bytes)..
.

User Arg 14 (32 bytes)




Field
Chain ID























Address

Routing information

User Arg
0 – 14User

Sender-side chain transaction stability: To ensurethat the message transaction is stable on the source chain,
we rely on the inherent properties of decentralized oracle networks—the Oracle will only notify the destination chain of a particular block header after it hears somenumber of block confirmations, which in the case of
Ethereum is 15. Precisely speaking, Step 8 of the LayerZero protocol (Section 4.2) will only execute after the
Oracle hears 15 block confirmations on chain A.
LayerZero Endpoint: We implement the LayerZero
Endpoint as a series of smart contracts, composed of
the four main modules we describe in Section 4.4.
For most existing blockchains, including the Ethereum
blockchain, we are able to implement the Communicator, Validator, and Network each as separate smart contracts. However, this design does not preclude the implementation of LayerZero Endpoint on (future) chains withdifferent requirements.
The Library component of the LayerZero Endpoint is
the key to providing support for the Ethereum blockchain
in this case study. We implement a Library to handle
the construction of the EVM-specific LayerZero packet
shown in Figure 5 and handle the encoding and decodingof EVM smart contract address information.
An additional responsibility of the Library is to handle
the actual computation involved in validating the transaction proof. Our EVM Library handles Merkle-Patricia
Tree validation [16] for transactions on an EVM block,which we base on an open-source implementation byGolden Gate [11].

payload





















Figure 5: LayerZero packet layout for EVM endpoints.

Gate [11], could cost millions of dollars per day to run
on popular Layer 1 chains like Ethereum.
To solve this problem, we set out to design the mostlightweight client possible. Our key observation is that
replicating and storing block headers within the client is
not necessary. Rather, we delegate the task of fetching
the necessary cross-chain headers and transaction proofs
to off-chain entities: the Oracle and Relayer. This resultsin LayerZero Endpoints being incredibly lightweight,
making them cost-effective even on notoriously expensive [20] chains like Ethereum.

5

Description
A unique identifier for eachchain on the LayerZero network.
The address of the recipient smart
contract on the destination chain.
The payload sent by theuser application—in EVM thiscan contain up to 15 32-byte args.

Case Study: LayerZero on EVM

In this section, we briefly describe the details of how
we implemented support for running LayerZero on
Ethereum Virtual Machines (EVMs) [13]. For the sake ofbrevity, we focus on the aspects of the system whose implementation is likely to vary by chain and highlight how
our implementation handles the specific requirements ofthe Ethereum chain. As mentioned in Section 4.1, thecurrent version of LayerZero relies on ChainLink to provide the Oracle service, and expects users to use the Relayer service that we provide.

6

Applications on LayerZero

Cross-chain decentralized exchange: As briefly described in Section 2.2, LayerZero enables a cross-chain
DEX (cross-chain bridge) that deals exclusively in native assets. Contrary to existing DEX designs that issue
wrapped tokens or go through intermediary sidechains,a DEX built using LayerZero to send messages between
chains can be built such that liquidity pools exist on bothchains, and users can simply deposit their native assets in
one pool and withdraw native assets from another. LayerZero’s messaging primitive is powerful enough to enable direct bridges (1:1 pricing), automated market making (ab = k pricing), and any other derivation (such as

LayerZero packet: The format of the LayerZero
packet will vary depending on the source and destination
chains. We illustrate the precise layout of the LayerZero
packet for EVM endpoints [19] in Figure 5. Each field
functions as follows:8one similar to Curve DAO pricing [25]). The guaranteeof valid delivery that LayerZero provides enables a wide
range of decentralized exchange applications.
Multi-chain yield aggregator: Current yield aggregators typically operate within the confines of single chain ecosystems, with projects such as Yearn Finance [27] enabling yield aggregation using single chain
strategies. One key weakness of these single chain yieldaggregation systems it that they cannot take advantage ofany yield opportunities outside of their current ecosystem, potentially missing out on many of the best yields.
A yield aggregator that uses LayerZero for cross-chaintransactions would allow for strategies that tap into thebest opportunities across all ecosystems, increasing access to high yield opportunities and enabling users totake advantage of market inefficiency. A multi-chain
yield aggregator would be strictly better than a singlechain yield aggregator, as in the worst case the strategy
would degrade to taking advantages of opportunities on
only one chain, and in the best case it would have exponentially more opportunities to choose from.
Multi-chain lending: Today, users have no easy way
to take advantage of opportunities on chains where they
do not hold assets. For example, suppose that a user withassets consolidated in ETH wants to take advantage ofan opportunity on Polygon [17]. Their choices are to either (1) move their entire asset base to another chain andconvert it to the desired currency, or (2) lend their assets
on Ethereum, borrow the desired asset, and then bridgethat asset to the destination chain. LayerZero enables a
lending protocol that would allow the user to keep their
entire asset base in-place on Ethereum, lend it out, thenborrow directly in MATIC on Polygon. This eliminatesintermediary costs such as bridge and swap fees.
These three examples represent but a tiny fractionof the many possibilities that LayerZero enables. Byleveraging LayerZero, developers will be able to write
their applications without worrying about differing semantics between inter- and intra-chain transactions, andusers will be able to freely move liquidity across chains.
We look forward to the creative new applications thatthe community will develop given the power of trustlesscross-chain transactions.

7

not preclude the use of arbitrary relayer services, which
ensures that there is no collusion between the Relayer
and Oracle. The LayerZero protocol enables native transactions between supported chains, while the novel LayerZero Endpoint design can be easily extended to support
any chain. In addition to this, our Endpoint design islightweight enough to run on expensive Layer 1 chainssuch as Ethereum without incurring prohibitive costs.
We presented a case study of how to implement support
for EVM-based chains in LayerZero, using a reference
Relayer implementation in conjunction with ChainLink’s
decentralized oracle network to enable cross-chain transactions through LayerZero.
LayerZero is the backbone that will connect the various disjoint blockchain ecosystems and allow frictionlessmovement of liquidity, data, and ideas between chainsand communities.

References[1] All layer 1 blockchain protocols. https://blockchaincomparison.com/blockchain-protocols/.
Accessed:
2021-5-13.
[2] Anyswap dex user guide.
https://anyswapfaq.readthedocs.io/en/latest/index.html.
Accessed:
2021-5-13.
[3] Binance.com. https://www.binance.com/. Accessed: 20215-14.
[4] B REIDENBACH , L., C ACHIN , C., C HAN , B., C OVENTRY, A.,
E LLIS , S., J UELS , A., KOUSHANFAR , F., M ILLER , A., M A GAURAN , B., M OROZ , D., NAZAROV, S., T OPLICEANU , A.,
T RAM ÈR , F., AND Z HANG , F. Chainlink 2.0: Next steps in theevolution 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] E LLIS , S., J UELS , A., AND NAZAROV, S. Chainlink: A decentralized oracle network. White paper, ChainLink, 2017.
[8] Ethereum. https://ethereum.org/en/. Accessed: 2021-513.
[9] Ethereum 2.0 (eth2) vision. https://ethereum.org/en/
eth2/vision/. Accessed: 2021-5-13.
[10] G ALAL , H. S., E L S HEIKH , M., AND YOUSSEF, A. M. An
efficient micropayment channel on ethereum. In Data Privacy Management, Cryptocurrencies and Blockchain Technology. Springer, 2019, pp. 211–218.

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

This paper introduced the design and implementation ofLayerZero, the first trustless cross-chain communication
platform that does not involve any intermediate transactions. We showed that by leveraging two independent,
untrusted off-chain entities, the Oracle and Relayer, LayerZero is able to achieve valid delivery without requiring
costly cross-chain state machine replication or intermediary tokens. Our protocol is designed in a way that does[12] Announcing the gravity bridge. https://blog.althea.net/
gravity-bridge/. Accessed: 2021-5-15.
[13] H ILDENBRANDT, E., S AXENA , M., RODRIGUES , N., Z HU , X.,
DAIAN , P., G UTH , D., M OORE , B., PARK , D., Z HANG , Y.,S TEFANESCU , A., ET AL . Kevm: A complete formal semantics

9

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] L AZARENKO , A., AND AVDOSHIN , S. Financial risks of theblockchain industry: A survey of cyberattacks. In Proceedings ofthe Future Technologies Conference (2018), Springer, pp. 368–
384.
[16] L U , Z., WANG , Q., Q U , G., Z HANG , H., AND L IU , Z. A
blockchain-based privacy-preserving authentication scheme forvanets. 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] S ALTZER , J. H., R EED , D. P., AND C LARK , 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] S PAIN , M., F OLEY, S., AND G RAMOLI , V. The Impact ofEthereum 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-515.
[22] The eth2 upgrades. https://ethereum.org/en/eth2/. Accessed: 2021-5-13.
[23] Thorchain. https://thorchain.org. Accessed: 2021-5-13.
[24] V IRIYASITAVAT, W., DA X U , L., B I , Z., AND S APSOMBOON ,A. New blockchain-based architecture for service interoperationsin 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] W OOD , G. Polkadot: Vision for a heterogeneous multi-chain
framework. White paper, Polkadot, 2016.
[27] yearn.finance. https://yearn.finance/. Accessed: 2021-514.

10