Account Model vs UTXO

In brief

In Bitcoin’s UTXO model, every input points to a specific unspent transaction output. A valid transaction consumes each referenced output once and creates replacement outputs. A wallet’s displayed BTC balance is a sum calculated from UTXOs its keys can authorize; Bitcoin does not maintain one mutable balance field for each address.

In Ethereum’s account model, global state contains accounts with nonce, ETH balance, storageRoot, and codeHash fields. Transactions update that state in nonce order. ERC-20 balances are contract state, not entries in the native ETH balance field.

Solana also stores state in addressed accounts, but “account” is broader than an Ethereum user account. Programs are executable accounts, mutable application state lives in separate data accounts, and token holdings live in token accounts owned by a Token Program.

UTXO and account are useful families, not a complete taxonomy. Some chains use extended-UTXO designs or other hybrids.

Bitcoin: spending outputs, not debiting an address

The Bitcoin Developer Guide says wallet software gives the impression that satoshis move between wallets, while protocol transactions actually spend earlier transaction outputs. Each output is identified by its transaction and output index, carries a value, and contains a locking script. A later input supplies the data needed to satisfy that lock.

An output can be spent only once in the accepted chain. Referencing it again is a double-spend attempt. Ignoring coinbase rules, outputs cannot total more than inputs; when inputs total more than outputs, the difference is available as the miner fee.

Suppose a wallet controls a 0.5 BTC UTXO and wants to pay 0.3 BTC. It cannot shave 0.3 off the old output. It spends the 0.5 output and might create:

• a 0.3 BTC payment output;
• a change output back under the wallet’s control; and
• an implicit fee equal to inputs minus all new outputs.

The exact change is less than 0.2 BTC once a positive fee is included. Coin selection affects transaction size, fees, and privacy: combining many UTXOs generally needs more input data and can reveal that one spender controlled them.

An address “balance” shown by a Bitcoin wallet or explorer is therefore an indexed view, not a protocol account object. Spending conditions such as signatures, multisignature policies, and timelocks attach to outputs through Script.

Ethereum: updating global account state

Ethereum’s state has two familiar account categories: externally owned accounts (EOAs) and contract accounts. The core account fields are:

• nonce — transaction count for an ordinary EOA, or contract-creation count for a contract account;
• balance — native ETH in wei;
• codeHash — hash of executable account code;
• storageRoot — root of the account’s persistent storage trie.

An ordinary EOA authorizes a transaction with a signature. The transaction carries a nonce, destination, optional ETH value and input data, plus fee limits. A plain ETH payment reduces the sender’s native balance by the value and charged fee and credits the recipient’s native balance. There is no change output.

Contract accounts do not have private keys that independently sign transactions. Their code runs when execution reaches them. EIP-7702 adds an important modern caveat: an EOA can set a delegation designator in its code field, so “EOAs always have empty code” is no longer a safe universal rule.

ERC-20 is a second accounting layer. A token contract typically maps addresses to token amounts. Calling its transfer function changes contract storage; it does not move ETH in either account’s native balance field.

Solana: accounts as explicit state inputs

Every Solana account has an address and fields including lamports, data, an owner program, and an executable flag. The runtime rule is precise: only an account’s owner program can modify its data or debit its lamports, while any program can credit lamports to a writable account.

Solana programs are executable sBPF code and are designed to be stateless. Mutable state sits in separate data accounts supplied to instructions. Programs deployed with an upgrade authority can be upgraded; revoking that authority makes them immutable.

Token state follows the same separation:

• a mint account identifies a token and stores shared fields such as supply, decimals, and authorities;
• a token account holds units of exactly one mint and is program-owned by the original Token Program or Token-2022;
• the token account’s internal owner field names the authority that can transfer its tokens;
• an associated token account (ATA) is a conventionally derived default token account for an owner, mint, and Token Program.

That last distinction matters. “Program owner” controls the data under Solana’s runtime, while “token-account owner” is an authority recorded inside that data. They are not the same role. The Token Program ID is also part of ATA derivation, so the original Token Program and Token-2022 do not share an ATA for the same wallet and mint inputs.

How the designs change transactions

Ordering and replay. A Bitcoin input names the exact output it consumes; after that output is spent on the accepted chain, it cannot be consumed again. Ethereum transactions from an account use sequential nonces. Solana transactions normally include a recent blockhash and can instead use a durable nonce for offline or delayed signing.

Parallel work. Independent UTXOs have no shared mutable balance. Ethereum senders have sequential account nonces, and contracts may contend over shared storage. Solana transactions declare the accounts their instructions use, allowing the runtime to lock accounts and schedule non-conflicting work in parallel.

Storage cost. A small Bitcoin UTXO may be uneconomical to spend because its input increases transaction size. Ethereum keeps native ETH in one account field but charges gas for execution and storage operations. Solana accounts must maintain a data-size-dependent rent-exempt lamport balance while they remain on-chain; closing eligible accounts can recover that balance.

These are consequences, not promises. Parallelism depends on the full transaction and application, and no model automatically provides low fees or privacy.

Common mistakes

• Treating a Bitcoin address as a mutable account with a nonce.
• Saying a wallet “contains” coins; wallets manage keys and construct a view of ledger state.
• Treating ERC-20 balances as native ETH balances.
• Calling a Solana token account a per-token smart contract.
• Assuming “account-based” means Ethereum and Solana organize code, state, authorization, and replay protection identically.