UTXO vs the Account Model

Before we can describe a transaction, we have to answer a more basic question: what is a coin? Most people picture a bank — a giant table with one row per person and a number in the balance column. Bitcoin does not work this way. There is no row that says “you own 2 BTC.” Instead the ledger is a pile of discrete, individually-owned chunks of coin called UTXOs — Unspent Transaction Outputs. This page builds that mental model from the ground up, because almost every later confusion (“where did my change come from?”, “why is my whole balance in one transaction?”) dissolves once it clicks.

A UTXO is a coin-like object

Every Bitcoin transaction produces one or more outputs. Each output is a self-contained packet with exactly two things:

OUTPUT
├── value         : an amount, in satoshis (1 BTC = 100,000,000 sats)
└── scriptPubKey  : a lock — the spending condition (usually "whoever proves
                    they hold key K can spend this")

The moment an output is created, it sits in the global UTXO set as a spendable coin. When someone spends it, it is consumed whole and removed from the set — you cannot spend “half” of a UTXO any more than you can hand over half a physical $20 bill. To pay an exact amount you spend the whole bill and take change back as a brand-new UTXO. This is why Bitcoin coins behave like cash, not like a checking account.

There is no “balance” field, anywhere

Your wallet’s balance is a derived number, not a stored one. The wallet scans the chain, finds every UTXO whose lock your keys can open, and adds them up. “You have 2 BTC” really means “the unspent outputs you control sum to 2 BTC.” Bitcoin Core literally keeps no per-person ledger — only the set of unspent outputs.

Worked picture: balance = a handful of coins

Suppose your wallet controls three UTXOs:

   UTXO #1 :  0.40 BTC
   UTXO #2 :  0.15 BTC      ──►  reported balance = 0.60 BTC
   UTXO #3 :  0.05 BTC

To send 0.50 BTC you might consume UTXO #1 (0.40) and UTXO #2 (0.15) as inputs — total 0.55 — producing a 0.50 BTC output to the recipient and a ~0.049 BTC change output back to yourself (the missing fraction is the miner fee). Afterwards your “balance” is the new change UTXO plus the untouched UTXO #3. The number looks continuous; the underlying objects are chunky and discrete.

The account model, for contrast

Ethereum (and traditional banking) uses the opposite design: the account model. The ledger is a mutable map from address → balance, and a transaction is an instruction that mutates two entries:

UTXO model (Bitcoin)              Account model (Ethereum)
-----------------------          ---------------------------
state = set of coins             state = map{ address : balance }
spend = consume coins,           spend = decrement sender,
        create new coins                 increment receiver
coin is either in the set        balance is a single number
or it is gone (binary)           that goes up and down

Both are valid ways to run a shared ledger. They make different trade-offs.

Why the UTXO model — what it buys you

The UTXO model exists because it makes the core job of a cryptocurrency easy to verify: deciding whether a payment is a double-spend.

Property	How UTXO delivers it
Trivial double-spend check	A coin is either still in the unspent set or it isn’t. Spending it twice means referencing an output that’s already gone — instantly rejected. No balance arithmetic, no ordering puzzles.
Parallelism	UTXOs are independent objects. Transactions touching different UTXOs have no shared state, so validators can check them in any order, in parallel.
Stateless-ish validation	To verify a transaction you only need the specific UTXOs it spends, not the entire account history.
Privacy by default	Best practice is a fresh address (a fresh lock) per output, so there’s no single long-lived “account” stitching your activity together.

The trade-off is statefulness for the user: your funds are scattered across many coins, the wallet must track them all, and complex stateful logic (a contract that remembers a running counter) is awkward — Bitcoin Script is deliberately not built for that. The account model flips this: a smart contract holding evolving state is natural, but every transaction touches global mutable balances, which complicates parallel execution and forces a strict ordering (the “nonce”) on each account’s transactions.

A clean one-liner

UTXO is cash; the account model is a chequebook. Cash is a pile of discrete bills you hand over and get change from. A chequebook is a single running balance you debit and credit. Bitcoin chose cash because cash is easy for strangers to count without trusting each other.

The thread

How does this help untrusting strangers agree on one ledger? The whole point of a decentralized ledger is that thousands of mutually distrusting nodes must independently reach the same verdict on every payment. The UTXO model reduces “is this payment valid?” to “does each referenced coin still exist, unspent, in the set, and is the unlocking proof correct?” — a check any node can perform locally, deterministically, and in parallel, with no opinion required. Validity becomes a matter of set membership, not of trusting anyone’s balance bookkeeping. That objectivity is exactly what lets strangers converge on one ledger without a referee.

In the next pages we open up an actual transaction — its inputs and outputs, how value is conserved and fees emerge, and how each coin is addressed.

Check your understanding

1. Where in Bitcoin is “your balance” actually stored? What is it really the sum of?
2. Why can’t you spend half of a UTXO, and what mechanism gives you the remainder back?
3. Give the one-line double-spend check the UTXO model enables, and explain why it needs no trust.
4. Contrast how state is represented in the UTXO model vs the account model.
5. Name one thing the account model does more naturally than UTXO, and one thing UTXO does more naturally than the account model.