The UTXO model
If you are coming from Ethereum, this is the adjustment that matters most. Kaspa has no account balances. There is no field anywhere that says how much KAS an address holds.
What exists is a set of unspent transaction outputs — UTXOs. Each one is a discrete chunk of value with a locking condition saying what it takes to spend it. A balance is not stored; it is computed by adding up the UTXOs you can unlock.
What a transaction actually is
A transaction consumes some UTXOs entirely and creates new ones. There is no partial spend: if you hold a 100 KAS output and want to send 30, you consume the whole 100 and create two outputs — 30 to the recipient and 70 back to yourself as change, minus the fee.
This has consequences you will meet immediately:
- Change is your job. Forget the change output and the difference is collected as fee. This is a real and expensive mistake.
- Coin selection is a real algorithm. Which UTXOs to consume affects fees and how fragmented your wallet becomes.
- Fragmentation is a state you can get into. A wallet holding thousands of tiny outputs is expensive to spend from.
- Parallelism comes free. Transactions touching different UTXOs have no ordering relationship at all, which is what lets a DAG process them concurrently.
Why this matters for contracts
An account-based chain gives a contract a persistent storage slot it mutates. UTXO chains have no such slot. A contract is a locking condition, and state persists only by being consumed and recreated: a transaction spends the UTXO holding the old state and creates one holding the new state.
That constraint shapes everything above it. It is why Silverscript describes spending conditions rather than mutable objects, and why Argent’s central idea is an actor that gets consumed and recreated by each transaction rather than updated in place.
Once you have this page, the map will make sense.