Crypto custody & compliance · engineering reference
A transaction hash is evidence, not an identity. Start with the chain’s own finality model, then build controls that catch missing, duplicate, and orphaned ledger postings.
This sheet covers the two moments a business actually touches a blockchain: money arriving, and money leaving. Both are conversations with a system you do not control and cannot roll back, and every rule below follows from that.
There is no universal number, and six is a convention rather than a derivation. The real question is what an attacker would have to spend to reverse a block against what you just credited. A chain with a small security budget needs more confirmations than Bitcoin, not fewer because its blocks are fast.
Account-model nonces are strictly sequential per address, so two workers that read the same next value both submit and one of them loses. You need a single writer handing out nonces, and you get throughput by sharding across several hot addresses rather than by parallelising one.
Moving a token out of a deposit address is a transaction sent from that address, and it needs the chain's native coin for gas. Nobody sends you ETH when they send you USDT, so every token sweep is a funding problem with a transfer attached.
No. Exactly-once does not exist against a system you cannot transact with atomically. What you build instead is at-least-once delivery, an idempotency key so a retry returns the original transaction, and a reconciler that keeps comparing your ledger against the chain.
If you remember one lineRecord the intent before you sign it. A signed transaction your system has no record of is the worst state in the pipeline.
The numbers that matter are chain-specific. Copying a confirmation count from one chain to another is a common cause of bad credits.
Four components, one continuous loop. The reconciler is the backstop — it does not wait for an incident report to tighten the confirmation policy.
Record the block hash, height or slot, status, adapter version, and policy version for every decision. A confirmation count on its own is not enough to audit activity across chains.
| State | Customer balance | Withdrawal | Required evidence |
|---|---|---|---|
| Observed | Hidden / pending | Blocked | Transaction parsed; asset identity validated |
| Provisional | May display | Blocked | Canonical block at adapter-defined safe depth |
| Credited | Available by value tier | Risk hold may remain | Chain-native safe/final state |
| Settled | Available | Allowed by policy | Reconciled ledger posting + final chain evidence |
| Orphaned | REVERSE | Freeze derived funds | Previously observed block left canonical chain |
This uses a log axis because a text column hides the gap between a 400 ms slot and a 10-minute target. Cadence is not finality; it only sets the clock that the finality rule runs on.
At every state, decide balance visibility and withdrawal eligibility separately.
Cadences are protocol targets or typical ranges, not SLAs. Your production adapter should query live network state and support an incident override. Last checked August 2026.
| Chain | Consensus | Cadence | Native vocabulary | Credit rule | Critical caveat |
|---|---|---|---|---|---|
| Bitcoin | PoW · probabilistic | ~10 min target | mempool → block depth | 1 / 3 / 6 blocks by value | No protocol-final state |
| Ethereum | PoS · economic finality | 12 s slot | head → safe → finalized | Use safe or finalized | Finality normally spans epochs; query the node |
| Solana | PoS + Tower BFT | ~400 ms slot target | processed → confirmed → finalized | Use commitment parameter explicitly | Finalized means max lockout / rooted |
| Tron | DPoS / SR | ~3 s | latest → solidified | Credit only solidified for withdrawal | Resource and SR behavior differ from EVM |
| BNB Smart Chain | PoSA | Network-upgrade dependent | latest → finalized | Use finality RPC where supported | Never hard-code an old block interval |
| Polygon PoS | Heimdall/Bor + Ethereum checkpoints | ~2 s Bor | Bor inclusion → checkpoint | Separate fast credit from bridge exit | PoS reorg and L1 checkpoint are different states |
| Avalanche C-Chain | Snowman · accepted finality | Sub-second to seconds | processing → accepted | Require accepted | Do not add Bitcoin-style confirmations mechanically |
| Litecoin | PoW · probabilistic | ~2.5 min target | block depth | Value-tiered depth | Security budget differs from Bitcoin |
| Dogecoin | PoW · probabilistic | ~1 min target | block depth | Value-tiered depth | Merged mining does not make depth policies identical |
| Bitcoin Cash | PoW · probabilistic | ~10 min target | block depth | Value-tiered depth | Deep-reorg history requires incident override |
| XRP Ledger | Federated consensus | ~3–5 s ledger | open → validated | Credit validated ledger only | Destination tag is part of deposit identity |
| Stellar | SCP · deterministic | Usually seconds | pending → successful ledger | Successful ledger close | Memo is part of deposit identity |
| Cardano | Ouroboros · probabilistic | ~20 s slot | block depth | Node/venue risk policy | Settlement assurance grows with depth |
| Cosmos SDK / CometBFT | BFT · deterministic | Chain configured | commit | Committed block | Validator-set and chain halts dominate |
| Tezos | PoS with finality | Protocol-version dependent | head → finalized | Use finalized level | Upgrade can change timing parameters |
| Aptos | Jolteon/DiemBFT | Sub-second target | pending → executed | Committed execution | Expiration timestamp is operationally significant |
| Sui | Narwhal/Bullshark lineage | Path dependent | effects certified/checkpointed | Checkpointed for external credit | Fast-path and consensus-path semantics differ |
| TON | PoS sharded | Shard/masterchain dependent | included → masterchain confirmed | Observe masterchain state | Shard routing and memo identity matter |
Each row is a distinct claim about the network's state, not a synonym for "confirmed." Map your adapter's polled field to one of these rows explicitly — don't assume latest or head means the same thing across chains.
| Chain | State | What it actually means | Can revert? |
|---|---|---|---|
| Ethereum | head / latest | Current winner under LMD-GHOST fork choice | Yes, normally |
safe | Block judged safe against reorg under honest-majority and network-synchrony assumptions | Only under abnormal/adversarial conditions | |
justified | Checkpoint has ≥2/3 stake supporting the FFG link | Very difficult, but technically yes | |
finalized | Casper FFG has finalized the checkpoint | Requires ≥1/3 stake to violate safety (and get slashed), or extraordinary social intervention | |
| Solana | processed | Your RPC node processed a block containing the transaction | Yes |
confirmed | ≥66% of stake voted for the block | Extremely unlikely | |
finalized | Tower BFT lockout has reached maximum depth — traditionally 31+ confirmed descendants | Effectively deterministic under BFT assumptions | |
| Tron | head | Block produced by a Super Representative | Yes |
| solidified | ≥19 of the 27 active SRs have progressed to that height or beyond | Treated as irreversible | |
| Cosmos SDK / CometBFT | committed | >2/3 of voting power precommitted the block | Final immediately, under the <1/3 Byzantine assumption |
| Bitcoin | N confirmations | Block has N−1 blocks mined on top of it | Always theoretically yes |
Each additional PoW block makes a reversal more expensive, but it never creates a protocol-final flag.
Concrete use: You might show a 1-block provisional credit while holding a large BTC deposit’s withdrawal availability until 6 blocks.
Failure mode: Using the same count for Dogecoin and Bitcoin ignores their different security budgets.
Reversing a PoS checkpoint requires an exceptional consensus failure and exposes validators to slashing.
Concrete use: On Ethereum, request safe for lower latency or finalized for the strongest standard RPC state.
Failure mode: The JSON-RPC latest tag is not a finality promise.
A sequencer receipt, L1 data publication, and challenge-window completion are three distinct points in the process.
Concrete use: You may credit a small Arbitrum deposit after L1 inclusion, while keeping a bridge-dependent withdrawal locked until the relevant protocol state.
Failure mode: An L2 cannot be more final than the L1 data and state it inherits.
An accepted L1 validity proof establishes state correctness. Data availability and L1 finality are still separate questions.
Concrete use: Track batch inclusion, proof verification, and L1 finalized block as independent fields.
Failure mode: A sequencer UI saying final does not prove L1 settlement.
Screening can reject before a key ever signs. Everything after signing is chain-specific plumbing; everything before it is policy.
Use one durable allocator to lease sequential nonces for each hot address. Workers should never independently poll for the next value.
Concrete use: Lease nonce 418 for 60 seconds, persist request ID and fee fields, then mark broadcast by transaction hash.
Failure mode: Two workers reading pending can assign the same nonce.
One missing nonce blocks every transaction that follows it from the same address.
Concrete use: If 418 is stuck and 419–425 are queued, replace 418 first; do not keep adding higher nonces.
Failure mode: A gap can look like seven unrelated provider failures.
Resubmit the same nonce for the same intent, with a sufficiently higher effective fee.
Concrete use: Keep maxPriorityFeePerGas and maxFeePerGas under a policy ceiling, then reconcile whichever hash lands.
Failure mode: A replacement creates multiple hashes for one withdrawal intent.
Because nonce serialization is per sender, throughput comes from multiple funded hot addresses.
Concrete use: Route withdrawals predictably across 8 addresses, while keeping one writer for each address.
Failure mode: Sharding multiplies gas, reconciliation, policy, and rebalancing surfaces.
The fee examples illustrate the arithmetic; they are not fee recommendations. Query a current node estimator and enforce a maximum fee policy.
| Operation | Control | Worked value | Do not |
|---|---|---|---|
| Coin selection | Minimize input cost, change, and privacy leakage | At 20 sat/vB, a 68-vB input costs ~1,360 sat to spend | Select nominal value without effective value |
| Batching | One transaction, many outputs | 10 P2WPKH outputs avoid repeating 10 transaction overheads | Mix incompatible urgency or screening states |
| RBF | Replace an opt-in unconfirmed transaction | Same inputs; higher fee; preserve withdrawal identity | Credit both hashes |
| CPFP | Spend a low-fee parent output with a high-fee child | Package feerate must clear the target | Assume every output is spendable |
| Consolidation | Merge small UTXOs during low-fee windows | Only consolidate inputs whose future fee saving exceeds current cost | Create one operationally catastrophic mega-UTXO |
| Descriptor scan | Derive monitored addresses with an explicit range | Persist last-used index and scan beyond configured lookahead | Rely on an implicit gap limit |
An address holding tokens still needs the chain’s native asset to pay execution fees.
Concrete use: Detect USDC, estimate sweep gas, fund only the bounded amount, then sweep and reconcile both transactions.
Failure mode: Pre-funding every address strands native asset and expands attack value.
The chain and token contract identify an asset. Its symbol and decimals are display metadata.
Concrete use: Credit only the allowlisted Ethereum USDC contract and read its configured 6 decimals.
Failure mode: A fake token can emit the same symbol and Transfer event.
Some chains route many users through one address, so the tag is part of the account key.
Concrete use: Store (chain,address,tag) and hold unmatched XRP deposits for operations review.
Failure mode: Address-only indexing miscredits or strands deposits.
Zero-value or dust transfers can plant a lookalike address in a user’s history.
Concrete use: Never populate destinations from recent on-chain counterparties; use authenticated address books.
Failure mode: Prefix/suffix visual checks are weak against generated lookalikes.
Fee-on-transfer tokens, rebasing, and contract-originated moves can break simple amount assumptions.
Concrete use: Credit the observed balance delta after finality, not the requested calldata amount.
Failure mode: Transaction success does not imply the expected token amount arrived.
Your balance tolerance should be zero. Put timing differences in explicit in-flight accounts, not in an unexplained reconciliation allowance.
| Mismatch | Detection | Likely cause | First response |
|---|---|---|---|
| On-chain, no ledger | Finalized inbound absent internally | Indexer/webhook loss | Pause auto-sweep; backfill by block range |
| Ledger, no chain | Broadcast intent has no accepted hash | Timeout/crash before broadcast | Query provider by idempotency ID before retry |
| Duplicate credit | Same transfer identity posted twice | At-least-once delivery | Reverse duplicate journal entry; fix uniqueness key |
| Orphaned credit | Credited block no longer canonical | Reorg | Freeze derived availability; post compensating entry |
| Amount mismatch | Observed delta differs from ledger amount | Decimals/fee-on-transfer | Quarantine asset adapter |
| Wrong network | Supported address, unsupported chain | User routing error | Do not automate recovery; assess key/control path |
| Fee drift | On-chain fee ≠ booked expense | Replacement or estimator error | Attach all hashes to one intent and settle actual fee |
| In-flight snapshot | Invariant break clears next cycle | Timing boundary | Model in-flight account explicitly; do not use tolerance |
Run this list before enabling a new chain or asset.
If a primary record does not establish a trustworthy depth, do not invent one. No number is safer than a false confirmation rule.
| Network / date | Observed event | Evidence | Engineering consequence |
|---|---|---|---|
| Bitcoin · 2013-03-11 | 0.8/0.7 consensus split from Berkeley DB lock behavior | BIP 50: fork at height 225,430; experimental double-spend documented | Suspend on node-version disagreement; height is not a unique ID |
| Bitcoin · 2013-08-16 | Unpatched nodes forked at block 252,451 | BIP 50 resolution record | Track consensus alerts and client versions, not depth alone |
| Ethereum Classic · 2020-07-31 | Successful 51% reorganization attack | Project history | Static confirmation policy can become obsolete during attack |
| Ethereum Classic · 2020-08-06 | Third successful 51% reorganization attack | Repeated within one week | Pause can be safer than adding a few blocks |
| Ethereum Classic · 2020-08-29 | Fourth successful 51% reorganization attack | Repeated in same month | Security budget and incident state govern policy |
Set bands from your loss tolerance and the chain’s attack economics. Never treat one confirmation count as an inherent property of every asset.
| Tier | Credit | Withdrawal | Incident overlay |
|---|---|---|---|
| Low | Provisional at conservative safe level | Hold until settled | Raise or pause automatically |
| Medium | Chain-native safe/final state | Additional risk/KYT hold | Manual release during instability |
| High | Strongest final state + independent node agreement | Human approval after reconciliation | Pause on fork/finality alarm |
We checked the operational and volatile claims against these first-party documents on 2026-08-31. The examples illustrate controls; they are not legal, investment, or vendor-selection advice.