Native tokens | Cardano Docs (2024)

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

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

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

Read more aboutnative tokens and how they compare to ada and ERC20and watch thisnative tokens explainer video.

Single asset ledgers​

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

Multi-asset (MA) support​

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

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

Native versus non-native MA support​

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

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

Assets and tokens​

Assets

An asset is an object that represents value on the blockchain. These objectscan be a variety of things, such as a digital asset like ada, a role, acredential, 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', '24couttscoins', 'this house' or 'these 10 tonnes of coffee'.

An asset is uniquely identified by an asset ID, which is a pair of both thepolicy ID and asset name. It is important to note that although ada canact 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 eachother, and are not fungible with tokens that have a different asset ID. Anasset 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 andRushConcertPolicyID. The ID is computed by applying a hash function to thepolicy 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 distinguishdifferent assets within the same policy. Unlike the policyID, the asset namedoes 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 anasset is scoped can specify some constraints on valid asset names.

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

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

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

Tokens

A token is a short term for 'asset token', which is the on-chainrepresentation of an asset and its basic accounting unit. A token can representone 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 refersto 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 asfee-payment, to make deposits, and is also the only currency in which rewardsare distributed. This property of ada (and no other type of asset) is due to theconstruction of the underlying consensus protocol.

Native tokens represent some value and act as an accounting unit, which can beused for payments, transactions, and can be sent to an exchange address.Native means that these tokens are supported by the Cardano accounting ledgerwithout the need for additional smart contracts, as the ledger features built-insupport 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 transactionunit, only ada is used for fees and rewards, while only native tokens can becustomly created.

Using ada for administrative operations​

Ada is Cardano’s principal currency. It is essential to hold ada (besides othercurrencies) to transfer multi-asset tokens between addresses, since each addressmust hold aminimum 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 themin-ada-value of the output, but the number of types of tokenscontained in an output increases the min-ada-value. (The reason for thisis that the names and policy IDs of each of the types of tokens take upadditional space in the output.)
3. Sending custom tokens to an address always involves sending themin-ada-value of ada to that address alongside the custom tokens (byincluding the ada in the same output). If the address is not spendable by theuser that is sending the tokens, the ada sent alongside the tokens no longerbelongs to the sender.

4. To recover the ada stored alongside custom tokens in an output O, the usermust 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 withthe same collection of types of custom tokens stored in another output (spentwithin the same transaction)

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

5. Splitting custom tokens into more outputs than they were contained in beforethe transaction was processed requires more total ada to cover themin-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 canbe bundled together. Token bundles are the standard - and only - way torepresent and store assets on the Cardano blockchain.

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

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

Token bundles are contained in outputs and mint fields of transactions, and theoutputs in the UTXO set tracked by the ledger. Note that certain fields of atransaction 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 iscreating the tokens in the bundle.
2. In an output of a transaction or an output in the current UTXO tracked by theledger, alongside the address of the output, egMulti { MyAddress, value: TB_Example }

Splitting and combining token bundles

Transactions can arbitrarily split and combine token bundles into differentbundles. 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 tokenissuance on various platforms today. The peculiarity of this token type lies inthe fact that it can represent value and serve for such purposes as payments,value transfer, exchange, rewards or incentives, access to services andproducts, represent voting rights, etc. Also, these tokens can hold both utilityand 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-mentionedpurposes 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 supportedby the ledger natively (ERC20 tokens require smart contracts to achieve the samething). An important benefit of using native tokens is that they do not requiresmart contracts to transfer their value and can be transferred alongside othertoken types. Also, unlike ERC20, native tokens do not require special transferfees or additional event-handling logic to track transactions.

Another advantage of native tokens over ERC20 is security. ERC20 tokens haveproven vulnerable to a wide range ofsecurity issues.This is conditioned by the fact that ERC20 token creation requires manualmodification of the contract standard, which can result in errors and possiblebugs. Creating and transacting tokens natively removes the possibility of humanerror, since the ledger itself handles the token logic. Additionally, over- andunder-flow vulnerabilities that are present for ERC20 are eliminated for nativetokens, as Cardano’s scripting language does not have fixed-size integers andthe 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 ofassets scoped under that policy. The point of a minting policy is to specify theconditions under which tokens are minted (or burned). For example, the rulesmight 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. Forexample, a user might wish to only allow themselves to mint any more of acertain 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, amultisig specification, where no code is needed).
2. A specification of during what slot the script can be spent from (eg, afterslot 15 and before slot 20) With a Plutus Core script.

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

Important points about minting policies and assets​

• All assets necessarily have a minting policy. For example, the minting policyof 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 scopedunder it. Adherence to it is checked both at the time of minting as well asburning.
• An asset cannot ever change its associated minting policy. This association ispermanent. In other words, existing tokens cannot be associated with a newpolicy. Users can, however, buy back and burn all existing tokens and mint newones, 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 isguaranteed that it was originally minted according to that policy.
• Unless tokens of a given policy are being minted in a transaction, the actualpolicy is irrelevant. It is just used as an identifier of the asset.
• Assets associated with different minting policies are never fungible with oneanother. They can be traded in the same way one may use USD to buy CAD: theamount of CAD you can buy with a fixed amount of USD depends on the exchangerate 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 safetyreasons: this feature protects the users and the system from illegitimatelyminted tokens.

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

Note that this is not as restrictive as it sounds. In a loose parallel with theUS monetary policy, we can say that the policy is 'government and laws set thepolicy', and this is a policy which requires looking up the current laws (whichthemselves 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 aparticular 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 signedthe minting transaction.

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

Time-locked minting policy (token-locking)

This type of policy can be used to specify when tokens can be spent from anaddress. 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 conjunctionwith the multi-signature or single issuer policy. For example, this output canbe 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 isminted by one specific transaction. This means that no more tokens in thatparticular asset group will ever be minted. This type of policy needs Plutussmart contracts to be implemented.

One-type mint policies would be useful for generating concert ticket tokens fora specific concert, for example. The venue capacity is known ahead of time, sothere'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 removeexisting tokens (burning), each transaction features a mint field. Thetransactions where the mint field is not empty are known as mintingtransactions. The use of this field needs to be tightly controlled to ensurethat the minting and burning of tokens occur according to the token's mintingpolicy.

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

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

It is important to highlight that a single transaction might mint tokensassociated with multiple and distinct minting policies. For example,(Policy1, SomeTokens) or (Policy2, SomeOtherTokens). Also, a transactionmight 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:

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, andauthorise token issuers to mint/burn tokens. They may also retain co-signingrights for any tokens that are issued/burnt.
• Token issuers, who mint new tokens, maintain the reserve of tokens incirculation, issue them to token holders, and burn tokens when they are nolonger of use.
• Token holders, who hold tokens, send them to other users, use them forpayment, and who may redeem them with the issuers when they have finishedusing 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 tokenissuers in accordance with the monetary policy script that the assetcontroller has defined. New tokens will usually be created to fulfill specificpurposes. For example, fungible or non-fungible (unique) tokens may becreated to be used for specific payment, purchasing, or exchange needs. When anew token is minted, the total token supply for that token increases, butthere is no impact on the ada supply. Minting coins and transferring them tonew addresses may require an ada deposit to be paid, which may be proportionalto the number of different tokens that are held, for example.

Token holders will hold tokens in their wallets, may pass them on to otherusers, exchange them for items of value (including non-native tokens), etc. inexactly the same way that they can use ada. When a user has finished using thetoken, they may choose to redeem them. This means that tokens are returnedto 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 asneeded. Token holders will need to maintain some ada in their wallets to pay fortransaction fees.

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