The most obvious difference between the UTXO and account models appears the moment you open your wallet and check your balance. The "balance" shown in a Bitcoin wallet is not a single number stored somewhere on the chain. Instead, the wallet adds up all the unspent transaction outputs (UTXOs) that belong to you and displays that total. An Ethereum wallet shows a balance that is directly read from a field called balance in the on-chain account state. The issues of change and concurrency both grow out of this fundamental difference.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
Balance: Summed Up or Stored
In the UTXO model, there is no on-chain entity called "account balance." When you receive Bitcoin, the chain creates an output pointing to your address, and the amount is the value of that transfer. When you receive more Bitcoin, another independent output is created. What your wallet does is scan all outputs on the chain, find those that "belong to your address and have not been spent by any transaction," and add them up for display. So your "balance" is a view calculated by your wallet. The chain does not store a total in something called "your account."
The account model works the other way. Each externally owned account on Ethereum has four fields: nonce, balance, storageRoot, and codeHash. When you send a transaction, the system directly subtracts from your balance and adds to the recipient's balance. The balance is a maintained state, not a derived sum. This design feels closer to a bank account for users and is easier to connect with existing financial accounting logic.
Change: Everyday in UTXO, Nonexistent in the Account Model
Change in the UTXO model is not something the system handles automatically. It is an output that must be explicitly created when building a transaction. Suppose you have a 1 BTC UTXO and need to pay a merchant 0.1 BTC. The transaction will consume the 1 BTC input and create two outputs: one 0.1 BTC output to the merchant and another 0.9 BTC change output back to your own address, usually a new one. The difference between total input and total output is the miner fee. If you forget to create the change output, that 0.9 BTC becomes the fee entirely. The system will not save you from this.
The account model has no concept of change. When you send 0.1 ETH from an account with a balance of 1 ETH, the contract or protocol directly deducts 0.1, and the balance becomes 0.9. There is no step of "spending the whole account first and then returning the rest." This is why many users coming from Ethereum to Bitcoin feel uncomfortable the first time they build a transaction manually. You have to choose inputs yourself, calculate change yourself, and decide on a change address yourself.
Choosing a change address also has a privacy consideration. If you always use the same address to receive change, on-chain analysis can easily link your transactions together. Using a new address for change is a common practice in Bitcoin wallets to break the address link between inputs and change. The account model does not have this problem because all your activity is already tied to the same address. Privacy there relies on mixers or privacy protocols, not address rotation.
Concurrency: UTXO Independence and Account Model Nonce Lock
The concurrency advantage of UTXO comes from its "fragment" nature. Each transaction consumes specific, referenced outputs. As long as two transactions do not try to spend the same UTXO, they can be validated independently without waiting for each other. Miners or validators can check in parallel whether inputs exist, signatures are valid, and amounts are sufficient, because each input's state is self-contained.
The concurrency difficulty of the account model comes from shared state. Ethereum uses nonce to manage this. Every externally owned account has a transaction counter. Each transaction sent from that account must carry the current nonce value, and after execution the nonce increases by one. This means transactions from the same account are naturally serial. You cannot send two transactions with the same nonce at the same time because they will conflict. If you first send a low-gas transaction that gets stuck in the mempool, later transactions with higher nonces also cannot be confirmed until the stuck transaction is processed or replaced. This design prevents replay attacks, but it also creates a queueing effect for high-frequency operations from the same account.
However, the concurrency limit of the account model only applies to the same account. Transactions between different accounts can run in parallel because their nonce and balance are independent. The concurrency advantage of UTXO appears in multiple independent outputs within the same user or the same batch of transactions. The bottlenecks of the two models are not on the same dimension, so simply saying "UTXO is more concurrent than the account model" is not accurate.
An Easily Overlooked Cost: Fees and Fragmentation
Fees in the UTXO model depend not only on amount but also on data size. Every input needs a signature. More inputs mean a larger transaction and higher fees. If you have many small UTXOs, such as dust accumulated from frequent small transfers, and you want to send a large amount, your wallet needs to include all those small UTXOs as inputs. The transaction size balloons, and the fee may be far higher than you expected. This is the fragmentation problem.
Fees in the account model are usually calculated by computational complexity, or gas, and have nothing to do with how many historical incoming payments your account has. Your balance is just a number. Whether you send a lot or a little, the base cost will not differ by orders of magnitude. From a user experience perspective, the account model is more predictable on this point.
Practical Takeaways
If you are building a wallet or on-chain tool that handles Bitcoin, you must treat UTXO selection, change construction, and fee calculation as core logic. "Balance" in your system should be a derived value, not a stored value. Every time you need to display or judge available funds, you should recalculate from the current UTXO set, or maintain a reliable local UTXO cache and handle chain reorganizations.
If you are developing on Ethereum or an EVM chain, the account model saves you from the trouble of change and input selection, but you need to take nonce management seriously. Batch transactions, replacing stuck transactions, and concurrent sending all need to be designed around the monotonic increase of nonce. Do not assume that two transactions can be sent "at the same time" from the same account and both be accepted.
If you are just a regular user, the practical meaning of understanding this difference is this: the fee fluctuation you see when sending Bitcoin often has little to do with how much money you received and much more to do with how many payments you received and how large each one was. Regularly consolidating small UTXOs can reduce future transaction costs, but consolidation itself also costs fees, so the timing requires your own judgment. Ethereum users do not need to worry about these things, but if a nonce error occurs, a transaction can get stuck, and you need to know how to replace it by sending another transaction with the same nonce and a higher gas price.
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！
References
- Gate.com·What is an Unspent Transaction Output (UTXO) | Bitcoin UTXO Model Explained, page published or updated: 2026-01-06; verified: 2026-10-21.
- Gate.com·UTXO: A Comprehensive Look at Unspent Transaction Output, page published or updated: 2026-01-30; verified: 2026-10-21.
- Ethereum.org·Accounts on Ethereum, page published or updated: no update date listed; verified: 2026-10-21.
- arXiv·Blockchain in a nutshell - The account-based model, page published or updated: no update date listed; verified: 2026-10-21.
