---
title: "Unspent Transaction Output (UTXO) Model"
url: "https://radix.wiki/contents/tech/core-concepts/unspent-transaction-output-utxo-model"
version: "1.2.3"
updated: 2026-08-19
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Unspent Transaction Output (UTXO) Model

The **Unspent Transaction Output ([UTXO](https://en.wikipedia.org/wiki/Unspent_transaction_output))** model is a way to track ownership of digital assets in cryptocurrency systems. The [Radix Engine](/contents/tech/core-protocols/radix-engine) implements a novel UTXO architecture that enables unique features around scalability, asset universality, transaction concurrency, and accounts, while preserving the core integrity of UTXO-based accounting.

## Classic [UTXO](https://en.wikipedia.org/wiki/Unspent_transaction_output) Model

The unspent transaction output (UTXO) model was popularized by [Bitcoin](https://bitcoin.org) as a way to track ownership of coins in a distributed ledger. In this model, the ledger consists of a set of UTXOs representing coins that can be spent. Each UTXO has a value and a locking script that defines the conditions required to spend it.

When a transaction occurs on the Bitcoin network, it consumes UTXOs by satisfying their locking script conditions and creates new UTXOs with updated owners and values.

Copy

```rust
Example: If Alice has a 2 BTC UTXO, she can create a transaction consuming that UTXO and creating two outputs:

		➡️ 1.5 BTC UTXO assigned to Bob
		➡️ 0.5 BTC change UTXO back to herself.
```

The key rules of the classical UTXO model are:

- Coins are represented exclusively as UTXOs on the ledger. The set of available spendable coins equals the set of unspent UTXOs.
- UTXOs are created via mining rewards and transaction outputs. New UTXOs come into existence when transactions produce change.
- UTXOs are consumed and destroyed when used as transaction inputs. This transfers ownership by assigning new UTXOs to new owners.
- Transactions specify input UTXOs to consume and output UTXOs to create in a single atomic operation.
- Consensus rules validate transactions verify ownership of input UTXOs via satisfaction of their locking scripts.
- The ledger is represented as the chain of transactions with each transaction changing UTXO state.

This model provides a complete historical record showing the full chain of custody for every coin on the network. The UTXO architecture offers useful integrity properties around ownership and prevents double spending without a central authority.

## [Radix Engine](/contents/tech/core-protocols/radix-engine) UTXO model

The [Radix Engine](/contents/tech/core-protocols/radix-engine) implements a UTXO model that makes several optimizations tailored for scalability and performance of decentralized applications. Some key properties of the Radix Engine UTXO architecture:

- Assets are defined as universal resources rather than being tied to specific smart contracts or accounts. Resources can be freely used across components and shards.
- Components group all their owned resources into a single UTXO. This allows maximum throughput for each component on its shard.
- Accounts are components, so each user's balance is represented by an account-specific UTXO.
- Transactions specify intent rather than directly specifying input/output UTXOs. The protocol dynamically selects UTXOs to satisfy intent.
- Validity relies on digital signatures proving ownership of resources rather than locking script conditions.
- Transferring ownership is done by constructing/destructing resources rather than a locking model. This provides inherent atomicity.
- Concurrent double spends are resolved by aborting one transaction rather than rejecting both.
- The ledger tracks transactions that transform state by constructing/destructing resources.

With these properties, the Radix Engine UTXO model offers several key benefits:

- Assets are universal across the ledger, enhancing composability between dApps.
- Component grouping into single UTXOs maximizes shard throughput.
- Specifying intent avoids transaction conflicts, increasing concurrency.
- Validity via signatures has low coordination overhead.
- Construction/destruction enables atomicity without locks.
- Selective transaction abortion increases throughput.