The UTXO model, and why there are no balances

An output is created when a transaction is confirmed. The transaction that creates it also spends something: every input names an existing unspent output and carries the data that satisfies its spending condition, usually a signature. When the transaction is mined, the outputs it named are removed from the unspent set and the outputs it created are added. The set changes size and shape with every block, but at no point does any part of the system hold a running total per address.

An output is spent exactly once, and it is spent whole. There is no partial spend and no way to leave a remainder attached to the same output. If an output worth one bitcoin is used to pay someone a tenth of a bitcoin, the transaction creates a new output of that tenth for the recipient and a second output returning the rest to the sender. That second output is the change, and it is a genuinely new output with its own identifier, not a modification of the old one. The original output is gone from the unspent set entirely.

This is the part of the model that surprises people most, because it means a wallet must plan its inputs the way a person plans banknotes. If the only outputs a wallet controls are large, a small payment still consumes a large output and produces change. The change output is indistinguishable on-chain from a payment, which is one reason wallet software takes care over how change is handled. The Script page covers the conditions attached to an output; the address types page covers how those conditions are encoded for a payer to read.

The first consequence is that validation is local and cheap. To check a transaction, a node does not need to know anything about the sender's history beyond the specific outputs being spent. It looks up each cited output, confirms that it exists in the unspent set and has not already been consumed, checks that the spending condition is satisfied, and confirms that the outputs created do not exceed the inputs in value. Nothing about the sender's other holdings enters the calculation, and no global state has to be reconciled.

The second is that double spending is prevented by construction rather than by trust. Because an output can be spent only once and its removal from the unspent set is part of the same state change that confirms the spending transaction, two conflicting spends cannot both be valid. A node that has seen one of them will reject the other, and the network converges on whichever the chain ultimately includes. There is no need for a central authority to arbitrate, because the rule is a property of the data structure.

The third is less often stated. Because outputs are discrete and individually identified, a transaction's provenance is explicit. Anyone can trace an output back through the transactions that produced it, which is what makes the chain auditable and also what makes it transparent: the same property that lets a node verify a payment lets an observer follow it. The model is not anonymous by design, and the privacy discussion on the Taproot page follows directly from it.