Blockchain transaction finality

Blockchain transaction finality is the assurance that a transaction recorded on a blockchain will stay in its accepted history. The network's consensus rules determine how that assurance is established. For a trading desk reconciling a deposit, the first sighting of the payment, its status on the network and the credit to the trading account are separate events.

A fictional Bitcoin payment appears in block A100 at height 100. The node's active chain ends at A105. Bitcoin Core's getblock counts the inclusion block itself, so the payment has six confirmations and five successor blocks. At first inclusion, when A100 is the tip, the count is one. Bitcoin Core block depth implementation

Now suppose another valid branch from block 99 overtakes branch A in cumulative proof of work. The node switches to branch B, a chain reorganisation. The new tip is B106 and branch B omits the payment. A100 and B100 share a height but have different block hashes. A getblock query for the old block by hash now reports -1 confirmations if the block data is available. The payment's current inclusion must be checked separately. Bitcoin Developer Guide on forking · Bitcoin Core getblock RPC

Bitcoin provides probabilistic finality. In Nakamoto's model, an attacker with a fixed minority of hash power is less likely to catch up from a larger deficit. The attacker's private progress is unobserved, and the public confirmation count alone leaves reversal risk undetermined. Nakamoto's catch-up model, §11

Ethereum's proof-of-stake design uses Casper FFG to finalise checkpoints. Validators vote on links between checkpoints, with a supermajority requiring at least two-thirds of active stake by effective balance. In the usual consecutive-epoch case, a supermajority link from a justified checkpoint to the next one justifies the newer checkpoint and finalises the older one. A transaction is finalised when its block is the finalised checkpoint block or one of its ancestors. A chain can keep adding blocks while finalisation stalls if too little stake votes. Ethereum finality documentation · Consensus specification for justification and finalisation · Fork choice specification

For a common validator set and fixed stake weights, finalising conflicting checkpoints requires slashable votes from validators representing at least one-third of the stake. That safety condition concerns validator behaviour. Counting more blocks above a payment gives no universal settlement threshold across networks. Casper FFG accountable safety, §2.1

A custodian or exchange can keep a deposit pending until it meets the provider's confirmation policy. A reconciliation record can pair the network, transaction ID, inclusion block hash and time-stamped confirmation or finality observations with the provider's credit timestamp. If the payment disappears from the active chain, that record distinguishes lost on-chain inclusion from a payment still waiting for an account posting. Coinbase deposit-status documentation