Confirmation Tracking

Overview

A tracker begins by locating the transaction through a node, indexer, or provider. Before inclusion, it may inspect mempool status, fee competitiveness, nonce dependencies, or replacement activity. After inclusion, it records the block hash and calculates confirmations against the current canonical tip.

Each new block can increase confidence, but the tracker must detect when the original block is no longer canonical. It may then reduce confirmations, locate the transaction in a replacement block, or return it to pending status. For smart-contract transactions, it should also verify execution success and relevant event logs.

Tracking systems need durable checkpoints and retries because WebSocket events and callbacks can be missed. Multiple data sources can improve resilience, but disagreements require a defined resolution strategy.

Merchant workflows should map blockchain tracking states to invoice states without conflating them. “Detected,” “confirming,” and “finalized” communicate different levels of assurance. The tracker also provides evidence for support, refunds, and reconciliation by preserving every important state transition.

Tracking can continue after the initial business action when residual risk remains. High-value deposits may be monitored until explicit finality, and bridge transactions may require destination-chain completion. The system should make each state transition auditable and prevent an old provider callback from overwriting a newer canonical status. This requires event ordering, version checks, and durable transaction history rather than a single mutable status field.

Privacy should also be considered. Tracking through third-party explorers or APIs can reveal which addresses and transactions interest the application. Self-hosted nodes or privacy-aware provider designs may be appropriate for sensitive operations.