Ordered NFT Batch Standard
Video
Original
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 tokenId
s 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 tokenId
s. 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.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all