Following a transaction from wallet to final record
What happens between pressing send and the point where a blockchain transaction can no longer be changed, and what the word pending means along the way.
When a wallet shows the word pending, it means the transaction has been signed and sent out, but it is not yet part of the blockchain's permanent record. Many people picture a single queue somewhere, with their transfer waiting at the back. The real picture is different, and understanding it clears up most confusion about delays. A transaction passes through several stages: signing, broadcast, waiting in local pools, inclusion in a block, and finally finality. Each stage is handled by different participants, and none of them promises a clock time, which is why the same transfer can feel quick one day and slow the next. This page follows one transfer through those stages on a proof-of-stake network.
The first stage is signing. Your wallet builds a message that says who is sending, who receives, and what data comes along, then signs it with your private key. The signature proves that the owner approved the message without revealing the key. Next, the wallet hands the signed message to a node, which checks it and passes it on to other nodes. Each node keeps its own list of waiting transactions, usually called a mempool. There is no single shared pool. Two nodes may hold slightly different lists at the same moment, because messages take time to spread across the network. A node may also drop a message it considers invalid or stale.
Imagine a user named Omar who sends a token to a friend. He presses send and sees pending. Behind the screen, his wallet has passed the signed message to one node, and neighboring nodes have copied it into their lists. A validator chosen to propose the next block, or a specialized block builder working with it, scans its list and picks transactions to include. Omar's message is among them. Once the block is proposed and added, the wallet changes from pending to confirmed. A few minutes later the network votes on that block, and only after those votes does the transfer become final. Omar saw two changes on his screen, but the network took more steps.
Several things can leave a transaction waiting. Builders and validators choose what to include, so no timetable is promised, and a transaction that offers little to the one choosing can sit while others pass it. A message with a wrong sequence number, called a nonce, may stall until the gap is filled. A transaction can also be included yet fail, for example when a contract rejects the call, and in that case it appears on the record as unsuccessful. Another confusion is mixing up inclusion with finality. A block that has just been added can, in rare cases, be replaced by a competing one, and that is why finality is a separate stage.
Several checks help a reader make sense of a pending transfer. Copy the transaction hash from the wallet and look it up in a block explorer, which reads the public record. Does the explorer show the transaction as pending, included, or failed? If included, which block holds it, and has that block been marked as finalized? Does the nonce match the sequence your address expects? Is the receiving address the one you meant? A wallet screen only reports what it learns from a node. Block explorers are run by independent operators and read the same public data as everyone else. The explorer lets you compare that report with the record itself, and it takes no keys or signatures to do so.
Finality on a proof-of-stake network comes from votes. Validators vote on checkpoints, and once at least two-thirds of the staked coins back a pair of checkpoints, the earlier one is justified and then finalized. According to ethereum.org, this is how the network reaches a state that is very costly to reverse. Ideas such as encrypted pools and inclusion lists are proposals under discussion, not current behavior, and details differ between networks. This page is general education, not technical or financial advice, and the sources below give the exact definitions. Timing and block structure vary between networks, so the terms used here apply most directly to the network those pages describe, and other chains may name or order these stages differently.
- Pending means signed and broadcast but not yet in a block; there is no single shared queue
- Inclusion in a block and finality are two separate stages, and only the second is hard to reverse
- A block explorer lets you check the real status of a transaction hash without any keys
How a ledger works: a guide for beginners
Definitions
- Mempool
- The list of signed but not yet included transactions that a single node keeps. Each node holds its own list, so there is no one shared pool.
- Finality
- The point at which a block is locked in by validator votes, so that changing it would be extremely costly and the transaction is treated as settled.
Direct answers
- What does a pending transaction mean?
- It has been signed and sent to the network, but no block has included it yet. It waits in the local lists that nodes keep.
- Who decides when a transaction is included?
- A validator or block builder picks transactions from its own list and puts them into a block. No one promises a timetable.
- When is a transaction final?
- On a proof-of-stake network, it is final after validator votes justify and then finalize the checkpoint that covers its block.