Transaction Chains: How a Transaction Spends a Freshly Created UTXO

Key Takeaway

A transaction chain describes the continuous process of UTXOs being spent and re-created across a series of transactions. Understanding this concept unlocks the meaning of the white paper statement that a coin is a chain of digital signatures, and shows why many BSV applications carry state forward by updating UTXOs in sequence.

A Minimal Model: From A to B

Suppose Transaction A creates an output:

At this point, output 0 is still a UTXO.

Transaction B wants to spend it, so it must reference:

Transaction B's input:

Transaction B then creates new outputs:

Now, A's output 0 has been spent and is no longer a UTXO. B's output 0 and output 1 become new UTXOs.

Why It's Called a Chain

Each subsequent transaction references an output from a previous transaction.

This is the chain of a coin. It's not an account balance table but a history of outputs being spent and re-created.

Note: The blockchain is a chain of blocks linked by time and proof-of-work; the UTXO chain is the chain of coin ownership transferring across transactions. Together, they form the traceable public ledger.

Building a Transaction Chain with the SDK

Key to constructing a transaction chain manually: Transaction B’s input must reference Transaction A’s output.

Below is a conceptual code example using the BSV TypeScript SDK:

Note: In real-world broadcast scenarios, you must also handle the order of txA and txB, dependency relationships, fees, service policies, and error handling.

Unconfirmed Transactions Can Form Dependencies

Transaction B can directly depend on an output from Transaction A, even if A hasn't been accepted by the network or included in a block yet. In this case, txB depends on a parent transaction that is still unstable.

This dependency is significant in practice:

• txB depends on txA.
• If txA is invalid, txB cannot be valid.
• If txA hasn't propagated to a processing node, txB may fail due to a missing parent.

The official Advanced Transaction Tutorial describes options like sendWith that allow dependent transactions to be sent together. Production systems need to handle parent-child relationships, ancestor limits, retries, and state queries.

Transaction Chains and Application State

BSV applications can model state as a chain of UTXOs. For example:

• A token can be represented by a single UTXO. When the token is transferred, the old token UTXO is spent and a new token UTXO is created.
• A credential's state can be updated through a transaction chain: the old state output is spent, and a new state output records the updated state.
• Games, orders, or supply chain events can follow a similar pattern, recording state changes in successive transactions.

This design has the advantage that state transitions have a clear predecessor-successor relationship—each step references the previous state—rather than allowing arbitrary row writes like a traditional database.

Transaction Chains and Parallel Processing

The UTXO model also offers inherent parallelism benefits:

• If two transactions spend different UTXOs, they have no direct conflict and can be processed in parallel.
• If two transactions spend the same UTXO, they conflict and only one can be valid.

This is crucial for BSV scaling. Large numbers of independent UTXOs can be verified and processed concurrently, avoiding the bottleneck of a single global account state.

Why Wallets Must Manage UTXOs

Transaction chains also explain why wallets can't just keep a single balance figure. They must track:

• Which UTXOs they control.
• Which transaction and output index each UTXO came from.
• Which UTXOs have been spent.
• Which UTXOs are currently being used by unconfirmed transactions.
• Dependencies between transactions.

A Stage 7 wallet can handle these relationships automatically. Studying the process manually in Stage 8 prepares you to better debug wallet and application state issues in the future.

Common Beginner Misconceptions

• New transactions cannot arbitrarily reference nonexistent outputs.
• You spend a specific outpoint, not an account balance.
• When Transaction B depends on Transaction A, ensure the processing node can see A.
• The transaction chain is not the blockchain itself; it is the chain of coin or state UTXO transfers.
• Putting application state on-chain isn't just appending a log. Many state protocols require spending old state and creating new state.

References

• BSV Transactions Documentation
• Advanced Transaction Construction Tutorial
• Transaction Inputs and Outputs
• Direct Transaction Creation Guide