IOTA Tokenization Framework Specifications

padding: 12px;
background: var(--button-shadow-color-normal);
border-radius: 8px;
">
TL;DR:


Today we release specifications for the new Tokenization Framework for the IOTA mainnet. This future upgrade will transform the mainnet protocol to a multi-asset ledger with smart contracts and seamless cross-chain asset transfers. Native tokens and NFTs live inside the Tangle and inherit the feeless and scalable nature of the base currency, the IOTA coin. A trustless bridge mechanism of the Native Tokenization Framework ensures that smart contract tokens can be effortlessly wrapped into and unwrapped from native tokens. The protocol specifications are undergoing public review and work has been started on the testnet implementation.

Tokenization is one of the greatest innovations in the DLT space, enabling entirely new use cases and business models. IOTA has been exploring the tokenization landscape with the Native Tokenization Framework, which was released for the IOTA 2.0 DevNet in June 2021.

In previous blog posts, we have explained the novel use cases and opportunities that tokenization brings to the table and showed how powerful the testnet implementation of the framework is. Users can mint their own native tokens and assets directly on the Tangle, which are then feelessly transferable just like IOTA coins.

By experimenting with digital assets in the development network, we have learned a great deal about the limitations of our concepts. We took a step back and imagined a world where digital assets are a vital building block of the whole IOTA technology stack. In this token wonderland, assets flow seamlessly and trustlessly between smart contract chains and user accounts. They can be wrapped or unwrapped without centralized bridge solutions. Anyone is free to create and manage their own tokens. After all, IOTA is about freedom.

Today, we are proud to present the mainnet specifications of the IOTA Tokenization Framework and invite the community to explore this exciting space with us as we start our journey to bring the biggest ever utility upgrade to the IOTA mainnet.

Transforming IOTA into a Multi-Asset Ledger

Most DLTs fall into the category of single-asset ledger, as they are only capable of tracking ownership of one specific base currency inside their ledger. Multi-asset ledgers, on the other hand, are capable of managing several native tokens in the very same ledger that maintains the base currency. As the base ledger of IOTA provides feeless transactions, a multi-asset IOTA ledger is capable of executing feeless transfers of any native tokens, which is a unique game-changer in the field.

We have redesigned and extended the Unspent Transaction Output (UTXO) model of the IOTA ledger to transform it into a fully-fledged Multi-Asset Ledger. Any account in the ledger is capable of holding and transferring native tokens that are minted into existence by Token Foundries. It is no longer necessary to “tag” or “color” IOTA coins: all native tokens are standalone tokens in the ledger that are forged into existence by foundries.

Native tokens are injected into the IOTA ledger by users; therefore they are also called user-defined tokens. They consume precious resources of nodes maintaining the network, mostly storage. As a consequence, each account that holds native tokens must carry a deposit in IOTA coins to compensate for the excessive resource usage.

---

Token Foundries

The creator of the user-defined token, referred to as the issuer, is in control of the Token Foundry and regulates the minting or burning activity of tokens that belong to the foundry.

Anyone can become an issuer and start minting their own tokens. Token foundries let issuers choose an appropriate supply control policy for their use cases. So, depending on the Token Scheme of the foundry, a native token in IOTA might have a dynamic, fixed, or capped total supply. More advanced schemes such as minting or burning flow control will be iteratively added to the framework as its implementation progresses.

The entity of the issuer may be a single address, a multi-signature address, a threshold multi-signature address with arbitrary participants and threshold, or a smart contract chain address. It is also possible to transfer issuer rights to other entities, but it is prohibited to change the supply control policy defined upon deployment of the foundry, allowing for an incredible variety of use cases that go far beyond a mere coloring of tokens, introduced earlier this year.

The transparency of the Tokenization Framework is of utmost importance to IOTA. Foundries produce tokens with a specific token ID that incorporates the globally unique identifier of the controlling foundry and some predefined token metadata, such as a name. Based on the token ID of a native token, it is possible to infer information about:

• Issuer defined token tags, such as name or ticker
• Issuer account information
• The token scheme, which is the supply control policy
• Circulating and maximum token supply
• Token metadata stored on-chain

There is no need for off-chain token registries; everything about a token can be documented and stored on-chain, directly inside the UTXO ledger of the Tangle. Issuers might choose to disclose their on-chain account publicly to increase the transparency of their tokens. Given a list of validated issuer identities that are linked to real-world identities, wallets can automatically determine the authenticity of any native tokens.

---

Non-Fungible Tokens

Token foundries are great for fungible tokens, but they might also produce non-fungible tokens (NFTs). A token foundry that defines maximum supply as 1 essentially controls only one token that is globally unique in the ledger; therefore, it is an NFT.

Most NFTs represent ownership of something unique, like a digital artwork or collectible. Therefore they must have a globally unique identifier and a description of the underlying asset. The latter is often encoded as metadata attached to the NFT. Ownership of the token means ownership of the metadata too.

A foundry-controlled native NFT can be transferred to any accounts on the ledger, but the on-chain metadata still resides in the foundry. Moreover, the issuer remains in control of burning the native NFT, not the actual owner. To mitigate the risks attached by an issuer being in control instead of the current owner, we added advanced support for NFTs in the Tokenization Framework with a dedicated NFT output type.

With their own output type, NFTs become first-class citizens in the IOTA ledger. Anybody can create an NFT that has:

• A globally unique identifier, assigned upon minting. This identifier also functions as a regular iota address, so your NFTs can own funds, native tokens or other NFTs.
• Immutably attached metadata describing the underlying asset of the token. Set on minting, it is not allowed to change for the whole lifetime of the NFT.
• Verified issuer address that may never change. The protocol ensures that an NFT with a verified issuer can only be created in a transaction that is cryptographically signed by the issuer.

Transacting with NFTs is feeless, like any other IOTA transaction, and the current owner is in full control of either transferring the token with the attached metadata or burning it. The NFT output was designed with smart contract interoperability in mind, therefore it is possible to send it as part of a smart contract request, for example, to deposit it to a smart contract chain as collateral or listing it for auction.

---

Smart Contract Tokenization

IOTA Smart Contracts are a layer 2 extension to the base ledger that makes the powerful world of smart contracts and ledger programmability a reality for IOTA. Smart contracts are executed in smart contract chains run by layer 2 validators. As smart contracts provide quasi-Turing complete programmability, they bring a plethora of complex tokenization schemes to life.

Indeed, most tokens on the market today are built via smart contracts. Each of them keeps and maintains a local ledger inside the smart contract that records who owns what. It offers rich functionality and composability. However, it also comes with a caveat for major blockchains: low performance and costly smart contract execution.

As a consequence, IOTA designed its smart contract platform to scale horizontally via parallel chains. This strategy however poses a significant challenge: how do smart contract chains communicate and transfer value between themselves? The answer is obvious: they rely on the Tangle and the Native Tokenization Framework to do the job.

---

Asset Wrapping

Not only is it possible to deposit native assets in smart contract chains, but the chains themselves can also act as issuers of native assets. Each smart contract therefore can issue native tokens that are transparently traceable back to the specific smart contract on the specific chain. This mechanism provides the foundation for trustless, guaranteed asset bridges across multiple chains.

A smart contract that handles layer 2 tokens (ERC-20 tokens for example) inside a chain can interact with core contracts to wrap layer 2 tokens into layer 1 native assets or unwrap native tokens that belong to the smart contract into their layer 2 representation. The asset-wrapping logic is provided by the chain virtual machine (VM); smart contracts just need to call the appropriate core contract on the chain to perform the operation.

An important property of this multi-layered tokenization approach is flexibility:

• Layer 2 smart contract tokens are fully programmable and customizable, but they come with possible smart contract execution fees.
• Layer 1 native tokens leverage the performance and security of the IOTA ledger; moreover, they do not incur any transfer fees.
• Smart contract tokens can be seamlessly wrapped into native tokens and vice-versa. IOTA Smart Contracts provide built-in support for developers.

The two token classes might be best understood through the metaphor of banks and cash. Smart contract chains are banks that offer a wide range of financial assets, IOUs, products and services (smart contract tokens) to those who have an account on the chain. The bank may choose to print cash (native tokens) representing the aforementioned assets, which then can circulate in the economy (layer 1, Tangle) independently of the control of banks.

---

Smart Contract Requests

Interacting with smart contract chains from regular layer 1 IOTA accounts is done via on-ledger requests sent to the chain’s layer 1 account. Such requests may carry native tokens or NFTs that are part of the request. A user might choose to deposit some native assets in a chain and command the chain to unwrap them in order to unlock their full potential.

Some possible use cases of native tokens in smart contracts:

• The chain owner decides to accept fees for running any smart contracts in a particular native token.
• A specific smart contract can only be executed if fees are paid with a given native token.
• A smart contract requires the deposit of a specific native token to unlock functionality for the user.
• Smart contract privileges are tied to the presence of a specific native token. Control rights are transferable instead of hard coding them into the smart contract.
• A gaming dApp accepts in-game items as NFTs from a verified issuer.

The above list is far from complete; rather it offers a sneak peek of what is possible with IOTA Smart Contracts and the native Tokenization Framework.

---

What's next?

With the release of the mainnet (Chrysalis) protocol specifications for smart contracts and tokenization, we enter an exciting period for IOTA. The specifications will guide us to implement the new protocol features and integrate them into the existing frameworks, client libraries, and developer tools.

Our first milestone is a Hornet-based testnet with the Tokenization Framework enabled. While we are getting there, work on integrating IOTA Smart Contracts with the new protocol has already begun.

We welcome the community and our partners to read through the proposed protocol changes and help us iterate the design by sharing their feedback and comments. Join the conversation on GitHub or engage with our team directly in the #digital-assets channel on our Discord.