How Does Blockchain Work? From Transaction Creation to Confirmation

A blockchain processes a transaction through creation, private-key signing, network broadcast, node validation, block inclusion, and consensus confirmation. A successful broadcast only means the network has received the request; it does not mean the assets have arrived.

The process below uses a transfer on a typical public blockchain as an example. Networks may use either the UTXO or account model and may rely on different consensus mechanisms, but the basic roles involved in moving a transaction from authorization to a shared ledger are similar.

Step 1: The Wallet Creates and Signs the Transaction

After the user enters a recipient address, amount, and fee settings, the wallet constructs a transaction. Under the account model, the transaction usually also contains a nonce that determines the order of transactions from the same account and prevents duplicate execution. Under the UTXO model, it references previously unspent outputs and creates new outputs.

The wallet uses the private key to sign specific transaction data. The private key does not need to be—and should never be—sent to a node. The network receives the transaction data and signature. Nodes can use them to verify authorization, but they cannot derive the private key from the signature.

Step 2: The Transaction Is Broadcast to the Node Network

The signed transaction is first sent to one or more nodes and then propagated across the peer-to-peer network. A node does not immediately write a transaction to the ledger when it receives it. It first checks the format, signature, available balance or UTXOs, nonce, fee, and script execution result.

A transaction that satisfies a node's local rules usually enters its mempool or pending queue. Nodes may see different sets of pending transactions because of network latency, local policies, and differing minimum-fee settings. The mempool is not the blockchain itself. A pending record may disappear after a node restarts or the transaction is replaced.

Step 3: A Block Producer Selects Transactions

Miners or validators select some of the available transactions and assemble them into a candidate block according to the protocol. A higher transaction fee does not guarantee earlier inclusion, but fees commonly affect priority when block space is scarce.

In addition to transactions, a candidate block contains fields such as a reference to its parent block and time or state commitments. Bitcoin-like networks typically summarize transaction hashes in a Merkle root, while account-based networks may also record the resulting state root. See Blockchain Block Structure Explained for the purpose of each field.

Step 4: Other Nodes Independently Validate the Block

When a block propagates through the network, other nodes verify it independently instead of simply trusting its producer. They check whether the parent block is known, whether the block header satisfies consensus rules, whether the transactions are valid, whether any double-spending occurs, and whether execution results match the state commitment in the block.

A valid block is attached to the chain head recognized by the node, while an invalid block is rejected. If a node sees two candidate chain heads at the same time, it follows that network's fork-choice rule to decide which one to follow. The exact rule depends on the consensus mechanism and is not simply a comparison of block counts.

Step 5: The Transaction Receives Confirmations

When a transaction first enters a recognized block, this is generally counted as one confirmation. As subsequent blocks build on that block, the confirmation depth increases. The confirmation count measures the distance between the transaction's block and the current chain head; it is not a universal security guarantee across all networks.

Proof-of-work networks can experience short-chain reorganizations, while proof-of-stake networks often distinguish among included, justified, and finalized states. Trading platforms also set their own deposit confirmation requirements, so a block explorer may show success before the balance appears on the platform.

What Is the Difference Between Pending, Failed, and Dropped?

Pending means some nodes have seen the transaction, but it has not yet entered a block on the canonical chain. Common causes include a low fee, network congestion, an earlier transaction with a lower nonce that remains unresolved, or incomplete propagation between nodes.

Failed usually means the transaction was included on-chain, but contract execution did not complete the intended action. The account may still pay a network fee because nodes consumed resources to execute the transaction. Dropped or replaced generally applies while a transaction is still pending—for example, when its fee is too low, another transaction uses the same nonce, or nodes stop retaining it after a long delay.

When investigating a transaction, check its hash, network, status, block height, confirmation count, and the actual asset movement. See How to Use a Blockchain Explorer for details on these fields.

What Affects Confirmation Speed?

• Supply and demand for block space or execution resources.
• The fee selected by the user relative to current network fee levels.
• Whether the transaction depends on an earlier transaction or the correct nonce.
• Node propagation speed, block production intervals, and consensus status.
• Additional confirmation requirements and internal review time imposed by the receiving platform.

Do not use the completion time of one past transaction to predict the next. Cross-chain bridges, trading platforms, and custodial wallets also involve off-chain processing, so their crediting times may differ from on-chain confirmation times.

To learn why multiple nodes can maintain the same history, continue with Distributed Ledger Technology. To understand the first block in a chain, read What Is a Genesis Block?. Both concepts are also covered in Blockchain Fundamentals Explained.

Frequently Asked Questions

Can a Transaction Hash Be Used to Reverse a Transfer?

No. A transaction hash is a lookup identifier, not a cancellation credential. Some networks allow a pending transaction to be replaced by another transaction with the same nonce and a higher fee, but whether this is possible depends on the protocol, wallet, and status of the original transaction.

Why Does the Same Transaction Show Different Confirmation Counts on Two Explorers?

The explorers may connect to different nodes, have different indexing progress, or present transaction states differently. During a temporary network fork, they may also see different chain heads. Wait for their data to synchronize and compare the block hash.

Does a Signed Transaction Remain Valid Forever?

Not necessarily. An account's nonce, whether a UTXO has already been spent, fee rules, and protocol upgrades can all affect whether nodes accept it later. A signature only proves authorization for specific data; it does not guarantee that nodes will accept the transaction at any time.

Can a Block Producer Change My Recipient Address?

Not while keeping the original signature valid. If a signed field such as the address or amount changes, signature verification will normally fail. Malware may still alter a wallet interface or clipboard before signing, so always verify the address before approving the signature.