In BSV, Spending Means Consuming Old UTXOs and Creating New Ones

In BSV, spending does not mean “updating an account balance.” It means using a transaction to consume existing UTXOs and create new UTXOs.

That is the core idea behind the UTXO model. Ordinary payments, change outputs, transaction chains, tokens, and application state transitions can all be understood from this starting point.

A UTXO Is Not an Account Balance

In an account-based model, a transfer is often understood as a balance update:

The UTXO model works differently.

If Alice has a 100-satoshi UTXO and wants to pay Bob 30 satoshis, the system does not reduce that UTXO from 100 to 70. Instead, the transaction will:

• consume Alice’s 100-satoshi UTXO as an input;
• create a 30-satoshi output for Bob;
• create a change output back to Alice;
• leave the remaining amount as a transaction fee.

After the transaction is confirmed, the original UTXO is marked as spent. What Alice can use later is not the “reduced” old UTXO, but the newly created change UTXO.

A Concrete Example

Suppose Alice currently has one UTXO:

Alice wants to pay Bob 30 satoshis, and the transaction fee is 1 satoshi. A simplified transaction structure would look like this:

After confirmation:

• UTXO A: 100 is spent and cannot be used again;
• Bob receives a new 30 satoshis UTXO;
• Alice receives a new 69 satoshis change UTXO;
• the miner receives a 1 satoshi fee.

So the process is not “changing Alice’s balance from 100 to 69.” It is “consuming one old UTXO, creating two new UTXOs, and leaving a fee.”

Why an Old UTXO Must Be Consumed in Full

A UTXO can be thought of like a banknote. You cannot directly reduce the face value printed on a banknote. You hand over the note and receive change.

The UTXO model follows similar logic: a UTXO is either unspent or spent. It is not partially modified.

This design provides several important properties:

• clear transaction history;
• traceable provenance for each UTXO;
• more explicit double-spend checks;
• easier parallel validation;
• the ability to express state transitions through transaction chains.

At the same time, it requires developers and wallets to handle additional details, such as change, UTXO selection, and UTXO fragmentation.

One Transaction Can Consume Multiple Old UTXOs

A transaction does not have to contain only one input, and it does not have to contain only one output. It can consume multiple old UTXOs and create multiple new UTXOs at the same time.

For example, Alice’s wallet may contain three UTXOs:

Now Alice needs to pay 90 satoshis, with a fee of 2 satoshis. The wallet can choose to consume A, B, and C, for a total input value of 110 satoshis, and then create:

After the transaction is complete, the old UTXOs A, B, and C are all spent. The recipient’s 90-satoshi output and Alice’s 18-satoshi change output become new UTXOs.

Change Is Part of the Model, Not Just an Implementation Detail

Many beginners think of change as a wallet implementation detail. In the UTXO model, however, whenever the total input amount is greater than the intended payment plus the fee, the remainder must be returned through a new output.

If no change output is created, the difference between the inputs and outputs becomes part of the transaction fee.

So when constructing transactions manually, this equation must be explicit:

This is also a basic rule that BSV application developers need to understand.

New UTXOs Can Form Transaction Chains

A new UTXO created by one transaction can be spent by a later transaction.

For example:

This forms a transaction chain.

In BSV applications, many state updates can be expressed using this chained structure. For example, a credential, token, or business state can be updated by consuming the old state UTXO and creating a new state UTXO each time.

State Transitions in BSV Applications

BSV is not only a payment system. It is also often designed as a network for data and application state. The UTXO pattern of “consuming old state and creating new state” is suitable for expressing many business processes, such as:

• token transfers;
• digital credential updates;
• contract state progression;
• supply chain event changes;
• application record version updates.

Each state change can be represented by a transaction, with history that is naturally traceable.

However, this does not mean that simply writing data on-chain automatically creates a good application experience. Real applications usually also need supporting protocol design and Overlay indexing; otherwise, on-chain records can be difficult for applications to query and use efficiently.

Common Beginner Misunderstandings

When learning the UTXO model, it is useful to avoid these common misunderstandings:

• Spending does not modify the amount of an old UTXO;
• once an old UTXO is spent, it cannot be used again;
• change must be created as a new output;
• the difference between the total input value and the total output value is the transaction fee;
• a transaction can consume multiple old UTXOs and create multiple new UTXOs;
• state transitions can be represented with UTXO chains, but they require clear protocol rules.

References

• BSV Transactions docs
• Transaction Inputs and Outputs
• First Transaction tutorial