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.