The previous page described the parts of a transaction. This page covers the accounting model, and why Kaspa tracks coins the way Bitcoin does rather than the way Ethereum does.
Two accounting models
Cryptocurrencies track ownership one of two ways:
- Account model (Ethereum and most smart contract chains): a global ledger of balances. A transaction mutates balances in place.
- UTXO model (Bitcoin, Kaspa): no balances stored anywhere. The ledger is a set of unspent transaction outputs - discrete coins, each locked to a script. A balance is the sum of the UTXOs an address can spend.
Kaspa uses UTXO accounting, inherited from Bitcoin.
How it works
- Every transaction consumes existing UTXOs as inputs and creates new UTXOs as outputs.
- An input spends a UTXO entirely - there is no partial spend. Paying 0.2 KAS from a 10 KAS UTXO means creating two outputs: 0.2 to the recipient and ~9.8 back to a change address.
- The fee is implicit:
sum(inputs) - sum(outputs). - A UTXO is spendable by whoever can satisfy its locking script - usually a signature matching the address, or a pay-to-script-hash redeem script.
- Validation is local: whether a UTXO is spendable depends only on the current UTXO set, not on the history that produced it.
Paying 0.2 KAS out of a single 10 KAS coin, in full:
The fee is 10 − 0.2 − 9.7997 = 0.0003 KAS. No field states it - it is the difference between the two sides, and it goes to the miner.
No balance was decremented. A coin was destroyed and two were created; the sender’s balance is the sum of the coins they can still spend.
Why UTXO fits a blockDAG
Kaspa’s parallel blocks make UTXO accounting a structural fit:
- Conflicts are explicit. A double spend is two transactions consuming the same outpoint (transaction ID + output index). Once GHOSTDAG orders the blocks, the first spend is accepted and the second is rejected - there is no intermediate account state to reconcile.
- Duplicates are harmless. Parallel blocks routinely include the same transaction. Under UTXO accounting it can only apply once (its inputs are gone after the first application); it is accepted once and counted as one unique transaction.
- Independent transactions commute. Transactions spending disjoint UTXOs can be applied in any order with the same result, so merging blocks from across the DAG is mostly conflict-free.
An account model would face all three problems at once during every merge.
The UTXO set as durable state
The UTXO set is what a node actually keeps. Old block data is pruned after ~30 hours; the UTXO set persists as the complete spendable state of the network. Blocks propagate updates; the UTXO set is the ledger. The set’s live size and churn are charted at UTXO count, UTXOs created, and UTXOs spent.
Wallet balance displays follow directly from this: a wallet scans or subscribes to UTXOs for its addresses (requires a node with --utxoindex), and the balance is a sum over them.
Beyond simple payments, locking scripts extend to pay-to-script-hash and - since the Toccata hard fork - covenants.
See Also: Transaction Model