Understanding BSV Transaction Outputs: Amounts, Locking Scripts, and UTXOs

In a BSV transaction, a transaction output is a new unit of value created by the transaction. It usually consists of two parts:

• Amount: how many satoshis the output contains.
• Locking script: the conditions that must be satisfied to spend the output in the future.

If an input represents “which old UTXOs are being spent,” then an output represents “which new UTXOs or data records are being created.” Understanding outputs is essential to understanding how BSV expresses payments, change, on-chain data, and application state.

What an Output Contains

A standard output usually contains two core pieces of information.

1. Amount

The amount indicates how much BSV the output carries, usually denominated in satoshis.

For example:

This means the output contains 1,000 satoshis of value.

2. Locking Script

The locking script defines who can spend the output in the future, and how it can be spent.

For example, a simple payment output can be understood as:

If this output has not yet been spent by a later transaction, it becomes a UTXO.

How an Output Becomes a UTXO

When a transaction first creates an output, it is simply one of that transaction’s outputs. As long as no later transaction references it as an input, it is a UTXO — an Unspent Transaction Output.

The process can be simplified as follows:

1. Transaction A creates output 0.
2. output 0 has not yet been spent, so it is a UTXO.
3. An input in Transaction B references Transaction A’s output 0.
4. output 0 is spent, so it is no longer a UTXO.

Wallet balances are calculated from this model: a wallet finds all UTXOs it can control and sums their amounts.

The Role of the Locking Script

The locking script is the spending condition attached to an output.

In a common P2PKH payment, the locking script roughly means:

Only someone who can provide the corresponding public key and a valid signature can spend this output.

This means an output does not simply say “pay Bob.” Instead, it contains a verifiable condition. If Bob’s wallet controls the corresponding private key, it can later create a new transaction and provide the signature and public key in the input, satisfying the output’s spending condition.

This design allows BSV to determine spending authority without relying on a centralized account system. The right to spend is expressed through scripts and signature verification.

Outputs Are Not Always Payments

People encountering transaction outputs for the first time often think of an output as “a payment to someone.” That is a common use case, but it is not the whole picture.

In BSV, outputs can represent many types of content:

• Standard payment outputs.
• Change outputs.
• OP_RETURN data outputs.
• Token protocol outputs.
• Application state outputs.
• Outputs related to credentials or business records.

Some of these outputs are spendable, while others are not.

For example, an OP_RETURN output is usually used to write data and does not create spendable funds. It is still a transaction output, but it is usually not a UTXO that can be spent in the future.

A Transaction Can Have Multiple Outputs

A transaction is not limited to one output. In practice, transactions often contain multiple outputs at the same time.

For example:

This structure is common. A single transaction can handle payment, change, and data writing at once.

In BSV application development, multi-output transactions are especially important. One application scenario may need to:

• pay a specific address;
• return the remaining amount as change;
• write business data;
• create or update application state.

Why the Output Index Matters

Outputs in a transaction are numbered in order:

If a later transaction wants to spend a specific output, its input must reference two pieces of information:

Therefore, a UTXO is not fully identified by “a txid” alone. It is identified by both the transaction ID and the output index.

This is also important for application development. When developers store on-chain business state or reference a particular output, they should usually store both:

• txid
• output index

Saving only the txid is often not enough, because the same transaction may create multiple outputs.

Output Design in BSV Applications

On BSV, the core of many application protocols is reflected in their output design.

For example:

• File notarization can use an OP_RETURN output to write a file hash.
• Tokens can use specific outputs to represent ownership or state.
• Credentials can use outputs to record issuance information.
• Supply chain events can use outputs to record changes in item status.

However, creating an output does not mean an application protocol has been fully designed. A maintainable output design usually needs to define:

• where the data is stored;
• whether the output is spendable;
• how scripts perform validation;
• how the protocol can be upgraded;
• how an Overlay identifies and indexes the output.

In other words, an output is the carrier for protocol expression, but the protocol itself still needs clear rules, indexing methods, and a way to interpret state.

Common Misunderstandings for Beginners

When learning about transaction outputs, pay particular attention to the following points:

• Outputs are not always payments “to someone.”
• The locking script is the actual spending condition; an address is only a convenient representation used to generate a script.
• OP_RETURN outputs usually do not represent spendable funds.
• A single transaction can create multiple outputs.
• When storing business references, a txid usually needs to be paired with an output index.
• Once an output is spent by a later transaction, it is no longer a UTXO.

References

• BSV Transactions docs
• Transaction Inputs and Outputs
• Script docs