Extended UTXO (EUTXO)

Overview

How it works

In a basic UTXO model, each output contains value and a locking condition. A future transaction consumes the output by satisfying that condition. EUTXO expands the model so outputs can carry custom data and use expressive scripts to decide whether they may be spent.

Cardano smart-contract transactions can include datums, redeemers, script references, and multiple assets. The validator examines the relevant transaction context and returns approval or rejection. If all referenced inputs still exist and the transaction was constructed correctly, execution behavior is more predictable than in a shared global-state model.

Concurrency depends on input design. Two transactions can be processed independently when they consume different UTXOs. If they both require the same output, only one can succeed, creating contention. Scalable applications therefore divide state across multiple outputs when possible.

EUTXO also supports precise fee and resource estimation before submission, although script-failure rules and collateral still matter. Developers coming from account-based platforms must use different design patterns because state is represented through outputs rather than mutable contract accounts.

The model improves local reasoning and parallelism, but transaction construction, input selection, and state-machine design can be more complex for applications accustomed to account balances.

Application architecture must account for state fragmentation. A single shared UTXO can become a bottleneck because only one transaction can consume it at a time. Developers can improve concurrency by dividing liquidity or state across several outputs and coordinating them through off-chain logic. This differs from account-based systems, where contention occurs around mutable accounts or contract storage rather than explicit input consumption.

What matters in practice

An EUTXO transaction identifies the exact outputs it will consume and the conditions for doing so. Scripts can inspect datums, redeemers and transaction context, making state transitions explicit and, in some implementations, more predictable before submission. A shared state machine represented by one output creates contention if multiple users try to consume that output concurrently; applications mitigate this by sharding state or designing independent outputs. Developers must still manage script costs, datum versions and multi-asset accounting, so 'deterministic validation' should not be mistaken for automatic scalability.

Related glossary concepts

UTXO Model; Transaction