Accounts vs UTXO: Two Models of Spending

A blockchain can be viewed as a shared history of state changes that everyone agrees on. Each new block adds another set of changes to that shared record. In earlier lessons, ownership meant the ability to authorize changes to this shared state, not holding coins in a file on a device. A transaction was a signed proposal to update who controls some value, and transactions from the same sender needed to be applied in a clear order so the history stayed consistent.

A spending model is the rule system a blockchain uses to represent who controls value and how that representation is updated over time. It defines what “can be spent right now” means for the network. In this sense, a balance is not a single object stored on-chain, but a viewpoint on the current state. In an account-based model, each address has one evolving state, which includes its current balance. In a UTXO-based model, value is represented as many individual spendable outputs, each of which can be used once and then replaced by new outputs.

In an account-based model, each address has a single current state that the chain tracks, including its balance and possibly a few other simple fields. At any moment, there is exactly one latest version of that account state. A transaction in this model is a proposal to decrease the balance of one account and increase the balance of another. When the network is ready to include the transaction, it looks up the sender’s current account state, checks that the balance is high enough, and then applies the change. Transactions are applied in order, so each new one uses the most recent account state as its starting point.

In a UTXO model, value is tracked as many separate units called unspent transaction outputs, or UTXOs. Each UTXO is an individual piece of value that can be spent exactly once. A transaction in this model works by selecting one or more existing unspent outputs as its inputs. It then creates new outputs that belong to the recipients, and often one new output that returns any leftover value back to the sender. Once an output has been used as an input to a transaction, it is marked as spent and cannot be used again; only the new outputs created by that transaction remain available for future spending.

When the network finally processes a transaction, it must decide whether that transaction still fits the current state. In an account-based model, this means checking the sender’s latest account state at that moment and confirming that the balance is still high enough. In a UTXO model, the check is different: the system looks at the specific outputs the transaction wants to use and asks whether they are still unspent. Because state can change between the time a transaction is signed and the time it is included, a transaction that once looked valid can later fail or need to wait, and this behavior follows directly from the spending model being used.

Neither the account-based model nor the UTXO model is more correct or more real; they are two different ways to describe the same idea of controlling and moving value. Each one supports a slightly different way of thinking about what is being spent. Account-based models feel similar to a changing bank balance for each address, where one number goes up and down over time. UTXO models feel more like holding a collection of separate spendable pieces that can be combined and broken apart. Protocol designers choose a model that fits the overall behavior and features they want their system to have.

Across both models, a “balance” is simply a summary of the current state, not a separate object that lives somewhere on-chain. The spending model decides how that state is represented. In both account-based and UTXO-based systems, transactions are signed authorizations to change who controls value. The differences people see in transaction behavior come from what each model tracks and checks at the moment a transaction is applied.

Understanding accounts vs UTXO explains why different wallets and blockchains build transactions in different ways. Each one has to follow its own rules about what counts as spendable at any moment. Future articles in this track will show how mempools keep track of what can be spent right now under each model, and why some transactions wait, fail, or are replaced before they ever reach a block.