---
title: "Unspent Transaction Output (UTXO) Model"
path: "/contents/tech/core-concepts/unspent-transaction-output-utxo-model"
version: "1.2.0"
author: "Hydrate"
createdAt: "2026-02-03T14:27:00.615Z"
updatedAt: "2026-03-16T18:25:44.235Z"
---

# 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.

<Columns gap="md" align="start">
<Column>

</Column>
<Column>

</Column>
</Columns>

## 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](/developers/legacy-docs/reference/radix-engine/radix-engine) UTXO model

The [Radix Engine](/developers/legacy-docs/reference/radix-engine/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.