Bridge finality is not the first check mark in a wallet. Separate the source-chain transaction, the bridge’s verification of its message and execution on the destination chain. Each stage has its own conditions, and a successful first stage does not establish that the recipient has spendable funds.
The transfer has several stages
A confirmed deposit shows inclusion on the source network. The bridge still has to recognise the event under its own rules and arrange delivery. Destination execution may require gas, available liquidity or a separate claim. Check the actual transfer route rather than assuming every bridge uses the same sequence.
An illustrative withdrawal
With a canonical withdrawal from an optimistic rollup, L2 confirmation can precede a challenge window and a later L1 step. A faster service may advance liquidity, but does not magically shorten every protocol guarantee. It adds its own conditions. The relevant waiting periods depend on the system and route used.
Further reading: related technical explainer.
Evidence to keep
Record the source hash, network, recipient and message identifier where applicable. Check the official bridge interface and documentation, then the destination transaction when one exists. Estimated completion times are not guaranteed deadlines. Two explorers may display different stages of the same transfer without either being wrong.
Further reading: connected operating guide.
Do not duplicate a pending deposit
Sending again can create another transfer rather than release the first. Before signing a claim or changing fees, establish that the protocol actually requires that action. Never disclose recovery secrets to someone offering faster processing or approve a contract supplied through an unsolicited private message.
Further reading: security checklist.
Speed is only one part of risk
Light clients, validator groups, multisignature arrangements and attestations have different trust assumptions. Quick delivery can still depend on vulnerable contracts or an intermediary. Compare the exact asset received, net amount, exit route and all-stage costs, not just the advertised number of minutes.
An interface failure or a transfer failure?
If the interface stops updating, separate display problems from transaction state. A browser message is not on-chain evidence, but a source hash alone does not prove delivery either. If the documented statuses remain unclear, use official support and provide only the necessary public identifiers. A second deposit is not a diagnostic test of the first.
Resources needed after delivery
A balance on the destination network may not be ready for the next operation. You might receive a token without holding the asset needed for gas. Check that requirement and any minimum amount before starting. The operational cost includes being able to use or withdraw what arrives, not merely obtaining a success notification.
Compare equivalent routes
Record starting amount, net receipt, exact destination asset, manual steps and external dependencies. Compare the same amount and destination using estimates taken together. Better pricing can come with slower delivery or different trust assumptions. Neither a confirmation count nor a time estimate summarises all of these trade-offs.
Practical checks
- treating source confirmation as completed delivery.
- confusing an estimated time with a guarantee.
- sending twice when a relayer is delayed.
- ignoring the canonical versus fast route distinction.
- approving unlimited token spending for a one-off bridge.
