You clicked Send in your wallet, watched the interface spin, and then… then you stare at the screen and wait. You might instinctively assume the money should arrive in the recipient’s account within seconds, just like a bank app transfer. But sometimes it shows Pending for over ten minutes, and sometimes you see a transaction hash has already been generated while the recipient says they haven’t received anything.

This is exactly where things get confusing: after you click Send, a lot happens before a transaction truly becomes an immutable record on the blockchain. It is not an instantaneous “send—arrive” action; it is a journey with clear stages. This article follows the full lifecycle of a transaction and breaks the process down step by step, so you can understand when your action is actually complete and which stages it has gone through.

What the Wallet Does First When You Click Send

When you enter the recipient address, fill in the amount, and press Send, the first thing the wallet does is not “send the money out.” It assembles a transaction locally on your device.

The recipient address and amount you enter are essentially just your intent. It is like writing “Pay Zhang San 100 yuan” on a blank remittance slip: the slip has no effect yet—it only expresses what you want to do. The wallet’s next job is to organize all the information this transaction needs.

This transaction usually contains the following key information:

• Recipient address
• Transfer amount
• Relevant identifier of the sender
• Fee parameters (how much fee you are willing to pay for this transaction)
• nonce or sequence number (used to identify the order of transactions sent from your account and prevent transactions from being submitted repeatedly or processed out of order)

After these fields are assembled, the wallet does something crucial: it digitally signs the transaction data with your private key.

This step is the most important security link in the whole process. Only you possess the private key. Signing a transaction with it is equivalent to proving to the entire network that “this transfer really is authorized by the asset owner.” Without this signature, nodes will not accept the transaction.

After signing is complete, the transaction data produces a unique transaction hash. You can think of it as the transaction’s “ID number”—a unique string calculated from the transaction contents. Later, when you check the transaction status in a block explorer, you will use this hash.

But note: at this point, nothing has actually happened. The transaction has only been prepared and signed on your device. It has not entered the blockchain, nor has anyone else seen it.

As an analogy: this is like writing and signing a remittance slip with the recipient and amount filled in, but the slip is still in your hand and has not been handed to anyone. The signature completes authorization, but the funds have not moved.

How a Transaction Enters the Blockchain Network

A signed transaction will not fly to the blockchain by itself. The wallet needs to broadcast it.

Specifically, the wallet usually sends the signed transaction through an RPC node or a blockchain API service. This node acts like an entrance through which the transaction enters the blockchain network.

After a node receives the transaction, it first performs some basic format checks—for example, whether fields are complete and whether the transaction size meets requirements—and then places it in a place called the mempool.

The mempool can be understood as a “waiting area for pending transactions.” All transactions that have passed basic checks but have not yet been packed into a block remain there temporarily. It is not a state on the blockchain; it is simply a “to-do list” maintained locally by each node.

After a transaction enters the mempool, the node also continues propagating it to other nodes. One node forwards it to several neighbors, and those neighbors forward it to more neighbors. Soon, a large number of nodes across the network receive the transaction. This is what broadcasting means.

Here you encounter the first common misunderstanding. Many people think that after clicking Send, the money immediately arrives in the recipient’s account. In reality, clicking Send only completes local signing and initial broadcasting; the transaction has only begun spreading through the network and has not been written into any block. The recipient will not see a balance change at this point, because the on-chain state has not changed.

If you enter the transaction hash in a block explorer at this point, you may see a Pending status. This means the transaction has entered the mempool and is waiting to be packed, but it is not “on-chain.” The fact that the hash can be found only means the network already knows the transaction exists.

How Nodes Check a Transaction

A transaction that has entered the mempool is not necessarily valid. Nodes verify it from multiple dimensions.

Signature verification is the first step. The node checks whether the signature on the transaction really comes from the private key corresponding to the sender’s address. If the signature does not match, the transaction is rejected outright.

Balance verification is the second step. The node checks whether the sender’s address has enough assets to pay the transfer amount and fee. For example, Alice’s address contains 10 ETH, and she tries to send 2 ETH. The node confirms that her balance really is enough to cover 2 ETH plus the fee. If the balance is insufficient, the transaction is rejected and will not remain in the mempool.

nonce or sequence number verification is equally important. On blockchains that use the account model, each transaction sent from an account has an increasing sequence number. The node checks whether the transaction’s nonce matches the order the sender should currently have. If Alice has already sent a transaction with nonce 5, then a second transaction with nonce 5 cannot be accepted again—this prevents the same funds from being spent twice and also prevents transactions from being maliciously replayed. If the nonce jumps too far ahead, the transaction may also fail to be processed, because the preceding transactions have not yet been confirmed.

Fee parameter verification is also within scope. A transaction must meet the network’s minimum fee requirements. If the fee is too low, the transaction may be rejected by nodes, or it may sit in the mempool for a long time without being selected for packing.

Only transactions that pass these checks remain in the mempool and continue to propagate to other nodes. This also explains why transactions sometimes fail—not because “the network is broken,” but because nodes judge the transaction to be invalid according to the rules.

From Mempool to Block: How Transactions Are Packed

Transactions sit in the mempool, waiting to be “selected” and packed into a block. The choice is not in the user’s hands; it is in the hands of the block producer.

On different blockchains, the block producer may be a miner (PoW chains) or a validator (PoS chains), but the core logic is similar: they pick transactions from the mempool and assemble them into a candidate block.

There is a key constraint here: each block has a capacity limit. Capacity may be a maximum block size or a gas limit. This means a block cannot fit all transactions in the mempool. The producer must make choices.

Selection rules are not entirely public and transparent, but there is a general tendency: higher fees or tips usually increase the probability of being selected first. However, the specific rules vary by chain, and experience from one chain cannot be directly applied to all chains.

This explains a common question: why did the other person’s transaction get on-chain first even though I sent mine earlier? Because packing order is not determined entirely by arrival time. The mempool is not a queue; it is more like a waiting hall. The bus has limited seats, and the boarding order does not depend entirely on who arrived first.

As an analogy: the mempool is the waiting hall, and blocks are the buses. Each bus has a fixed number of seats. Someone may arrive first but fail to get on, while someone who arrives later but bought a more expensive ticket may board first.

When a transaction is selected into a candidate block, it does not immediately become a final record. The candidate block still needs to go through network validation and consensus before it can truly be appended to the chain.

How a Block Is Accepted by the Network and Produces Confirmations

After the block producer assembles the candidate block, it broadcasts it to other nodes in the network.

After other nodes receive this candidate block, they verify it according to the rules of their respective chains: whether the block structure is valid, whether every transaction in the block is valid, whether there is a double spend, whether it complies with consensus rules, and so on. Only blocks that pass validation are accepted.

After the consensus mechanism, this block is appended to the end of the blockchain. When the block containing your transaction becomes a link in the chain, the transaction receives its first confirmation.

The confirmation count is a cumulative concept. Suppose your transaction is included in block height 100. When block height 101 is appended, your transaction has 2 confirmations; when height 102 is appended, it has 3 confirmations, and so on.

By analogy, the first confirmation is like receiving the first official seal, and each new block afterward is like adding another seal. The more seals there are, the harder it is to revoke this record.

Pay special attention here: different blockchains have different confirmation times and finality semantics. Some chains produce blocks quickly, with a block every few seconds; some produce blocks more slowly. Some chains have an explicit “finality” mechanism, after which a transaction is almost impossible to reverse once a certain condition is met; other chains rely on probability—the more confirmations, the lower the probability of reversal, but in theory it is never absolutely zero. Therefore, you cannot apply one fixed confirmation count to all chains.

The confirmation count represents security, not speed. A transaction with 1 confirmation may have just recently been included on-chain; a transaction with 100 confirmations has accumulated confirmations over a long period, and the cost of reversing it is extremely high.

From Pending to Success: How to Tell Whether a Transaction Is Really On-Chain

Once you understand the whole process, you can correctly interpret the various statuses in wallets and block explorers.

Pending usually means the transaction is still waiting in the mempool and has not yet been included in any block. At this point the transaction is only waiting to be processed; it is not on-chain.

When a transaction is included in a block accepted by the network, the block explorer will show that the transaction is confirmed and give the confirmation count. In the transaction details, you can see which block it was included in and what the block height is. This is the core basis for judging that it is “really on-chain.”

Success means the transaction has been executed and has reached a state accepted by the network. But note that different chains do not have exactly the same semantics for finality. Some chains can be considered very difficult to reverse after a small number of confirmations, while others require more confirmations to reach a higher security level. In addition, Success describes the execution result of the transaction; it does not mean that under all circumstances it is absolutely irreversible. The specific rules of the relevant chain’s finality must also be considered.

If a transaction remains Pending for a long time, common reasons include a fee set too low, network congestion, or a stuck nonce order. In such cases, many wallets and networks support replacing the transaction by increasing the fee, or offer wallet-provided ways to handle it. But there is an important dividing line: once a transaction has been confirmed on-chain, it cannot be canceled directly. Cancellation only makes sense for transactions that have not yet been packed.

This is also where a common misunderstanding needs correcting: a transaction that has been Pending for a long time does not have to be left waiting passively. You can check the current network status and the features supported by your wallet, and actively choose to replace or speed it up. But a confirmed transaction cannot be withdrawn.

Finally, when checking transaction status, rely on the confirmation information shown by the block explorer and wallet. The transaction hash is the entry point for lookup, but seeing the hash itself does not mean the transaction has successfully made it on-chain; what really matters is whether it has been included in a confirmed block and what the confirmation count is.

—

To review the whole process: when you click Send, the wallet constructs the transaction locally and signs it with your private key. This completes authorization, but the funds do not move. After the transaction is broadcast to nodes, it enters the mempool, where it waits for validation and packing. Nodes check the signature, balance, nonce, and fee parameters, and only transactions that pass validation continue to propagate. Block producers select transactions from the mempool, subject to block capacity limits, and the fee level affects the probability of being selected. The candidate block is appended to the chain after validation and consensus by nodes across the network, and the transaction receives its first confirmation. As subsequent blocks are continuously appended, the confirmation count increases, and the difficulty of reversing the transaction grows.

From “you clicked a button” to “becoming an immutable record on-chain,” a transaction essentially goes through three stages: signature authorization, broadcast validation, and packing confirmation. The difference between Pending and Success is essentially the difference between “still waiting” and “already on-chain.” The confirmation count is not a speed metric; it is an accumulation of security. Once you understand this process, you will no longer be confused by Pending, and you will be able to accurately judge which step a transaction has reached.