Crypto Deposit Confirmations: Network and Credit Policy

Identify the transfer precisely

Record the network, asset, destination, amount and observing provider or node. Identify a Bitcoin transfer by network, transaction ID and output index (vout). For a token event, retain network, transaction hash, log or event index and token contract. A transaction can contain several transfers; hash plus asset alone is insufficient. A ticker such as USDT also does not identify the network.

Also retain the invoice or deposit reference and any required address tag or memo. Keep unmatched transfers in an exception process. Neither successful technical receipt nor a correct memo establishes that a business may accept the payment; provider eligibility, custody arrangements and applicable controls require their own approval. For event logs retain block hash and removal status, so a reorganization can invalidate an observation without silently creating a fresh credit.

Choose evidence appropriate to the network

Bitcoin's developer documentation explains confirmations as blocks building on the block containing a transaction. A broadcast transaction has not yet been included, and reorganizations are a reason to distinguish observation from confidence. Historical examples on that page are not a current universal confirmation recommendation.

Ethereum proof-of-stake documentation describes checkpoint-based finality. A raw block count on one network is therefore not interchangeable with another network's finality signal. Specify the network, data source, acceptable state and behavior during degraded or conflicting observations. Review the policy when the network, provider or asset changes.

Define provisional credit and reversals

If the operator permits provisional credit, state exactly which actions it allows and who carries the risk. Displaying an observed deposit need not authorize withdrawal or trading. Store provisional and final states explicitly, with the evidence and policy version behind each transition.

Document what happens when a previously observed transfer disappears, changes canonical position or conflicts with another data source. Avoid quietly deleting a credited transaction. Preserve the observation history, restrict further actions where the approved policy requires it and escalate the discrepancy. A later resolution should identify whether the original credit was confirmed, corrected or reversed and how affected obligations were handled.

Example: two observations are not two deposits

A fictional invoice receives one token transfer reported by a provider callback and then by a node query. Both observations identify network N, transaction H, event index 4 and contract C, with matching destination and amount. They update one transfer record rather than crediting twice. Another event in transaction H needs its own identity and invoice match. If an observation is removed during a reorganization, reconcile the replacement chain evidence before applying the credit policy. No universal confirmation count or waiting time is implied.