Skip to main content

Native tokens

info

To start working with native tokens, see:

Native tokens is a feature that enables the transacting of multi-assets on Cardano. Users can transact with ada, and an unlimited number of user-defined (custom) tokens natively.

Native support offers distinct advantages for developers: there is no need to create smart contracts to handle custom tokens, for example, which removes a layer of added complexity and potential for manual errors since the ledger handles all token-related functionality.

The native tokens feature extends the accounting infrastructure defined in the ledger model (originally designed for processing ada-only transactions) to accommodate transactions using a range of assets. These assets include ada and a variety of user-defined custom token types.

Read more about native tokens and how they compare to ada and ERC20 and watch this native tokens explainer video.

Single asset ledgers​

Cryptocurrency ledgers that track exactly one type of asset are called single-asset ledgers.

Multi-asset (MA) support​

A blockchain, ledger, or cryptocurrency is said to have multi-asset (MA) support when the network or ledger supports tracking, transfer, and ownership of different types of assets on its ledger. In the Cardano environment, this functionality is provided by the native tokens feature.

This feature accommodates transactions that simultaneously use a range of assets. These assets include ada and a variety of user-defined custom token types.

Native versus non-native MA support​

Some cryptocurrency ledgers have built-in support to track ownership and transfer of more than one type of asset. This type of MA support is called native. Cardano's MA functionality is native.

If a cryptocurrency platform has sufficiently powerful smart contract functionality, it is possible to track assets for which there is no ledger accounting support. This is done with a layer-2 solution built using smart contracts. This type of MA support is non-native.

Assets and tokens​

Assets

An asset is an object that represents value on the blockchain. These objects can be a variety of things, such as a digital asset like ada, a role, a credential, or a quantity of goods.

The term asset can refer to either:

  • the identifier of a class of objects, such as 'ada' or 'couttscoins'; or
  • a particular quantity of a specific object, such as '100 lovelace', '24 couttscoins', 'this house' or 'these 10 tonnes of coffee'.

An asset is uniquely identified by an asset ID, which is a pair of both the policy ID and asset name. It is important to note that although ada can act as an asset, it is not represented using an explicit policy ID.

Tokens that have the same asset ID have the property of being fungible with each other, and are not fungible with tokens that have a different asset ID. An asset ID is a unique identifier for a collection of fungible tokens.

  • PolicyID - the unique identifier that is associated with a minting policy. Let’s take a look at two policy ID examples: NFLPlayerCardsPolicyID and RushConcertPolicyID. The ID is computed by applying a hash function to the policy itself, and is thus a sequence of letters and numbers. For example:
NFLPlayerCardsPolicyID = e0d123e5f316bef7
  • Asset name - an (immutable) property of an asset that is used to distinguish different assets within the same policy. Unlike the policyID, the asset name does not refer to any code or set of rules, and can be common words, such as ‘tickets’ or ‘VIPTickets’, for example. However, the policy under which an asset is scoped can specify some constraints on valid asset names.

Different policies can use the same asset names for different tokens. For example, the token bundle:

FAKERushConcertPolicyID {  (Tickets, 500),
                           (VIPTickets, 50)}

contains the Tickets and VIPTickets asset names, but these are not fungible with the RushConcertPolicyID tickets that have been defined in another token bundle, since they are scoped under different policies.

Tokens

A token is a short term for 'asset token', which is the on-chain representation of an asset and its basic accounting unit. A token can represent one ada, one house, or the value of ten tonnes of coffee, for example.

Currencies​

Currency is a medium of exchange for goods and services that commonly refers to a payment unit. Cardano supports currencies such as ada and native tokens, which act similarly in the network.

However, ada is the principal currency that, at this time, is accepted as fee-payment, to make deposits, and is also the only currency in which rewards are distributed. This property of ada (and no other type of asset) is due to the construction of the underlying consensus protocol.

Native tokens represent some value and act as an accounting unit, which can be used for payments, transactions, and can be sent to an exchange address. Native means that these tokens are supported by the Cardano accounting ledger without the need for additional smart contracts, as the ledger features built-in support to track ownership and transfer of more than one type of asset.

While both ada and native tokens hold value and act as a payment and transaction unit, only ada is used for fees and rewards, while only native tokens can be customly created.

Using ada for administrative operations​

Ada is Cardano’s principal currency. It is essential to hold ada (besides other currencies) to transfer multi-asset tokens between addresses, since each address must hold a minimum ada value (min-ada-value).

As a consequence of this design, the following apply:

  1. It is impossible to create outputs that contain only custom tokens.
  2. The number of each kind of token in an output does not affect the min-ada-value of the output, but the number of types of tokens contained in an output increases the min-ada-value. (The reason for this is that the names and policy IDs of each of the types of tokens take up additional space in the output.)
  3. Sending custom tokens to an address always involves sending the min-ada-value of ada to that address alongside the custom tokens (by including the ada in the same output). If the address is not spendable by the user that is sending the tokens, the ada sent alongside the tokens no longer belongs to the sender.
note

Before transferring custom tokens, users may choose to use off-chain communication to negotiate who supplies the ada to cover the min-ada-value in the output made by the transferring transaction.

  1. To recover the ada stored alongside custom tokens in an output O, the user must either:
  • Spend the output O, and burn the custom tokens that are stored therein
  • Spend an output O and an output O’, and consolidate the tokens therein with the same collection of types of custom tokens stored in another output (spent within the same transaction)

For example: (CryptoDoggiesPolicy, poodle, 1) contained in O can be consolidated with (CryptoDoggiesPolicy, poodle, 3) in O’, for a total of (CryptoDoggiesPolicy, poodle, 4) in a new output that is made by the consolidating transaction.

  1. Splitting custom tokens into more outputs than they were contained in before the transaction was processed requires more total ada to cover the min-ada-value, since some ada must be supplied in each output.

Token bundles​

A token bundle is a heterogeneous (‘mixed’) collection of tokens. Any tokens can be bundled together. Token bundles are the standard - and only - way to represent and store assets on the Cardano blockchain.

Token bundles organize tokens into a particular kind of data structure (see example and explanation below), so that which tokens are fungible with which other tokens explicitly adheres to this organization.

In previous versions of the Cardano ledger, ada amounts were specified in transaction and UTXO outputs. With the introduction of multi-asset support, these amounts have been extended with token bundles, which can specify an ada amount alongside quantities of other assets in a single output.

Token bundles are contained in outputs and mint fields of transactions, and the outputs in the UTXO set tracked by the ledger. Note that certain fields of a transaction must still explicitly specify ada amounts, such as the fee field.

Token bundle example

Here is an example of a token bundle, let’s call it TB_Example:

{
NFLPlayerCardsPolicyID {(SomeNFLPlayerCard, 1),
                        (SomeOtherNFLPlayerCard, 1),
                        (YetAnotherNFLPlayerCard, 1)}


RushConcertPolicyID {(Tickets, 500),
                     (VIPTickets, 50)}
}

How and where are token bundles stored?

Token bundles can be found:

  1. As the mint field of a transaction, indicating that the transaction is creating the tokens in the bundle.
  2. In an output of a transaction or an output in the current UTXO tracked by the ledger, alongside the address of the output, eg Multi { MyAddress, value: TB_Example }

Splitting and combining token bundles

Transactions can arbitrarily split and combine token bundles into different bundles. For example, we can split the bundle TB_Example into two:

TB_Example_Part1:

NFLPlayerCardsPolicyID {(SomeNFLPlayerCard, 1)}


RushConcertPolicyID {(Tickets, 200),
                     (VIPTickets, 20)}

TB_ExamplePart2:

NFLPlayerCardsPolicyID {(SomeOtherNFLPlayerCard, 1),
                        (YetAnotherNFLPlayerCard, 1)}

RushConcertPolicyID {(Tickets, 300),
                     (VIPTickets, 30)}

Comparison with ERC20 tokens​

ERC20 is an Ethereum token standard, widely used for the purpose of token issuance on various platforms today. The peculiarity of this token type lies in the fact that it can represent value and serve for such purposes as payments, value transfer, exchange, rewards or incentives, access to services and products, represent voting rights, etc. Also, these tokens can hold both utility and security features, which opens a range of possible use cases for businesses, applications, and enterprises.

On Cardano, users can create native tokens that will serve the above-mentioned purposes and in addition, it is possible to create unique (non-fungible) assets representing value like real estate or intellectual rights, for example (in Ethereum, this functionality requires a separate standard, ERC721).

Unlike ERC20 tokens, the tracking and accounting of native tokens is supported by the ledger natively (ERC20 tokens require smart contracts to achieve the same thing). An important benefit of using native tokens is that they do not require smart contracts to transfer their value and can be transferred alongside other token types. Also, unlike ERC20, native tokens do not require special transfer fees or additional event-handling logic to track transactions.

Another advantage of native tokens over ERC20 is security. ERC20 tokens have proven vulnerable to a wide range of security issues. This is conditioned by the fact that ERC20 token creation requires manual modification of the contract standard, which can result in errors and possible bugs. Creating and transacting tokens natively removes the possibility of human error, since the ledger itself handles the token logic. Additionally, over- and under-flow vulnerabilities that are present for ERC20 are eliminated for native tokens, as Cardano’s scripting language does not have fixed-size integers and the ledger itself (rather than the ERC20 user code) tracks token movement.

Minting policy​

Overview

A minting policy is the set of rules that govern the minting and burning of assets scoped under that policy. The point of a minting policy is to specify the conditions under which tokens are minted (or burned). For example, the rules might specify who has control over the asset supply through minting and burning.

Minting policies are defined by the users who want to create a new asset. For example, a user might wish to only allow themselves to mint any more of a certain kind of token. This would be specified in the policy.

Minting rules can be expressed:

As very basic set of rules that is made up of (ANDs and ORs of):

  1. A specification of what signatures are needed to allow the mint (eg, a multisig specification, where no code is needed).
  2. A specification of during what slot the script can be spent from (eg, after slot 15 and before slot 20) With a Plutus Core script.

Adherence to minting policies is checked by the node at the time a transaction is processed, by running the code or checking the relevant signatures. Transactions must adhere to all the minting policies of all assets that the transaction is attempting to mint.

Important points about minting policies and assets​

  • All assets necessarily have a minting policy. For example, the minting policy of ada is 'new ada can never be minted'.
  • A token is associated with (eg, scoped under) exactly one minting policy.
  • A single policy specifies both minting and burning conditions of tokens scoped under it. Adherence to it is checked both at the time of minting as well as burning.
  • An asset cannot ever change its associated minting policy. This association is permanent. In other words, existing tokens cannot be associated with a new policy. Users can, however, buy back and burn all existing tokens and mint new ones, with a new minting policy. Note that this is a feature, not a bug!
  • If an existing asset on the ledger is scoped under a particular policy, it is guaranteed that it was originally minted according to that policy.
  • Unless tokens of a given policy are being minted in a transaction, the actual policy is irrelevant. It is just used as an identifier of the asset.
  • Assets associated with different minting policies are never fungible with one another. They can be traded in the same way one may use USD to buy CAD: the amount of CAD you can buy with a fixed amount of USD depends on the exchange rate of the place where you do the trade.

Association between an asset and its minting policy​

The association between an asset and its minting policy is permanent for safety reasons: this feature protects the users and the system from illegitimately minted tokens.

If the minting policy of a token changes, it is not really the same token any more, and its value cannot be compared to that of the original token. This permanent asset-policy association scheme is integral to defining high-assurance policies. Loosening this identification opens our MA scheme to various attacks. Having a permanent association between these allows us to guarantee that every token was minted in accordance with its minting policy, and not any other policy which it might have previously been associated with.

Note that this is not as restrictive as it sounds. In a loose parallel with the US monetary policy, we can say that the policy is 'government and laws set the policy', and this is a policy which requires looking up the current laws (which themselves could change), and only minting money in adherence to them.

Minting policy examples​

  • Single-issuer policy
  • Time-locked mint policy
  • One-time mint policy.

Note: There are many other types of minting policies.

Single-issuer policy

A single-issuer minting policy specifies that only the entity holding a particular set of keys is allowed to mint tokens of the particular asset group. For example, the set of keys specified in the minting policy must have signed the minting transaction.

An example of an asset group that would use a single-issuer policy would be tokens representing baseball cards. The company manufacturing legitimate collectors' cards would publish the keys required by the minting script to mint new baseball cards. This would mean that no new baseball card tokens can be minted without the company's signatures. This type of policy can be implemented without Plutus smart contracts.

Time-locked minting policy (token-locking)

This type of policy can be used to specify when tokens can be spent from an address. In particular,

  • only in or after a specified time slot
  • only before a specified time slot.

This type of policy is usually not used by itself. Usually, it is in conjunction with the multi-signature or single issuer policy. For example, this output can be spent after slot s and only by a transaction signed by key k.

This type of policy can be implemented without Plutus smart contracts.

One-time minting policy

In a one-time mint policy, the complete set of tokens of a given asset group is minted by one specific transaction. This means that no more tokens in that particular asset group will ever be minted. This type of policy needs Plutus smart contracts to be implemented.

One-type mint policies would be useful for generating concert ticket tokens for a specific concert, for example. The venue capacity is known ahead of time, so there'll be no need to ever allow more tickets to be minted.

Minting transactions

To introduce new quantities of new tokens on the ledger (minting) or to remove existing tokens (burning), each transaction features a mint field. The transactions where the mint field is not empty are known as minting transactions. The use of this field needs to be tightly controlled to ensure that the minting and burning of tokens occur according to the token's minting policy.

Apart from the mint field, minting transactions must also carry the minting policies for the tokens they are minting, so that these tokens can be checked during validation.

The outcome of processing a minting transaction is that the ledger will contain the assets included in the mint field, which is included in the balancing of the transaction: if the field is positive, then the outputs of the transaction must contain more assets than the inputs provide; if it is negative then they must contain fewer.

It is important to highlight that a single transaction might mint tokens associated with multiple and distinct minting policies. For example, (Policy1, SomeTokens) or (Policy2, SomeOtherTokens). Also, a transaction might simultaneously mint some tokens and burn others.

The native token lifecycle​

The native token lifecycle consists of five main phases:

  1. minting
  2. issuing
  3. using
  4. redeeming
  5. burning.

The following diagram outlines the interaction between the system components:

Multi-asset

Each of these logical phases involves transactions on the Cardano blockchain, which may incur fees in ada. The main groups of actors are:

  • Asset controllers, who define the policy for the asset class, and authorise token issuers to mint/burn tokens. They may also retain co-signing rights for any tokens that are issued/burnt.
  • Token issuers, who mint new tokens, maintain the reserve of tokens in circulation, issue them to token holders, and burn tokens when they are no longer of use.
  • Token holders, who hold tokens, send them to other users, use them for payment, and who may redeem them with the issuers when they have finished using them. Token users may include normal users, exchanges etc.

The lifecycle of multi-asset tokens starts with their creation – minting, which refers to the process whereby new tokens are created by one or more token issuers in accordance with the monetary policy script that the asset controller has defined. New tokens will usually be created to fulfill specific purposes. For example, fungible or non-fungible (unique) tokens may be created to be used for specific payment, purchasing, or exchange needs. When a new token is minted, the total token supply for that token increases, but there is no impact on the ada supply. Minting coins and transferring them to new addresses may require an ada deposit to be paid, which may be proportional to the number of different tokens that are held, for example.

Token holders will hold tokens in their wallets, may pass them on to other users, exchange them for items of value (including non-native tokens), etc. in exactly the same way that they can use ada. When a user has finished using the token, they may choose to redeem them. This means that tokens are returned to an issuer (perhaps in return for a product, service, or some other currency, for instance). Once redeemed, tokens could then be re-issued to other users as needed. Token holders will need to maintain some ada in their wallets to pay for transaction fees.

When tokens become redundant, they can be burned, if desired, in accordance with the underlying monetary policy script. The process of burning destroys these tokens (removes them from circulation), and the total token supply decreases. Any deposits will be returned at this point. The burning process is identical for fungible and non-fungible tokens.

note

Note: The multi-asset token lifecycle potentially allows tokens to be obtained and reissued by other parties - token holders who act as reissuers for the token. This can be done to eg, enable trading in multiple asset classes, maintain liquidity in one or more tokens (by acting as a broker), or to eliminate the effort/cost of token minting, issuing or metadata server maintenance. Thus, both reissuers and issuers can gain from such a deal - eliminating cost and effort, maintaining separation and integrity, and injecting value into the asset class.

On this page