A destination-chain reorg can erase a bridge credit for several blocks; on Ethereum, finality usually takes around 13–15 minutes, so a receipt alone is not an irreversible payout signal. For treasury operations, treat source acceptance, destination inclusion and destination finality as separate states. A transfer can be valid on its source chain while its apparent credit is still reversible on the destination.
A destination receipt is provisional until its block is stable
A reorg replaces a chain’s recent canonical blocks, which can remove a transaction and its logs from the active history. The balance change then disappears from the recipient’s canonical state, even if an RPC endpoint previously returned a successful receipt. The source-chain transaction is not automatically undone: the bridge debit or message may remain valid while the destination execution needs to be reconciled.
This distinction matters in a how to move assets with Mantle bridge flow: a transfer can cross from one network to another, and the destination’s confirmation policy determines when treasury can safely book the proceeds. If Mantle is the destination, its sequencer can show a fast soft confirmation before the corresponding state is anchored and settled against Ethereum. Mantle’s SDK exposes a configurable depositConfirmationBlocks parameter for L1 deposits, a reminder that confirmation depth is a policy input, not a universal number.
On Ethereum, a block receipt is not the same as consensus finality. Slots are 12 seconds and epochs contain 32 slots; finality normally takes roughly two epochs, or about 13 minutes under normal participation. The Ethereum Foundation’s documentation describes finalized blocks as economically costly to reverse, not metaphysically impossible to change. For lower-value operational updates, a team may use a shorter confirmation threshold, but should label the resulting credit provisional.
Set the payout threshold by destination and exposure
Use the destination chain’s own finality signal where available; otherwise define a confirmation depth, N, that matches the chain’s block cadence, reorg history and loss tolerance. A rule such as “wait 12 blocks” has no consistent meaning across networks: on a 2-second chain it is about 24 seconds, while on a 12-second chain it is about 144 seconds. Treat a block-count threshold as a risk limit, not a proof that a reorg cannot happen.
For example, imagine a business bridges 50,000 USDC to fund a same-day supplier payout. Its destination monitor sees a successful receipt at block 20,000, then that block is orphaned before the payout ledger is finalized. If the business already sent the supplier payment, it has an unreconciled exposure; if it waited for its chosen finality threshold, it can keep the bridge credit pending and avoid paying against a vanished balance.
Choose the threshold based on the amount at risk and the cost of waiting. A practical treasury policy can release small routine transfers after a conservative confirmation depth, while requiring finalized status or manual review for larger payouts. On Ethereum, waiting for finalized typically costs about 13–15 minutes; waiting only for safe is faster but remains exposed to a significant L1 reorg. If the destination is an L2, check whether its RPC distinguishes unsafe, safe and finalized; a sequencer’s immediate inclusion response is not equivalent to parent-chain finality.
Reconcile by transaction identity before retrying
When a destination receipt disappears, first check whether the transaction remains in the canonical chain, is pending, or was dropped. Query a second independent RPC, inspect the current block hash and receipt, and compare the bridge message or transfer identifier with the source event. A transaction that was reorged may be re-included without a new source transfer; submitting another bridge transfer immediately can therefore create a duplicate credit.
If the destination execution is genuinely absent, the next action depends on the route’s design. A relayer may rebroadcast an eligible destination transaction, while a user-submitted transaction may need a replacement using the same account nonce and a suitable fee; neither behavior is guaranteed across services. Keep the source event and message ID as the idempotency key, and reconcile balances and logs before initiating a fresh transfer. When using a Mantle bridge, record destination inclusion separately from source completion so a reorg does not cause an automated payout or retry to run twice.
- Track source acceptance, destination inclusion and destination finality as separate states.
- Set a chain-specific threshold against the value and timing of each payout.
- After a reorg, verify the canonical receipt and reconcile by message ID before retrying.
Top comments (0)