Abstract

This standard introduces a smart contract interface that can represent a batch of non-fungible tokens of which the ordering information shall be retained and managed. Such information is particularly useful if tokenIds are encoded with the sets of unicodes for logographic characters and emojis. As a result, NFTs can be utilized as carriers of meanings.

Motivation

Non-fungible tokens are widely accepted as carriers of crypto-assets, hence in both ERC-721 and ERC-1155, the ordering information of multiple NFTs is discarded. However, as proposed in EIP-3754, non-fungible tokens are thought of as basic units on a blockchain and can carry abstract meanings with unicoded tokenIds. Transferring such tokens is transmitting an ordered sequence of unicodes, thus effectively transmitting phrases or meanings on a blockchain.

A logograph is a written character that represents a word or morpheme, examples include hanzi in Mandarin, kanji in Japanese, hanja in Korean, and etc. A unicode is an information technology standard for the consistent encoding, representation, and handling of texts.

It is natural to combine the two to create unicoded NFTs to represent logographic characters. Since a rich amount of meanings can be transmitted in just a few characters in such languages, it is technically practical and valuable to create a standard for it. Emojis are similar with logographs and can be included as well. For non-logographic languages such as English, although the same standard can be applied, it is tedious to represent each letter with an NFT, hence the gain is hardly justifiable.

A motivating example is instead of sending the two Chinese characters of the Great Wall 长城, two NFTs with IDs #38271 and #22478 respectively can be transferred in a batch. The two IDs are corresponding to the decimal unicode of the two characters. The receiving end decodes the IDs and retrieves the original characters. A key point is the ordering information matters in this scenario since the tuples (38271, 22478) and (22478, 38271) can be decoded as 长城 and 城长, respectively, and both are legitimate words in the Chinese language. This illustrates the key difference between this standard and ERC-1155.

Besides, in the eastern Asian culture, characters are sometimes considered or practically used as gifts in holidays such as Spring Feastival, etc. (24685, 21916, 21457, 36001) 恭喜发财 can be used literally as a gift to express the best wishes for financial prosperity. It is therefore cuturally natural to transfer tokens to express meanings with this standard.

Also in logographic language systems, ancient teachings are usually written in concise ways such that a handful of characters can unfold a rich amount of meanings. Modern people now get a reliable technical means to pass down their words, poems and proverbs to the future generations by sending tokens.

Other practical and interesting applications include Chinese chess, wedding vows, family generation quotes and sayings, funeral commendation words, prayers, anecdotes and etc.

Specification

pragma solidity ^0.8.0;

/**
    @title EIP-4341 Multi Ordered NFT Standard
    @dev See https://eips.ethereum.org/EIPS/eip-4341
 */
interface ERC4341 /* is ERC165 */ {
    event Transfer(address indexed from, address indexed to, uint256 id, uint256 amount);

    event TransferBatch(address indexed from, address indexed to, uint256[] ids, uint256[] amounts);

    event ApprovalForAll(address indexed owner, address indexed operator, bool approved);

    function safeTransferFrom(address from, address to, uint256 id, uint256 amount, bytes calldata data) external;

    function safeBatchTransferFrom(address from, address to, uint256[] calldata ids, uint256[] calldata amounts, bytes calldata data) external;

    function safePhraseTransferFrom(address from, address to, uint256[] calldata phrase, bytes calldata data) external;

    function balanceOf(address owner, uint256 id) external view returns (uint256);

    function balanceOfPhrase(address owner) external view returns (uint256);

    function balanceOfBatch(address[] calldata owners, uint256[] calldata ids) external view returns (uint256[] memory);

    function retrievePhrase(address owner, uint256 phraseId) external view returns (uint256[] memory);

    function setApprovalForAll(address operator, bool approved) external;

    function isApprovedForAll(address owner, address operator) external view returns (bool);
}

Rationale

In ERC-1155 and ERC-721, NFTs are used to represent crypto-assets, and in this standard together with EIP-3754, NFTs are equipped with utilities. In this standard, the ordering information of a batch of NFTs is retained and managed through a construct phrase.

Phrase

A phrase is usually made of a handful of basic characters or an orderred sequence of unicodes and is able to keep the ordering information in a batch of tokens. Technically, it is stored in an array of unsigned integers, and is not supposed to be disseminated. A phrase does not increase or decrease the amount of any NFT in anyway. A phrase cannot be transferred, however, it can be retrieved and decoded to restore the original sequence of unicodes. The phrase information is kept in storage and hence additional storage than ERC-1155 is required.

Backwards Compatibility

EIP-3754 is the pre-requisite to this standard.

Reference Implementation

https://github.com/simontianx/ERC4341

Copyright

Copyright and related rights waived via CC0.