UTXO vs the Account Model (Ethereum)

You already met the two ways to run a ledger in UTXO vs the Account Model: Bitcoin’s pile of discrete unspent coins versus a mutable map of address → balance. That page introduced the contrast; this one takes the account model seriously on its own terms, using the system that made it famous — Ethereum — and asks the first-principles question for this whole part: what does the account model buy, and what does it cost? The answer turns out to explain a surprising amount about why the two chains feel so different to use, to scale, and to audit.

Ethereum’s state: one global map, always mutating

Bitcoin keeps no balances. Its entire state is the UTXO set — the pile of coins that currently exist — and a transaction simply consumes some coins and creates new ones. Ethereum does the opposite. Its state is a single global table with one row per account:

   ETHEREUM WORLD STATE  (one entry per account)
   address ─┬─ nonce        : how many transactions this account has sent
            ├─ balance      : amount held, in wei (1 ETH = 10^18 wei)
            ├─ codeHash      : the contract's code, if any (empty for a plain wallet)
            └─ storageRoot   : the contract's own key/value storage, if any

There are two kinds of account, and the difference matters for the rest of this part:

• Externally Owned Accounts (EOAs) — controlled by a private key. This is a “wallet.” It has a nonce and a balance, no code.
• Contract Accounts — controlled by code, not a key. They have a balance and their own persistent storage. Code runs when the account is called. (This is the door into smart contracts and the EVM.)

A transaction is an instruction that mutates this map: debit the sender, credit the receiver, maybe run some contract code that rewrites storage. After it runs, the global table is different. That single sentence — the ledger is mutable shared state — is the root of almost every trade-off below.

The same word, two opposite meanings of “state”

Bitcoin is sometimes called “stateful” because every node holds the UTXO set — but each coin is self-contained and independent. Ethereum is stateful in a stronger sense: accounts persist and evolve, and a contract you call today can behave differently than yesterday because its storage changed. Bitcoin’s state is a set of nouns (coins that exist or don’t). Ethereum’s state is a running machine (accounts whose values change over time). Hold that distinction — it drives everything else.

The nonce: ordering is now mandatory

Because an account is a single running balance, Ethereum needs something Bitcoin never does: a strict per-account order on transactions. That is the nonce — a counter that starts at 0 and increments by exactly 1 with every transaction an account sends.

Why it’s required:

• Replay protection. Without a nonce, a signed “send 1 ETH to Bob” could be rebroadcast forever, draining the sender. The nonce makes each transaction one-time-use: once nonce 5 is mined, a second nonce 5 is invalid.
• Deterministic ordering. nonce 5 cannot be processed before nonce 4. Every node applies an account’s transactions in exactly the same sequence, so everyone computes the same resulting balances.

   account 0xabc…  must send in order:
      nonce 0  →  nonce 1  →  nonce 2  →  nonce 3  …
      (a gap — say nonce 2 is missing — stalls everything after it)

Bitcoin needs no such counter. A UTXO is consumed whole and disappears from the set; you cannot “replay” spending a coin that no longer exists, and independent coins have no required order among them. The nonce is the account model’s price for not having discrete, one-shot coins.

A real footgun the nonce creates — “stuck” transactions

Because nonces must be strictly sequential, a single transaction stuck in the mempool (say its fee was too low) blocks every later transaction from the same account — they all have higher nonces and can’t be mined until the gap fills. Ethereum users routinely “replace” a stuck transaction by re-sending the same nonce with a higher fee. This is a class of confusion Bitcoin users never meet, because Bitcoin has no per-account sequence to stall — it’s a direct, observable cost of the account model’s mandatory ordering.

Parallelism: the account model’s hardest trade

Recall why the UTXO model parallelizes so cleanly: coins are independent objects, so two transactions touching different coins share no state and can be verified in any order, even at the same time. Validity is a question of set membership.

The account model loses this by construction. Transactions touch shared, mutable balances, and the result depends on the order they run:

   Two transactions, same account, balance = 10:
      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 — it cannot freely parallelize. This is a major reason Ethereum’s base-layer execution is essentially single-threaded today: to guarantee every node reaches the identical world state, transactions are applied one after another in block order.

This single fact is why later chains care so much about declaring what state a transaction touches. Solana’s Sealevel makes transactions list their accounts up front precisely so non-overlapping ones can run in parallel — it is trying to recover, by brute engineering, the parallelism that the UTXO model gets almost for free.

	UTXO (Bitcoin)	Account model (Ethereum)
State	Set of independent coins	Global map of mutable accounts
A spend is	Consume coins, create coins	Mutate sender + receiver entries
Ordering	None required between independent coins	Strict per-account nonce order
Parallel verify	Natural (disjoint coins, any order)	Hard (shared balances, order-dependent)
Stateful contracts	Awkward (Script is bounded, stateless-ish)	Natural (contracts own evolving storage)

Privacy: one long-lived address vs a fresh lock each time

The state model also quietly sets the default privacy posture of each chain.

• Bitcoin / UTXO. Best practice is a fresh address per output — a new lock for every coin (see address types and the privacy page). There is no built-in “account” stitching your activity together. Chain analysis is still possible (clustering inputs, following change), but the model defaults to scattering your footprint across many one-time addresses.
• Ethereum / accounts. Your account is your long-lived identity. Every transaction you ever send, every contract you interact with, every token you hold sits under one reusable address that others can watch in real time. Reusing the address is not a mistake — it is how the model works. The convenience (a single balance, a stable name) is paid for in a permanently linkable history.

Cash vs a named account, again

The earlier book put it as UTXO is cash; the account model is a chequebook. Privacy is the same coin’s other side: cash is anonymous because each bill carries no name, while a named account records every movement under your identity by design. Neither is “more correct” — Bitcoin optimized for strangers counting cash without trusting each other; Ethereum optimized for programs that need a stable place to keep state.

By the numbers — why Ethereum’s state size is a standing worry

Because accounts and contract storage persist and accumulate, Ethereum’s world state only grows as more accounts and contracts are created and keep their storage. As of the mid-2020s the live state that a node must keep in a fast-access trie is on the order of a hundred-plus gigabytes, and “state growth” / “state expiry” is an active research topic precisely because an ever-growing mutable map raises the bar to run a node.

   Bitcoin live working set (UTXO chainstate)  :  a few GB
   Ethereum live state (accounts + storage)    :  ~100+ GB and growing  (order of magnitude, mid-2020s)

Bitcoin’s UTXO set can shrink when coins are spent; Ethereum’s state has no equivalent automatic pruning — a contract’s storage sticks around until someone explicitly clears it. The account model’s expressiveness shows up, years later, as a heavier thing for every node to carry.

The thread

How does each model help untrusting strangers agree on one ledger? Both reach the same goal by opposite routes. The UTXO model makes “is this payment valid?” a stateless, order-free question of set membership — any node checks it locally and in parallel, no balances to trust. The account model makes validity depend on the current global state and a strict transaction order — every node must replay the same sequence of mutations to reach the same map. That replay is heavier and harder to parallelize, and it ties your whole history to one visible address — but in return the ledger can hold evolving, programmable state, which is exactly what makes the next page possible. Bitcoin chose the model that’s easiest for strangers to verify; Ethereum chose the model that’s richest to build on. The rest of this part is the bill for that richness.

The architect’s lens

The account model is a deliberate alternative to UTXOs — interrogate it as the design choice it is:

• Why does it exist? Ethereum’s account model — a global map of address → nonce, balance, code, storage — exists to hold evolving, programmable state, the thing Bitcoin’s stateless pile of one-shot coins can’t naturally express.
• What problem does it solve? Stateful programs: a contract needs a stable place whose values change over time (a token’s balances, a running market), and the nonce supplies the replay protection and deterministic ordering that a mutable shared state requires.
• What are the trade-offs? Shared mutable balances make execution order-dependent, so the base layer is essentially single-threaded — none of the free parallelism the UTXO model gets; the nonce creates stuck-transaction footguns; one long-lived address makes your whole history permanently linkable; and state only grows (~100+ GB, no automatic pruning).
• When should I avoid it? It’s the wrong model when you want cheap parallel verification, default privacy, or a shrinkable working set — exactly where Bitcoin’s UTXO model wins (and why Solana’s Sealevel re-imposes up-front account declarations to claw parallelism back).
• What breaks if I remove it? Swap the account model for pure UTXOs and you lose natural stateful contracts — no EVM world computer — which is precisely the expressiveness Ethereum exists to provide.

Check your understanding

1. List the four fields stored for an Ethereum account, and say which two are only meaningful for a contract account.
2. What is the nonce for, and what two problems does it solve that Bitcoin handles without any per-account counter?
3. Using a single account with balance 10 and two outgoing transactions, show why the account model resists parallel verification while the UTXO model does not.
4. Why does Ethereum default to a less private footprint than well-used Bitcoin, even though both are public ledgers?
5. Why does Ethereum’s live state tend to grow while Bitcoin’s UTXO set can actually shrink?

Show answers

1. nonce, balance, codeHash, storageRoot. codeHash and storageRoot are only meaningful for a contract account (a plain wallet / EOA has no code and no persistent storage).
2. The nonce is a per-account counter that increments by 1 each transaction. It provides replay protection (a signed transaction can’t be rebroadcast forever — once nonce 5 is mined, another nonce 5 is invalid) and deterministic ordering (nonce 5 can’t process before nonce 4, so every node applies the account’s transactions in the same sequence). Bitcoin needs neither because a UTXO is consumed whole and vanishes — you can’t replay spending a coin that no longer exists, and independent coins have no required order.
3. 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 they can be verified in any order, in parallel.
4. Bitcoin’s best practice is a fresh address (lock) per output, so there’s no built-in account stitching activity together. Ethereum’s account is a long-lived, reusable identity — every transaction, contract interaction, and token sits under one watchable address by design. Address reuse is how the account model works, so it defaults to a permanently linkable history.
5. Ethereum accounts and contract storage persist and accumulate — there’s no automatic pruning; a contract’s storage stays until explicitly cleared. Bitcoin’s UTXO set shrinks whenever coins are spent (the consumed outputs are removed from the set), so the live working set isn’t a one-way ratchet the way Ethereum’s world state is.