How a transaction gets confirmed

Confirmation is a process, not a moment

People often speak of a transaction being “confirmed” as if it were a single yes-or-no event. It is more accurate to think of confirmation as a process that strengthens over time. A transaction moves through several distinct stages, and its certainty grows at each one. Understanding those stages explains why a wallet might show a payment as “pending” for a while, and why an exchange or merchant may ask you to wait before a deposit is credited.

Step one: signing

Nothing can happen until the transaction is authorised. Your wallet assembles the transaction’s details, who is sending, to which address, how much, any accompanying data, and the fee parameters, and signs them with your private key. Ethereum’s documentation notes that a transaction “needs to be signed using the sender’s private key,” which “proves that the transaction could only have come from the sender and was not sent fraudulently.”

One field deserves special mention: the nonce, described in Ethereum’s documentation as “a sequentially incrementing counter which indicates the transaction number from the account.” The nonce fixes the order of transactions from a single account and prevents the same signed transaction from being replayed twice. At the moment of signing, a cryptographic transaction hash is generated, a unique identifier you can later use to look the transaction up.

Step two: broadcasting to the network

A signed transaction is not sent to a central server. It is broadcast to the peer-to-peer network. Your node passes it to the nodes it is connected to, which pass it to theirs, and within seconds the transaction has propagated widely. Every node that receives it first checks it against the rules: is the signature valid, is the nonce correct, does the account have enough balance to cover the amount and the fee? Invalid transactions are dropped immediately and go no further.

Step three: waiting in the mempool

A valid, broadcast transaction that has not yet been included in a block sits in the mempool (memory pool), the set of pending transactions each node holds. Ethereum’s documentation describes this stage as the transaction being “added to a transaction pool.” The mempool is a waiting room, not a queue with guaranteed order.

Whoever builds the next block generally has discretion over which pending transactions to include, and typically prioritises those offering higher fees, since fees are their reward. This is the practical reason fees and confirmation speed are linked: when the network is busy and the mempool is full, a transaction offering a low fee may sit unconfirmed for a long time while higher-fee transactions are chosen first. Fees are the subject of a separate article; here it is enough to know that they influence how quickly a transaction is picked up, not whether it is valid.

Step four: inclusion in a block

Eventually a block producer selects your transaction. On Ethereum, as its documentation explains, “a validator is randomly selected to be the block proposer,” and they “bundle transactions together, execute them and determine a new state.” On Bitcoin, a miner assembles a candidate block and expends proof-of-work effort to earn the right to add it. Either way, your transaction is now written into a block and, when that block is accepted by the network, has received its first confirmation.

It is worth pausing on what inclusion means. Being in a block is not merely a note that the transaction happened; the block producer has executed it and folded its effect into the network’s new state. From this point the transaction is part of the shared ledger, subject only to the small risk discussed next.

Step five: confirmations and depth

Why isn’t one confirmation the end of the story? Because, briefly, two valid blocks can be produced at nearly the same time, creating a temporary fork. The network resolves such forks by converging on one chain, and a transaction stranded on the discarded branch would return to pending. The defence against this is depth: each additional block built on top of the one containing your transaction is another confirmation, and burying the transaction deeper makes it exponentially harder to dislodge.

Bitcoin’s developer documentation captures the underlying security clearly: “the cost to modify a particular block increases with every new block added to the block chain, magnifying the effect of the proof of work.” A transaction with one confirmation sits in the latest block; with six confirmations, five more blocks have been stacked on top. Waiting for several confirmations, a common convention for larger Bitcoin payments is around six, is simply a way of buying a very high degree of certainty that the transaction is permanent.

Ethereum’s explicit finality

Under proof of stake, Ethereum adds a formal notion of finality on top of simple depth. Its documentation explains that “as time passes the block containing your transaction will be upgraded to justified then finalized,” and that these upgrades “make it much more certain that your transaction was successful and will never be altered.” Finalization is a strong guarantee: reversing a finalized block would require an attacker to destroy an enormous amount of staked value, making it economically ruinous rather than merely difficult. In practice, finality on Ethereum arrives within roughly a couple of epochs, on the order of minutes, rather than depending on an informal confirmation count.

Why receivers wait

All of this explains a behaviour that can otherwise seem like needless caution. When you withdraw to an exchange, or pay a merchant a significant sum, the recipient often waits for a number of confirmations before treating the funds as settled. They are not doubting that the transaction was broadcast; they are waiting for it to become deep enough, or finalized, that a reversal is no longer a realistic concern. For small, everyday amounts the risk of a shallow reorganisation is negligible and fewer confirmations are accepted; for large amounts, a short wait is cheap insurance.

A failed transaction is a separate case worth distinguishing. A transaction can be included in a block and still “fail”, for instance if a smart contract call reverts. On Ethereum such a transaction still consumes gas and appears on the ledger with a failed status; it was confirmed as an event, but its intended effect did not take place. Confirmation, in other words, means the network agrees the transaction happened, not that it necessarily achieved what the sender hoped.

Following a transaction through its stages

It helps to see the whole arc in one place. The table below summarises the states a typical transaction passes through and what each one tells you.

Reading a wallet’s status messages against this arc removes most of the anxiety around a “pending” label. A transaction that is broadcast but not yet included is behaving normally; it is somewhere in the waiting room, and the question is when, not whether, a producer will pick it up, assuming its fee is competitive for current conditions.

Sources

• Ethereum.org — Transactions
• Ethereum.org — Blocks
• Ethereum.org — Proof-of-stake
• Bitcoin Developer Guide — Block Chain