Layerzero message tracking from first send to closure

Set the stop point before signing

Review the proposed source transaction before authorizing it. Confirm the selected destination endpoint, receiving contract, message payload and execution options before authorizing the send. These values determine where the packet goes and how destination execution will be attempted. If the destination or receiver doesn't match the intended pathway, stop before signing. Nothing has been sent at that point, so correcting the request doesn't create an abandoned onchain message.

Once the request is accurate, submit one source transaction and wait for its receipt. Save the transaction hash immediately. That hash becomes the first stable lookup key for the message, while the receipt shows whether the source chain accepted or reverted the call. Don't submit a replacement merely because the crosschain status hasn't appeared yet. First establish whether the original transaction produced a protocol packet.

Use the source receipt as the first checkpoint

For a Layerzero V2 EVM send, a successful receipt is necessary, but the relevant evidence is the PacketSent event emitted through the Endpoint. The event connects the application call to a Layerzero message and includes packet data needed for later identification. If the source transaction reverted, no message entered the protocol. If it succeeded without the expected event, inspect the called contract and transaction logs before searching for destination activity.

This boundary prevents two different failures from being confused. A source-call failure belongs to the sending transaction. An accepted packet has moved into crosschain processing and should be traced through its existing record. Repeating the send creates another source transaction and may create a separate message rather than repairing the first one.

Keep the transaction hash, GUID and pathway together

The source hash locates the initial record, while the GUID identifies the individual packet across its lifecycle. Pathway fields add the source and destination endpoint IDs, sender, receiver and nonce. Preserve these values together. A hash lookup may return an array, so the GUID and pathway prevent an unrelated packet from being mistaken for the message you intended to follow.

The Layerzero Scan API accepts a source transaction hash and returns message records containing pathway, source, verification, destination, configuration, status and GUID fields. The same record can expose separate transactions for DVN attestations, the verification commitment and destination execution. Those hashes describe different actions within one message lifecycle; they aren't replacements for the packet GUID.

Let the current status choose the next inspection

Layerzero Scan condenses several lifecycle checkpoints into an overall status. Inflight can mean that the source transaction still needs confirmations, a required DVN hasn't attested, the optional-DVN threshold hasn't been met, verification hasn't been committed or the Executor hasn't submitted destination execution. Open the detailed record before deciding which condition applies.

Confirming means a destination transaction has been submitted and is waiting for destination-chain finality. That state calls for observation, not another source send.

Failed points to an attempted destination execution that didn't complete. The failed transaction and its error data determine whether a retry is appropriate.

Blocked indicates a pathway or application configuration problem. Repeated execution attempts won't correct a missing peer, incompatible security configuration or invalid receiver.

Source confirmations come before DVN verification

The sending application's outbound configuration tells DVNs how many source block confirmations to wait before verifying. The receiving application's inbound configuration sets the minimum confirmation count it will accept when verification is committed. Neither threshold is a universal Layerzero duration, and settings can differ by pathway. Compare the recorded source count with both configurations. When the outbound threshold hasn't been reached, an Inflight label describes expected waiting rather than an execution failure.

Time sensitivity doesn't justify guessing a deadline or duplicating the message. Chain finality, the pathway's confirmation thresholds and worker activity all affect progression. Once the outbound threshold is satisfied, inspect the required and optional DVN entries. Their individual states reveal whether verification has started and whether any required attestation or optional threshold remains outstanding.

If all required attestations are present and any configured optional threshold is satisfied but the packet hasn't been committed, the next checkpoint is the committer transaction. Destination execution can't begin from a packet that hasn't reached the Endpoint's message channel.

Verification and delivery are separate checkpoints

A verified message has passed its configured verification policy and has been committed to the destination Endpoint's message channel. Delivery comes later, when the destination call succeeds. This separation matters because a packet can be valid even when its receiving application rejects the call, runs out of supplied gas or encounters a logic error.

View full-size image

A Layerzero V2 verification is committable only after every required DVN and the configured number of optional DVNs, if any, have attested. Treat those as different forms of evidence. Verification records establish the packet's DVN policy result, not the receiving contract's application result.

At the execution checkpoint, match the destination transaction to the same GUID, receiver and nonce. A successful protocol call should also produce the destination evidence expected for that message, such as a receipt event or a readable application-state change.

A hypothetical first message with insufficient destination gas

Assume hypothetical V2 EVM source and destination chains. The configured sender and receiver contracts, payload, execution option and resulting source transaction hash are also hypothetical. In this example, the receiving contract stores the payload in a readable field. Before signing, check the destination endpoint and receiver. Then submit the request and retain the source receipt.

View full-size image

On the normal path, the receipt contains PacketSent. The configured source-confirmation threshold is reached, the configured DVN policy is satisfied and the packet is committed at the destination Endpoint. Execution succeeds, the status becomes Delivered and the receiving field equals the hypothetical payload. That matching destination state closes the task.

In the edge case, keep every hypothetical input the same except the hypothetical execution option, which supplies too little destination gas. Verification completes, but execution produces an alert and the message becomes failed rather than delivered. After the failed transaction identifies insufficient gas, retry the verified receive call with adequate gas instead of resending from the source. A successful retry ends with: Delivered status and a receiving field that matches the hypothetical payload. If the error instead identifies application logic, that invalidates the gas diagnosis and the logic fault must be corrected before retrying.

Failed execution calls for a targeted retry

A failed destination call should be diagnosed from its own transaction. The destination record can include failed transactions, error data and a revert reason. An empty reason can accompany exhausted gas or a contract revert without a readable message, so it doesn't prove either cause by itself. Inspect the execution options, trace and receiving-contract behavior before changing anything.

View full-size image

After a failed EVM receive execution, the Endpoint restores the payload so the verified message remains available for retry. The corresponding LzReceiveAlert carries the failed attempt's context. On EVM pathways, anyone can resubmit the verified call through lzReceive, although the retrying account must pay for its destination transaction.

Change only the input tied to the diagnosed fault. Insufficient execution gas supports a retry with more gas. A decoding error, paused receiver or unmet application condition needs a correction at that layer first. When lzReceive succeeded but a composed action failed, retry lzCompose instead of replaying the receive step.

Blocked status marks a configuration boundary

A blocked message can't progress until the pathway or receiving application configuration changes. Typical causes include an unset trusted peer, an invalid destination receiver, a pathway that can't initialize, incompatible DVN sets or a source confirmation policy below the receiving requirement. A configuration that contains an unusable DVN can also prevent verification from completing.

Compare the recorded sender, receiver and endpoint IDs with the deployed pathway before changing configuration. Then inspect the send and receive libraries, DVN selections and confirmation settings that were active for this message. These changes may require the OApp owner or delegate. A message observer shouldn't authorize an unfamiliar configuration transaction merely to remove the status label.

After the responsible configuration is corrected, follow the same message record again. Whether it can continue depends on the state at which it was blocked. Creating a fresh source message before understanding that state leaves the original issue unresolved.

Ordered execution makes the earlier nonce relevant

Ordered execution tells the Executor to deliver messages by nonce. If an earlier ordered packet's destination execution fails, later ordered packets won't execute until that failure is resolved. A later message may already be verified and otherwise ready, but retrying it doesn't remove the dependency.

Open the execution options to determine whether ordering applies, then identify the earliest prior nonce that blocks execution. Check whether that packet is awaiting verification or has a failed destination call. Trace the relevant checkpoint and fix the earliest incomplete dependency, not whichever later message first attracted attention.

This distinction also limits what a status can tell you alone. A pending Executor step may reflect an ordering condition rather than insufficient destination gas or broken receiving logic. The nonce sequence and each earlier message's verification and execution records establish which explanation fits.

Close the trace against destination application state

Delivered indicates that the destination lzReceive call succeeded. Record the destination transaction hash and match its receiver, nonce and GUID to the source packet. For a Layerzero V2 EVM message, the successful receipt and PacketDelivered event provide protocol-level evidence, while the receiving contract supplies the application-level result.

Read the state or event that the application was meant to change. A message that updates storage, credits an asset or initiates another action has its own completion condition. Don't substitute the explorer label for that condition. If the message includes a composed call, inspect its separate status because lzReceive can succeed while lzCompose fails.

Keep the source hash, GUID, destination hash and final application evidence as one record. A delivered message with the intended state change is closed. A failed message remains retryable after its cause is fixed, while a blocked message still needs configuration work. Burned or skipped packets may be terminal, but they aren't successful delivery.