Expert guides, insights and articles updated for 2026
Published 2 hours ago
If you have ever sent crypto and then stared at a wallet screen showing Pending, Confirmed, or Success, you have already run into the core parts of a blockchain system. The problem is that wallet apps hide most of the process. You tap send, but the transfer does not always happen instantly. Fees change. Confirmation counts matter. And sometimes a block explorer says one thing while an exchange shows another.
This guide explains the basics in plain English. We will follow one simple example from start to finish: Alice sends ETH to Bob. Along the way, you will see what a transaction, node, mempool, block, validator or miner, and finality actually do.
The goal is practical clarity. By the end, you should be able to interpret a pending transfer, understand why fees move, and judge when a payment is reasonably safe to treat as settled.
Imagine Alice opens her Ethereum wallet and sends 0.5 ETH to Bob.
From her point of view, it looks simple. She enters Bob’s address, checks the amount, sees the network fee, and taps Send. But tapping send does not mean the transfer is complete.
A better way to think about it is this: Alice is submitting a signed request to update a shared ledger. Her wallet creates a transaction, signs it with her private key, sends it to the network, and waits for the network to accept and record it.[^1]
That is why a transfer can appear before it is confirmed. It is also why one transfer can complete quickly while another sits pending. The wallet is just the interface. The blockchain’s state lives on the network, not inside the app.
A simple model helps:
Create → Broadcast → Wait → Include → Settle
That flow explains most of what users see in wallets and explorers.
When Alice taps send, her wallet creates a transaction. A blockchain transaction is not a coin being attached to a message and shipped across the internet. It is a signed instruction telling the network how to update the ledger.
On Ethereum, a transaction usually includes:
The signature proves Alice authorized the transaction without revealing her private key.[^2]
This is the key mental shift: the wallet does not contain the blockchain. It manages keys and helps prepare instructions for the network. If Alice restores the same wallet somewhere else, her funds still appear because the balances live on-chain, not inside the original app.
That also explains why a wallet can create a valid transaction but still fail to get it confirmed quickly. Creation is only the first step.
After the wallet creates and signs the transaction, it sends it to one or more nodes.
A node is a computer running blockchain software. Its job is to check data against network rules, relay valid data to other nodes, and store or serve blockchain history.[^1][^3]
Even if Alice never runs a node herself, nodes still matter. Her wallet likely depends on a node provider or backend service to:
This is why different wallet apps can sometimes show status updates at slightly different times. They may rely on different node infrastructure or indexing systems.
A useful way to think about a node is as both a checker and a messenger. It does not decide final inclusion on its own, but it helps move transactions through the network and helps everyone agree on what data is valid.
Once the transaction reaches the network, it usually enters the mempool.
A mempool is the waiting area for valid transactions that have been broadcast but not yet included in a block.[^4] In practice, different nodes can have slightly different views of pending transactions, but for users, “the mempool” is still a useful shorthand.
For Alice, this is the stage where her wallet may show Pending.
Why would a transaction stay there?
The most common reason is fee competition. If many users are trying to send transactions at the same time, block space becomes scarce. Transactions offering higher fees are usually more attractive to block producers, so lower-fee transactions may wait longer.
Example: Alice chooses a low fee during a busy market move. Her transaction is valid, so nodes accept and relay it. But many other users are paying more. Those higher-fee transactions get picked first, and Alice’s transaction stays pending.
Pending does not always mean something is broken. It often just means the network has seen the transaction, but it has not been included yet.
The next step is block inclusion.
A block is a batch of accepted transactions plus metadata. For users, its most important job is ordering. It records which transactions were accepted together and in what order.
Who chooses that next batch depends on the network:
You do not need deep consensus theory to understand the practical result. Miners and validators assemble the next block, so they determine which pending transactions get included next, within the network’s rules and incentives.
For Alice, this is when her transaction moves from pending to included. On an explorer, she will now see a block number and at least one confirmation.
This is also where fees become real. If Alice sent ETH, her fee paid for block space on Ethereum. If she had sent USDT on Ethereum instead, the transaction would still use Ethereum and still require ETH for gas. The token does not override the rules of the chain it runs on.
After inclusion, the transaction starts to settle.
This is where many beginners get confused. A transaction being in a block is not exactly the same as finality. Inclusion means the network currently accepts that transaction as part of the chain. Finality means it is now very unlikely, or in some systems economically impractical, to be reversed.[^5]
On many networks, confidence grows over time:
For Alice, one confirmation may be enough if she is just moving funds between her own wallets. But if Bob is an exchange, the platform may wait for several confirmations before crediting the deposit. That is not a contradiction. It is a risk policy.
So the final stage is not just “was it included?” It is “is it settled enough for this use case?”
Now that the process is clear, the main terms are easier to define.
A blockchain transaction is a signed request to update the ledger.
It does not physically carry coins from one place to another. It tells the network, “if this request is valid, update the shared record this way.”
For Alice’s ETH transfer, the transaction says: this sender authorizes sending 0.5 ETH to Bob and agrees to pay the fee for processing.
That framing clears up a lot of confusion around wallets, balances, and pending status.
A block is a grouped set of accepted transactions.
Its main user-facing role is not just storage. It creates shared ordering. That matters because a blockchain has to answer questions like:
Without blocks, there is no common record of accepted order. With blocks, the network has a structured history.
A node checks transactions and blocks against network rules, relays valid data to peers, and stores or serves blockchain information.
If wallets are the front desk, nodes are the operational system behind them.
That is why nodes matter even if you never run one. Your wallet, exchange, and block explorer all rely on nodes to tell them what happened. The limitation is that if you trust only one app’s interface, you are also trusting that app’s infrastructure to reflect the chain accurately and quickly.
That is one reason block explorers are so useful. They help you check whether a problem is on-chain or just in the app’s display layer.
Every blockchain has limited room in each block. That limited room is called block space.
When few people are transacting, the network can process most valid transactions quickly at lower cost. When activity surges, users compete for the same limited space. Fees rise because users want priority.
This explains the real-world question: “Why did my fee spike today?”
If 10,000 users want inclusion now, but the next few blocks cannot fit all of them, some have to wait. On many networks, the users paying more usually wait less.
Bitcoin, Ethereum, and lower-fee networks do not all behave the same way.
Bitcoin has its own transaction structure, block cadence, and fee dynamics. Ethereum adds smart contract execution, so fees are shaped not only by demand but also by computational complexity. A simple ETH transfer and a token transfer can cost different amounts because token transfers interact with smart contracts.[^2]
Lower-fee networks may offer faster or cheaper transactions because of different design choices, different demand levels, or different tradeoffs in decentralization and throughput.
So when comparing fees across chains, it is rarely just one variable. Network design and real demand both matter.
This is the tradeoff users feel most often.
Suppose Alice sets a low fee on Ethereum during a period of heavy activity. Her transaction is valid, so it reaches nodes and sits in the mempool. But because many other transactions are offering more, validators keep choosing those first.
The result is simple:
On some Ethereum-style wallets, Alice may be able to speed up or replace the pending transaction by submitting another one with the same nonce and a higher fee. Not every wallet makes this obvious, and support differs, but this is one reason the nonce matters in practice.
One confirmation usually means one thing: the transaction has been included in a block.
That is useful, but it is not the whole story. A recipient may still want more confirmations before treating the payment as final.
A good rule is to separate these two questions:
They are related, but they are not the same.
On some networks, confidence grows gradually as more blocks are added after your transaction. This is often called probabilistic finality. Bitcoin is the classic example.
On other networks, especially many proof-of-stake systems, finality can arrive faster or come with stronger economic guarantees, though the exact mechanics vary by chain.[^5]
For users, the main lesson is not to memorize consensus jargon. It is to understand that “confirmed” can reflect different levels of confidence depending on the network and the app displaying the status.
There is no universal answer.
Use this simple decision framework:
Example: Alice sends ETH to an exchange. Etherscan shows one confirmation. She expects the deposit immediately, but the exchange still says pending. The missing piece is that the exchange may require more confirmations before crediting the funds.
In other words, on-chain confirmation and platform crediting are not always synchronized.
Start with this workflow:
Check the transaction hash in a block explorer.
Make sure the transaction is actually visible on the network.
Verify the correct network.
This matters especially for assets like USDT that exist on multiple chains.
Compare the fee paid with current network conditions.
If the fee is low for current demand, waiting is normal.
Look for status clues.
Some explorers or wallets may show pending, replaced, dropped, or failed.
Check whether speed-up or replacement is available.
This is often possible on Ethereum-style transactions if the original is still pending.
Consider wallet lag.
A wallet UI can show pending even when the explorer already shows confirmation.
This checklist helps you separate a chain-level delay from an app-level display issue.
Once the transaction is in a block, check three things:
How many confirmations does it have?
One confirmation means inclusion. More confirmations usually mean stronger confidence.
What does the recipient require?
Exchanges and platforms often have their own thresholds.
Has the destination platform credited the funds?
On-chain success does not always mean immediate account availability.
This matters most for deposits to exchanges, payment processors, or other custodial platforms.
The easiest way to understand these basics is to stop thinking of crypto as tiny objects flying between wallets.
A better model is this:
When you see a transaction pending, you are watching that system move through its stages: Create → Broadcast → Wait → Include → Settle.
Once you understand that flow, wallet statuses make more sense. Fees make more sense. Confirmation counts make more sense. And most importantly, you can make better decisions when a transfer is delayed, confirmed, or still not safe enough to treat as final.
Your wallet creates a signed transaction, sends it to a node for broadcast, and the transaction enters the network’s pending pool until a miner or validator includes it in a block. After that, it gains confirmations and becomes safer to treat as settled.
In practical terms, it updates the blockchain’s shared ledger. Your wallet is not mailing coins like a file transfer. It is submitting a signed instruction that tells the network how balances or token ownership should change.
A blockchain transaction is a signed request to update the network’s record. It usually includes the sender, recipient, amount, and fee settings. On networks like Ethereum, it may also include data for smart contracts or token transfers.
A block is a batch of valid transactions that a miner or validator adds to the blockchain. For users, the key idea is that a block gives transactions accepted ordering: which ones were processed first and recorded together in the chain’s history.
A node helps run the network by checking transactions and blocks against the rules, relaying valid data to other nodes, and storing or serving blockchain data. Wallets, explorers, and exchanges all rely on nodes to show balances and transaction status.
A mempool is the waiting area for valid transactions that have been broadcast but not yet included in a block. It is helpful to think of it as a queue, though different nodes can have slightly different views of pending transactions.
A transaction can stay pending because the fee is too low for current demand, the network is congested, the transaction has not fully propagated yet, or a wallet interface is lagging behind chain data. A block explorer usually gives the clearest view of its actual status.
Miners or validators choose which pending transactions to include in the next block, usually based on fee incentives and protocol rules. When block space is limited, higher-paying transactions are often prioritized.
Fees change because users are competing for limited block space. When demand rises, more transactions are waiting than a block can fit, so users often pay more to be included sooner. Different blockchains also use different fee markets and have different capacity limits.
One confirmation usually means your transaction has been included in a block. It does not always mean the payment is fully settled, because some recipients wait for more confirmations before treating it as final.
Blockchain finality means a transaction is unlikely enough to be reversed that users can safely treat it as settled. On some networks, confidence grows with each additional block. On others, finality may arrive faster, but the practical threshold still depends on the network and the situation.
There is no single number that fits every case. A small self-transfer may need only one confirmation, while an exchange deposit or large payment may require more. The safest rule is to follow the recipient’s confirmation policy and the norms of that network.
An exchange may wait for additional confirmations before crediting your account. On-chain confirmation means the transaction is in the blockchain, but the platform can still apply its own risk controls before showing the deposit as available.
Sometimes yes. On Ethereum-style networks, some wallets let you speed up or replace a pending transaction by submitting another one with the same nonce and a higher fee. This depends on wallet support, network rules, and whether the original transaction is still pending.
Look up the transaction hash in a block explorer. That can show whether the transaction is pending, confirmed, replaced, or missing entirely. It also helps you compare the fee paid with current network conditions.
Would you like to contribute content to this article? Contact us today!
No comments yet. Be the first to comment on this article!