What Is a UTXO? Understanding the Foundation of the BSV Transaction Model

UTXO in One Sentence

UTXO stands for Unspent Transaction Output. It means a transaction output that has not yet been spent.

In BSV, the “balance” shown in a wallet is not an account field stored on-chain. It is the sum of the UTXOs that the wallet can control. Understanding UTXOs is essential for understanding BSV transactions, wallets, change, fees, double-spending, parallel processing, and application state design.

From Output to UTXO

A transaction can create multiple outputs. Each output contains at least two key pieces of information:

• an amount;
• a locking script, which defines the conditions that must be satisfied to spend it in the future.

If an output has not yet been spent as an input by a later transaction, it is a UTXO.

A simple flow looks like this:

If a later Transaction B references output 0 from Transaction A as an input, that output has been spent:

A UTXO therefore has a clear lifecycle:

1. It is created by a transaction.
2. It remains unspent.
3. It is consumed as an input by a later transaction.

How UTXOs Differ From Account Balances

Many people first encounter blockchain through an account model. An account model can usually be understood like this:

The UTXO model works differently. It is closer to physical cash.

If you have a 100 yuan banknote and want to buy something for 30 yuan, you cannot tear off part of the banknote and give it to the merchant. You hand over the 100 yuan note, and the merchant gives you 70 yuan in change.

UTXOs follow a similar logic. Suppose you have a UTXO worth 100 satoshis and want to pay 30 satoshis. The 100-satoshi UTXO is consumed in full as an input, and new outputs are created:

The result is that the old 100-satoshi UTXO disappears, and new outputs of 30 satoshis and 69 satoshis appear. The 30 satoshis belong to the recipient, the 69 satoshis usually return to the payer as change, and 1 satoshi is paid as the transaction fee.

How a Wallet Balance Is Calculated

A wallet scans or queries the UTXOs it can control and adds up their amounts to produce the balance shown in the interface.

For example:

The wallet displays the balance as:

There is no on-chain field that says “this wallet balance is 750 satoshis.” That number is calculated by the wallet from the relevant set of UTXOs.

This is also why a single wallet can have many addresses, many UTXOs, and many change outputs. The wallet interface hides this complexity, but the underlying model is still UTXO-based.

How a UTXO Is Identified

A UTXO is typically identified by two values:

Where:

• txid identifies the transaction that created the UTXO;
• output index identifies which output it is within that transaction.

For example:

This refers to output 1 of transaction abc...123.

Storing only the TXID is not enough, because one transaction can contain multiple outputs. To reference a specific UTXO accurately, both the TXID and the output index must be stored.

A UTXO Contains More Than an Amount

A UTXO is not just an amount record. It also includes a locking script.

The locking script determines who can spend the UTXO in the future. In a standard payment scenario, the locking script may require the future spender to provide:

• the corresponding public key;
• a valid signature.

A UTXO can therefore be understood as a combination of “amount + spending conditions.”

This is important: BSV does not bind balances to accounts. It binds value to verifiable spending conditions. Only a transaction that satisfies the locking script can spend the corresponding UTXO.

Why UTXOs Come First When Learning BSV

Many core concepts in BSV transactions are built on top of UTXOs:

• input: references an old UTXO;
• output: creates a new UTXO;
• change: creates a new UTXO returned to yourself;
• fee: the total value of old UTXOs minus the total value of new outputs;
• double-spend: the same UTXO is referenced more than once;
• Script: defines the spending conditions of a UTXO;
• wallet: manages available UTXOs;
• token: often represents state as the transfer of a specific UTXO.

Without understanding UTXOs, BSV transactions can feel counterintuitive. Why does making a payment create change? Why can one address have multiple “balance fragments”? Why must an output index be specified when referencing a transaction output? The answers all come from the UTXO model.

UTXOs From a BSV Perspective

BSV emphasizes on-chain scaling and parallel processing. The UTXO model is one of the important foundations for this technical direction.

Different UTXOs can be verified relatively independently. As long as two transactions spend different UTXOs, they have no direct state conflict. This provides a structural basis for parallel validation.

Of course, UTXOs alone do not mean unlimited scaling. High throughput also depends on node software, storage, network propagation, miner policy, and architectures such as Teranode. But UTXO is the underlying model, and understanding it helps explain why BSV can be designed around parallel processing and large-scale on-chain transactions.

Common Misunderstandings for Beginners

When learning about UTXOs, it helps to remember the following:

• A UTXO is not an account.
• A UTXO is not an address.
• A UTXO is the state of a transaction output: unspent.
• One address can correspond to multiple UTXOs.
• A wallet balance is the sum of UTXOs, not an on-chain balance field.
• When a UTXO is spent, the old UTXO is consumed in full.
• When storing a UTXO reference, store both the TXID and the output index.

Summary

A UTXO is the basic unit of the BSV transaction model. It represents a transaction output that has not yet been spent, and it contains both an amount and spending conditions.

From a user’s perspective, a wallet balance looks like a single number. But in the on-chain data structure, it is the sum of a set of controllable UTXOs. When a transaction occurs, old UTXOs are consumed as inputs and new outputs are created. These may include recipient outputs, change outputs, and the fee difference.

Once you understand UTXOs, BSV transaction structure, wallet behavior, double-spend detection, Script conditions, and parallel processing become much easier to reason about.

References

• BSV Transactions docs
• Transaction Inputs and Outputs