APP-4 Multi Token Standard

[HelloRWA]

title	description	author	app type
APP-4: Multi Token Standard	A standard interface for contracts that manage multiple token types	TG: HelloRWA	contract standard

---

Abstract

This standard outlines a smart contract interface that can represent any number of fungible and non-fungible token types. Existing standards such as APP-2(Token Standard) require deployment of separate contracts per token type. The APP-3(NFT Standard)'s token ID is a single non-fungible index and the group of these non-fungibles is deployed as a single contract with settings for the entire collection. In contrast, the APP-4 Multi Token Standard allows for each token ID to represent a new configurable token type, which may have its own metadata, supply and other attributes.

The _id argument contained in each function’s argument set indicates a specific token or token type in a transaction.

Motivation

Tokens standards like APP-2 and APP-3 require a separate contract to be deployed for each token type or collection. This places a lot of redundant code on the AO and limits certain functionality by the nature of separating each token contract into its own permissioned address. With the rise of blockchain games and platforms on AO, game developers may be creating thousands of token types, and a new type of token standard is needed to support them. However, APP-1155 is not specific to games and many other applications can benefit from this flexibility.

New functionality is possible with this design such as transferring multiple token types at once, saving on transaction costs. Trading (escrow / atomic swaps) of multiple tokens can be built on top of this standard and it removes the need to “approve” individual token contracts separately. It is also easy to describe and mix multiple fungible or non-fungible token types in a single contract.

Specification

Handlers

info (APP-1)

messages (APP-1)

balanceOf

• address: _owner
• uint256: _tokenId
• emit message: Success.balanceOf with uint256 _balance

balanceOfBatch

• address[]: _owners
• uint256[]: _tokenIds
• emit message: Success.balanceOfBatch with uint256 _balances[]

ownerOf

• uint256: _tokenId
• emit message: Success.ownerOf with address _owner

transfer

• address: _from
• address: _to
• uint256: _tokenId
• uint256: _value
• emit message: Success.transfer

batchTransfer

• address: _from
• address: _to
• uint256[]: _tokenId
• uint256[]: _value
• emit message: Success.batchTransfer

approve

• address: _approved
• uint256: _tokenId
• emit message: Success.approve

setApprovalForAll

• address: _operator
• bool _approved

isApprovedForAll

• address _owner
• address _operator
• emit message Success.isApprovedForAll with bool _approved

tokenURI

• uint256: _tokenId
• emit message: Success.tokenURI with string _uri

The returned uri should be a JSON file following the ERC-1155 metadata JSON schema.

Messages

Success

TransferSingle

• address: _operator
• address: _from
• address: _to
• uint256: _id
• uint256: _value

Approval

• address: _owner
• address: _approved
• uint256 _tokenId

ApprovalForAll

• address: _owner
• address: _operator
• bool: _approved

URI

• string: _value
• uint256: _id

Implementation

TBD