3. Tokenization standard

Standard fungible tokens that fill the same niche as the ERC-20 does on Ethereum are defined by the MLS-01 standard on Mintlayer. MLS-01 represents the most basic form of token on the chain, and due to the simplicity of the UTXO architecture in Mintlayer, they are significantly more straightforward to create than a token on competing chains where a contract written in a language like Solidity is required. Any token following the MLS-01 standard should be compatible with any Mintlayer wallet.

An MLS-01 has several associated features, including a ticker, an amount to issue, an amount of decimals for the issuance amount, and a metadata uri. A token will also support features such as increasing the circulating supply, blocking the circulating supply from ever being increased, and being associated with an access control list, sometimes called a whitelist, which will allow for an entity issuing a token to enforce KYC, AML or any other financial regulations over their token, it is possible to have similar functionality by using multi sigs and requiring cosigning of transactions with the whitelisting checks happening off-chain. MLS-01 tokens on Mintlayer are directly usable on the Lightning Network to allow for speedy token transactions.

   pub struct TokenIssuance {
      pub token_ticker: Vec<u8>,
      pub amount_to_issue: Amount,
      pub number_of_decimals: u8,
      pub metadata_uri: Vec<u8>,
   }

Non-fungible tokens, often called NFTs, are implemented via the MLS-03 standard on Mintlayer. As with NFTs on other chains, they represent a unique token. They function much the same as MLS-01 tokens without the need to handle a supply since only one exists. An NFT does, however, have some extra data associated with it: a creator, a name, a description, an icon, a media hash, and a media URI.

   pub struct Metadata {
      pub creator: Option<TokenCreator>,
      pub name: Vec<u8>,
      pub description: Vec<u8>,
      pub ticker: Vec<u8>,
      pub icon_uri: DataOrNoVec<u8>,
      pub additional_metadata_uri: DataOrNoVec<u8>,
      pub media_uri: DataOrNoVec<u8>,
      pub media_hash: Vec<u8>,
   }

So far, we have jumped from MLS-01 to MLS-03 and skipped MLS-02. The MLS-02 standard represents a similar token to MLS-01 but with the added benefit and complexity of being a privacy-focused token that allows for zero-knowledge based private transactions.

3.1. UTXO structure

Mintlayer uses a Bitcoin-esque UTXO structure instead of the account-based models of Ethereum, Ripple, Stellar, or others. From a certain point of view, the UTXO model is less efficient than the account base: since each transaction’s output is stored separately (even when sent to a single address), it is only possible to spend the entire transaction’s output. Therefore, most transactions require change, creating what is commonly referred to as “dust” - smaller outputs that are costly to transfer, given the fee’s weight over the transaction volume. Despite this, the UTXO model has been chosen because of three essential features:

  1. It is compatible with technologies already implemented in Bitcoin, such as the atomic swap and Lightning Network.
  2. It is more privacy-oriented because a single wallet usually utilizes multiple addresses, making it difficult and sometimes impossible to distinguish which ones belong to the same user.
  3. Payments can be batched together (aggregated) in a single transaction, saving a considerable amount of the space otherwise required for making a single transaction per payment.

3.2. Atomic Swaps

An atomic swap transaction generally allows two users to exchange tokens between blockchains. On Mintlayer, this will be between the Bitcoin sidechain and an asset on the Mintlayer chain.

  1. User A creates a transaction, sending an amount of BTC to user B. The transaction output has some specific conditions:

    1. B can grab the coins within a specific timeframe (about 24 hours - 144 Bitcoin blocks). Otherwise, the transaction is reverted. This clause ensures that A does not lose money if the exchange does not happen.
    2. B’s only condition to spend those coins within 24 hours is to claim them before A, which is possible only if B knows a “secret” X revealed by A himself.

    B does not know the secret X, but A sends the result of a hash function of that secret h(x) to B.

  2. User B creates a transaction, sending USDT to user A in exchange for the BTC. The transaction output has some specific conditions:

    1. A can grab the coins within a specific timeframe (about 12 hours). Otherwise, B can get his coins back.
    2. The only condition that allows A to spend those coins within 12 hours is to reveal the secret. The “key” to unlock the transaction output is the secret x.

A must reveal X to grab the coins sent by B and has about 12 hours to do so. Once A grabs the coins, B knows the secret X and can take the BTC sent by A.

Even if A reveals the secret at the last hour (12th), B has an additional 12 hours to take the BTC sent by A since the lock time for the first transaction’s output is 24 hours instead of 12.

If A does not reveal the coins, both users will get back their assets within 12 and 24 hours, respectively. If everything goes as expected, both users will receive the coins in the first blocks validated on the respective chain (Bitcoin and Mintlayer).

The only flaw of a traditional cross-chain atomic swap is that the timelock (nLockTime parameter on Bitcoin) cannot be reliable as one of the blockchains may remain behind due to block production rate variability. Possible reorganizations or other factors may also come into play, depending on the specific blockchain structure and rules.

Moreover, if one of the transactions involved in the atomic swap has relatively lower fees, the user might not be able to spend the output before the lock time expires. It may even invalidate the swap, leading to a loss of funds for that user while the counterpart grabs all the coins on both chains.

Mintlayer bypasses these issues by introducing the first reliable cross-chain Bitcoin atomic swap. Since it is structured as a Bitcoin sidechain, each Mintlayer block carries a reference to the Bitcoin blockchain. The nLockTime of the two transactions returning the coins to the sender is calculated in the exact number of Bitcoin blocks counted on both chains.

Moreover, the wallet also provides the CPFP (child pays for parent) functionality, speeding up the atomic swap transaction if it is stuck in the mempool due to too low fees. For example, the wallet can collaborate with a watchtower (even controlled by the user himself or by a service provider/oracle) to notify the user when the transaction spending output is late and suggest a proper CPFP transaction fee amount.

The atomic swap technology is at the base of the concept of a decentralized exchange.

3.3. Transaction fees

The default fee for any transaction on Mintlayer is set to ML unless the user chooses otherwise. A user can, however, use an MLS-01 token on the Mintlayer blockchain to pay their transaction fee. A block producer then has the ability to select which transactions from the mempool to put in the block they’re producing, meaning they can choose to accept or not accept a transaction with a fee paid in any given token.

The network participants that need to calculate the fee value (i.e., to choose which transaction is more convenient, in case the chain is saturated) will query data prices from a centralized exchange (using API) or DEX oracles.

When preparing a transaction, the wallet UI suggests a fee amount for each token based on an algorithm that analyzes the Mintlayer’s mempool and past transactions.


Next: Decentralized finance