# UTXO vs Account Model
The question this note answers: what shape does blockchain state take?
Two answers dominate the field. Bitcoin tracks coins; Ethereum tracks accounts. It sounds like an implementation detail, but the choice ripples through everything built on top — which is why it's worth understanding both.
## UTXO: Bitcoin's answer
In Bitcoin there are no balances, only unspent transaction outputs. A transaction consumes old outputs and creates new ones:
```text
Alice owns a UTXO worth 1 BTC.
Alice spends it:
input: the 1 BTC UTXO
outputs:
0.7 BTC to Bob
0.299 BTC back to Alice (change)
0.001 BTC fee
```
A coin is valid if it traces back, spend by spend, to a valid issuance. "Alice's balance" isn't stored anywhere — it's a view, the sum of UTXOs her keys can spend.
| **Strengths** | **Costs** |
|---|---|
| Simple validity rules | Awkward for rich application state |
| Natural parallelism (disjoint inputs don't conflict) | Constrained smart contracts |
| Clean provenance and auditability | Change-output bookkeeping |
## Accounts: Ethereum's answer
Ethereum stores state as a map from address to account:
```text
Account {
nonce
balance
code_hash
storage_root
}
```
There are two kinds: externally owned accounts (controlled by a private key) and contract accounts (controlled by code). Transactions mutate this shared map directly.
| **Strengths** | **Costs** |
|---|---|
| Natural for smart contracts and app state | Shared-state contention |
| Expressive | More complex execution |
| Familiar programming model | Larger attack surface |
## The database analogy
Here's a framing that tends to stick: UTXO is an append-only ledger of immutable records, where spends consume rows and produce rows. Accounts are a mutable key-value store, updated in place, effectively under a global write lock per block. The first parallelizes beautifully and expresses little; the second expresses anything and serializes everything.
Neither answer is "right" — they optimize for different questions. Which is why newer designs (Solana's accounts with declared access lists, Move's object model, smart-contract experiments on UTXOs) keep exploring the space between the two.
## Where this matters
- [[03 Blocks, Hashes, and History]] — what the blocks are actually transitioning
- [[05 Execution and Smart Contracts]] — why the EVM assumes accounts