Why bridge transfers show different statuses across explorers

A pending bridge transfer can look different across explorers because each explorer reports activity on one chain, while a bridge moves value through steps on multiple chains. The source transaction may already be confirmed even as the destination transaction has not been submitted. “Pending” therefore describes a particular stage or data view, not necessarily the whole transfer.

The source chain records the user’s call to a bridge contract. Depending on the bridge design, that contract may lock or burn tokens, emit a message, or interact with a liquidity pool. A relayer, validator set, proof system or liquidity provider may then enable delivery on the destination chain. A fuller account of the mechanics of a super bridge move-and-swap across chains adds context to that route. Each stage has its own on-chain transaction or off-chain processing, and explorers do not share a single status record.

What does “pending” mean on a source-chain explorer?

On a source-chain explorer, “pending” usually means the submitted transaction has not yet been included in a block, or the explorer has not indexed its inclusion. The transaction hash identifies that source-chain transaction only. It does not identify a future transaction on the destination chain.

Once included, the source transaction may show success even though the transfer is unfinished. Success means the transaction executed without reverting under that chain’s rules. It does not, by itself, prove that a bridge message was accepted or that the destination contract delivered tokens. A source transaction can also revert, leaving no successful bridge action to complete.

After inclusion, the bridge may require additional conditions before acting on the source event. These can include a confirmation threshold, finality, proof submission, validator approval, or relayer processing. The exact condition depends on the bridge and the chains involved. A bridge status page may label this stage “confirming,” while a source explorer simply shows a successful transaction and a destination explorer has no corresponding transaction yet.

Why is there no matching transaction on the destination explorer?

A destination explorer cannot show a transaction that has not been submitted to its chain. The bridge’s cross-chain system must first observe and process the source action, then arrange destination execution. That work may happen after source confirmation, and its timing depends on the bridge’s mechanism and operating conditions.

When the destination call is submitted, it has a different transaction hash. Searching the source hash on the destination explorer will usually return no result because hashes are scoped to chain data, not to a bridge transfer as a whole. Some bridge interfaces connect the two transactions through a message identifier or transfer record; ordinary chain explorers generally show only the transaction and events they indexed for that chain.

Destination execution can also fail after a successful source transaction. The destination contract may reject a message, a relayer may need to retry, or the destination transaction may run out of gas or revert for another contract-level reason. In a liquidity-based route, a provider may send destination funds before completing its own settlement on the source chain. These designs can make the order of visible transactions differ from a simple lock-then-mint flow.

How should you compare bridge statuses?

Compare the evidence for each stage, rather than treating labels from different explorers as equivalent. Explorer labels are interfaces built over chain data; “success,” “confirmed” and “pending” can refer to different events or indexing states. A bridge’s own tracking page may aggregate more steps, but its status label is still a summary of the route’s state.

• Open the source transaction on the correct chain and check its execution result, block inclusion and bridge-related event.
• Find the bridge’s transfer or message record using the source hash, recipient or route identifier. Check which stage it reports and whether it supplies a destination hash.
• If a destination hash exists, open it on the destination chain and inspect its execution result and token transfer details.
• Verify the destination token contract and recipient. A token with the same ticker can be a different asset, and a successful transfer to another address does not credit the intended wallet.

Do not infer completion from a source-chain success alone. For most users, the clearest completion evidence is a successful destination transaction that transfers the expected token to the intended address. If the bridge record shows source confirmation but no destination hash, the transfer may still be processing; if it shows a destination hash, inspect that transaction before relying on its label.

Which status is the authoritative one?

No single explorer status is authoritative for the entire route. The source explorer is evidence about source-chain execution; the destination explorer is evidence about destination-chain execution; the bridge tracker may connect those events and report intermediate processing. Their views can differ because they index different chains, update at different times and use different definitions of “pending.”

What is confirmed is limited to the transactions and events recorded on each chain, plus any bridge status the route exposes. Whether a missing destination action is merely delayed, requires a retry, or has failed cannot be established from the source explorer alone. Check the route’s own message record and destination execution to distinguish those states.