DCIPs/EIPS/eip-4341.md

---
eip: 4341
title: Ordered NFT Batch Standard
description: The ordering information of multiple NFTs is retained and managed
author: Simon Tian (@simontianx)
discussions-to: https://github.com/ethereum/EIPs/issues/3782
status: Stagnant
type: Standards Track
category: ERC
created: 2021-10-01
---

## 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](./eip-721.md) and [ERC-1155](./eip-1155.md), the ordering information of 
multiple NFTs is discarded. However, as proposed in [EIP-3754](./eip-3754.md), 
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](https://en.wikipedia.org/wiki/Logogram)** 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](https://en.wikipedia.org/wiki/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](./eip-1155.md).

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](./eip-1155.md) and [ERC-721](./eip-721.md), NFTs are used to represent
crypto-assets, and in this standard together with [EIP-3754](./eip-3754.md), 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](./eip-1155.md) is required.

## Backwards Compatibility
[EIP-3754](./eip-3754.md) is the pre-requisite to this standard.

## Reference Implementation
https://github.com/simontianx/ERC4341

## Copyright
Copyright and related rights waived via [CC0](../LICENSE.md).