Why a Bridge Deposit Can Change Status After a Reorg

A bridge deposit can change from confirmed to pending when the source chain reorganizes recent blocks and removes the block that contained it. The bridge may have seen the deposit before the source chain settled on its current history. For more on the mechanics and trade-offs of moving assets between chains, see manta bridge. A status change alone does not tell you whether funds are lost; it tells you to check which step the bridge has reached.

What happens during a bridge deposit reorg?

A reorg happens when a chain’s consensus rules select a different recent block history as canonical. A transaction in a dropped block no longer counts as confirmed in that history. It may be included again in a later block, but until then, an explorer or bridge interface may show fewer confirmations or mark the deposit as pending, failed or reverted.

The deposit moves through several parts. First, you submit a transaction on the source chain. Validators or miners include it in a block. The bridge’s contract, relayer or other monitoring system detects that block and applies its own waiting rule. Once that rule is met, the bridge may release or mint the corresponding asset on the destination chain.

Think of the bridge as waiting for a receipt to stay in the source chain’s ledger. A reorg can invalidate that receipt before the bridge treats it as reliable. The bridge’s exact rule matters: systems differ in how many confirmations they require, whether they wait for explicit finality, and how they handle a deposit that disappears.

What should I check when the status changes?

Start with the source transaction, because that is where the deposit originated. Use its transaction hash in the source chain’s explorer and check whether it appears in the current canonical chain. Then check the bridge’s deposit record and the destination chain for any release or mint transaction.

• Still included: If the source transaction remains in a canonical block, check whether the bridge is waiting for more confirmations or finality.
• Missing after the reorg: The deposit may need to be included again before the bridge can process it. Check the wallet and source chain before taking another action.
• Destination transaction exists: Confirm its status on the destination chain. A source-side status update may lag behind a completed destination action.

Do not submit a second deposit just because the interface changed status. First establish whether the original transaction is still active and whether the destination side already processed it. A repeated transaction can move more funds than you intended if the original deposit later succeeds.

When is the deposit considered settled?

Settlement depends on the source chain and the bridge’s acceptance rule. Some chains use probabilistic finality: each additional block makes a recent transaction less likely to be removed, but does not create a single finality switch. Other chains expose a finalized state through their consensus process. A bridge can choose to wait for that state or use a confirmation threshold of its own.

Read the bridge’s status labels as reports about its process, not as a universal guarantee. “Confirmed” may mean the source transaction has enough confirmations for that bridge; it does not necessarily mean the transaction is irreversible. “Completed” should be checked against the destination chain’s transaction record.

The practical rule is simple: follow the transaction hash from source inclusion through the bridge’s acceptance rule to the destination transaction. A reorg changes the source chain’s recent history. Whether that changes the outcome depends on when the bridge acted and what its rules require.