Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Research · Ethereum

The Ethereum account model

Ethereum keeps a balance per account rather than a set of unspent outputs, and it lets an account be controlled by code as well as by a key. That single decision shapes how transactions are ordered, how state is stored, and what a wallet has to track.

Last reviewed 2026-09-21Source: Ethereum Yellow Paper and ethereum.org developer documentationMechanism descriptions only; no figures are stated that the cited sources do not carry.

Two kinds of account

Ethereum's state is a mapping from addresses to account objects, and every account object carries the same four fields: a nonce, a balance in wei, a storage root, and a code hash. The difference between the two account types is which of those fields are actually used. An externally owned account, controlled by a private key, carries a nonce and a balance and leaves the storage root and code hash empty. A contract account carries all four, because it has code that can read and write its own storage.

The nonce means something different in each case, and the difference matters. For an externally owned account it counts the transactions the account has sent, which is what makes replaying a signed transaction impossible and what forces transactions from one key to execute in order. For a contract account it counts the contracts the account has created, and it is what determines the address of the next contract that account deploys. Neither counter is a balance or a sequence number in the blockchain sense; both are part of the account's persistent state.

The address itself is derived rather than assigned. An externally owned account's address is the last twenty bytes of the Keccak-256 hash of its public key, so the address exists as soon as the key does and needs no registration. A contract's address is derived from the creator's address and its nonce, or from the creator's address and a supplied salt when the creation uses the deterministic deployment pattern. In both cases the address is computable in advance, which is why a contract can be sent funds before it has been deployed.

Accounts against unspent outputs

The two models answer the same question — who may spend what — with different data structures, and the trade-offs run in opposite directions.

How Bitcoin's unspent-output model and Ethereum's account model differ on the properties that shape wallet and node behaviour.
PropertyBitcoin (UTXO)Ethereum (accounts)
Unit of ownershipAn unspent output, spent wholeA balance attached to an address
BalanceDerived by summing outputsStored directly in the account
Replay protectionEach output can be spent onceA per-account nonce orders transactions
Parallel executionOutputs are independent by constructionTransactions from one account are strictly ordered
State growthGrows with the output set; spent outputs are prunedGrows with the account set; empty accounts persist unless cleared
Address reuseFresh addresses are the normOne address is reused for every transaction

Last reviewed 2026-09-21Source: Ethereum Yellow Paper; Bitcoin Developer ReferenceStructural comparison; no performance figures are claimed.

The account model makes a balance a first-class value, which is why an Ethereum wallet can display a number without scanning the chain for outputs. It also makes every transaction from one key strictly sequential, because the nonce must increase by exactly one each time. That ordering is a convenience for users and a constraint for builders: two transactions from the same account cannot be executed in parallel, and a transaction that is stuck at a given nonce blocks every later transaction from that account until it is mined or replaced.

The model also changes what an address means. A Bitcoin address is conventionally used once, and reusing it links every payment to it. An Ethereum address is a persistent identity that is reused for every transaction, so the account's entire history is associated with one identifier by design. That is not a flaw in the account model; it is the model working as specified, and it is why privacy on Ethereum is approached through additional contracts rather than through address hygiene.

Storage, code and the state trie

A contract account's storage is a sparse mapping from 256-bit slots to 256-bit values, and it is not stored as a flat table. Each account's storage is committed to as its own Merkle-Patricia trie, and the root of that trie is the storage root recorded in the account. The account objects themselves are committed to in a separate state trie keyed by address. The result is a two-level commitment: a single 32-byte state root commits to every account, and each account's storage root commits to everything that account has written.

That structure is what lets a light client ask a full node for a proof about one account or one storage slot without downloading the whole state. It is also what makes state growth a structural concern rather than a storage-cost concern: a slot that is written once and never cleared remains part of the state that every full node must carry, and the trie nodes along its path are shared with other accounts, so the cost of a new account is not simply the size of its data.

Code is stored separately from storage and is immutable once deployed. A contract's code hash is recorded in its account, and the code itself is content-addressed by that hash, so two contracts with identical bytecode share one copy. Because the code cannot be changed, the common pattern for upgrading a contract is to deploy a new implementation and have the old contract delegate its calls to it — a pattern that moves the upgradeable surface into storage rather than into code, and that is covered in the smart contracts page of this cluster.

Sources and references

The account structure, address derivation and state commitment described above are taken from Ethereum's own specification and developer documentation.

  • Account structure and the two account types. ethereum.org, Ethereum accounts: an account has a nonce, a balance, a storage root and a code hash, and is either externally owned or a contract.
  • The formal state transition and account definition. Ethereum Yellow Paper, Ethereum: A Secure Decentralised Generalised Transaction Ledger: the world state is a mapping between addresses and account states.
  • State and storage tries. ethereum.org, Patricia Merkle Trie: each account has its own storage trie, and the state trie commits to every account.
  • The unspent-output model this page compares against. Bitcoin Developer Reference, Transactions: a transaction spends whole outputs and creates new ones.

Related reading