How a Crypto Transaction Gets Confirmed

A crypto transaction is confirmed in stages: the wallet signs it, nodes check and relay it, a miner or validator puts it in a block, and later blocks pile on top until reversal is very unlikely or, on Ethereum, formally finalized. So "confirmed" means different things depending on the network and on who uses the word.

Key takeaways

One confirmation means the transaction sits in a block; each later block adds one. On Bitcoin, depth lowers the chance of reversal but never makes it formally final.
Bitcoin blocks arrive every 10 minutes on average but randomly: the next block takes over 30 minutes about 5% of the time, and six confirmations take 60 minutes on average with a standard deviation of about 24.5 minutes.
Ethereum labels blocks safe (unlikely to be reorganized under stated assumptions) and finalized (not reversible without manual intervention); finality takes about 15 minutes.
The confirmation counts exchanges demand are their own policies; one published example is three for Bitcoin.
A Bitcoin Core node drops an unmined transaction after 336 hours (14 days) by default, or sooner if its mempool fills, so "pending" does not last forever.

Signing and broadcasting

Step 1: create and sign

A wallet assembles the transaction: on Bitcoin, the unspent outputs it spends and where the value goes; on Ethereum, the recipient, amount, data and a nonce, a counter that numbers the transactions sent from an account in sequence. It signs the data with the private key, and the result is hashed into a transaction ID that identifies it from then on.

Step 2: broadcast to peers

The wallet hands the signed transaction to a node. On Bitcoin, a node announces it to peers with an inv message; a peer that wants it answers with getdata, and the node sends it, as the Bitcoin developer guide on the peer-to-peer network describes. Each peer that finds it valid forwards it the same way, so it spreads in hops. On Ethereum, too, the transaction is broadcast and added to a pool of pending transactions.

Step 3: node checks and the mempool

The developer guide says each peer and miner validates the transaction independently before relaying it, and that nodes on default Bitcoin Core settings will not relay or mine non-standard transactions. The community-maintained protocol rules page lists the checks (as the original client ran them, not every current node):

It is well formed (non-empty inputs and outputs, amounts in the legal range) and not already in the pool or a block.
Every input refers to an output that exists and is unspent; this is the double-spend protection.
Inputs are worth at least the outputs, and the fee is not too low.
Each input's script verifies. If an input's parent is unknown, the transaction is held as an orphan until the parent arrives.

Transactions that pass wait in the node's memory pool, or mempool. The pool is not a shared ledger: each node keeps its own, so two nodes can hold slightly different sets of waiting transactions at the same moment. Older documentation calls the pool non-persistent, but current Bitcoin Core saves it to disk on shutdown and reloads it on start by default.

Inclusion and confirmation counts

Step 4: inclusion in a block

A miner (Bitcoin) or validator (Ethereum) picks transactions from its pool for a block; on Ethereum, a transaction must be included in a block before it counts as successful. Other nodes verify the announced block, and the transaction leaves their mempools.

Step 5: confirmations as blocks on top

The block containing the transaction gives it its first confirmation, and each later block adds one. Exchange help pages count the same way. If the block sits at height 900,000 and the chain tip is at 900,005, the transaction has 6 confirmations (900,005 - 900,000 + 1); these heights are made up to show the arithmetic.

What platforms require is policy

No protocol rule sets a required number of confirmations; whoever accepts the funds chooses it. As a dated example, Kraken's deposit-processing page, last updated October 5, 2026, states that it credits Bitcoin deposits after three confirmations, about 45 minutes by its own estimate, because it assumes a 15-minute average block rather than the 10-minute protocol target discussed below. Other platforms publish other numbers, and they change, so the figure that counts is the receiving platform's current one. This example illustrates the mechanism, not a recommendation of any provider.

Reorgs and finality

Why a block can be replaced

Two miners can find blocks at nearly the same moment. Nodes usually use the first block they see, then follow the chain with the most proof of work and discard blocks on shorter forks (stale blocks). Transactions from a stale block can return to the mempool and be mined again, but if a conflicting spend wins, the original payment fails: this is reorganization, or reorg, risk. The Bitcoin whitepaper's analysis in section 11 shows that, for an attacker with less hash power than the honest network, the odds of rewriting history drop exponentially as blocks accumulate.

Bitcoin: probabilistic settlement

Bitcoin has no "finalized" flag; settlement is a probability that rises with depth. One protocol rule does hard-code depth: newly created coinbase outputs cannot be spent for at least 100 blocks, so a miner cannot spend a reward from a block that later turns stale.

Ethereum: justified, safe and finalized

Ethereum's proof-of-stake chain divides time into 12-second slots and 32-slot epochs. The first block of each epoch is a checkpoint. When validators holding at least two-thirds of staked ETH vote for a checkpoint it becomes justified, and the earlier checkpoint in the pair becomes finalized; reverting it would require destroying at least one-third of total stake. ethereum.org puts the wait at about 15 minutes for a block to finalize. From the published lengths, an epoch lasts 32 × 12 = 384 seconds (6.4 minutes), and a block waits for the rest of its epoch plus about two more: roughly 12.8 to 19.2 minutes under healthy conditions.

Software can request these levels directly. The Ethereum execution API schema defines the tags:

Block tag	Meaning in the schema
`latest`	Most recent block in the canonical chain the client has seen; it may be reorganized out even under normal conditions
`safe`	Most recent block considered safe from reorgs under honest-majority and certain synchronicity assumptions
`finalized`	Most recent crypto-economically secure block; cannot be reorganized outside of manual intervention

The JSON-RPC documentation lists the same tags. An application that credits money at latest accepts more reorg risk than one that waits for finalized.

Waiting-time math for Bitcoin

Bitcoin's difficulty is set so blocks arrive every 10 minutes on average; the reference source sets a target spacing of 600 seconds and a retarget timespan of two weeks (2,016 blocks). Mining is a repeated lottery, so a standard model treats arrivals as a Poisson process: gaps are exponentially distributed, and the next block does not care how long ago the last one came. Hash-rate changes between difficulty adjustments shift the real numbers.

P(next block within t minutes) = 1 - e^(-t / 10)
P(k blocks within t minutes)   = 1 - sum for i = 0..k-1 of [ e^(-t/10) * (t/10)^i / i! ]
Mean time for k blocks = 10k minutes; standard deviation = 10 * sqrt(k) minutes

Here t is elapsed minutes, k the number of confirmations wanted and 10 the mean gap in minutes. It assumes the transaction makes the very next block.

Minutes after broadcast	Chance of at least 1 block	Chance of at least 6 blocks
10	63.2%	under 0.1%
30	95.0%	8.4%
60	99.75%	55.4%
90	99.99%	88.4%

Illustrative example. A platform requires three confirmations. The mean wait is 3 × 10 = 30 minutes with a standard deviation of 10 × √3, about 17.3 minutes. The median is about 26.7 minutes and the 90th percentile about 53.2, so roughly one wait in ten exceeds 53 minutes although the average is 30. For six confirmations the mean is 60 minutes, the median 56.7 and the 90th percentile 92.7; about 11.6% of waits exceed 90 minutes. "About an hour" is the middle of a wide spread, and a low-fee transaction can wait longer than the model suggests because it may miss the next block entirely.

Stuck and dropped transactions

A transaction is stuck when it is valid but no block has included it. On Bitcoin, never-mined transactions tend to slowly disappear from the network, in the developer guide's words. In Bitcoin Core one mechanism is expiry: the source sets the default for -mempoolexpiry at 336 hours, which is 14 days (336 / 24). That is one implementation's default, checked on its master branch in October 2026; operators can change it, and other software may differ. An expired transaction can still sit in other nodes, and a wallet may rebroadcast it.

The developer guide's advice for a transaction that seems lost is to reissue it so that it invalidates the lost one, for example by spending the same outputs, because paying from different coins risks paying twice if the original later confirms. Fee bumping and replacement rules are a fee-market topic not covered here.

On Ethereum the nonce adds an ordering wrinkle. Geth's documentation separates transactions pending for inclusion in the next block(s) from queued ones scheduled for future execution only, and its example lists one account's queued nonces as 2 and 6, with nothing between. Read as an example, not a stated rule, a transaction with missing earlier nonces may stay queued until the gap is filled.

Reading a block explorer entry

Explorers show fields that the nodes' own interfaces expose:

Field	What it tells you
Status or "unconfirmed"/"pending"	Seen in a mempool but not in a block. On Ethereum, a pending transaction has a null block hash, block number and index, and no receipt yet
Block hash and height	Where it was included; confirmations are counted from here
Confirmations	Number of blocks from the inclusion block to the tip. Bitcoin Core's `getrawtransaction` result includes block hash, confirmations and block time
Receipt status (Ethereum)	The receipt returns 1 for success or 0 for failure, plus gas used; a transaction can be included and still have failed
Finalized or safe label (Ethereum)	Whether the block has reached the stronger tags; not every explorer shows this

Frequently asked questions

Do mined bitcoin rewards need the same confirmations as a normal payment?

No, they face a stricter rule set by the protocol: newly generated coinbase outputs cannot be spent for at least 100 blocks, according to the Bitcoin developer guide. At the 10-minute average spacing that is about 1,000 minutes, roughly 16.7 hours (100 × 10 / 60).

What happens if two transactions try to spend the same coins?

Only one can end up in the chain that nodes accept: a node rejects a transaction whose referenced output does not exist or is already spent, which the protocol rules page calls the protection against double-spending. Once one version is in a block, the other is invalid on that chain, but if that block is reorganized away, the other can still be mined, which is why platforms wait for more confirmations.

Does my pending transaction disappear if the node I sent it through restarts?

Usually not on a default Bitcoin Core node, which saves its mempool on shutdown and reloads it on start. A node with that setting off, or running other software, may lose its copy, but other nodes can still hold the transaction.

What does a missing receipt mean on Ethereum?

The JSON-RPC documentation says a null result instead of a receipt means the transaction has not been included in a block yet. If looking up the transaction itself also returns nothing, the node does not know it at all, for example because it is on another network or was dropped. Once it is included, the receipt reports success or failure and the gas used.

Can a low-fee Bitcoin transaction be dropped before 14 days?

Yes. Bitcoin Core caps its mempool's memory use at 300 MB by default. When the pool grows past that, the node removes the lowest fee-rate transactions first and raises its minimum accepted fee rate, so in busy periods a cheap transaction can fall out of many nodes long before the 336-hour expiry.

A checklist for one transaction

Copy the transaction hash and look it up in an explorer for the right network.
Read the status: not in a block yet, or included at a block height.
Note the confirmations count and compare it with the receiving platform's currently published requirement.
On Ethereum, check for a safe or finalized label if the amount matters more than the wait.
If it is still unconfirmed after hours, do not send a second payment from different coins until the first is resolved or dropped.