CrowdSent Blog Team · 24 October 2026 · Blockchain literacy
UTXO vs account model compares two ways a blockchain represents spendable value and updates its records. In a UTXO model, transactions consume specific unspent outputs and create new outputs. In an account model, transactions update account balances and other state.
A wallet can display one balance under either model. The similar display hides different underlying bookkeeping. The UTXO vs account model distinction explains Bitcoin change outputs, Ethereum account nonces and why adding every transaction output can overstate the amount paid to someone else.
Bitcoin and Ethereum are the main examples below. Their wider purposes are covered in the Bitcoin introduction and Ethereum introduction. Here the focus is the ledger model, with invented arithmetic rather than price comparisons or instructions to send funds.
UTXO vs account model starts with the record being changed
UTXO means unspent transaction output. A Bitcoin output specifies a quantity and conditions for spending it. An ordinary later transaction refers to that specific output as an input. Once consumed in the accepted history, it cannot be consumed again as a second independent spend.
The Bitcoin transaction guide explains how inputs spend earlier outputs. An input identifies an output using the earlier transaction identifier and its output index. The identifier plus index matters because one transaction can create several separate outputs.
An account-based ledger instead keeps state associated with accounts. On Ethereum, the native ETH balance is one part of that state. An ordinary transfer changes the sender and recipient balances under the protocol’s rules rather than selecting a collection of ETH outputs to consume.
Ethereum’s accounts documentation describes fields including balance and nonce. Contracts also have code and storage-related state. These descriptions concern how records are represented; they do not determine who owns an address or whether a displayed wallet has signing authority.
Follow a Bitcoin payment and its change
Suppose a fictional wallet tracks three spendable Bitcoin outputs: A contains 70,000 satoshis, B contains 45,000 and C contains 30,000. The displayed total is 145,000 satoshis. Each letter is a placeholder for a particular output, not a real address or transaction identifier.
The wallet prepares an illustrative payment of 90,000 satoshis and selects A and B as inputs. Their combined value is 115,000. Assume an invented fee of 1,000 satoshis. The transaction can create a 90,000-satoshi recipient output and a 24,000-satoshi change output controlled by the sender.
The accounting is 70,000 + 45,000 = 90,000 + 24,000 + 1,000. Both selected outputs are consumed completely. The 24,000 is a new output, not an unspent fragment left inside A or B. C remains unspent and unaffected by this transaction.
After the transaction, the sender’s remaining quantity is 30,000 + 24,000 = 54,000 satoshis. It is not merely the 24,000 change amount, because the untouched output still belongs in the wallet’s coverage. The total reduction is 91,000: the recipient’s 90,000 plus the 1,000 fee.
This example also explains why “output value” can differ from “payment value.” Summing the recipient and change outputs produces 114,000. Calling that the amount paid to another person would misclassify the sender’s change. Real ownership attribution requires evidence; the example supplies it explicitly.
Change is an explicit output, not an automatic refund
A Bitcoin transaction spends the entire value of each chosen input. Value that is not assigned to outputs becomes the transaction fee. Wallet software constructs a change output when appropriate; the network does not inspect the user’s intention and add a forgotten change destination.
The Bitcoin transaction reference documents inputs, outpoints and output values. The ordinary input-output accounting has a special exception for the coinbase transaction that creates the block subsidy and claims fees. That exception is outside the payment exercise.
Return to the invented inputs totaling 115,000. If a hypothetical transaction contained only the 90,000 recipient output, the residual would be 25,000 rather than the intended 1,000. This is an explanation of transaction arithmetic, not a suggestion to construct or broadcast such a transaction.
Coin selection is the wallet’s choice of which available outputs to spend. Different selections change the transaction’s structure and may change its size and future change outputs. A balance of 145,000 satoshis does not tell you how many inputs the wallet must use for a particular payment.
The cash-note analogy can help: a payment may require consuming a larger denomination and receiving change. Its limit is that blockchain outputs are programmable records, not physical notes, and the change must be included in the transaction’s construction.
Follow an account-based native-asset transfer
For a separate Ethereum example, assume an ordinary sender has 1.45 ETH and sends 0.90 ETH. Set an invented actual execution fee of 0.01 ETH, with no other balance changes. The resulting sender balance is 1.45 − 0.90 − 0.01 = 0.54 ETH.
The remaining 0.54 ETH stays in the account’s updated balance. There is no Bitcoin-style selection of particular ETH outputs and no change output needed to represent the remainder. The examples compare bookkeeping shapes, not equivalent monetary values of BTC and ETH.
Suppose the sender’s next transaction nonce is seven. The ordinary transaction uses nonce seven, and after it is processed the account’s counter advances to eight. The nonce helps sequence transactions from that account and prevents the same signed instruction from simply being executed again as a new payment.
Ethereum’s transaction documentation describes transaction fields and state changes. Contract-wallet and account-delegation arrangements can add other authorization logic; they do not turn the native ETH ledger into Bitcoin’s UTXO model.
The example uses an actual-fee assumption to keep the balance reconciliation simple. A fee cap is a different number. For that distinction, use the Ethereum gas-fee guide rather than subtracting a maximum budget as if it were always the final charge.
A token balance adds another layer of state
An Ethereum account’s native balance records ETH. A standard ERC-20 token usually keeps its ownership balances in the token contract’s storage. The same address can therefore have an ETH balance and separate balances recorded by many token contracts.
OpenZeppelin’s ERC-20 guide describes a token implementation and its balance representation. Reading “account model” as one universal balance for every asset would miss this distinction.
Imagine the sender from the previous example also holds 200 Example Tokens. A transfer of 30 Example Tokens can leave 170 in that token’s ledger, while a separate ETH execution charge changes the native balance. Adding “0.54 ETH + 170 tokens” as 170.54 units would combine incompatible quantities.
For receipt fields and token-specific effects, use the blockchain explorer guide. This comparison concerns the underlying records, not a complete explorer-reading workflow.
Different dependency patterns do not create a universal winner
In a UTXO model, two attempted spends of the same output conflict. Transactions consuming separate outputs can have independent input dependencies, although scripts and surrounding protocol rules still matter. A later transaction may also depend on an output created by an earlier transaction.
In an account model, ordering can affect balances and shared contract state. Two transactions from one ordinary Ethereum account have nonce dependencies. Transactions involving a shared application can interact through its storage even when their senders differ. The EVM documentation explains transaction-driven state transitions.
Neither description establishes a universal claim about throughput, privacy or security. Performance depends on the implementation, workload, validation rules and resources. Privacy depends on what is revealed and how activity is linked. A transaction-model label alone is too broad for those conclusions.
UTXO also does not mean “no smart contracts.” Cardano’s Plutus documentation describes an extended UTXO model with additional data and validation logic. This is a useful boundary on simplistic comparisons, without implying identical programmability across all UTXO networks.
UTXO vs account model: what to record for each transaction
For a UTXO explanation, preserve the selected output references, input amounts, new output amounts, relevant spending conditions and fee. Identify which outputs remain untouched. If recipient and change labels come from a heuristic rather than verified context, say so.
For an account-based explanation, preserve the network, account, before-and-after state, transaction nonce where relevant, native transfer value, actual fee and token-specific changes. Use matching block boundaries so intervening activity does not contaminate the comparison.
The Bitcoin Core gettxout reference illustrates that an unspent-output query depends on an output identifier and can include mempool state. An output’s absence from one such query is not, by itself, a complete narrative of who spent it or why.
The strongest short explanation reports the change the ledger establishes. In the Bitcoin example, two outputs were consumed, two were created and one was untouched. In the Ethereum example, the sender’s native balance and nonce changed. Economic purpose and personal identity are additional questions.
Explore CrowdSent’s current service and membership information for research context. A platform summary does not replace protocol documentation or establish ownership of an address.
UTXO vs account model: frequently asked questions
1. Does UTXO stand for an entire unspent transaction?
No. It means an unspent transaction output. A transaction can create multiple outputs, and some may be spent while others remain unspent. The transaction identifier and output index identify the particular record being discussed.
2. Can one Bitcoin address correspond to several UTXOs?
Yes. Multiple outputs can use the same receiving conditions or address representation. A wallet’s displayed balance may sum several of them. Counting addresses and counting unspent outputs therefore measure different things.
3. Is the sender’s remaining balance always the change output?
No. Other outputs may remain untouched. In the worked example, the sender retains 24,000 satoshis of change plus an unused 30,000-satoshi output, totaling 54,000. The transaction’s change is only one component of the remaining wallet quantity.
4. Does Bitcoin create change if the wallet forgets it?
No automatic change record is added by consensus. An ordinary transaction’s input value minus output value is its fee. The transaction must explicitly contain the intended output amounts and conditions before it is authorized and submitted.
5. Does Ethereum use UTXOs for native ETH?
Its native ledger uses account state, including balances. An ordinary transfer updates those records without selecting prior ETH outputs. An application can implement its own accounting structures, but that does not change the base ledger model.
6. Is an account nonce the same as a mining nonce?
No. An ordinary Ethereum account nonce is a transaction counter involved in sequencing and replay protection. A proof-of-work mining nonce is used in searching for a valid block hash. Their shared name does not make their functions interchangeable.
7. Does a failed Ethereum call leave every field unchanged?
A reverted execution can still consume gas and advance the sender’s transaction nonce when included. The intended contract changes may be rolled back while those transaction-level effects remain. Distinguish execution outcome from fee and sequencing records.
8. Does UTXO automatically mean proof of work?
No. A transaction model describes ledger representation; a consensus mechanism describes agreement on history. They are separate design choices. Identify both before attributing a network’s behavior to either one.
9. Are UTXO networks always more private?
The label alone does not establish that. Visible input-output relationships, address reuse and external attribution can reveal patterns. Account-based systems have their own visibility characteristics. Any privacy comparison needs a specific protocol, usage pattern and threat model.
10. Why should a researcher care about the model?
It determines what a transaction amount and remaining balance actually represent. Understanding it prevents change from being mistaken for a payment, a token balance from being confused with native currency, and ledger records from being overinterpreted as evidence of people or intentions.
Primary documentation checked 24 October 2026. Examples are hypothetical and explain mechanisms rather than current market conditions. This article is educational and does not provide investment recommendations.