Cross-chain message finality is the point at which a source-chain event is safe for another chain to act on; depending on the chain and security setting, that can take seconds or roughly 19 minutes. A transfer can therefore be confirmed on its source while its destination action is still waiting for an attestation or execution.
Why is a confirmed transfer still pending?
If you have initiated a token transfer and the destination balance has not changed, first separate the source transaction from message delivery. The source contract may have emitted a message successfully, while the verifier is waiting for the chosen finality threshold, or the destination contract may not yet have executed it.
Think of finality like waiting for a parcel’s dispatch record to become authoritative before the receiving warehouse releases its matching item. If a source-chain reorganization cancels the dispatch, releasing the destination asset early can leave the system undercollateralized. That is why the finality setting trades speed for confidence in the source event.
This distinction matters for omnichain applications, where a message can coordinate state or token supply across networks. Use the site as a way to initiate the cross-chain action, then judge its status by the source event, message attestation and destination transaction separately.
What does the finality setting actually control?
It controls how much source-chain commitment a verifier requires before signing or forwarding a message. For example, Wormhole’s consistencyLevel is a uint8; its meaning is chain-specific. On Solana, the documented values include 1 for confirmed and 32 for finalized. On Ethereum, the finalized option typically takes about 19 minutes; Solana finality is typically about 14 seconds. Treat these as illustrative timings, since network conditions and protocol configuration can change the wait.
LayerZero deployments make a related choice through the configured verification stack and confirmation requirements. The practical question is the same: what source state must verifiers observe before the destination can accept the message? A lower threshold reduces latency but increases reorganization exposure. For a message that releases or mints an asset, choose the strongest supported finality that meets the application’s timing needs; a faster setting needs risk limits that account for a possible rollback.
Finality is not destination execution. A verifier can produce a valid proof and the receiving contract can still revert because its state changed, its preconditions failed, or execution ran out of gas. Some applications allow a failed delivery to be retried; that does not mean the source action should be submitted again.
How do you trace one pending transfer?
Check the stages in order and stop at the first one that has not completed:
- Source transaction: Confirm it succeeded and emitted the expected message. Record the source chain, emitting contract and message identifier.
- Finality and attestation: Check whether the configured threshold was reached and whether a proof was produced. With Wormhole, a VAA is associated with the emitter chain, emitter address and sequence; a reorganization before finality can complicate that identity.
- Destination submission: Look for a destination transaction that verifies the proof and calls the receiving application. If it reverted, inspect the revert reason and retry through the application’s supported delivery path once the cause is fixed.
- Application state: Confirm the destination contract recorded the expected mint, unlock or state update. A proof existing off-chain does not itself change destination state.
Before acting on a slow transfer, verify that the destination has not already processed the message; replay protection should prevent duplicate execution, but a second source transfer is a separate message. In an omnichain flow, the useful completion signal is the destination application state, not merely a source confirmation or an attestation.