Choose a source-chain finality rule, not a universal confirmation count: a Bitcoin transfer may use a block-depth threshold, while Ethereum offers an explicit finalized checkpoint and rollups add their own settlement conditions. The right threshold depends on the value at risk, the destination action’s reversibility, and the bridge’s proof model.
Key points
- Track source inclusion and source finality as separate states.
- Set thresholds per chain and route; block counts are not comparable across networks.
- Do not release irreversible value based only on a relayer’s notification.
Block depth suits chains with probabilistic finality.
A confirmation threshold waits for a transaction’s block to be buried under a configured number of successors. It is simple to implement where the source chain exposes no finality flag, but the threshold is a risk policy, not a guarantee: a reorganization can still remove a deeply confirmed transaction.
Bitcoin’s developer guide describes one confirmation as a sharp reduction in double-spend risk and six as a common threshold for higher-value payments; six blocks take around an hour on average, though block times vary. Treat that as a starting point, not a bridge standard. For a low-value transfer to a reversible destination, fewer confirmations may fit; for a large transfer that triggers an irreversible mint, six or more may be justified.
Store the observed block hash as well as the height. If the canonical hash at that height changes before release, roll the transfer back to “source pending,” remove its provisional credit, and resume monitoring. A height-only check can mistake a replacement block for the block that actually included the deposit.
Protocol finality signals reduce arbitrary waiting.
Where the chain exposes explicit finality, use the protocol’s finalized state rather than picking an equivalent-looking number of blocks. Ethereum proof-of-stake finalizes checkpoints when the required supermajority link is established; ethereum.org describes the two-thirds stake threshold and the distinction between justified and finalized checkpoints.
In your indexer, persist the inclusion block, then wait until the consensus client marks that block finalized. Set a timeout and alert when finality stalls; do not silently convert “not finalized yet” into “safe after N minutes.” A delay may reflect network conditions or loss of finality, and treating it as final defeats the signal you chose.
This model is best when a bridge verifies or consumes native consensus evidence. It does not fit a route whose security instead depends on an external attestor or liquidity provider: their observation and settlement rules are separate trust assumptions. For a relay bridge, explain the route’s proof and settlement condition to integrators so they can distinguish source-chain finality from the service’s transfer status.
Rollup transfers need a settlement-specific threshold.
A rollup’s fast inclusion on its own chain is not necessarily final settlement on its parent chain. The correct wait depends on how the rollup proves its state and what the destination action requires; a bridge must not equate “sequencer accepted” with “withdrawal can no longer be challenged.”
For example, an optimistic rollup withdrawal may require a challenge period after its proof is posted. Use the rollup’s currently configured period and verify the withdrawal’s status against the settlement contract before releasing funds. That is best for native withdrawals whose security relies on the challenge mechanism; it is too slow for an application promising near-instant delivery, which must price in a different risk model or use a separate liquidity route.
Keep the threshold attached to the transfer route.
Represent a transfer as explicit states: source submitted, source included, source finalized or threshold-met, destination submitted, and destination settled. Record the chain ID, transaction hash, block hash, threshold or finality evidence, and policy version used for each transition. Then retries can be idempotent: a repeated event updates the same transfer record instead of issuing a second destination action.
Consider a $2,000 deposit that appears in an Ethereum block but has not finalized. Mark it included, not spendable. If the transaction disappears in a reorganization, remove that provisional state; once the block is finalized, authorize the destination submission. This costs time, but avoids converting an observation into an irreversible credit.
Can I use the same confirmation count on every chain?
No. A block on one chain can represent a different reorganization risk and elapsed time than a block on another, while some chains expose explicit finality and others do not. Configure policy by source chain and route, then test it against the destination action’s reversibility and maximum tolerable loss.
Should a bridge act on a transaction with zero confirmations?
Only if the route deliberately accepts unconfirmed-transaction risk and can absorb a conflicting spend or reorganization. For an irreversible mint or payout, zero confirmations are not a sound default. If the application offers a faster path, make its provisional status explicit and prevent it from being treated as settled value.
What should happen when finality stalls?
Keep the transfer pending, expose the last observed inclusion and finality evidence, and alert when a route-specific timeout expires. Do not mark the transfer failed solely because it is late: the source transaction may still finalize. Recovery should follow the bridge’s documented settlement or refund conditions, with duplicate destination execution prevented by an idempotency key.
When can I lower the threshold?
Lower it only when the value at risk is bounded and the destination effect can be reversed or covered if the source reorganizes. Measure the added reorganization exposure against the latency saved, and review the policy when chain conditions or route mechanics change. Before acting, ask: what loss can this threshold expose the application to?
Top comments (0)