UTXO vs account model: which ledger design, and why
Every blockchain answers one question first: is money a set of discrete coins, or a number in an account? The answer shapes privacy, parallelism, and smart contracts. QBC chose UTXO, and this page explains both models and the reason.
UTXO vs account model, defined
In the UTXO model, the ledger is a set of unspent transaction outputs: discrete coins, each with a value and a spending condition. A wallet balance is not stored anywhere; it is computed as the sum of the unspent outputs your keys control. A transaction consumes whole outputs as inputs and creates new outputs, sending change back to yourself. Bitcoin defined this model in the original whitepaper. In the account model, the ledger is a mapping from addresses to balances: a transaction subtracts from one account and adds to another, and a per-account nonce orders transactions and blocks replays. Ethereum is the canonical example, documented in the ethereum.org accounts guide. Neither model is simply better; they optimise for different things, and QBC is a UTXO chain for reasons this page makes concrete. The choice is foundational rather than cosmetic: it fixes how wallets are built, how transactions parallelize, what privacy retrofits cost, and what an auditor can verify cheaply, which is why it belongs at the start of any chain design review.
How the UTXO model works
Think of UTXOs as banknotes of arbitrary denomination. If you hold a 10 QBC output and want to pay 3, your transaction consumes the whole 10, creates a 3 QBC output locked to the recipient, and a 7 QBC change output locked back to you (minus fee). Validation is local and crisp: check each input exists in the current unspent set, check its spending condition is satisfied, on QBC a Dilithium5 signature as covered on the signatures page, and check that input value covers output value plus fee. Double-spending reduces to a set-membership question: an output is either unspent or it is not, and once consumed it leaves the set forever. There is no account state to reconcile and no nonce ordering to enforce; each transaction carries its own context. That self-containment is what later makes confidential outputs and shielded sets bolt on cleanly.
A worked example: one payment, output by output
Trace a payment to make the model concrete. You hold two outputs, 8 QBC and 5 QBC. To pay 10, your wallet selects both, consumes them whole, and creates two new outputs: 10 QBC locked to the recipient and about 3 QBC of change locked to a fresh key of yours, minus fee. Validators check that both inputs are in the unspent set, verify the Dilithium5 signatures, and confirm inputs cover outputs plus fee; the block lands on the 3.3 second cadence and is irreversible under deterministic GRANDPA finality moments later. The private variant runs the same economics through commitments: shield the 13 into the hidden set, transfer 10 with the amount concealed by a STARK, unshield when needed, the exact flow shown step by step in the shield, transfer, unshield writeup and in the quantum-secure wallets post. Coin selection and change handling are the UX tax of the model, absorbed by wallet software; fresh one-time change keys are its privacy dividend, since no address accumulates a visible running history, the leak that account chains cannot structurally avoid.
How the account model works
The account model keeps a global state: every address maps to a balance, a nonce, and, for contract accounts, code and storage. A transfer is a state transition, debit here, credit there, and the nonce prevents the same signed transaction from executing twice. The strengths are real. Balances are direct state reads, wallets are simple, and, most importantly, shared mutable state is exactly what general smart contracts want: a DEX pool or lending market is naturally one account many parties touch. The costs are the mirror image. Transactions against the same account serialize on the nonce, state grows without the natural pruning that spent outputs give (a spent UTXO can be forgotten; an account lingers at zero), and every payment publicly updates a long-lived balance, so an observer watching an address sees its running total change with each transaction, a graph-analysis gift that the privacy-focused chains surveyed elsewhere mostly avoid by not using accounts.
Privacy: why commitments fit UTXOs naturally
Here is the argument that decided QBC's design. Confidential transactions replace each amount with a commitment, and in a UTXO ledger the mapping is one-to-one: one output becomes one commitment with one range proof, and the balance rule, inputs equal outputs plus fee, becomes one relation over commitments, exactly the construction on the confidential transactions page. Stealth-style one-time output keys kill address reuse because every output is fresh by construction; there is no persistent account identifier to link activity around. This is why essentially every strong privacy design, Grin and Mimblewimble, Monero, Zcash's note-based pools, is built on outputs or notes rather than accounts: hiding updates to a persistent balance is far harder than hiding the contents of discrete, single-use envelopes. On QBC the result is post-quantum private transactions as an opt-in layer over the same output set. The account model can host confidential transfers, but only by rebuilding note-like objects inside contracts, paying execution overhead and losing protocol-level enforcement, which is engineering against the grain of the state model.
Parallelism, state growth, and smart contracts
The remaining tradeoffs, fairly. Parallelism: UTXO transactions touching disjoint outputs validate in parallel trivially, since each declares exactly the state it consumes; account transactions must be ordered against shared balances and nonces. State: the UTXO set stays bounded by economic activity because spent outputs are prunable, while account state accretes. Smart contracts: the account model wins for shared-state applications, which is why Ethereum chose it; expressing a many-party contract in pure UTXO terms is awkward. Fees and UX: account chains meter execution with gas naturally, and UTXO wallets must manage coin selection and change, real complexity that wallet software absorbs. An honest scorecard, not a shutout: the account model is the right call for a general-purpose contract platform, and the UTXO model is the right call when payments, privacy, and parallel verification lead the requirements list. None of these tradeoffs is hypothetical; each shows up directly in wallet code, node performance, and audit cost, which is why the ranking of your own requirements, not fashion, should pick the model.
Auditing a UTXO ledger: supply you can prove
The strongest audit property of the UTXO model is that total supply is a checkable sum: walk the unspent set, add the values, done, with no need to replay every account ever touched. Anyone can run that check on QBC from a fresh machine: warp sync brings a node to the finalised head in minutes, documented in the warp sync writeup, and hash-based BEEFY MMR commitments give even light clients verifiable finality proofs, shipped per the finality proofs post. The confidential set complicates the sum deliberately: shielded values are hidden, so the auditable statement becomes the net flow across the shield and unshield boundary plus STARK-enforced conservation inside, exactly the statement specified in the pq-confidential STARK paper. That is also where the quantum argument bites hardest: a classical commitment scheme would let a future adversary silently violate the very conservation the auditor relies on, the scenario walked through on the quantum threat page. The same verify-everything posture extends beyond payments into the chain's AI audit trail.
Why QBC is a UTXO chain
QBC's requirements ranked privacy and post-quantum soundness first, and the UTXO model serves both. Balances are the sum of unspent outputs; privacy is opt-in, public transactions by default with confidential transfers by choice; and the shield, transfer, unshield flow moves value between the transparent output set and the shielded commitment set with opening proofs on each side, guarded by a spent-commitments set that is itself just UTXO discipline applied to commitments. The transparent side authorizes spends with Dilithium5 signatures, part of the end-to-end post-quantum architecture. Facts, at honest scale: blocks every 3.3 seconds, chain id 3303, Substrate-based, four validators live today. The claim is not that UTXO is universally superior; it is that for a chain whose defining features are private, quantum-sound payments, discrete outputs were the only design that did not fight the cryptography. The result is a base layer where nothing needs to be believed on reputation: the outputs, the proofs, and the finality trail are all checkable by anyone who syncs a node and looks.
| Conventional approach | QuantumAI Blockchain | |
|---|---|---|
| Ownership record | Set of discrete unspent outputs | Address to balance mapping |
| Balance | Computed: sum of your unspent outputs | Stored directly in state |
| Replay defense | Outputs are consumed once, set membership | Per-account nonce ordering |
| Privacy fit | Natural: one output, one commitment, one-time keys | Hard: persistent balances leak deltas |
| Parallel validation | Trivial for disjoint outputs | Serializes on shared accounts and nonces |
| Smart contracts | Awkward for shared state | Natural home for shared-state apps |
Frequently asked questions
What is a UTXO?
An unspent transaction output: a discrete coin with a value and a spending condition. Your balance is the sum of the UTXOs your keys control, computed rather than stored.
What is the main difference between UTXO and account models?
UTXO ledgers track discrete spendable outputs that are consumed whole and replaced; account ledgers store balances per address and mutate them. Bitcoin uses UTXO, Ethereum uses accounts.
Which model is better for privacy?
UTXO. Commitments map one-to-one onto outputs and one-time keys prevent address linkage, which is why Grin, Monero, and note-based Zcash pools all build on outputs, not accounts.
Which model is better for smart contracts?
Accounts. Shared mutable state is what DEXes and lending markets need, and the account model represents it directly. Expressing many-party contracts in pure UTXO form is awkward.
How does the UTXO model stop double-spending?
By set membership: an output exists in the unspent set until consumed, then leaves it forever. Every validator rejects a transaction whose input is no longer in the set.
Why did QBC choose the UTXO model?
Because its defining features are opt-in confidential transfers and post-quantum soundness. Discrete outputs map one-to-one onto hash-based commitments, and shield and unshield flows are just output-set discipline extended to commitments.
Can you audit total supply on a UTXO chain?
Yes: sum the unspent set. On QBC the transparent supply is directly summable, and the shielded set's conservation is enforced by STARK proofs on every transfer plus opening proofs at the shield and unshield boundary.
Verify it yourself.
QBC is live. Explore the network, read the on-chain proofs, and see a decentralised AI being trained and finalised in real time.
Enter qbc.network →