How a Bitcoin Transaction Works: UTXOs, Mempools, and Finality

A Bitcoin ($BTC) transaction is a cryptographic message broadcast to a decentralized network that reassigns ownership of digital value. Instead of updating account balances on a central server, the protocol destroys previous inputs and creates new outputs recorded on a public ledger. This process relies on mathematical proofs, network consensus, and economic incentives to ensure security without a trusted intermediary.

Understanding this mechanism requires looking past the user interface of a digital wallet. Beneath the surface, the network operates on a strict set of rules governing how value is proven, transferred, and permanently recorded.

The UTXO Model

Traditional banking systems and many other blockchain networks use an account-based model. In an account model, a central database or state machine maintains a running balance for every user. When a user sends money, the system deducts the amount from the sender's account and adds it to the receiver's account.

Bitcoin operates differently. It uses the Unspent Transaction Output (UTXO) model. There are no accounts and no floating balances on the base layer of the network. Instead, the ledger tracks discrete, indivisible chunks of value called UTXOs.

The UTXO model functions similarly to physical cash. If a buyer wants to purchase a $5 item and only has a $20 bill, they cannot tear off a quarter of the bill. They must hand over the entire $20 bill to the merchant, who then returns $15 in change. The original $20 bill changes hands, and new bills representing the change are returned to the buyer.

Every $BTC transaction operates on this exact principle. A user's wallet balance is simply the sum of all the individual UTXOs that the user's cryptographic keys can unlock. When a user initiates a transaction, they are not deducting a flexible amount from a total balance. They are selecting specific UTXOs to consume in their entirety.

Constructing the Transaction

A standard transaction consists of three primary components: inputs, outputs, and metadata. The wallet software handles the construction of these elements automatically.

Inputs are references to existing UTXOs that the sender intends to spend. Because UTXOs are indivisible, an input must consume the entire value of the referenced UTXO. A single transaction can include multiple inputs, combining several smaller UTXOs to make a larger payment.

Outputs define the new UTXOs being created. An output specifies two things: the amount of $BTC being transferred and the cryptographic conditions required to spend it in the future. This condition is typically a locking script tied to the recipient's public address.

Because inputs must be consumed entirely, transactions almost always require a change output. If the total value of the inputs exceeds the intended payment amount, the wallet creates a second output directing the remaining funds back to an address controlled by the sender.

Transaction metadata includes a version number, which tells the network which set of rules to apply, and a locktime. The locktime specifies the earliest time or block height at which the transaction can be added to the ledger, allowing for delayed execution.

Cryptographic Signatures

To consume a UTXO, the sender must prove they have the authority to spend it. This is achieved through public-key cryptography.

Every Bitcoin address is mathematically derived from a public key, which is paired with a secret private key. The public key is visible to the network, while the private key is kept secure by the user. The locking script on a UTXO dictates that it can only be spent by someone who can produce a valid Digital Signature corresponding to the public key.

When constructing the transaction, the sender's wallet uses the private key to generate this signature. The signature is unique to both the specific transaction data and the private key used to create it.

This cryptographic design ensures two critical security properties. First, it proves ownership without requiring the sender to reveal their private key to the network. Second, it guarantees the integrity of the transaction. If any detail of the transaction—such as the recipient address or the amount—is altered after signing, the signature becomes mathematically invalid, and the network will reject the transfer.

The Mempool and Network Propagation

Once the transaction is constructed and signed, the wallet broadcasts it to a node on the network. A node is a computer running the core software that maintains a copy of the ledger and enforces the protocol's rules.

Upon receiving the transaction, the node performs a series of independent validation checks. It verifies that the transaction syntax is correct, that the inputs reference valid and unspent UTXOs, and that the digital signatures match the locking scripts. Crucially, the node checks that the total value of the outputs does not exceed the total value of the inputs.

If the transaction passes all validation checks, the node adds it to its Mempool. The mempool is a temporary holding area for valid transactions that have not yet been permanently recorded on the ledger.

After adding the transaction to its local mempool, the node forwards it to its connected peers through a gossip protocol. Those peers repeat the validation process and forward it further, rapidly propagating the transaction across the global network. It is important to note that there is no single, centralized mempool; every node maintains its own list based on the transactions it has received and validated.

Transaction Fees and Miner Selection

While the network validates transactions, it relies on specialized participants called miners to permanently record them. Miners group pending transactions from the mempool into blocks and compete to append these blocks to the ledger.

Block space is strictly limited by the protocol's rules. Because miners cannot include every pending transaction in a single block, they must prioritize which ones to process. This prioritization is driven by economic incentives in the form of transaction fees.

The transaction fee is not explicitly defined as a separate output. Instead, it is the residual value left over when the total outputs are subtracted from the total inputs. Miners claim this unassigned value as compensation for processing the block.

Fees are calculated based on the data size of the transaction, not the monetary value being transferred. The standard metric is satoshis per virtual byte (sats/vByte). A transaction combining dozens of small inputs requires more data than a transaction using a single large input, and will therefore require a higher absolute fee to achieve the same priority.

Consider a worked numeric example. Assume Alice wants to send 0.5 $BTC to Bob. Her wallet selects a single UTXO she owns worth 0.8 $BTC. The transaction creates two outputs: one for 0.5 $BTC locked to Bob's address, and a change output of 0.299 $BTC locked back to Alice's address.

The total input is 0.8 $BTC. The total outputs equal 0.799 $BTC. The difference of 0.001 $BTC is the transaction fee. When a miner includes this transaction in a block, they collect the 0.001 $BTC.

Confirmations and Finality

A transaction remains unconfirmed while it sits in the mempool. It only becomes part of the permanent ledger when a miner successfully hashes a new block containing the transaction and broadcasts it to the network.

When a transaction is included in a newly mined block, it receives its first Confirmation. The network is designed to produce a new block at regular intervals. As subsequent blocks are mined and added to the chain on top of the block containing the transaction, the transaction receives additional confirmations.

Finality on this network is probabilistic rather than absolute. In the event of a temporary network split, where two miners find a block at the same time, the network will eventually converge on the longest chain with the most accumulated proof-of-work. Transactions in the discarded chain are returned to the mempool.

Because the computational energy required to rewrite the ledger increases exponentially with each new block, transactions become more secure over time. A single confirmation is often sufficient for small transfers. For large institutional settlements, the industry standard is to wait for six confirmations, at which point reversing the transaction becomes economically and computationally unfeasible.

For a broader view of how this settlement architecture functions within the wider ecosystem, see Understanding Bitcoin: The Architecture of Decentralized Digital Scarcity.

Common Misconceptions

A frequent misunderstanding is that digital assets are stored inside a software or hardware wallet. In reality, wallets do not contain funds. The assets exist exclusively as UTXOs on the public ledger. A wallet is simply a keychain that stores the private keys necessary to sign transactions and move those UTXOs.

Another misconception is that transactions are entirely anonymous. The ledger is completely public, and every transaction history is permanently visible. While user identities are not explicitly linked to addresses, the system is pseudonymous. Chain analysis can often trace transaction flows and connect addresses to real-world identities, particularly when users interact with regulated exchanges that enforce identity verification.

Finally, users often confuse the broadcasting of a transaction with its settlement. When a wallet indicates a transaction is "sent," it typically means the transaction has been successfully broadcast to the mempool. The transfer is not finalized until it is selected by a miner and buried under multiple block confirmations.

How This Connects to the Market

The mechanics of transaction processing directly impact market structure and user behavior. Because base-layer block space is finite, the fee market operates on pure supply and demand.

During periods of high market volatility or increased network usage, the mempool becomes congested. Users must pay higher fee rates to incentivize miners to prioritize their transactions. This dynamic ensures the network remains secure and resistant to spam, but it also makes small-value transactions on the base layer economically impractical during peak times.

This fee pressure drives the development and adoption of secondary layers and scaling solutions. Institutional custodians often batch hundreds of client transfers into a single base-layer transaction to optimize fee costs. Meanwhile, retail users and payment providers increasingly rely on Layer 2 networks, which route payments off-chain and only use the base layer for final settlement. Understanding the strict, resource-intensive nature of a base-layer transaction clarifies why the broader market is continuously building infrastructure to scale above it.