How to show cross-chain transfer status in an app

An app should show a cross-chain transfer as a sequence of verified events, not a single “sent” label. Track the origin transaction, the bridge’s processing step and the destination transaction separately; mark the transfer complete only when the destination action is confirmed to the standard the app defines.

What status should a cross-chain transfer show?

Show the latest stage and what evidence supports it. A useful status sequence is:

• Submitted: the app has received the request, but the origin transaction is not yet confirmed.
• Origin confirmed: the source-chain transaction is included and has met the app’s confirmation threshold.
• Bridge processing: the bridge is verifying, relaying or waiting through a protocol-specific step.
• Destination confirmed: the destination-chain transaction has been found and confirmed.

Not every route exposes a separate bridge event. In that case, say “waiting for destination” and explain the last verified event, rather than implying the bridge is stuck or finished. For a fuller look at Ethereum-to-L2 routes, the article on super bridge designs compares how route mechanics affect that middle stage.

What evidence should the app display?

Attach each state to its own chain and transaction. Show the network name, transaction hash, timestamp, amount and token, plus a link to the relevant explorer if the app has a verified URL for it. Keep the origin and destination hashes distinct: one transfer may involve two transactions, and a bridge may expose additional identifiers.

Use chain-specific confirmation rules. A transaction appearing in a block is not always the same as being final; the app should state whether its label means included, confirmed after a chosen threshold, or final under that chain’s rules. Do not present an estimated arrival time as a guarantee.

How should the app handle delays or failures?

Keep the last verified state visible and add a plain explanation of what is pending. If the origin transaction fails, report that; if it succeeds but no destination event is found, report that the transfer is awaiting destination evidence. Do not infer failure from elapsed time alone.

For most apps, the clearest design is a compact timeline with one status per stage, timestamps, and links to the available transaction records. That gives users a way to check progress without treating an origin-chain confirmation as proof that the destination funds have arrived.