Pay for a 30-dollar dinner with a 50-dollar note and the waiter brings back 20. Pay by card and the bank lowers one number on your account by 30. Bitcoin works like the note, Ethereum like the card. That design choice, the UTXO vs account model, explains why a Bitcoin wallet sends part of every payment back to you, why a payment built from many small receipts costs more, and why one stuck Ethereum transaction freezes every transaction you send after it.
Most days the difference stays hidden behind the wallet app. It shows up when a Bitcoin payment costs four times what a friend paid to send the same amount, when an address you have never seen appears inside your own transaction, or when a transfer sits “pending” for an hour and holds back the next three. This lesson takes both ledgers apart, adds Cardano and Solana, which bent each model their own way, and ends on an echo few people expect: the tax rules on which units you sold.
It follows the previous lesson of the path, how the mempool works and how transaction fees are set. The one point to carry over: transactions wait in each node’s mempool and are picked by fee rate, counted in satoshis per virtual byte (sat/vB). Keep that unit in mind. In the UTXO model it is what turns a wallet full of small coins into a bill.
Two ways to keep a ledger: coins or accounts
Every blockchain has to answer one question for each transaction: does the sender really have what she is spending? There are two ways to store the answer.
In the UTXO model (for unspent transaction output), the ledger is a pile of separate pieces of value, each locked by a condition, usually “a valid signature from this key”. No balance is written anywhere on the chain. Your wallet looks for the pieces it can unlock and adds them up: the figure on your screen is a sum computed by the app.
The account model keeps a table of accounts instead. Each entry has a stored balance, and a transaction subtracts from one entry and adds to another. An Ethereum node keeps that number as it is, ready to read.
Both record who owns what. The difference is what a transaction points at. A Bitcoin transaction names the earlier outputs it consumes. An Ethereum transaction names an account and a counter. Almost everything below follows from that.
How the UTXO model works in Bitcoin
An output is spent whole, and the change comes back
A Bitcoin transaction has inputs and outputs. Each input points to an output of an earlier transaction (its transaction ID and position) and supplies the proof, usually a signature, that unlocks it. Each output carries an amount and a locking script that says who can spend it next. Once created, an output waits until a later input consumes it, and then it is gone for good. The Bitcoin developer guide sets the rule plainly: the full value of the outputs you spend must go somewhere, either to new outputs or to the miner as a fee.
Satoshi Nakamoto described the usual shape in section 9 of the 2008 white paper: a transaction normally has “at most two outputs: one for the payment, and one returning the change, if any, back to the sender.”
Here is an example with round figures. Your wallet holds one output of 0.05 BTC on a native SegWit address, and you pay a merchant 0.03 BTC. The transaction spends the whole 0.05 BTC and creates two outputs: 0.03 BTC to the merchant and 0.01999718 BTC to a new address of your own wallet. The 282 satoshis that are missing are the fee, for a transaction of about 141 virtual bytes at 2 sat/vB. No output is labelled “fee”: the miner simply collects whatever the outputs leave unassigned.
That rule cuts both ways. A wallet adds the change output for you; anyone who builds a transaction by hand and forgets it hands the whole difference to the miner.
Why your Bitcoin wallet holds several “coins”
Every payment you receive creates a new output. Ten payments mean ten outputs, even if all of them went to the same address. Your balance is their total. Some wallets show the list under a “coins” or “UTXOs” tab, with a coin control option that lets you choose which outputs a payment will spend.
The change explains a puzzle that worries many users. Open one of your own payments in a block explorer and you will often see an address you do not recognise receiving part of the money. In most cases it is your change address, derived from the same seed as the rest of your wallet. The developer guide recommends sending change to a fresh address, and section 10 of the white paper already advised a new key pair for every transaction. Formats and the risks of reusing an address are covered in our guide to crypto addresses.
So before suspecting theft, check two things: that the amount matches what you expected back, and that your wallet lists that output among your coins.
Coin selection: which outputs does the wallet spend?
Say you pay 0.03 BTC from a wallet that holds twelve outputs of various sizes. The software has to pick, and the choice is called coin selection. Its goals pull in different directions. Fewer inputs make today’s transaction cheaper. A payment that needs no change output saves a few bytes and leaks less information. Spending small outputs while fees are low avoids paying more for them later.
The wallet code of Bitcoin Core lists the methods it can use: Branch and Bound, which searches for a set of inputs close enough to the amount to skip the change output; Knapsack; Single Random Draw; CoinGrinder, which looks for the lightest set of inputs; and manual selection by the user. Each candidate solution gets a computed “waste” score that weighs what the inputs cost at today’s fee rate against a long-term rate, plus the cost of any change or excess. Other wallets use their own rules, which is one reason two apps can charge different fees for the same payment from the same seed.
Dust, consolidation and why fees grow with inputs
Bitcoin fees are paid by size in virtual bytes, not by amount. Moving 1 BTC held in one output is cheaper than moving 0.01 BTC gathered from forty. Each input carries its reference to an earlier output and its signature data, and that is where most of a transaction’s weight sits. The approximate sizes for the three common address types:
| Address type | Input (approx. vB) | Output (approx. vB) |
|---|---|---|
| Legacy P2PKH (starts with 1) | 148 | 34 |
| Native SegWit P2WPKH (bc1q…) | 68 | 31 |
| Taproot P2TR, key path (bc1p…) | 57.5 | 43 |
The legacy and native SegWit output sizes, 34 and 31 bytes, are the ones Bitcoin Core’s own dust code uses, as is the 148-byte legacy input; for a native SegWit input the code rounds down to 67. The Taproot figures are approximate, worked out from the byte layout of a key-path spend, which carries a single 64-byte Schnorr signature. Add about 10.5 vB of fixed overhead per SegWit transaction. Real sizes vary by a byte or so with the signature.
The same arithmetic defines dust. In Bitcoin Core’s relay policy, a comment states the idea in one line: “If you’d pay more in fees than the value of the output to spend something, then we consider it dust.” At the default dust relay rate of 3 sat/vB, the code’s comments give 546 satoshis for a legacy output and 294 for native SegWit. Taproot is not listed: the same formula, applied to its 43-byte output, puts the limit at about 330 satoshis, because the developers kept the SegWit input size on purpose rather than lower the dust level. These are policy, not consensus rules: an output below the limit is valid in a block, but nodes on default settings will not relay a transaction that creates one.
Consolidation is the answer to a wallet full of small outputs: you send them all to one address of your own while fees are low. Take 50 native SegWit inputs and one output, about 3,440 vB in all. What that costs depends only on the fee rate (example, prices at 76,015 dollars per bitcoin per Blockchair, 7 November 2026, 09:55 UTC):
| Fee rate | Fee (satoshis) | Fee (dollars) |
|---|---|---|
| 1 sat/vB | about 3,440 | about 2.60 |
| 10 sat/vB | about 34,400 | about 26 |
| 50 sat/vB | about 172,000 | about 131 |
Those 50 inputs cost the same bytes whether you consolidate now or spend them inside a payment later. What you choose is the fee rate you pay them at. On 7 November 2026 at 09:53 UTC, the mempool.space fee API recommended 3 sat/vB for the next block and 1 sat/vB for confirmation within the hour, close to the floor, and Blockchair put the median fee of the previous 24 hours at 330 satoshis, about 25 cents.
Consolidation has two costs beyond the fee. It ties all those outputs together on the public record, which the privacy section below explains. And it is a job for your own wallet: no website, “UTXO unlock” tool or support agent ever needs your seed phrase to merge your coins.
The UTXO set every full node keeps
Each full node holds the list of every output not yet spent, known as the UTXO set (the chainstate folder in Bitcoin Core). Validating a new transaction mostly means checking it against that list: does each input point to an output that exists and has not been spent? If the answer is yes and the signatures hold, the spent outputs leave the set and the new ones join it.
The mempool.space UTXO Set Report counted about 173 million unspent outputs at block 892,385 (14 April 2025), needing about 11 GB on disk with default settings. That snapshot, published in May 2025, is still the most detailed public count of what the set contains; the set has kept changing since. For scale, Blockchair counted 4,006,954,560 outputs created since 2009 at block 974,916 on 7 November 2026: the great majority of everything ever created has already been spent.
The set matters because every node must store it and search it quickly. A tiny output that nobody will ever spend, because it is worth less than the fee to move it, stays in that list for good. Dust rules exist partly to keep it from swelling.
Because each input refers to one specific output and needs nothing else, inputs can be checked independently of each other, and the order of two unrelated payments does not matter. That makes validation easy to spread over several processor cores. It does not make Bitcoin a parallel computer in the sense Solana claims, as the Solana section shows.
What outputs reveal: the privacy heuristics
Section 10 of the white paper admits the main weakness: “Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner.” Chain analysts call it the common-input-ownership heuristic, and it is the first thing they apply.
The second is change detection: guessing which output went back to the sender. The Bitcoin wiki’s privacy page lists the usual clues. A round amount is probably the payment and the odd one the change. An output of the same script type as the inputs is probably change. If one input alone would have covered the smaller output, a wallet that still added a second one was probably paying the larger output. In a fee bump, the output that shrinks is the change. Address reuse makes all of it easier.
CoinJoin, where several people put their inputs into one transaction, exists to break the first heuristic. Coin control helps in a quieter way: keeping outputs from different sources apart stops one payment from linking them. Consolidation does the opposite and glues 50 histories into one.
The account model starts weaker. One Ethereum address gathers every payment it ever received and sent, and anyone who learns it can read the whole history and the balance in one page.
Cardano’s extended UTXO
Cardano kept outputs but gave them more to carry, a design it calls extended UTXO. According to the Cardano documentation, an output can hold almost arbitrary data next to its address and value, and it can be locked by a script instead of a single key. The spender supplies extra data called a redeemer for each input, and the script reads the output’s data, the redeemer and the whole transaction before answering yes or no.
Because a transaction lists exactly what it consumes and what it creates, the documentation says the fee of a valid transaction can be known precisely before it is posted. That differs from Ethereum, where the result depends on the state at the moment of execution and a transaction can fail after paying for the gas it used.
The price is concurrency. If two users build transactions that both expect the same output, for example the state of a shared application, only the first one in can succeed; the docs say a transaction fails when another one has already consumed an input it needed. Developers spread application state over many outputs to avoid the queue.
How the account model works in Ethereum
Four fields per account
The ethereum.org documentation describes two kinds of account. An externally owned account is controlled by whoever holds its private key and can start transactions. A contract account is a smart contract deployed on the network: it has code, no key, and acts only when a transaction reaches it. Both carry the same four fields:
| Field | What it holds |
|---|---|
| nonce | Number of transactions sent by an externally owned account, or of contracts created by a contract account |
| balance | Ether held, in wei (1 ETH = 1018 wei) |
| codeHash | Hash of the account’s code; for an externally owned account, the hash of an empty string. It cannot change |
| storageRoot | Root hash of a Merkle Patricia trie encoding the account’s storage; empty by default |
The line between the two kinds blurred with the Pectra upgrade, live on 7 May 2025. Its EIP-7702 lets an externally owned account point to contract code and behave like a smart contract wallet, according to ethereum.org’s Pectra page. The four fields stay the same. For the wider picture of the network, see our guide to Ethereum.
The nonce: one counter that orders everything
The nonce counts the transactions an account has sent, and each new transaction must carry exactly the next number: 0, then 1, then 2. In the words of ethereum.org, “Only one transaction with a given nonce can be executed for each account.” Once nonce 7 is used, a copy of the same signed transaction broadcast again is simply invalid. That is Ethereum’s protection against replay on its own chain.
A second layer covers other chains. EIP-155, titled “Simple replay attack protection”, was written by Vitalik Buterin in October 2016 and activated at block 2,675,000 in the Spurious Dragon upgrade. It lets the wallet include a chain ID in what the user signs (1 for Ethereum mainnet), so a transaction signed that way for one chain cannot be replayed on another chain that shares the format.
Bitcoin needs neither. An output can be spent once; after that it is no longer in the UTXO set, so a replayed transaction points to something that does not exist.
Why one stuck transaction blocks all the next ones
Say you send a transaction with nonce 41 and a fee that turns out too low. Then you send nonce 42, and 43. Nonce 41 waits. Nonces 42 and 43 cannot go into any block before 41 does, whatever fee they pay, because the counter has to move one step at a time.
Nodes keep the two cases apart. Transactions with the next nonce are executable (“pending”); those behind a gap are “queued”. The source code of Geth, still the most widely run Ethereum execution client, sets the defaults: a replacement must pay at least 10% more than the transaction it replaces, each account gets up to 64 queued slots, and queued transactions are dropped after 3 hours. Other clients use their own values.
The fix is to fill or replace the blocking nonce. To speed up, you send the same transaction again with nonce 41 and a higher fee. To cancel, you send 0 ETH to yourself with nonce 41 and a higher fee, so the number is used and the original becomes invalid. The “speed up” and “cancel” buttons of wallets do exactly this, and they only work while the original is still waiting. The steps are in our guide to how crypto transactions work.
Bitcoin has no such queue. Two payments that spend unrelated outputs do not wait for each other. Only a payment that spends the change of an unconfirmed one is chained to it.
Contract storage and the weight of state
Your tokens are not in your account. An ERC-20 balance is an entry in the storage of the token’s contract, filed under your address, while your own storageRoot stays empty. That is why token approvals exist: you authorise one contract to change entries held by another.
Everything written to state stays there until it is cleared: every account, every storage slot, every contract. EIP-8037, a proposal in Last Call status in November 2026 that raises the gas cost of creating state, states that as of January 2026 the database a Geth node dedicates to state was about 390 GiB. That is the current state alone, not the chain’s history. The proposal’s stated aim is to keep state growth near 120 GiB a year at a reference gas limit of 150 million.
The comparison with Bitcoin’s 11 GB is not like for like: Ethereum’s state holds code and contract data, and Bitcoin’s set holds only coins. It does show which way each design leans. A UTXO ledger stores little and asks transactions to bring their proofs; an account ledger keeps more in memory so that contracts can read it at any time.
Solana: accounts that every transaction must declare
Solana also uses accounts, built differently. On Solana everything is an account: wallets, programs and token balances. The Solana documentation gives each one five fields: lamports (the balance; 1 SOL is one billion lamports), data, owner, executable, and rent_epoch, now marked deprecated. An account can hold up to 10 MiB of data. Only the program that owns an account can change its data or take lamports from it.
Every account must keep a refundable minimum balance, long called the rent-exempt minimum. The formula is (account size + 128) bytes x 3,480 lamports per byte-year x 2 years. An account with no data needs 890,880 lamports. A standard token account, 165 bytes in the SPL Token program source, needs 2,039,280 lamports, about 0.00204 SOL. The money comes back when the account is closed, which is why wallets offer to close empty token accounts.
The bigger difference is in the transaction. Each instruction lists every account it will touch and flags each one as signer or not, writable or read-only. The documentation on instructions says what that buys: “The validator uses this metadata to determine which transactions can run in parallel. Transactions that write to different accounts can execute in parallel.”
The flip side follows from the same rule. Transactions that write to the same account have to run one after another, so a very popular account, such as a busy trading pool, becomes a queue of its own. In the Ethereum Virtual Machine, by contrast, the transactions of a block are defined to run one after another.
Solana does not use an account nonce against replay. A transaction carries a recent blockhash valid for 150 slots and is rejected after that; durable nonces exist for transactions signed offline. Its fee is a base of 5,000 lamports per signature, half of it burned, plus an optional priority fee, according to the fee documentation.
UTXO vs account model side by side
| UTXO (Bitcoin) | Accounts (Ethereum) | Accounts (Solana) | |
|---|---|---|---|
| Unit of state | Unspent output | Account: nonce, balance, code, storage | Account: lamports, data, owner, executable |
| Balance | Sum of outputs, computed by the wallet | Stored number | Stored number (lamports) |
| Spending part of it | No: spend whole outputs, change comes back | Yes: subtract | Yes: subtract |
| Replay protection | An output can be spent once | Nonce, plus chain ID (EIP-155) | Recent blockhash (150 slots) or durable nonce |
| Ordering | Unrelated outputs are independent | Strict nonce order per account | Conflicts only on shared writable accounts |
| What drives the fee | Size in vB: more inputs, higher fee | Gas used by the execution | 5,000 lamports per signature, plus priority fee |
| Parallel processing | Inputs checked independently | Transactions run in sequence | Declared accounts allow parallel execution |
| Default privacy | New address per payment, but heuristics | One address holds all history | One address holds all history |
| Programmability | Limited scripts (Cardano: extended UTXO) | Full smart contracts | Programs own data accounts |
| State burden (dated) | About 173 million outputs, about 11 GB (April 2025, mempool.space) | About 390 GiB in a Geth node (January 2026, EIP-8037) | Accounts backed by a refundable minimum balance |
Neither model wins. The UTXO side gives checks that stay local to each transaction and a plain answer to replay, at the cost of awkward smart contracts and fees that grow with every small receipt. The account side gives programs a shared memory they can read and change, at the cost of strict ordering and a state that keeps growing. Solana’s declared accounts and Cardano’s extended outputs are two attempts to take part of each.
What it changes for you in practice
A few habits come straight out of the two designs.
- If you receive many small Bitcoin payments, each one will cost an input’s worth of fee when you spend it. Consolidating when fees are near 1 sat/vB is cheaper than doing it during a fee spike, but it links those payments together on chain.
- An unknown address receiving part of your Bitcoin payment is normally your change. Check the amount and your wallet’s coin list.
- Coin control, where your wallet offers it, lets you keep coins from different sources apart and choose what each payment reveals.
- On Ethereum and other EVM chains, a pending transaction with too low a fee holds back every later one from the same account. Replace it with the same nonce and a higher fee, or cancel it, rather than sending more.
- Your Ethereum tokens are entries in token contracts. Approvals give other contracts the right to move them, so review the ones you no longer use.
- On Solana, every empty token account keeps about 0.002 SOL locked as its minimum balance; closing it returns the lamports.
- In every model, no legitimate tool needs your seed phrase to consolidate, unlock or speed up anything.
Lots and averages: tax rules that echo the two models
Tax authorities ask the question the UTXO model asks: which units did you sell? This is general information, not tax advice, and the units in question are units of an asset, not Bitcoin outputs: an output in your wallet is not a tax lot by itself.
For American taxpayers, basis has been tracked wallet by wallet, or account by account, for acquisitions and sales from 1 January 2025 under the final regulations, Treasury Regulation section 1.1012-1. IRS Revenue Procedure 2024-28 gave a safe harbor for moving to that system: taxpayers could allocate their unused basis “to digital assets held within each wallet or account of the taxpayer as of January 1, 2025”. Inside a wallet you can identify the specific units sold; otherwise the earliest units are treated as sold first (first in, first out). Units held at a broker can be identified by a standing order. Details are in our guide to crypto taxes in the United States and in how to calculate crypto capital gains.
France works the other way, like an account. Under article 150 VH bis of the French tax code, the gain on a sale is the sale price minus the total acquisition cost of the whole crypto-asset portfolio multiplied by the sale price and divided by the portfolio’s global value at the time of the sale. Which units left the wallet does not matter. Gains of 2026 are taxed at a flat 31.4% (12.8% income tax plus 18.6% social levies) unless the taxpayer opts for the progressive scale, and nothing is due when the year’s total sale prices stay at 305 euros or less, according to the tax administration’s guidance updated on 17 July 2026. Italy picks a rule of its own: the Agenzia delle Entrate’s circular 30/E of 27 October 2023 sets LIFO (last in, first out) for crypto-assets with the same name, and gains realised from 1 January 2026 are taxed at 33%.
| Country | Which units count as sold | Source |
|---|---|---|
| United States | Per wallet or account since 1 January 2025; specific identification, otherwise first in, first out | Treas. Reg. 1.1012-1; IRS Rev. Proc. 2024-28 |
| France | No units: one formula for the whole portfolio | Code général des impôts, art. 150 VH bis |
| Italy | Last in, first out, for crypto-assets with the same name | Agenzia delle Entrate, circular 30/E of 2023 |
The next lesson in this path takes the question every ledger exists to answer, whatever its model: how a network stops the same coin from being spent twice.
