# How a payment confirmation works and what to check What a payment confirmation actually tells you, how many confirmations to wait for, and how to be certain funds are truly settled. --- ## How a payment confirmation works and what to check When you are responsible for disbursing proceeds at the close of a deal — whether that is a real estate sale, a business acquisition, an advisory retainer, or a structured fee split — the moment the payment clears is the moment your professional obligation turns into verified, settled fact. If you are new to onchain payments, the confirmation count sitting next to a transaction hash can seem like a technical detail left to developers. It is not. It is the signal that tells you whether the money is genuinely yours, or still in a state that could, under certain conditions, be reversed. This article explains precisely what a confirmation measures, what depth of confirmation you actually need for the transaction sizes that move in professional deals, and how to read what you see on a block explorer with the same confidence you bring to a closing statement. ## What a confirmation actually measures A confirmation is not a receipt. It is a measure of how deeply a transaction has been buried in the blockchain — and depth is what makes reversal impractical. When a payment is sent, the transaction is first broadcast to the network's mempool, a holding area of unconfirmed transactions waiting to be picked up and bundled into a block. A zero-confirmation transaction is one that has been broadcast to the network but has not yet been included in a block — it resides in the mempool, visible to nodes almost instantly. Visible is not the same as settled. Until a transaction is confirmed, there is no guarantee that it will be included in the blockchain. Block confirmation is the process of validating and adding transactions to a block in a blockchain network. The first confirmation happens the moment your transaction gets included in a block and that block is added to the chain. That single confirmation tells you the network has accepted the payment and written it into the ledger. But one confirmation, depending on the chain, is not necessarily the end of the story. Each new block built atop the one containing your transaction adds another layer of security, making it exponentially harder to alter. The confirmation count you see on an explorer — 1, 3, 6, 14, 50 — tells you how many blocks have been added on top of the block containing your transaction. The higher that number, the more computational or economic work that would need to be undone by anyone attempting to rewrite the history in which your payment exists. Confirmation depth refers to the number of blocks added after your transaction. This number is always increasing. Once a transaction is deep enough, it is considered final for any practical purpose. How deep is deep enough depends entirely on the chain. ## The core risk: why zero-confirmation is not good enough for professional payments The risk of treating an unconfirmed transaction as settled has a name: double-spending. One of the risks of zero confirmation is double spending — a phenomenon that occurs when an individual tries to spend the same funds in multiple transactions. If the initial transaction is not confirmed and included in a block, the sender could potentially attempt to spend the same funds again. Without confirmations, transactions are vulnerable to alteration or reversal through reorgs — a rewriting of transaction history which invalidates recently generated blocks. A reorg is rare on mature, high-hashrate networks, but rare is not zero, and professional disbursements are not the place to absorb tail risk for the sake of saving a few minutes. Chain reorganizations represent the primary finality risk on proof-of-work chains. A reorg occurs when a competing chain fork overtakes the current canonical chain, invalidating transactions that appeared confirmed. The risk is a function of block depth, attacker hashrate, and network propagation characteristics. Beyond the reorg risk, there is also the more mundane fact that if a transaction remains unconfirmed for an extended period, it is possible for it to be reversed or dropped from the mempool. An underfunded gas fee, a sudden spike in network congestion, a mempool that fills up — any of these can cause a pending transaction to stall or be discarded entirely. You see a transaction in the explorer; the payment appears to be in motion. But until that confirmation counter climbs, the money has not truly moved. For the deals professionals handle — commissions on a seven-figure property sale, a fee split on a middle-market acquisition, a closing attorney's disbursement of proceeds to multiple parties — the calculus is clear: you wait for confirmation, and you understand what confirmation depth the network requires for the amount in question. ## Confirmation standards by network Networks differ fundamentally in how they achieve finality, which means the number you need to see on the confirmation counter varies depending on which chain you are using. Treating all confirmations as equal across networks is a mistake. ### Bitcoin Bitcoin uses proof-of-work consensus, and its finality is probabilistic rather than deterministic. Each confirmation makes reversal exponentially more expensive, but no single moment makes it mathematically impossible. The professional standard for Bitcoin is well-established: one confirmation (approximately 10 minutes) provides reasonable security for small transactions under $1,000; three confirmations (30 minutes) for moderate amounts up to $10,000; and six confirmations (60 minutes) for large transactions or exchange deposits — at six confirmations, reversal becomes economically impractical, costing hundreds of millions. One confirmation signifies that your transaction made it into a block. Each subsequent block further cements your transaction on the blockchain. Six confirmations is widely considered "safe" and irreversible for most normal-to-large transactions. For professional deal payments — where the amounts typically dwarf $10,000 and where the professional disbursing the funds has fiduciary obligations — waiting for six confirmations is the standard. Most services wait for six confirmations before considering a payment final, especially for large amounts like $100,000. If you are handling the closing of a commercial real estate transaction or disbursing acquisition proceeds, that one-hour window is a reasonable operational cost against the certainty it provides. ### Ethereum Ethereum moved from proof-of-work to proof-of-stake, which changed its finality model meaningfully. Ethereum requires 12–15 confirmations (roughly 3–4 minutes) for reasonable finality since transitioning to Proof of Stake, though some exchanges require 30+ confirmations for large deposits. Ethereum's finality system works in epochs, and a checkpoint-based finalization mechanism means that once a transaction is finalized by the consensus layer, it carries a stronger guarantee than Bitcoin's probabilistic standard. Ethereum mainnet hits soft finality in about 13 minutes (32 blocks) and is the slowest of the major USDC rails. For high-value professional payments, waiting for that 13-minute soft finality checkpoint is the appropriate standard. ### Solana Solana is architecturally different. It produces blocks extremely quickly and uses a consensus model that provides two distinct tiers of confirmation. Solana offers two tiers of confirmation: "optimistic confirmation" is reached within roughly 400ms when a supermajority (two-thirds or more of stake) has voted on the block. Full finality is stronger: while Solana produces blocks every 400 milliseconds, actual finality takes approximately 12.8 seconds — this is when a supermajority of validators confirm a block as irreversible. From the user's perspective, stablecoin payments on Solana feel fast: a transfer appears in the recipient's wallet within a second, and reaches finality in about 13 seconds. For USDC or USDT transfers on Solana — which is increasingly the rail of choice for onchain professional payments — a confirmation count that has passed the full finality threshold (roughly 32 slots, about 13 seconds) means the payment is done. There is no waiting around for an hour. ### Stablecoins on Ethereum L2s Layer 2 networks like Base and Arbitrum are built on top of Ethereum and offer meaningfully faster confirmation at lower cost. For L2s like Base, Arbitrum, and Optimism, there is a distinction between soft finality (when the sequencer confirms) and hard finality (when the L1 settlement window closes). For practical purposes — wallet-to-wallet, exchange deposits — soft finality is what counts. A USDC transfer on Solana finalizes in roughly 400 milliseconds. On Ethereum L2s like Base, Arbitrum, and Optimism, soft confirmation arrives in about 2 seconds. The practical implication: a stablecoin payment on Base or Arbitrum reaches operational finality in seconds, which compresses deal timing significantly compared to waiting for Bitcoin or Ethereum mainnet confirmations on large disbursements. ## What the block explorer is actually showing you When you look at a transaction on a block explorer, you are reading a live ledger entry. Understanding each field matters if you are verifying a disbursement rather than just glancing at whether something "went through." **Status.** The first thing to look at is the transaction status. You will typically see one of three states: Pending (in mempool, not yet in a block), Confirmed or Success (included in a block, receiving confirmations), or Failed (broadcast but rejected at execution). A failed transaction means no funds moved, regardless of what the sender believes they sent. This matters enormously: a sender can share a transaction hash in good faith on a transaction that never executed. Always check status, not just hash existence. **Confirmation count.** This is the number next to "confirmations" or "block confirmations" on any major explorer. On Bitcoin block explorers like mempool.space, the number appears directly. On Ethereum explorers like Etherscan, you can see the current block number and the block your transaction was included in — the difference between the two is your confirmation count. Some explorers display it directly. Know which network you are looking at before you interpret the number, because three confirmations on Bitcoin and three confirmations on Solana mean completely different things in terms of elapsed time and security depth. **Block height and timestamp.** The block height tells you at what point in the chain's history your transaction was included. The timestamp tells you when that block was produced. If you need to document settlement for a closing file, both of these are useful for establishing timing to the second. **Amount and recipient address.** This sounds obvious, but check it every time. The amount displayed is the actual amount sent — not an invoice amount, not a quoted amount. If there is a discrepancy between what you expected to receive and what the explorer shows, that discrepancy exists on the blockchain and will not self-correct. Verify that the receiving address shown on the explorer matches the wallet address you control or have registered for the receiving party. **Gas fee or network fee.** On chains like Ethereum, the sender pays a gas fee that is separate from the transfer amount. A $500,000 USDC disbursement does not arrive as $500,000 minus gas — the gas is charged to the sender's native asset (ETH), not deducted from the USDC amount. But on some chains and in some configurations, fees are structured differently. Know your network's fee model before you tell a recipient what amount to expect. ## How confirmation requirements scale with transaction size The appropriate confirmation depth is not the same for every deal. The economics of attacking a transaction scale with the value being transferred, which means your confirmation threshold should too. Different use cases demand different security levels. For instance, a coffee shop might accept zero confirmations for small purchases, while an exchange requires many confirmations for large deposits. The logic scales directly to professional deal payments. A $2,500 referral disbursement to a co-broker carries a different risk profile than a $2 million commission split from a commercial acquisition. For Bitcoin: - Under $10,000: three confirmations is a reasonable threshold, representing about 30 minutes. - $10,000 to $100,000: six confirmations is the clear standard. - Above $100,000: six confirmations is the floor. Some institutional participants, including major exchanges, require more — some exchanges require 30+ confirmations for large deposits. For professional disbursements in large deal closings, waiting to see the confirmation count reach double digits before treating the payment as irrevocable is a defensible practice. For stablecoins on Ethereum, Solana, or Base: The calculus shifts because these networks have deterministic or near-deterministic finality. Once a stablecoin transfer on Solana passes the 13-second full finality window, or a USDC transfer on Ethereum clears the 13-minute checkpoint, that is the standard to meet. You are not waiting on probability the way you are with Bitcoin — you are waiting on consensus. The distinction matters when advising a counterparty or documenting settlement timing in a closing file. ## The three-state confusion: pending, confirmed, and final One of the most common sources of professional confusion around onchain payments is the difference between three states that can look identical to the naked eye. **Pending** means the transaction is in the mempool. It is visible on the blockchain explorer. The sender can see it. The recipient can see it. But nothing has settled. These transactions are broadcast instantly but are not yet secured on the blockchain. Unconfirmed transactions wait in a memory pool before miners include them in a block. **Confirmed** means the transaction has been included in at least one block. When a transaction is added to a block, it starts in a confirmed state and the wallet balance is updated. For many chains, one confirmation is enough for practical purposes on small amounts. For large professional disbursements, one confirmation is necessary but not sufficient. **Final** means the transaction has accumulated enough confirmations — or passed a network-specific checkpoint — that reversal is economically irrational or cryptographically impossible. Finality is the guarantee that confirmed blockchain transactions cannot be reversed, altered, or undone — representing the critical moment when blockchain transactions transition from tentative to permanent. Block time is not the same as finality, and finality is not the same as the number of confirmations your exchange requires before it credits the deposit. Knowing which state a payment is in determines whether you can mark a deal closed, release documents, or trigger a subsequent disbursement with full confidence. ## Reading confirmations in the context of a deal closing The practical workflow for a closing professional looks like this. When a payment is expected — a buyer sends stablecoin consideration to a closing wallet, or a platform executes a fee disbursement — you pull up the block explorer for the relevant network, enter the transaction hash, and check three things in sequence: status (confirmed, not pending or failed), confirmation count (relative to the threshold for that network and deal size), and recipient address (the correct wallet, confirmed character for character). Clear confirmation rules help finance teams reconcile payments, trigger order fulfillment, and meet audit requirements. In a deal context, those audit requirements are real. If a party later disputes receipt of funds, your contemporaneous record of the transaction hash, confirmation count at the time of release, and block timestamp constitutes evidence that would satisfy most legal and accounting standards. The confirmation-checking practice is also essential when disbursements are split across multiple recipients. If four parties to a deal are receiving payments simultaneously — the lead broker, the co-broker, the closing attorney, and the advisor — each party has their own wallet address and their own transaction. Each transaction has its own confirmation count. You do not treat the deal as fully settled until you have verified each individual disbursement against its own threshold. When Shaka is used to structure the payment, the router executes each split in a single transaction — every recipient's wallet receives funds directly, simultaneously, and automatically. What you are confirming in the explorer is one transaction that carries all the disbursements, not four separate wires each requiring individual follow-up. The confirmation depth check becomes simpler: one transaction hash, one confirmation count to track, one moment of finality that covers the entire distribution. ## The network congestion variable Confirmation counts accumulate at the pace of the network, and the network is not always predictable. Bitcoin has a limited block size of approximately 1 MB. When too many transactions are submitted, the mempool becomes crowded, and only higher-fee transactions get prioritized by miners. Users set transaction fees, and if the fee is too low relative to current network conditions, miners deprioritize the transaction. This is one of the leading causes of delayed confirmations. This means that a payment broadcast with a low fee during a high-congestion period can sit in the mempool far longer than expected. The explorer shows the transaction. The hash exists. But the confirmation count stays at zero. This is not a failed transaction — it is a stalled one. For a closing attorney with a time-sensitive disbursement, or a broker who needs to confirm payment before releasing documents, a stalled transaction can be operationally serious. The remedies depend on the chain and the wallet software, and generally involve adjusting the fee upward through a mechanism called Replace-By-Fee on Bitcoin, or simply waiting for congestion to clear. But the prevention is more useful than the cure: when disbursements are time-critical, verify that the gas or network fee attached to the transaction is competitive at that moment before broadcast. Most professional-grade payment tools handle this automatically, but it is worth understanding when you are monitoring a payment on the explorer and need to diagnose a slow confirmation. ## Deterministic versus probabilistic finality: a practical distinction The deeper principle underlying everything above is the difference between two types of finality. Blockchains with deterministic finality like Cosmos or Algorand provide absolute certainty in seconds — no waiting period needed. On these networks and on modern proof-of-stake chains like Ethereum post-Merge, finality is an event: the network reaches consensus, a checkpoint is passed, and the transaction is immutable. It is not a probability; it is a state. On Bitcoin, finality is probabilistic. Even after several confirmations, the transaction remains probabilistically final, meaning there's always a non-zero chance of reversal, albeit extremely unlikely under normal network conditions. The conventional standard of six confirmations exists because, at that depth, the economic cost of rewriting history becomes so large that no rational actor would attempt it for the gains achievable from reversing a commercial payment. After six blocks, reversing the transaction would require an attacker to control vastly more computing power than the rest of the network, making it practically impossible. For practical purposes in professional deal work, this distinction matters when setting expectations with clients or counterparties. A client who has just sent stablecoin over Solana should know that finality arrives in roughly 13 seconds and their payment is done. A client who sends Bitcoin should know they will be waiting for six confirmations — about an hour — and that this is not a delay, it is the security model of the network working exactly as designed. Most merchants already operate in a world where "payment accepted" and "payment final" are completely different events. A card swipe feels instant, but the merchant does not have irrevocable funds for days. Chargebacks can arrive months later. Compared to this baseline, even Bitcoin's 60-minute finality is faster than traditional card settlement, and crypto has no chargeback equivalent. That last point is worth holding onto. In the world of bank wires, wire recalls are possible. ACH payments are reversible for days. Chargebacks on card payments can arrive months later. A confirmed onchain payment — past the appropriate threshold for the network and deal size — has no equivalent mechanism for reversal. When the confirmation count is satisfied, that money is settled in a way that virtually no traditional payment instrument can match. ## What you owe a counterparty in terms of confirmation documentation When you are the professional responsible for confirming that funds have been received and disbursed, your counterparties — clients, co-brokers, attorneys, advisors — are relying on your statement that the payment settled. In a world of onchain payments, your documentation should reflect what the blockchain actually recorded, not just what a platform dashboard tells you. Best practice is to note the transaction hash, the network, the block explorer URL where the transaction can be independently verified, the confirmation count at the time of your verification, and the block timestamp. This creates an immutable, auditable record that any party can verify independently, without needing to trust your platform, your word, or a third-party custodian. The information is public and permanent on the blockchain. With each additional block confirmation, it becomes more difficult for an attacker to invalidate previous blocks. The confirmation number is the number of times a block must be confirmed before all transactions included in that block are considered final — allowing the block to reach finality and ensuring that all transactions included in that block cannot be altered or reversed. That permanence is what the confirmation check is ultimately measuring. Not whether the payment happened — the transaction hash proves that. Not whether the amount was correct — the on-chain record shows that. The confirmation count measures whether that payment is now beyond the reach of anyone to undo. For every professional whose job is to make sure money lands where it is supposed to land, that number is the final word.