Layerzeroscan Messages: pause and proceed signals for cross-chain delivery

Evidence after a successful source transaction

Tracking earns its place when a source transaction succeeds while the intended destination change remains unconfirmed. The source receipt establishes that the originating chain accepted the transaction. It does not establish that the required confirmations accumulated, the configured Decentralized Verifier Networks (DVNs) verified the packet, or destination execution finished.

A message record joins the route, GUID, pathway nonce, security configuration, execution options, and transaction evidence. These details identify the latest completed stage. Pending source confirmations or DVN responses support a pause. A recorded execution failure supports investigating its cause before another transaction. This makes the record a boundary between waiting and acting, rather than a timer that promises when delivery will occur.

Evidence to collect before making a decision

The useful fields answer different questions, so one status label should not carry the whole decision. Identity and route fields confirm that you found the intended packet. Source, verification, and destination fields then show how far that packet progressed.

A GUID, transaction hash, or address is a public lookup identifier, not a wallet authorization credential. Inspecting a record does not require a seed phrase. A request for secret recovery words belongs outside this tracking task and should not be followed.

What does the current message stage permit?

Wait while confirmation or verification is pending. After verification, monitor for destination execution; after a failure, diagnose the cause before retrying. A Delivered record shifts the final check to the application outcome.

LayerZero V2 separates verification from destination execution. A source transaction can therefore succeed while the packet remains short of either checkpoint.

While confirmation or verification is pending

Inflight or Confirming evidence calls for observation rather than a destination retry. The pathway may still be accumulating source confirmations or waiting for its configured DVNs. Elapsed time alone does not prove a failure because confirmation and verification requirements belong to the pathway configuration. A missing destination transaction at this stage is expected, not evidence that execution reverted.

After the packet becomes Verified

Verified means the destination Endpoint has accepted the packet into its messaging channel after the required verification conditions were met. Execution is still a separate event. If no destination transaction or alert appears, continued monitoring fits the known state better than resending the source operation. The packet already passed the checkpoint that a new source send would repeat.

Once destination execution appears

Delivered records support moving from protocol tracking to the application outcome. A failure alert points in the other direction: inspect the failed transaction, execution options, and reason before considering recovery. These outcomes have different next steps even though both occur after verification.

Open full-size image

Waiting while protocol checkpoints advance

Waiting is appropriate when the record still shows normal progress toward its next checkpoint.

Source finality and DVN verification can change without a wallet transaction from the reader. Submitting another source operation during that period does not complete the outstanding verification requirement. It can also create a second action whose result must be tracked separately.

The record should change the decision only when it adds evidence. A completed confirmation stage, committed verification, destination transaction, or failure alert supplies a new basis for proceeding.

If the status stays unchanged, compare its underlying fields before treating time as the deciding factor. Confirmation progress, DVN responses, configuration errors, and destination evidence provide more information than the age of the record by itself.

Comparing expected and observed checkpoints

Compare the expected next checkpoint with the one that actually appeared. For a Confirming message, source confirmations must accumulate before verification and any destination application outcome can complete. For a Verified message, the next protocol evidence to seek is destination execution. Before another attempt, confirm that the recorded cause of a failed execution has been addressed.

Keep the comparison consistent across the available choices: current checkpoint, unmet prerequisite, transaction requirement, and closing evidence. Waiting requires no new transaction and ends when the next protocol checkpoint appears. A destination retry adds a transaction and ends only when that transaction produces the expected execution result. If the record cannot establish the application outcome, the destination application’s own state becomes the deciding evidence.

Cases that belong outside the message view

Use the message view for cross-chain packet tracking. Use a chain explorer or application interface when the unresolved fact belongs there, and involve the authorized operator for delegate-controlled actions.

Source transactions without a message event

Use the source chain’s transaction record when the transaction reverted, was replaced, or never produced the protocol event that creates a trackable packet. Without that event, there is no cross-chain message lifecycle for the message view to follow. The source transaction must be resolved before destination tracking becomes relevant.

Application state after delivery

Use destination application state when the question concerns a balance, position, permission, or later application step. Delivered establishes protocol execution, but a multistep application can require additional state changes beyond that message. The destination transaction and the receiving contract’s state show whether the reader’s intended job finished.

Delegate-controlled channel actions

Some Endpoint V2 controls belong to the OApp delegate rather than an ordinary message recipient. Skipping stops an in-flight message before verification and makes that skipped payload unrecoverable. Clearing burns a verified payload so it cannot be retried. A status suggesting either action calls for the application operator’s review, not an improvised wallet transaction.

Failure evidence before a retry

Retry only after a message has reached verification and a destination execution attempt has failed. The failed transaction and alert identify the execution attempt, while its options and error data narrow the cause. A new attempt should address that recorded cause rather than repeat the same conditions.

Gas-limited execution

An execution attempt can fail when the destination call receives insufficient gas. The message record exposes the receive execution options that accompanied the packet. More gas is relevant only when the failure evidence identifies a gas shortfall. Increasing it does not repair an application rule, invalid parameter, paused contract, or unmet prerequisite.

Application rejection

Contract logic can reject a call even when verification completed correctly. In that case, correct the application condition before trying again. A failed receive call restores the payload for a later retry and emits an alert. The already verified packet does not need another source send, but the unresolved application cause still needs correction.

Can a message record confirm the intended outcome?

A message record confirms protocol checkpoints, while the intended outcome may require application-specific evidence. Delivered shows that destination execution completed through the Endpoint. It does not turn every possible application goal into the same observable result.

A message can carry application data, initiate a token operation, or trigger contract logic. The proof depends on what the message instructed the application to do. A destination event may settle one case, while contract state or an application balance settles another. If a later composed action belongs to the workflow, completion of the first receive call does not establish that every later action also finished.

Destination evidence sets the stopping point

Base the next move on the latest onchain evidence. Inflight or Confirming favors a pause while prerequisites progress. Verified favors watching for destination execution. A recorded failure calls for diagnosis and a changed condition. Delivered moves the final check to the destination application’s expected state.

Any offered recovery transaction creates a commitment boundary at wallet submission. Before that point, the reader can compare the route, message identity, failed stage, and proposed destination action. After submission, the new destination transaction becomes the evidence to follow. Ending with that transaction and the resulting application state prevents repeated retries based only on delay or an unchanged status label.