Two Ledgers: UTXO vs the Account Model

The part overview promised that Ethereum’s whole answer to how do untrusting strangers agree on the state of a shared world computer hangs on one design decision: what, exactly, is the “state” that everyone agrees on? There are two famous answers, and picking between them changes almost everything downstream — how a payment is validated, whether transactions can run in parallel, whether programs can remember anything, and how much of your life is visible to a stranger with a block explorer.

This page puts the two answers side by side. Bitcoin models state as a set of independent, one-shot coins (the UTXO model). Ethereum models it as a map from address to a mutable account record. They are not two flavours of the same idea — they are opposite mental models, and the word “balance” means something genuinely different in each. Getting this contrast crisp now is what makes every later page in this part — the two kinds of account, the account record, the global state map, and state transitions — feel inevitable rather than arbitrary.

Two mental models, one transfer

The fastest way to feel the difference is to move 30 units from Alice to Bob in each system.

   UTXO (Bitcoin)                        ACCOUNT (Ethereum)
   ─────────────                         ──────────────────
   state: a SET of coins                 state: a MAP address → account
     { Alice's 50-coin, ... }              { alice: {balance:50}, bob: {balance:0} }

   move 30:                              move 30:
     consume  Alice's 50-coin             alice.balance : 50 → 20
     create   Bob's   30-coin             bob.balance   :  0 → 30
     create   Alice's 20-coin (change)

   the 50-coin is DESTROYED forever;     the SAME two rows are
   two brand-new coins now exist         EDITED IN PLACE

In the UTXO world a transfer destroys and creates. Alice’s 50-coin is consumed whole — it ceases to exist — and two fresh coins are minted: 30 for Bob, and 20 of “change” back to Alice. Nothing is mutated. A coin is immutable: created exactly once, spent exactly once, then gone. The ledger is a pile of these one-shot coins, and it never edits any of them.

In the account world a transfer edits in place. There is a map from address to a mutable record, and moving value is just arithmetic on two numbers: subtract 30 from one row, add 30 to another. The rows persist; only their contents change. Nothing is destroyed and nothing is created — the same two accounts exist before and after, with different balances.

That single distinction — destroy-and-create versus edit-in-place — is the seed of every trade-off on this page.

”Balance” is the same word for opposite things

Ask each chain “what is Alice’s balance?” and you are asking two different questions.

In Bitcoin, a balance is DERIVED. There is no row anywhere that says alice: 50. There is only a set of coins, each locked to some key. Your wallet computes your “balance” by scanning the UTXO set for every coin your keys can unlock and summing them. The number is not stored; it is a query result. Spend a coin and it leaves the set — the sum recomputes itself.
In Ethereum, a balance is STORED. The account record literally contains a balance field. “Alice’s balance” is a single number you read directly out of her account, no scanning, no summing. A transfer writes a new value into that field.

   Bitcoin  "balance"  =  Σ (unspent coins my keys can unlock)     ← computed on demand
   Ethereum "balance"  =  world_state[alice].balance                ← read from one cell

This is why the same word feels so different in practice. A Bitcoin balance is an emergent property of a set of objects; an Ethereum balance is a fact recorded in a field. Everything that follows — nonces, parallelism, storage, privacy — is downstream of “is this number derived, or stored?”

Stateless coins vs stateful accounts

Here is the sense in which Ethereum is precisely, technically stateful — a claim worth pinning down, because “stateful” is used loosely.

A Bitcoin node absolutely holds state: the entire UTXO set is state everyone must agree on. But each coin is self-contained and inert. It is created once, carries a fixed value and a fixed lock, and the only thing that ever happens to it is that it gets spent and disappears. A coin never changes; it only exists or doesn’t. Bitcoin’s state is a set of nouns — things that are, or are not, in the set.

An Ethereum account is the opposite kind of object. It persists across transactions and mutates between them. Call a contract today and it may behave differently than yesterday, because a transaction in between rewrote its storage. The account is not a value that gets consumed — it is a cell that gets edited, over and over, and remembers the last write. Ethereum’s state is a running machine whose values evolve over time.

   UTXO coin lifecycle:      created ──spent──► gone         (one-shot, immutable, stateless)

   Account lifecycle:        created ──edit──► edit ──edit──► ...   (persistent, mutable, stateful)
                                        ▲                    │
                                        └──── remembers the last write

That is the precise meaning of “Ethereum is stateful”: not merely that nodes store data, but that the fundamental unit of state — the account — is a mutable cell with memory that outlives any single transaction. A coin is designed to be forgotten; an account is designed to remember. And a program is nothing without memory, which is exactly why the account model is the one that can host programs. (We meet those programs — contract accounts — next.)

The bill for mutability: the trade-off table

Nothing is free. The instant state becomes shared and mutable, four costs appear that the UTXO model simply never has to pay. Read this table as “what edit-in-place forces on you.”

	UTXO (Bitcoin)	Account model (Ethereum)
State is…	a set of independent one-shot coins	a map `address → mutable account`
A transfer…	destroys coins, creates coins	edits two numbers in place
”Balance” is…	derived (sum of your UTXOs)	stored directly in a field
Replay protection	inherent (a spent coin is gone)	needs an explicit nonce
Parallelism	easy (disjoint coins, any order)	hard (shared balances, order-dependent)
Persistent memory	none — coins are spent once	yes — per-account `storage`
Privacy default	fresh address per coin	one long-lived, linkable identity

Each row is a direct consequence of destroy-and-create versus edit-in-place. Walk the four costs:

Replay protection: inherent vs invented

In Bitcoin, a transaction names specific coins as its inputs. Once mined, those coins are spent and vanish from the set; rebroadcasting the same signed transaction is a no-op, because its inputs no longer exist. Replay protection is free — a property of the model.

In the account model, “pay Bob 30” is just edit two balances. Nothing is consumed. Rebroadcast Alice’s signed transaction ten times and — absent a defence — it would run ten times, because the signature is valid every time. So the account model must invent a defence: the nonce, a per-account counter a transaction must name and that applying it increments. A transaction is valid only if its nonce equals the sender’s current nonce, which makes each signed message one-time-use.

   alice.nonce = 0
   tx { from: alice, nonce: 0, pay bob 30 }   ✓  (0 == 0)   → alice.nonce = 1
   REPLAY the same tx: nonce 0                ✗  (now at 1) → REJECTED

Parallelism: disjoint objects vs shared cells

UTXO transactions that touch different coins share no state, so a validator can check them in any order — even at the same time. Validity is a local question of set membership.

Account transactions touch shared, mutable balances, and the answer depends on the order they run:

   One account, balance = 10, two outgoing txs:  T1: send 8    T2: send 5
      order T1 → T2 :  10 → 2  → T2 fails (only 2 left)
      order T2 → T1 :  10 → 5  → T1 fails (only 5 left)

The outcome depends on ordering, so a naive validator must process an account’s transactions sequentially. This is a major reason Ethereum’s base-layer execution is essentially single-threaded — to guarantee every node reaches the identical world state, transactions are applied one after another in block order.

Persistent memory: nothing vs per-account storage

A UTXO has no memory: it is a value, spent once, with no cell to write into. An account carries a storage map — persistent key/value memory that survives between transactions. This is the field UTXO has no equivalent for, and it is the entire reason the account model exists: a program needs somewhere to remember what it did.

Privacy: a fresh lock vs a long-lived name

Best practice in Bitcoin is a fresh address per coin — a new lock every time — so there is no built-in thread stitching your activity together. In Ethereum your account is your identity: every transaction, every contract you touch, every token you hold sits under one reusable address anyone can watch in real time. Reusing the address is not a mistake — it is how the model works. The convenience of a single stored balance is paid for in a permanently linkable history.

The derived-vs-stored split is not just conceptual; it shows up as different work at read time.

   Bitcoin — "what is my balance?"
     scan the UTXO set for coins my keys unlock, then sum:
       coin_a = 12  +  coin_b = 30  +  coin_c = 8   =  50      (work grows with # of coins)

   Ethereum — "what is my balance?"
     world_state[0xAlice].balance                    =  50      (one lookup, O(1))

A Bitcoin wallet holding fifty small coins does fifty lookups and one sum to answer “how much do I have?”; an Ethereum client does one. The flip side is the cost table above: that single stored number is why Ethereum needs a nonce, serialises execution, and links your whole history to one address. Convenience at read time, complexity at write time.

On 20 July 2016, Ethereum hard-forked (to reverse the DAO hack) and the un-forked chain continued as Ethereum Classic. Suddenly two chains existed with identical account histories and identical nonces. A transaction valid on one — same sender, same nonce, same signature — was often valid on the other, so value moved on ETH could be replayed to move the matching value on ETC, draining people who meant to transact once. The fix (later standardised as EIP-155) was to fold a chain ID into the signed data, binding a signature to one specific chain. It is the account model’s replay lesson one level up: because a transfer consumes nothing, “this already happened” is never self-evident — you have to encode uniqueness into what gets signed, or it can be done again. Bitcoin’s UTXO model never faced this class of bug, because a coin, once spent, is simply gone.

Neither model is “better”

It is tempting to score this as a contest. It isn’t one. The two models optimise for different things, and each is excellent at its own job.

UTXO is the simplest thing for strangers to verify. Validity is a stateless, order-free question of set membership: do these input coins exist and are they unspent, and do the signatures unlock them? Any node answers it locally, in parallel, with no balances to trust and no shared state to serialise. If your goal is money that mutually distrusting parties can audit cheaply, this is close to the theoretical minimum.

The account model is the minimum viable substrate for programmable, evolving state. The moment you want a program on a shared ledger — a token whose balances change, a market with a running order book, a vote that tallies over time — you need a cell of state that persists, is shared, and mutates. UTXO offers none of those by design; it is built to forget. The account model provides exactly that cell, and pays for it with the whole right-hand column of the table: nonces, serial execution, unbounded state growth, and a linkable identity.

So the choice is not good vs bad but cheap-to-verify vs rich-to-build-on. Bitcoin took the model that is easiest for strangers to agree on. Ethereum took the model that is richest to compute over — and the rest of this part is, quite literally, the itemised bill for that richness.

The architect’s lens

The account model is a deliberate alternative to UTXOs. Interrogate it as the engineering choice it is:

Why does it exist? To hold evolving, programmable state — a global map of address → mutable record — because Bitcoin’s stateless pile of one-shot coins can express money beautifully but cannot naturally express a program that remembers.
What problem does it solve? Stateful computation on a shared ledger: a contract needs a stable cell whose values change over time, and a stored balance gives every account a place that persists and mutates instead of a balance that must be re-derived from scattered coins.
What are the trade-offs? Edit-in-place makes state shared and mutable, which forces a nonce for replay protection, makes execution order-dependent (so the base layer is essentially single-threaded), ties your whole history to one linkable address, and lets state only grow — none of which the UTXO model has to pay.
When should I avoid it? When you want cheap parallel verification, default privacy, or a working set that can shrink — exactly the terrain where the UTXO model wins. For pure peer-to-peer money among strangers, stateless coins are the simpler and safer substrate.
What breaks if I remove it? Replace the account model with pure UTXOs and you lose the persistent, mutable cell that programs live in — no contract accounts, no state transitions that a “world computer” is defined by. The expressiveness that Ethereum exists to provide disappears with it.

Check your understanding

Contrast the state in each model in one phrase each, then contrast what a transfer does to that state.
“Balance” means opposite things in Bitcoin and Ethereum. Explain the difference between a derived balance and a stored balance, and how each responds to a spend.
In precisely what sense is Ethereum “stateful” that Bitcoin is not — given that a Bitcoin node also stores state everyone agrees on?
Bitcoin needs no nonce; Ethereum does. What property of destroy-and-create gives Bitcoin replay protection for free, and why does edit-in-place lose it?
Using one account with balance 10 and two outgoing transactions, show why the account model resists parallel verification while the UTXO model does not.

Show answers

UTXO state is a set of independent one-shot coins; account state is a map from address to a mutable record. A UTXO transfer destroys the input coins and creates new ones (including change back to the sender); an account transfer edits two balance numbers in place — the same rows exist before and after, with new values.
A derived balance (Bitcoin) is not stored anywhere — the wallet computes it by scanning the UTXO set and summing every unspent coin your keys can unlock; spending a coin removes it from the set and the sum recomputes. A stored balance (Ethereum) is a number written directly in the account’s balance field; a spend writes a new value into that one cell.
Both store state, but Bitcoin’s unit of state — a coin — is self-contained and inert: created once, spent once, never edited; it only exists or doesn’t. Ethereum’s unit — an account — is a mutable cell with memory that persists across transactions and is edited in place, so a contract can behave differently over time because its storage changed. “Stateful” means the fundamental unit remembers and mutates, not merely that data is stored.
In UTXO a transaction names specific coins as inputs and consumes them; once spent they no longer exist, so rebroadcasting the same signed transaction does nothing — replay protection is inherent. An account transfer consumes nothing (it just edits balances), so the same signed message stays valid and could re-run forever; the nonce, a per-account counter that must match and then increments, makes each signed transaction one-time-use.
With balance 10 and T1: send 8, T2: send 5: order T1→T2 leaves 2 then T2 fails; order T2→T1 leaves 5 then T1 fails. The outcome depends on ordering, so a validator must apply the account’s transactions sequentially. UTXO transactions touch independent coins (disjoint state), so any node can verify them in any order, in parallel.