Who pays the destination transaction fee for a manual retry?

The account that submits the manual retry funds the destination-chain transaction. The amount depends on the destination network’s fee rules and the resources consumed by the Endpoint and called application. The original execution options remain useful diagnostic evidence, but they should not be treated as a fixed quote for a later user-submitted attempt.

Does retrying run the original source transaction again?

No. Once the packet is verified on the destination, an execution retry calls the appropriate destination Endpoint function without resending the source transaction. A receive-stage failure uses lzReceive, while a compose-stage failure uses lzCompose. This distinction avoids creating another source message merely to repeat destination execution.

Why can a second attempt emit another LzReceiveAlert?

Another LzReceiveAlert means destination execution failed again. The added gas may still have been insufficient, or the application may have rejected the same message parameters or state. Compare the new failure reason and transaction gas with the previous attempt before increasing resources again. A different submission interface alone does not change contract behavior.

Is an ordered pathway free to process later messages after one execution fails?

Not necessarily. When the application uses ordered execution, an earlier failed nonce can hold later ordered messages until that failure is resolved. Without that option, LayerZero delivery is unordered by default. The message options and application behavior therefore determine whether the failed packet affects later traffic on the pathway.

What happens if the browser retry control is unavailable?

A verified execution failure can still be retried through the destination Endpoint. A block explorer or client library may call lzReceive for a receive failure or lzCompose for a compose failure. The caller must supply the matching message context, select the correct destination network, and confirm success from the resulting destination transaction.

Layerzeroscan

Layerzeroscan gives you the failure evidence to compare retry paths before submitting a destination transaction

Layerzeroscan supports an evidence-first comparison between its in-browser retry and a direct Endpoint call. Match the method to the failed stage, confirm that the cause has changed, and treat submission of the destination transaction as the commitment point. The later destination result decides whether recovery worked.

Updated on 17 Sep 2026

Only a verified execution failure belongs in the retry comparison

A retry path fits only after verification has finished and destination execution has failed. An Inflight status does not yet establish a failed destination execution, while a Verified message has reached the Endpoint messaging channel. Starting from the wrong state can produce an unnecessary transaction without addressing the delay.

Receive-stage failure

The receive stage invokes lzReceive against the destination application. When lzReceive fails, the transaction rolls back payload clearing, and an Executor can report the failure through the Endpoint’s LzReceiveAlert event. The stored failure reason and execution options help distinguish a gas shortfall from application logic that rejected the call. Either failure can be retried, but only after its cause has been addressed.

Compose-stage failure

A composed message adds a later lzCompose call after the receive logic has run. If that call fails, retrying the earlier receive step is the wrong boundary. The relevant action invokes lzCompose with the matching message context and compose index. This separation preserves the successful receive step while the composed action remains unresolved.

How do the available retry paths differ?

The available paths differ mainly in interface, repeatability, and the execution function they invoke. They do not create alternative versions of the verified packet. The browser route prepares the interaction, while direct calls require the caller to assemble and inspect the destination transaction.

Browser-mediated retry

Layerzeroscan detects a failed execution and can expose an in-browser retry. This path is useful when the record clearly identifies the failed stage and the prepared transaction matches it. The wallet still supplies the final approval and destination gas, so the interface does not remove the commitment boundary.

Direct Endpoint access

A block explorer or client library can call the Endpoint without using the browser retry control. After verification, lzReceive and lzCompose are permissionless Endpoint functions that any party may call. Direct access gives developers more control over transaction construction and repeated monitoring, while placing parameter selection and error handling on the caller.

Open full-size image

Direct Endpoint access
Retry path	Best-matched failure	Commitment and boundary
Layerzeroscan browser retry	The record identifies the failed receive or compose stage and exposes the matching action.	A connected wallet signs a destination transaction; the interface cannot repair unchanged contract logic.
Block explorer `lzReceive` call	A verified packet failed during the destination receive call.	The caller supplies the exact message context and pays destination gas for one receive attempt.
Client library `lzReceive` call	A client library fits when the caller needs scripted submission, logging, or repeated monitoring.	Code constructs the destination transaction, but it remains the same permissionless Endpoint operation.
Direct `lzCompose` call	The receive call completed and the separate composed action failed.	The retry targets the compose index and does not repeat the completed receive call.
Shared rule	Match the function to the recorded failure stage.	Confirm success from the resulting destination evidence, not from transaction submission alone.

For a receive-stage failure, the first three paths can reach the same Endpoint function through different interfaces. The shared acceptance condition is a successful destination execution for the same verified packet. A compose failure follows a separate call path, even when both stages use the same message GUID.

What must change before another attempt?

The condition that produced the alert must change, because selecting another interface does not alter execution. The record should support a specific correction before the wallet commits gas. Otherwise, the new transaction can reproduce the same revert and add another failed destination transaction.

Insufficient execution gas

Layerzeroscan can display the message execution options that accompanied the original attempt. Those values describe the resources requested for that execution; they are not a permanent guarantee that another call will finish. Destination opcode costs and application branches can change the required gas. A retry intended to correct exhaustion therefore needs a transaction gas allowance that covers the actual destination call.

Applications can also enforce execution options when messages are sent. Those settings explain why the first attempt received a particular gas allowance, but a later manual retry does not rewrite the original options. The useful comparison is between the recorded allowance, the failure reason, and the new transaction estimate.

Application rejection

More gas does not fix contract code or message parameters that make the destination call revert. The verified payload and recipient are part of the existing message, so a retry cannot edit them into a different request. The application condition must become acceptable, or an authorized OApp operator must choose a separate recovery operation when execution cannot succeed.

Submitting the destination transaction marks the commitment boundary

Inspection remains reversible until the destination transaction is approved and submitted. Before approval, compare the destination network, called Endpoint function, receiver, message identifier, native value, and gas estimate wherever the wallet or transaction view exposes them. A mismatch means the prepared call does not reflect the failure record being evaluated.

Rejecting the prompt does not cancel the verified message. It leaves the retry unsubmitted and preserves the existing evidence for another review. This is the cleanest way to back out when the network, function, or transaction value is unexpected.

The browser path reduces manual assembly, while a direct call exposes more parameters. Both reach the same commitment boundary: a destination-chain write that can spend gas even when execution fails again. Interface convenience should not be mistaken for a different protocol outcome.

Destination evidence closes the comparison

Submission returns a transaction hash, but the hash alone does not prove that destination execution succeeded. Wait for the receipt, then return to the message record. A successful receive retry should replace the unresolved execution state with Delivered and provide a successful destination transaction.

An alert on the new transaction means the acceptance condition was not met. Compare its reason and gas usage with the earlier attempt instead of assuming that the retry control malfunctioned. The second record can reveal that the gas increase remained insufficient or that application logic still rejected the packet.

Composed execution needs its own confirmation. A successful lzReceive result does not settle a later lzCompose failure, because each function has a separate execution boundary. In that case, the acceptance condition is a successful composed call for the recorded compose index.

Backing out while the evidence remains incomplete

Waiting is the reversible choice when the record does not establish the failed stage or a changed cause. A verified but unexecuted packet can remain available for a later retry, provided that an authorized recovery action has not removed it. Repeated attempts add cost without improving the message state when nothing material has changed.

Pause before signing

Keep the message GUID, failed destination transaction, alert reason, and execution options together while comparing paths. These fields bind the next action to one packet and one execution stage. They also make a later result comparable without relying on a source-chain success receipt that predates destination execution.

Delegate recovery is a different branch

The Endpoint recovery functions are not interchangeable with an ordinary retry. An OApp delegate may use skip to stop an in-flight verification, while clear can remove a verified payload that cannot safely execute. Neither operation is a retry path, and both change the message state beyond a wallet user simply declining a transaction.

In the EVM Endpoint flow, a skipped payload cannot be recovered. A failed execution should therefore remain on the retry branch unless the authorized OApp operator has a specific reason to remove it. For example, another LzReceiveAlert after a gas increase requires comparing the new failure reason and gas use with the previous attempt.

Common questions about Layerzeroscan

Who pays the destination transaction fee for a manual retry?: The account that submits the manual retry funds the destination-chain transaction. The amount depends on the destination network’s fee rules and the resources consumed by the Endpoint and called application. The original execution options remain useful diagnostic evidence, but they should not be treated as a fixed quote for a later user-submitted attempt.
Does retrying run the original source transaction again?: No. Once the packet is verified on the destination, an execution retry calls the appropriate destination Endpoint function without resending the source transaction. A receive-stage failure uses lzReceive, while a compose-stage failure uses lzCompose. This distinction avoids creating another source message merely to repeat destination execution.
Why can a second attempt emit another LzReceiveAlert?: Another LzReceiveAlert means destination execution failed again. The added gas may still have been insufficient, or the application may have rejected the same message parameters or state. Compare the new failure reason and transaction gas with the previous attempt before increasing resources again. A different submission interface alone does not change contract behavior.
Is an ordered pathway free to process later messages after one execution fails?: Not necessarily. When the application uses ordered execution, an earlier failed nonce can hold later ordered messages until that failure is resolved. Without that option, LayerZero delivery is unordered by default. The message options and application behavior therefore determine whether the failed packet affects later traffic on the pathway.
What happens if the browser retry control is unavailable?: A verified execution failure can still be retried through the destination Endpoint. A block explorer or client library may call lzReceive for a receive failure or lzCompose for a compose failure. The caller must supply the matching message context, select the correct destination network, and confirm success from the resulting destination transaction.