MLD-404: Semi-fungible tokens

MLD-404 is a duplicate of ERC-404, a new unofficial smart contract standard designed by the Pandora team. It aims to merge the characteristics of MLD-20 (fungible tokens) and MLD-721 (non-fungible tokens or NFTs) into a single standard. This standard enables the creation of digital assets that can function both as fungible tokens for use cases such as staking or trading, and as unique non-fungible token to represent unique ownership.

When a user buys a certain amount of MLD-404 tokens or receives them from another wallet, the contract not only updates the balance of fungible tokens but can also mint a unique MLD-721 NFT to the recipient. This NFT could represent a special right, membership, or ownership over a part of a unique asset associated with the fungible tokens. Conversely, selling or transferring the fungible tokens could trigger the transfer of associated NFTs, ensuring that ownership rights are correctly maintained and transferred alongside the fungible token balances.

Key features of MLD-404 include:

  • Hybrid Nature: While MLD-20 focuses on fungible tokens (identical and interchangeable) and MLD-721 on non-fungible (unique and not interchangeable), MLD-404 utilizes both types of token standards, allowing both fungible and non-fungible functionalities within the same smart contract. This functionality is similar to the already existing MLD-1155 standard, which also enables the same type of token operations from a single contract.

  • Native Fractionalization of NFTs: Unlike standard MLD-721, where an NFT represents a whole, indivisible asset, MLD-404 introduces native support for fractional ownership of NFTs. This means users can own a part of an NFT, enhancing liquidity and accessibility for high-value assets.

  • Enhanced Liquidity: By allowing fractional ownership, MLD-404 overcomes one of the main limitations of traditional NFTs—their lack of liquidity. It enables smaller investors to participate in the ownership of high-value assets and facilitates easier trading on exchanges.

  • Dynamic Functionality: MLD-404 tokens can act as either fungible or non-fungible assets depending on the transaction context. For example, when buying or receiving tokens from another user, the contract can automatically allocate MLD-721 NFTs to represent specific ownership rights or achievements while also handling fungible token transactions seamlessly.

MLD-404 Functions​

The MLD-404 introduces a set of functions that allow for the nuanced handling of both fungible and non-fungible token aspects within a single contract. Let's explain each function and component within the MLD-404 contract:

OWNER, SPENDER, AND OPERATOR

Before discussing the functions of the MLD-404 contract, let's define some key terms and roles to avoid confusion:

Owner: The entity or address that holds ownership of the tokens. In the context of NFTs (MLD-721 tokens), the owner possesses a unique token. For fungible tokens (MLD-20), the owner holds a certain quantity of the tokens.

Spender: An address that has been granted permission by the owner to transfer a specified amount of the owner's fungible tokens (MLD-20) or a specific NFT (MLD-721) on their behalf.

Operator: An entity or address given approval by the owner to manage all of their tokens, both fungible and non-fungible. This role is broader than that of a spender, as it can encompass management of all the owner's assets within a contract.

Events:​

  • MLD20Transfer: Emitted when a fungible token transfer occurs.

  • Approval: Indicates approval of a spender to withdraw tokens on behalf of the owner.

  • Transfer: Emitted for both MLD-20 and MLD-721 transfers, indicating a token's transfer.

  • MLD721Approval: Similar to Approval, but specifically for MLD-721 token IDs.

  • ApprovalForAll: Emitted when an owner approves an operator to manage all their tokens.

Errors:​

  • NotFound: Indicates a query for a non-existent token ID.

  • AlreadyExists: Thrown if attempting to mint a token with an ID that already exists.

  • InvalidRecipient: Used when a transfer is attempted to the zero address or an otherwise invalid recipient.

  • InvalidSender: Thrown if the sender is not authorized or valid.

  • UnsafeRecipient: Indicates that a recipient contract cannot handle MLD-721 tokens.

Metadata:​

  • name: The name of the token.

  • symbol: The symbol of the token.

  • decimals: Used for fungible tokens to define the smallest unit.

  • totalSupply: The total supply of fungible tokens.

  • minted: Counter for minted tokens, ensuring unique IDs for NFTs.

Mappings:​

  • balanceOf: Maps an address to its balance of fungible tokens.

  • allowance: Maps an owner to an operator and the number of tokens they're allowed to spend.

  • getApproved: Maps a token ID to an approved address for that specific token.

  • isApprovedForAll: Maps an owner to an operator for approval across all tokens.

  • _ownerOf: Internal mapping of token IDs to their owners.

  • _owned: Maps an address to an array of token IDs they own.

  • _ownedIndex: Keeps track of the index of each token ID in the _owned array.

  • whitelist: Maps addresses that are whitelisted from minting or burning tokens.

Constructor:​

Initializes the contract with the name, symbol, decimals, total supply of fungible tokens, and the contract owner.

Functions:​

  • setWhitelist: Allows the contract owner to whitelist addresses, preventing them from minting or burning tokens while transferring tokens.

  • ownerOf: Returns the owner of a specified token ID.

  • tokenURI: (Abstract Function) Should be implemented to return the URI for a token's metadata.

  • approve: Allows a token owner to approve another address to spend a specific amount or token ID on their behalf.

  • setApprovalForAll: Enables or disables approval for an operator to manage all of the caller's tokens.

  • transferFrom: Facilitates the transfer of fungible tokens or a specific NFT from one address to another.

  • transfer: Allows for the transfer of fungible tokens from the caller's address to another.

  • safeTransferFrom (with and without data): Similar to transferFrom but includes checks to ensure the recipient can safely receive NFTs.

  • _transfer: Internal function that handles the logic of transferring fungible tokens, including potential minting or burning of NFTs based on the transferred amount.

  • _getUnit: Returns the unit used for fractional transfers, typically 10^decimals.

  • _mint: Mints a new token ID to a specified address.

  • _burn: Burns the specified token ID from a given address.

  • _setNameSymbol: Allows updating the token's name and symbol.

PreviousMLD-1155: Multi-token standardNextMDL-6551: Token Bound Accounts

Last updated