Extended UTXO (EUTXO)

The EUTXO model provides deterministic transaction validation, meaning the outcome of a transaction is known before it is submitted to the network. This eliminates gas estimation errors and failed transactions, allowing for precise, upfront fee calculation. Key features include:

• No unpredictable gas costs: Transaction fees are fixed and known in advance.
• No transaction failures due to concurrency: Each UTXO can only be consumed by one transaction, preventing race conditions.
• Enhanced user experience: Wallets can guarantee transaction success and cost before signing.

Because EUTXOs are independent state objects, transactions that spend different UTXOs can be validated in parallel. This is a fundamental architectural advantage for scalability, as it allows:

• Horizontal scaling: Validators can process non-conflicting transactions simultaneously.
• High throughput potential: Parallel processing reduces bottlenecks compared to sequential execution in account-based models.
• Concurrency without conflicts: The model naturally avoids state contention issues common in global state architectures.

EUTXO extends simple value transfer with attached data and validation logic. A locked UTXO contains:

• Datum: Immutable data attached to the UTXO itself, representing the contract's state (e.g., the terms of an escrow).
• Redeemer: Data provided by the spending transaction, specifying how the UTXO is being spent (e.g., "claim refund").
• Validator Script: The Plutus or Aiken script that checks if the provided redeemer is a valid action for the given datum and context. This structure enables complex, multi-step off-chain contract logic.

The EUTXO model is primarily implemented on the Cardano and Ergo blockchains.

• Cardano: Uses Plutus (Haskell-based) and Aiken for writing validator scripts that define spending conditions. Its Alonzo hard fork introduced full smart contract capability.
• Ergo: Implements a similar model with its ErgoScript language, focusing on financial contracts and DeFi. Both chains leverage the model's security and predictability for decentralized applications, from DEXs like Minswap and WingRiders to stablecoins and oracles.

EUTXO differs fundamentally from the account-based model used by Ethereum and other EVM chains:

• State: EUTXO uses distributed, unspent outputs; EVM uses a global shared state.
• Execution: EUTXO validation is local to a transaction's inputs; EVM execution can affect any contract's global state.
• Fees: EUTXO fees are predictable; EVM gas costs can fluctuate and cause failures.
• Concurrency: EUTXO enables parallel processing; EVM processes transactions sequentially per block, leading to potential congestion and high fees.

The EUTXO model excels in applications requiring high assurance, predictability, and complex state logic. Common use cases include:

• Multi-signature wallets and escrows: Complex spending conditions are natively expressed.
• DeFi protocols: Predictable fees and execution are critical for financial contracts.
• NFTs with evolving logic: Datums can hold mutable metadata tied to the token.

Developer Note: Building on EUTXO requires a different mental model. Logic is split between on-chain validators (small, efficient scripts) and off-chain constructors (builders that assemble transactions with correct datums and redeemers).

Unlike the UTXO model's simple signature checks, the EUTXO model validates transactions against a Datum (on-chain state) and a Redeemer (user input). This creates a deterministic state machine where the validity of a state transition is computed locally before submission. This prevents invalid transactions from being included in a block, eliminating certain classes of front-running and reentrancy attacks common in account-based systems.

A key design challenge in EUTXO is concurrency. Since each UTXO (including its attached datum) is a unique, indivisible state token, only one transaction can consume it. This prevents double-spending at the protocol level but requires careful application architecture. Solutions include:

• State tokenization: Splitting a shared state into multiple UTXOs.
• Batching: Aggregating actions into a single transaction.
• Off-chain coordination: Using hydra heads or other layer-2 protocols for high-throughput state updates.

The EUTXO model offers superior predictability. A transaction's success or failure can be simulated off-chain with 100% certainty before broadcasting, as validity depends only on the referenced UTXOs and the current blockchain state. This enables:

• Fee predictability: Users know the exact cost upfront.
• No failed transaction fees: Invalid transactions are rejected by nodes, not miners/validators.
• On-chain audit trail: Every state change is permanently linked to a specific, consumed UTXO, providing a clear history for forensic analysis.

EUTXO smart contracts (validator scripts) execute within a strictly defined Script Context. This context includes only the specific transaction being validated and the UTXOs it directly references. This limited scope is a core security feature:

• No external calls: A script cannot arbitrarily read other parts of the chain state or call other contracts, eliminating unpredictable side-effects.
• Resource limits: Execution is bounded by CPU/memory steps and exact fee calculation, preventing gas-related attack vectors and ensuring resource costs are known in advance.

The separation of Datum (on-chain state) and Redeemer (user-provided input) is a fundamental security pattern. The Datum is set when a UTXO is created and is immutable until spent. The Redeemer provides the "why" for spending it. This enforces a clear separation of concerns:

• Business logic is encoded in the validator script.
• Application state is stored in the Datum.
• User intent is passed via the Redeemer. This structure makes contract behavior more transparent and auditable, as all possible state transitions are defined by the script's logic acting on these two inputs.

The Unspent Transaction Output (UTXO) model is the fundamental accounting system used by Bitcoin, where each transaction consumes existing outputs and creates new ones. It is inherently parallelizable and deterministic, providing strong security and privacy guarantees. EUTXO extends this model by adding data and logic to each output, transforming it from a simple value container into a stateful contract instance.

A core property of the EUTXO model where the validity of a transaction can be verified locally before submission, without relying on global state. The outcome of contract execution is guaranteed to be the same for all network participants. This eliminates gas estimation races and unpredictable fees, as the exact cost is known in advance. Failed transactions simply do not get included in a block, preventing wasted fees.

EUTXO handles concurrency through output-based state management. Each UTXO is an independent state object that can be spent by only one transaction at a time. This requires careful design patterns to manage shared resources, such as:

• Batching: Aggregating multiple actions into a single transaction.
• Hydra: A Layer 2 solution providing high-throughput, low-latency state channels for off-chain concurrency.
• Reference Inputs: A feature allowing transactions to read UTXOs without spending them, enabling more flexible data access.

The Alonzo upgrade was the hard fork combinator event that introduced smart contract capabilities to the Cardano mainnet by activating the EUTXO model and Plutus. It marked the transition from a simple UTXO ledger to a programmable blockchain, enabling decentralized applications (DApps), decentralized finance (DeFi), and non-fungible tokens (NFTs) to be built natively on the protocol.

These are the two critical data fields that extend a basic UTXO into an EUTXO.

• Datum: Arbitrary data attached to a UTXO that represents its current contract state. It is stored on-chain and is immutable until the UTXO is spent.
• Redeemer: Data provided by the spender of a UTXO as an input argument to the validation script. The script logic uses both the Datum and the Redeemer, along with the transaction context, to determine if the spend is valid.