Unspent Transaction Output (UTXO) Model

The unspent transaction output (UTXO) model tracks ownership of a digital asset as a set of outputs, each locked to an owner and spent once, in full, by a later transaction. Bitcoin introduced it in 2009. The first Radix Engine, which ran the Olympia mainnet from 28 July 2021, extended the model to general programs; Babylon, live since 28 September 2023, replaced it with the substate model.

How the UTXO model works

A UTXO ledger holds no balances. It holds a set of unspent outputs, each carrying an amount and a locking script that states the condition for spending it, usually a signature from one key (Bitcoin developer guide). A transaction names the outputs it consumes, satisfies each locking script, and creates new outputs whose total does not exceed the inputs; the difference is the fee. An output is consumed whole, so a payment smaller than the output returns the remainder to the sender as a change output: Alice spends a 2 BTC output by creating a 1.5 BTC output for Bob and a change output of 0.5 BTC, less the fee, for herself.

Two transactions that try to consume the same output are a double spend, and consensus accepts at most one. Each output points back to the transaction that created it, so the ledger carries the full chain of custody for every coin, and transactions that consume different outputs do not depend on each other (Nakamoto, 2008).

Does Radix use the UTXO model?

Not since Babylon. Olympia's engine was a UTXO design: Radix described its Constraint Machine as taking Bitcoin's UTXO model and expanding it for general programming, with state held in particles that a transaction spins down (consumes) and spins up (creates) (Radix: Constraint Machine). The Olympia node's instruction set encodes that model directly: a transaction is a list of UP, DOWN and READ instructions against substates (radixdlt/olympia-node: REInstruction).

Babylon's engine keeps the word substate and drops the spend-once rule. State belongs to nodes such as a component, a resource manager or a vault; each node's state is split into numbered partitions, and each partition holds substates under a key. A transaction reads and writes those substates in place, and the kernel holds the updates until the transaction ends and then commits them (Radix Engine Docs: Kernel). A token balance is a vault updated in place rather than a set of outputs.

The granularity carries over. Two transactions conflict only when they touch the same substate, even inside one component, which is the property Cerberus was designed to exploit by running unrelated transactions on different shards. Mainnet runs as a single shard group, so today the granularity decides what conflicts rather than where it runs; the Substate Model page covers it.