Layerzero

LayerZero crosschain messaging tasks and recovery boundaries

LayerZero routes application-defined messages between blockchain endpoints through configurable verification and destination execution. A sending application creates a packet for a trusted receiving application, the selected Decentralized Verifier Networks (DVNs) confirm it and an Executor submits the verified payload for execution. For each message, track the directional channel's peers, active libraries, security configuration and execution options along with its message record. Completion means the receiving contract has executed the intended logic. This state separation determines whether the next action is waiting, retrying or using an irreversible application-level control.

A crosschain task is complete only after destination execution, while verified failures remain recoverable without another source send.

Endpoints, channels and task records

One Endpoint on each supported chain provides the common interface through which applications send, verify and receive crosschain messages. An Omnichain Application, or OApp, connects to that interface and defines its own business logic. Communication occurs through directional channels identified by the sending application, source endpoint, destination endpoint and receiving application. Each direction can carry different libraries, verification settings and execution requirements.

A send produces a message receipt containing a nonce and globally unique identifier, or GUID. Keep that record with the source transaction because it distinguishes the packet from later retries or separate sends. The GUID follows the message across its lifecycle, while the nonce locates it within a particular channel. Neither field alone proves that the receiving contract completed its work.

Prerequisites before dispatch

A valid source transaction needs more than a destination chain selection. The intended pathway must already connect the correct application deployments, and its active configuration must support both verification and execution. Before authorizing a send, the relevant application or interface should establish these inputs:

Peer and library configuration belong to the application owner, not the individual message sender. A user-facing application may hide those details, but they still govern the packet. Execution options matter separately because they specify resources for destination calls such as lzReceive or lzCompose. An execution gas limit set too low can leave a valid message verified without completing the receiving logic.

From request to receiving-state proof

The message lifecycle separates source acceptance, destination verification and application execution. Treating those stages as one event makes failures harder to locate.

Request and dispatch

The source OApp passes destination details, a receiver, payload and execution options to the Endpoint. The Endpoint advances the channel nonce, creates the packet and returns its receipt. Source-chain confirmation establishes that the request was dispatched. It doesn't show that the configured DVNs accepted the packet or that anything ran on the destination.

Request and dispatch: The source OApp passes destination details, a receiver, payload and execution options to the Endpoint. The Endpoint advances the channel nonce, creates the packet and returns its receipt.; Source-chain confirmation establishes that the request was dispatched. It doesn't show that the configured DVNs accepted the packet or that anything ran on the destination.
Illustration: Request and dispatch.

View full-size image

Verification commitment

DVNs observe the source event and apply their own verification methods. The receive library waits for the channel's required DVNs and optional threshold, then commits the verified payload hash to the destination Endpoint. At this point the packet is verified, but the receiver's application logic hasn't necessarily executed. That distinction preserves a recovery route when delivery later runs out of gas or encounters a contract condition.

Destination execution

An Executor normally calls the destination Endpoint after verification. The Endpoint clears the payload before invoking the receiver to prevent duplicate or reentrant execution. A successful call emits PacketDelivered. If lzReceive fails, the clearing is reverted, the payload remains available and an LzReceiveAlert records the failed attempt.

What proves that a crosschain task is complete?

Destination execution provides the completion proof for a standard message. A confirmed source transaction proves dispatch, while a verified status proves that the configured security requirements were met. Neither is equivalent to delivery. Check the destination record for successful Endpoint execution and then confirm the application-owned state change that the payload requested. A composed task needs an additional check because lzCompose runs separately after the initial receive call.

Costs follow the selected pathway

A useful fee estimate comes from quoting the exact packet before sending it. The quote reflects the active DVNs, Executor service, destination execution options and any native value requested by the message. Changing the destination, payload or gas instructions can change the required payment. There isn't one durable LayerZero fee that applies to every application and pathway.

Automated execution is usually prepaid through the source-side send. A manual delivery or retry is a new destination-chain transaction, so its caller supplies destination gas. Extra execution options also add to the request rather than replacing enforced options. Duplicating the same option in both locations may therefore charge for both instructions.

Recovery choices by message state

Recovery starts by locating the packet before changing it. Verification failures, execution failures and application-level compose failures don't share the same remedy. The available operations also differ sharply in reversibility.

Operation Applicable state Recovery boundary
lzReceive retry Verified payload whose receive execution failed Retries destination execution without a new source packet
lzCompose retry Initial receive completed but the composed call failed Retries only the separate composed action
skip In-flight message whose verification must be stopped The skipped payload can't be recovered
clear Verified pending payload known to the OApp Removes it permanently and prevents another retry
nilify Non-executed payload hash requiring replacement Marks it NIL so a valid packet can be resubmitted
burn Old payload below the channel's lazy inbound nonce Permanently blocks it without requiring the original payload
Decision rule Match the operation to the packet's current state Prefer a retry before an irreversible removal

State-preserving retries

A verified LayerZero message whose execution failed can be retried without sending it again from the origin chain. Anyone can invoke the permissionless destination method once the payload is verified. The retry still needs enough gas, and any receiver-side precondition that caused the first failure must now permit execution.

Resending from the source creates another packet and can duplicate the application's intent. It isn't the normal recovery for an already verified message.

Application-controlled removal

The OApp delegate controls operations that alter the channel record. skip applies before successful verification, whereas clear removes a verified payload that shouldn't execute. Both are permanent for the affected payload. burn applies when the original payload isn't available and the nonce is already below the lazy inbound nonce.

nilify has a different purpose. It replaces a non-executed payload hash with the protocol's NIL value, allowing the Message Library to resubmit a valid packet. These controls address exceptional channel conditions, not ordinary delays or temporary execution failures.

Application-controlled removal: nilify has a different purpose. It replaces a non-executed payload hash with the protocol's NIL value, allowing the Message Library to resubmit a valid packet.; These controls address exceptional channel conditions, not ordinary delays or temporary execution failures.
Illustration: Application-controlled removal.

View full-size image

Security belongs to each directional pathway

A pathway's security policy determines which evidence the destination Endpoint accepts. Applications can configure the two directions independently, so a valid setup from one chain to another doesn't prove that the reverse route is ready.

Verification policy

Required DVNs must all verify, while optional DVNs contribute through a configured threshold. Message Libraries enforce that arrangement before committing the payload hash. Confirmation requirements also belong to the pathway. The active onchain configuration, rather than an interface label or a historical default, defines the actual verification rule for a message.

Delivery policy

The configured Executor handles delivery after verification, but it doesn't replace the DVNs. An Executor that stops submitting transactions can delay a message; it can't make an altered payload satisfy the recorded verification. Applications may select another Executor, operate one or rely on permissionless manual execution. Each choice changes liveness and operational work without changing the receiver's need for a verified payload.

Application tasks add their own completion rules

The protocol can carry arbitrary OApp data, support request-and-response reads, transport Omnichain Fungible Token instructions and trigger composed calls. Each application defines what the payload means. For an OFT, the source deployment debits tokens by burning or locking them and the paired destination credits them by minting or unlocking. The token contracts, not the messaging layer alone, enforce that supply relationship.

Application tasks add their own completion rules: The protocol can carry arbitrary OApp data, support request-and-response reads, transport Omnichain Fungible Token instructions and trigger composed calls.; Each application defines what the payload means.; For an OFT, the source deployment debits tokens by burning or locking them and the paired destination credits them by minting or unlocking.; The token contracts, not the messaging layer alone, enforce that supply relationship.

View full-size image

Composed calls create another boundary. The initial lzReceive may finish before lzCompose runs, so token receipt or message delivery doesn't prove that the follow-on action succeeded. Monitor the original receive and the composed execution as separate states. If the latter fails, retry the composed call instead of repeating the source transfer.

A clean handoff ends at the receiving contract

Stop at the first state that lacks evidence. No confirmed source transaction means the request wasn't dispatched. An unverified packet points to the channel, library or DVN requirements. A verified payload with an execution alert belongs on the destination retry path. Successful Endpoint delivery still needs the application-specific outcome, especially when a composed action follows. For a standard message, the clearest protocol-level finish is the destination PacketDelivered event.

Questions worth asking

Is Layerzero itself a token bridge?

LayerZero is a crosschain messaging protocol rather than a single token bridge. Applications can use its messages to implement token movement, including the Omnichain Fungible Token standard. In that design, token contracts handle the source debit and destination credit, while the protocol verifies and delivers the instruction. The exact custody, minting and supply behavior therefore depends on the token implementation.

Does an Executor decide whether a LayerZero message is valid?

An Executor doesn't decide whether a message is valid. The configured DVNs verify the packet, and the receive Message Library commits its payload hash after the required verification rule is satisfied. The Executor then submits the verified message for destination execution. It can affect delivery speed or provide insufficient resources, but an altered payload won't match the verified record held by the Endpoint.

When does a receive-library grace period matter?

A receive-library grace period matters during a library migration. It allows messages sent under the previous receive library to remain acceptable for a defined transition period. The associated expiry determines when that older library stops being valid for in-flight traffic. A zero grace period removes that overlap, so application operators must account for messages already moving through the old pathway before changing the configuration.

Do I need destination-chain gas for a manual retry?

A caller needs destination-chain gas to submit a manual retry transaction. Automated delivery is normally paid through the source-side quote and handled by an Executor, but a direct call to lzReceive or lzCompose occurs on the destination. The verified payload doesn't need to be sent again from the source, although the retry still needs adequate gas and any failed receiver precondition must be resolved.

Which identifier follows a LayerZero message across chains?

The GUID is the primary identifier that follows a message through its crosschain lifecycle. The send receipt also includes a channel nonce, while the source and destination transaction hashes identify separate onchain actions. Record the GUID with the source transaction, endpoint identifiers, sender and receiver. That set prevents confusion between the original packet, a destination retry and a new source send carrying similar data.

Can a destination OApp accept messages from any sender?

A properly configured destination OApp authenticates the remote sender against its trusted peer for the source endpoint. The Endpoint passes the packet's verified origin data, and the receiving application checks that the sender matches its configured counterpart. Permissionless access to Endpoint functions doesn't bypass that relationship. An unknown application may submit its own messages, but those messages shouldn't pass the destination OApp's peer check.

- last updated