Most software developers carry one model of money so deeply that they don't notice it's a model. A balance is a number stored somewhere. You read the number to find out how much someone has. You change the number to move value around. The number lives in a database row, a struct field, an account object. This is how banks work, how PayPal works, how every traditional payment system works. It is also not how Bitcoin works. Bitcoin doesn't store balances. Bitcoin stores coins. Discrete, individual coins, each with a value and an owner, each created by one transaction and destroyed by the next. Your balance is not a number that exists anywhere. It is a sum you compute by adding up the coins that happen to be yours. This lesson is about why Bitcoin makes that choice and what it buys.

Imagine you want to build a digital payment system. There are two natural ways to do it.

The first way is the account model, and it's the one almost every traditional system uses. The system keeps a table. Each row has a user and a balance. To send money, you decrement one row and increment another. To check a balance, you look up the row. Simple. Familiar. The way every developer's first instinct says payments should work.

The second way is the UTXO model, and it's the one Bitcoin uses. The system doesn't keep a table of users and balances. It keeps a set of coins. Each coin has a specific value and a specific owner. To send money, you don't update any balances. You destroy some of your coins and create new ones for the recipient. To check a balance, you scan for every coin still belonging to you and add them up.

UTXO stands for Unspent Transaction Output. Every coin in Bitcoin started life as the output of some past transaction and has not yet been spent by being used as the input of a later one. The set of every UTXO across the chain is what Bitcoin nodes actually track. There is no balance ledger. There is only the UTXO set.

In the account model, "Alice has 2.5 BTC" is a fact stored in one place. In the UTXO model, Alice has 2.5 BTC because she happens to hold two unspent coins worth 1.0 and 1.5. Her balance is a derived quantity that the system computes by summing her coins. The chain doesn't know who Alice is or what her total is. It just knows about those two specific coins.

The UTXO model produces a way of paying that feels strange the first time you see it. Here's the rule. A transaction takes one or more existing coins as inputs, destroys them, and creates one or more new coins as outputs. The total value of the new coins has to equal the total value of the old coins, minus a small fee that goes to whoever includes the transaction in a block.

Now imagine Alice wants to send 0.3 BTC to Bob. She holds the 1.0 BTC coin from the example above. There is no operation called "subtract 0.3 from Alice and add 0.3 to Bob." There is only "destroy old coins, create new coins." So Alice's payment has to be structured as follows.

Her transaction takes her 1.0 BTC coin as the input. That coin is destroyed in the process. She creates two new coins as outputs. One coin worth 0.3 BTC, owned by Bob. One coin worth a little less than 0.7 BTC, owned by Alice herself. The difference between the input value and the output value is the fee.

That second output, the one going back to Alice, is called a change output. It exists for exactly the same reason change exists in cash. If you owe someone three dollars and you only have a ten in your wallet, you don't tear the ten in pieces. You hand over the ten and the other party hands you back seven. UTXOs are the same. You don't split a coin. You hand the whole coin to the transaction and the transaction hands you a new, smaller coin in return.

After this transaction settles, Alice no longer has her 1.0 BTC coin. That coin is destroyed forever. In its place she has a fresh 0.699 BTC coin she didn't have a moment ago, and Bob has a fresh 0.3 BTC coin he didn't have either. The chain's UTXO set has changed: one coin removed, two coins added.

The previous section was the conceptual picture. The structural picture is one level more concrete, and it's worth seeing because the structure is what gets stored on the chain and what wallet software actually reads.

A transaction is a small record with three significant parts: a list of inputs, a list of outputs, and some housekeeping fields like a version number and an optional time lock.

Each input has two essential pieces. The first is a pointer back to the specific UTXO being spent. That pointer is the txid of the past transaction that created the coin, plus an index into that transaction's output list (called vout for "output index"). Together those two values uniquely identify a coin anywhere in the chain's history. The second piece is the data that satisfies the coin's lock, called the unlocking script or scriptSig, typically a signature and the public key that the signature was produced from.

Each output has two essential pieces. The first is the value of the new coin, stored as an integer in satoshis (the smallest unit of Bitcoin, one hundred-millionth of one BTC). The second is the locking script or scriptPubKey, a small program defining the condition the future spender will have to satisfy. The typical condition is "prove ownership of the private key corresponding to this address."

The "small program" framing is worth pausing on. Each locking condition is written in a stack-based language called Bitcoin Script, deliberately limited so that every node can run it cheaply and deterministically. No loops. No external data. No shared state. The language only exists to answer one question per transaction: is this spend allowed, yes or no? The most common locking pattern, used in almost every routine payment, is called Pay-to-Public-Key-Hash. It locks the coin to a specific public key hash, and the spender unlocks it by providing a signature plus their public key. Other patterns exist, but the shape is always the same: the output sets a condition, the input satisfies it. Bitcoin's intentional choice to keep this language small is one of its defining design decisions, and we'll come back to it when we look at the trade-offs at the end of the module.

This pointer-based structure is why the chain is best thought of as a directed graph rather than a list of balances. Every coin in existence traces back through a chain of references all the way to a mining reward, and every transaction is a node in that graph that consumes some incoming edges and produces some outgoing ones.

One detail worth flagging: the fee paid to the miner is not its own field in the transaction. It's computed implicitly as the difference between the total input value and the total output value. If a transaction has 1.0 BTC of inputs and 0.999 BTC of outputs, the 0.001 BTC difference goes to whoever includes the transaction in a block. This is one place where developers writing transaction-construction code go wrong: forget to leave a fee, and your transaction either gets rejected or pays an enormous one to the miner.

If you're meeting the UTXO model for the first time, your reaction is probably "this is a complicated way to do something simple." Why not just update Alice's balance and Bob's balance directly, like every database in the world?

The answer goes back to the framing lesson. Bitcoin is designed for a network where there's no operator, every node has to validate every transaction independently, and the validation has to be cheap and deterministic. UTXOs are a way of structuring state that makes that validation easy.

To validate a UTXO transaction, a node has to check three things. The inputs exist as unspent outputs in the current UTXO set. The signature on each input is valid against the coin's owner condition. The output values add up to no more than the input values. Three local checks. Each one is independent of everything else happening on the chain. There's no global table to consult, no balance to scan, no race condition to worry about. Just three lookups and some arithmetic.

The same validation in an account model has to look up balances, possibly across many accounts, and worry about ordering: if Alice tries to spend her balance in two different transactions at almost the same time, the system has to decide which one wins. The UTXO model can't have that problem because the coins themselves are the unit of state, and each coin can only be spent once.

This local-validation property pays off in three more ways.

Parallelism. Two transactions that touch different UTXOs are independent. The network can validate them in parallel without coordination. An account-model transaction touching Alice's balance and another transaction also touching Alice's balance cannot be processed in parallel without locking.

Privacy. Each coin has its own owner condition. The chain doesn't have a permanent identifier for a user. Alice can have a hundred different addresses, each holding different coins, and there's no on-chain record that they're all hers. The account model implies that every transaction from Alice is associated with the same account identifier, which is a privacy property the UTXO model doesn't have to give up.

Audit clarity. Every coin's history can be traced exactly. This specific coin was created by this transaction, which was funded by these earlier coins, which were created by these even earlier transactions, all the way back to a mining reward. The provenance is built into the data structure, not bolted on as an audit log.

The trade is that the UTXO model is unfamiliar and uses more storage for the same number of users, because the chain has to track every unspent coin separately rather than a single balance per user. Bitcoin accepts that trade. Several other chains made the opposite trade and use account models instead. Both work. They optimise for different things.