A transaction appearing in a block is an observation. Treating the resulting balance as available collateral or releasing an offchain payment is a business decision. Institutions need a clear policy connecting the two. That policy becomes especially important when a network reorganises its recent history or continues producing blocks without reaching finality. A dashboard marked successful can conceal several stages that carry different consequences for settlement, accounting and counterparty exposure.
Inclusion is not the finality rule
Blockchains do not all provide the same assurance. Ethereum explains the distinction between probabilistic finality, where confidence increases as blocks accumulate, and its proof-of-stake finality, where checkpoint votes establish an explicit finalised state. There is no universal confirmation count that can be copied across networks. A rule must identify the chain and the particular assurance on which the business relies.
For Ethereum, the consensus documentation describes checkpoint finalisation through votes representing at least two-thirds of staked ether. This is an economic security mechanism with defined assumptions. It does not answer whether a particular transfer discharged a contractual obligation. Our discussion of central bank money and tokenised settlement explains why the settlement asset and legal framework remain separate questions.
Give provisional balances their own state
An institution should distinguish observed, included, sufficiently confirmed or finalised, and available for use. The names matter less than consistent treatment. A provisional deposit may be visible to operations without becoming withdrawable client money. A collateral receipt may be tracked without immediately supporting new lending. Define which transitions are automatic, which need review and what happens if a previously observed transaction disappears from the canonical history.
Consider a hypothetical collateral transfer that appears onchain and triggers release of cash elsewhere. If the transfer is later removed from the accepted chain, the cash leg may already be irreversible. The exposure arose from the institution choosing to act on provisional evidence. Waiting for the specified finality condition can reduce that risk, but it can also delay funding. Make that trade-off explicit in the product design rather than leaving it to individual operators.
Plan for a network that does not finalise
A finality delay is different from a complete outage. New blocks and transactions may remain visible while the assurance needed for settlement has stopped advancing. Monitoring only the latest block timestamp can therefore report healthy service during an economically relevant incident. Track the finalised checkpoint or the network-specific equivalent, the age of pending business transactions and agreement between independent observations of chain state.
When the required condition is not met, the default workflow should hold the dependent action and alert the responsible team. Document who can approve a temporary change, the exposure limit and the affected counterparties. Extending credit against provisional receipts is a credit decision and should be recorded as such. It should not be hidden inside a technical adjustment to the confirmation setting.
Reorganisations need a ledger response
The transaction-processing system should be able to reverse provisional observations without deleting the audit trail. Retain the original block identifier, the event that removed it and any replacement observation. Link those records to the business instruction so a transaction appearing in another block is not counted twice. This is particularly important for systems that react automatically to deposit notifications or contract events.
Test the process with a simulated reorganisation and with stalled finality. Check client balances, collateral eligibility, exception queues and reporting exports, not only the node response. Our review of RPC provider dependence supplies the infrastructure context. The institutional standard is a coherent settlement policy: what evidence permits each financial action, how exceptions are authorised and how the books respond when provisional evidence changes.
Treat finality settings as product settings
Changing a confirmation rule can alter client availability, collateral eligibility and counterparty exposure. Put those changes through the same governance used for other settlement terms. The record should state the affected asset and network, the old and new conditions, the business reason and the expected financial impact. Review historic pending transactions as part of the release so the new rule does not unexpectedly free a backlog of provisional balances. This gives operations a defensible explanation when a client asks why a transfer is visible but cannot yet support a withdrawal.