Understanding the Meaning of Extended in Cardano's UTxO Model

Published 24.11.2023

Bitcoin uses the UTxO accounting model. For the IOG team, this model was not sufficient for the Cardano mission, so they extended it. Cardano uses the Extended UTxO model. In this article, we will explain the meaning of ‘Extended’.

More Than Payments

The Bitcoin network is designed for payments. The UTxO model of Bitcoin has a limited expressiveness of programmability. Cardano is a smart contract platform allowing developers a wider range of operations related to value, i.e. working with UTxOs.

The extension of the UTxO model concerns the following properties:

  • Ability to maintain contract state.
  • Ability to reuse a contract code for a sequence of transactions. The team calls it continuity.
  • Ability to support multi-assets.
  • Ability to support higher expressiveness and programmability of smart contracts (scripts).

Bitcoin cannot provide these properties, or only to a very limited extent. Bitcoin is designed as a transaction network that essentially just validates keys to verify spending conditions. Bitcoin is not suitable for more complex financial operations, i.e. for the execution of smart contracts.

Capabilities of Bitcoin's UTxO and Scripts

In Bitcoin, an address is generated by hashing a public key. This process is known as ‘locking to a public key’. When someone sends BTC to an address, they are essentially locking it to the public key associated with that address.

To spend BTC locked to a specific address, the owner of the address must unlock it by providing a digital signature. This signature is generated using the private key associated with the public key of the address. The act of signing the transaction with the private key effectively unlocks BTC, allowing it to be spent.

In Bitcoin, an address can be associated with a script, but in a specific way. Bitcoin has a few different scripts, with Pay-to-Public-Key-Hash (P2PKH) being the most popular.

Bitcoin scripts (code/small program) are embedded in the input and output sections of transactions. When you create a transaction, you're essentially writing a script (opcodes dictate the spending conditions). To deploy a script, you would incorporate it into a Bitcoin transaction.

You will commonly encounter these scripts:

  • scriptPubKey is a locking script that requires certain conditions to be met in order for a recipient to spend BTC
  • scriptSig is the unlocking script that satisfies the conditions placed on the output by the scriptPubKey, and is what allows BTC to be spent

Scripts are written in Script. Bitcoin Script is a stack-based programming language used for constructing Bitcoin transactions. Bitcoin Script lacks many of the functionalities of common programming languages. It’s not Turing complete, meaning it lacks several logical functions.

So, while Bitcoin addresses can be associated with scripts, they are typically locked to a specific public key and do not contain arbitrary logic in the form of (smart) scripts. Scripts are mostly used for key validation.

Scripts are not stored separately on the blockchain for reuse. Instead, each transaction includes its own scripts.

So, while you can certainly use the same script in multiple transactions, each instance of the script is stored separately as part of its respective transaction. There isn’t a mechanism to store a script once on the blockchain and then reference it in multiple transactions.

Bitcoin Script does not have a notion of state. All the information needed is contained in the locking and unlocking scripts. This means that scripts are stateless and do not store any information between executions. Scripts are used almost exclusively to lock and unlock BTC.

In Bitcoin, UTxOs are used to store and transact BTC value. Each UTxO represents a certain amount of BTC that has been sent to a specific address. It is not possible to create a new UTxO that would (exclusively) represent a custom token with its own value.

You may have heard that Bitcoin can have tokens on the first layer. For the first time, it was the so-called colored coins. It is about associating specific satoshis with custom tokens. This effectively turns them into tokens, which can be used to represent anything. It should be noted that these were not tokens in the true sense of the word.

There could be a UTXO with 1000 satoshis where 10 satoshis are colored as tokens X. If you wanted to send only one token X, a new UTxO would have to be created. This concept was not viable.

The concept of Ordinals is somewhat similar to the concept of colored coins but with some key differences. Ordinals are satoshis that have been ordered and inscribed with a piece of information, such as text or an image. This piece of information makes the sat unique and turns it into a de-facto non-fungible token (NFT).

Bitcoin can be simply described as a single-asset ledger. Bitcoin scripts are stateless and are mainly used for validating signatures (keys). Scripts are transferred in transactions and cannot be stored in the blockchain and reused.

The Extended UTxO Model

In the Extended UTxO model, the concept of an ‘address’ is generalized. Instead of restricting locks to public keys and keys to signatures, addresses in the EUTxO model can (indirectly) contain arbitrary logic in the form of scripts.

This means that instead of just being a hashed version of a public key, addresses in Cardano can be associated with scripts through the script hash contained in the address. This allows for more complex transactions and interactions, such as those needed for smart contracts.

An address can contain a hash of the script that is used to identify the script that has been stored in the blockchain.

So, in Cardano, a transaction can both contain and reference scripts. Bitcoin cannot reference scripts. Therefore, scripts must always be included in the transaction.

Cardano can reference scripts. These referenced scripts are attached to outputs and can be used to satisfy script requirements during validation. This means that transactions using common scripts can be much smaller. The transaction that uses the script will not need to provide it at all, so long as it references an output that contains the script.

The concept of reference scripts is related to the continuity aspect of Cardano’s Extended UTXO model. Contract continuity ensures that the same contract code can be used for a sequence of transactions.

The Plutus platform allows developers to write applications (scripts) that interact with the Cardano blockchain. The Plutus programming language evolved from Haskell. Plutus scripts are pieces of code that implement pure functions with True or False outputs. They are used to validate actions.

In the Extended UTxO model, validator scripts are passed three arguments:

  • Datum: This is a piece of data attached to the output UTxO that the script is locking. This is typically used to carry state.
  • Redeemer: This is a piece of data attached to the spending input UTxO. This is typically used to provide input to the script from the spender.
  • Context: This is a piece of data that represents information about the spending transaction. This is used to make assertions about the way the output UTxO is being spent.

Cardano's EUTXO model allows developers to write stateful scripts through the use of these primitives.

Datum can be used to keep track of the state of a script. The Datum plays a crucial role in using an output UTxO from a script address and in sending it to a script address. So, in Cardano, you can associate a state with a script using the Datum.

The expressiveness and programmability of Plutus scripts allow developers to implement a wide range of logic. For example, a simple validator script could check whether a particular key signed the spending transaction (this is similar to Bitcoin scripts). However, with a bit of careful extension, developers can use scripts to express more complex logic.

The use of Datum and Redeemer further enhances the capabilities of these scripts, enabling them to carry state and accept input from the spender. The script can take the Datum and Redeemer values, perform calculations or comparisons, and then output a boolean value (which determines the possibility of spending).

Cardano's ledger is designed to support multiple assets. It is called a multi-asset ledger. It allows Cardano to do accounting or transact with more than one type of asset (native ADA coins).

When tokens are minted, new UTxOs are created. When users mint tokens, they are essentially creating new UTxOs that hold these tokens. These UTxOs can then be spent in transactions, just like UTxOs with ADA coins.

Plutus scripts can work with tokens exactly the same as with ADA.

Cardano can be simply described as a multi-asset ledger. Minted tokens are new UTxOs that have similar properties to ADA coins. Plutus scripts are stateful. Scripts work with Datum, Redeemer, and transaction context, allowing developers to create more complex logic (beyond key verification). Scripts can be stored in the ledger and referenced repeatedly.


The UTxO model has another important meaning that is not mentioned in the article. Namely for the possibility of higher scalability. UTxOs are essentially objects that are independent of their surroundings. Transactions with UTxO can be validated regardless of other UTxOs (ie basically regardless of transactions of other users). In other words, another feature that the UTxO model supports is parallelism. This feature will be taken advantage of by an enhancement called Input Endorsers.

Probably the biggest difference between Bitcoin UTxOs and Cardano UTxOs is the ability to add Datum, i.e. arbitrary data. Although many of the described differences are somewhat related to UTxOs, they differ mainly due to the different philosophies and designs of the two projects. If it were possible to add data (Datum) to Bitcoin UTxOs, it would be necessary to further extend the Bitcoin Script. Stored data is more useful if it can be compared to something, ideally some transaction input (Redeemer). The ability to mint new UTxO is a feature that Bitcoin does not have on purpose. Such considerations could be continued further.

Blockchain is composed of multiple components whose properties form a whole. UTxO is only one of these components. Utilizing the potential of the accounting model is dependent on other components. The potential of Extended UTxO is related to the Plutus platform, transactions, ledger capabilities, etc.


Related articles

Did you enjoy this article? Other great articles by the same author