A Bitcoin reorganisation can delay recognition of a deposit because its block may be replaced. A swap protocol waits for the deposit to reach a configured depth before treating it as spendable input; each added block makes reversal less likely, but costs roughly ten minutes on average. That buffer protects settlement, and the required depth determines the usual wait.
A reorganisation can remove a deposit that looked confirmed
A Bitcoin transaction has one confirmation when it appears in a block; each block built on top adds another. Because miners can find competing blocks, nodes may briefly disagree about which valid chain has the most accumulated proof of work. If the competing branch wins, Bitcoin reorganises to it, and transactions in the displaced blocks return to the mempool if still valid.
Think of the transaction’s block as a page in a ledger being copied across a network. More pages copied on top make it increasingly costly for another version to replace that page, but there is no protocol-level moment when a probabilistic chain becomes mathematically irreversible. A swap system therefore sets an operational threshold rather than waiting for certainty.
For an active trader, the useful distinction is between broadcast, included, and recognised by the swap protocol. A high miner fee can improve the chance of timely inclusion, but it does not make the included block deeper; after inclusion, block production and the protocol’s confirmation rule dominate the wait.
Validators wait for depth before registering the input
For a Bitcoin-to-other-chain swap through Chainflip, validators watch the deposit channel and wait until the source transaction reaches the protocol’s required block depth. They then witness and register the deposit on the State Chain, where it can enter swap processing. This sequencing avoids committing the protocol’s liquidity against a source-chain payment that could still be removed.
Chainflip documentation describes Bitcoin recognition at three confirmations, about 30 minutes at Bitcoin’s ten-minute average block interval. The exact requirement is a protocol parameter and may change; the broker SDK exposes a per-chain required-confirmations value, and its example values are illustrative rather than a guarantee of today’s setting. For repeated swaps, check the live parameter before estimating latency.
The end-to-end sequence is straightforward:
- The transaction reaches a miner’s mempool; its fee rate influences when it is selected.
- A miner includes it in a block, giving it confirmation one.
- Bitcoin adds blocks, increasing its depth and reducing ordinary reorganisation risk.
- Once the configured threshold is met, validators witness the deposit and register it.
- The swap is processed, then the destination-chain transaction must also be included and confirmed under that chain’s rules.
The threshold is not a promise that the destination transfer appears exactly 30 minutes after broadcast. Broadcast-to-inclusion time varies with mempool demand and fee rate; block intervals vary stochastically; and State Chain witnessing and destination settlement add their own time. The 30-minute figure estimates only three average Bitcoin block intervals after inclusion.
Depth trades latency against the cost of reversal
A shallow threshold reduces expected delay but leaves more exposure to a reorganisation or deliberate double spend. A deeper threshold reduces that exposure, while adding roughly ten minutes of expected waiting for every extra Bitcoin confirmation. Six confirmations, often cited for high-value payments, means about an hour from inclusion on average; it is a conservative convention, not a universal guarantee of finality.
For example, suppose a deposit is included promptly and Chainflip’s active threshold is three confirmations. The expected source-chain wait is about 20 minutes after the inclusion block: that block is confirmation one, followed by two more. A user who sees the transaction in a wallet or explorer after the first block may still have roughly two block intervals before protocol recognition.
Bitcoin fees affect the first part of the timeline, not the depth rule. Paying a higher fee rate may get a transaction mined sooner during congestion, but once it is in a block, the protocol still counts subsequent blocks. A fee bump can help an unconfirmed transaction through Replace-by-Fee when the wallet and transaction permit it; it cannot accelerate Bitcoin’s block production.
Fast paths move risk instead of removing it
Some swap flows can proceed with fewer confirmations by assigning the reorganisation exposure to liquidity providers. Chainflip Boost, for example, is documented as allowing eligible Bitcoin deposits to proceed after one confirmation, with liquidity providers taking the loss if a reorganisation removes a boosted deposit. That can save expected time, but it relies on available risk-bearing liquidity and does not make the source transaction more final.
The trade-off is most relevant when the source asset is Bitcoin and the destination is time-sensitive. A faster path can reduce waiting, while its liquidity or risk premium may make it more costly; ordinary confirmation avoids that particular risk transfer and waits for the configured depth. If the fast path is unavailable or skipped, the deposit falls back to the normal confirmation requirement, so don’t build a deadline around the optimistic case.
When I need a predictable estimate, I separate three quantities: time to first inclusion, remaining blocks to the live source threshold, and destination-chain settlement. For a standard Bitcoin deposit, confirm the current Chainflip requirement and use about ten minutes per remaining block as an average, not a countdown. If you’re ready to swap Bitcoin with Chainflip, choose the route with the latency and risk allocation that fit the trade, then allow room for both chains to settle.
Top comments (0)