Two ways to hold money

Ethereum tracks one running balance per account. Kaspa wallets hold several separate coins instead of one number. Spend below and watch what actually changes in each.

Account model (Ethereum-style)

One number. A payment lowers it.

1,240
KAS, as a single balance
UTXO model (Kaspa)

Separate coins. A payment spends whole coins and returns change.

4 coins, 1,240 KAS total

Both sides hold 1,240 KAS. The account is one number. The wallet is four coins: 500, 300, 250, and 190 KAS. Nothing has been sent yet.

Now two spenders move at the same instant

Choose which situation to put them in. Each choice tests a different kind of collision, before you run it.

Choose a test above
A
Spender A
B
Spender B

Pick a test above to run it.

Why this suits Kaspa's block rate, and the cost it doesn't dodge

Why UTXO parallelizes and an account model doesn't

A payment from an account has to read the current balance, subtract, and write the new balance back, in that order, for that one account. A second payment from the same account has to wait for the first to finish, or the two writes race and the balance goes wrong. That serialization is a property of the model, not a performance bug: any two spends touching the same shared number must be ordered somehow.

A UTXO carries no such shared number. Two coins that belong to two different people are two unrelated pieces of state. Spending one has nothing to say about spending the other, so a network validating many blocks in parallel can accept both without coordinating between them. That is why a coin-based ledger scales more naturally with block rate: the thing that would need locking in an account model, one shared balance, doesn't exist. Kaspa's blockDAG accepts many blocks in parallel and orders them with GHOSTDAG; a payment system built on independent coins is the shape that fits a high block rate without inventing a way to lock individual accounts.

The one case where UTXO can't parallelize is the same coin spent twice. That's a real, unavoidable conflict, not a queue: exactly one of the two spends is accepted, and the other is rejected outright. Kaspa resolves this with a fixed rule: the first spend of a coin to appear in the ordered history wins, and any later conflicting spend is rejected. Every node runs the same rule over the same DAG and lands on the same answer with no voting round.

The honest cost: general-purpose contracts

The account model's shared, mutable, globally readable balance is genuinely the easier shape for arbitrary contracts. One contract can hold state, and any other contract can call into it, read that state, and change it, all in the same transaction, because there is one address with one storage slot others can point at. That's what makes something like Ethereum's account-based virtual machine a comfortable home for composable, general-purpose logic. This is a real advantage of the account model, not a strawman.

UTXO has no equivalent shared slot. State lives fragmented across individual coins, and a script only gets to inspect the transaction spending it, not reach out and call arbitrary other coins the way one contract calls another. Writing a general, freely composable smart-contract platform directly on top of that is genuinely harder, and Kaspa doesn't pretend otherwise.

That's the reason Kaspa's own contract story runs through covenants, not a general account-based virtual machine. A covenant is a rule attached to a coin about how it, and what it produces, are allowed to be spent, checked by script-level introspection of the spending transaction itself. Post-Toccata mainnet Kaspa has covenants, covenant IDs, and ZK proof checks enforced at the script level. There is no account-based VM underneath any of it.

Source
rusty-kaspa, consensus/core/src/tx.rs
Establishes
A transaction input names a previous output's outpoint (a whole prior output, consumed entirely); a transaction output carries a value and an optional covenant binding. That's the mechanical basis for "whole coin in, change coin out."
Does not establish
Wallet UX, fee mechanics, or how any specific wallet chooses which coins to spend.
Source
KIP-17, Covenants and Improved Scripting Capabilities and KIP-20, Covenant IDs, both listed Active on this site's KIP tracker
Establishes
Covenants work by script-level introspection opcodes that read fields of the spending transaction (amounts, script public keys, input/output counts) and constrain how a coin can be spent. This is the mechanism, not a general callable virtual machine.
Does not establish
Broad wallet support for constructing covenant transactions, or that native DeFi or vProgs-level app throughput are live today; this site's developments tracker keeps those separately labeled.