Introduction to ERC 1155 Token standard.

Ethereum
#1

ERC1155 is NFT contract standard that can be used to make both fungible and non fungible tokens, which helps us to have single smart contract to represent multiple tokens. The distinguishing feature of ERC 1155 from ERC20 and ERC777 is id argument, which keeps track of balance of specific token.
ERC721 also has id argument but it has no concept of balance of a specific token, It can only tell if a token exists or not. The ERC721 balanceOf function refers to how many different tokens an account has, but not the amount of specific tokens an account contains. In contrast, in ERC1155 accounts have a distinct balance for each token id, and non-fungible tokens are implemented by simply minting a single one of them.
For projects that require multiple tokens, this approach results in significant gas savings. In spite of deploying a new contract for every token type, an ERC1155 token contract can hold the entire system state, reducing the cost of deployment and complexity.
As all states are held in a single contract, which makes it possible to operate over multiple tokens in a single transaction in an efficient manner. The standard provides two functions, balanceOfBatch and safeBatchTransferFrom, which makes querying multiple balances and transferring multiple tokens simpler and less gas-intensive.

ERC 1155 tokens can be used to track physical assets such as limited edition cars, with all of their information stored on the blockchain and verifiable without the need for human intervention. Other potential use cases for ERC-1155 are in the gaming, collectibles, and metaverse industries. With the ability to support both fungible and non-fungible assets, ERC-1155 could be used to create and manage virtual assets, such as houses, clothes, weapons, armor, cars, and other collectibles. Users could then trade these items directly on the blockchain without having to go through a centralised exchange, making the process more efficient and secure.

ERC-721 vs. ERC-1155

The ERC-1155 token standard could see more prominent use than the ERC-721 token standard in the near future because of its additional features. Both allows the user to mint new NFTs, but there are some key differences:

  • ERC-1155 permits the creation of both fungible tokens and non-fungible tokens, whereas ERC-721 permits only the latter.
  • In ERC-1155, smart contracts are linked to multiple URIs and do not store additional metadata (such as file names). In comparison, ERC-721 only supports static metadata stored directly on the smart contract for each token ID, increasing deployment costs and limiting flexibility.
  • ERC-1155’s smart contract support infinite number of tokens, whereas ERC-721 requires a new smart contract for every type of token.
  • ERC-1155 also allows batch transfers of tokens, which can reduce transaction cost and time. With ERC-721, if user want to send multiple tokens, the transfer takes place one by one manually by the user.

ERC 1155 Token Standard

Official Link to ERC 1155 Token Standard.

Smart contracts implementing the ERC-1155 standard MUST implement all of the functions in the ERC1155 interface.

Smart contracts implementing the ERC-1155 standard MUST implement the ERC-165 supportsInterface function and MUST return the constant value true if 0xd9b67a26 is passed through the interfaceID argument.

interface ERC1155 {  
/*`TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see "Safe Transfer Rules" section of the standard).  
*/  
event TransferSingle(address indexed _operator, address indexed _from, address indexed _to, uint256 _id, uint256 _value);

/*`TransferSingle` or `TransferBatch` MUST emit when tokens are transferred, including zero value transfers as well as minting or burning (see "Safe Transfer Rules" section of the standard).  
*/  
event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values);

/* MUST emit when approval for a second party/operator address to manage all tokens for an owner address is enabled or disabled (absence of an event assumes disabled).  
*/  
event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

/* MUST emit when the URI is updated for a token ID.  
URIs are defined in RFC 3986.  
The URI MUST point to a JSON file that conforms to the "ERC-1155 Metadata URI JSON Schema".  
*/  
event URI(string _value, uint256 indexed _id);

/* Transfers `_value` amount of an `_id` from the `_from` address to the `_to` address specified (with safety call).  
*/  
function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;

/* Transfers `_values` amount(s) of `_ids` from the `_from` address to the `_to` address specified (with safety call).  
*/  
function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;

/* Get the balance of an account's tokens.  
*/  
function balanceOf(address _owner, uint256 _id) external view returns (uint256);

/* Get the balance of multiple account/token pairs  
*/  
function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);

/* Enable or disable approval for a third party ("operator") to manage all of the caller's tokens.  
*/  
function setApprovalForAll(address _operator, bool _approved) external;

/* Queries the approval status of an operator for a given owner.  
*/  
function isApprovedForAll(address _owner, address _operator) external view returns (bool);  
}

Smart contracts MUST implement all of the functions in the ERC1155TokenReceiver interface to accept transfers.

Smart contracts MUST implement the ERC-165 supportsInterface function and signify support for the ERC1155TokenReceiver interface to accept transfers.

interface ERC1155TokenReceiver {  
/* Handle the receipt of a single ERC1155 token type.  
An ERC1155-compliant smart contract MUST call this function on the token recipient contract, at the end of a `safeTransferFrom` after the balance has been updated.  
*/  
function onERC1155Received(address _operator, address _from, uint256 _id, uint256 _value, bytes calldata _data) external returns(bytes4);

/* Handle the receipt of multiple ERC1155 token types.  
An ERC1155-compliant smart contract MUST call this function on the token recipient contract, at the end of a `safeBatchTransferFrom` after the balances have been updated.  
*/  
function onERC1155BatchReceived(address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external returns(bytes4);  
}

Recommendations for writing ERC1155 Contract.

Safe Transfer Rule

Some of recommended rules for safe transfer :

  1. The caller must be approved to spend the tokens for the _from address or the caller must equal _from.
  2. The transfer call must revert if
  3. _to address is 0.
  4. length of _ids is not the same as length of _values.
  5. any of the balance(s) of the holder(s) for token(s) in _ids is lower than the respective amount(s) in _values sent to the recipient.
  6. any other error occurs.

Minting/creating and burning/destroying rules:

• A mint/create operation is essentially a specialized transfer and MUST follow these rules:

  • To broadcast the existence of a token ID with no initial balance, the contract SHOULD emit the TransferSingle event from 0x0 to 0x0, with the token creator as _operator, and a _value of 0.
  • The “TransferSingle and TransferBatch event rules” MUST be followed as appropriate for the mint(s) (i.e. singles or batches) however the _from argument MUST be set to 0x0 (i.e. zero address) to flag the transfer as a mint to contract observers.
    NOTE: This includes tokens that are given an initial balance in the contract. The balance of the contract MUST also be able to be determined by events alone meaning initial contract balances (for eg. in construction) MUST emit events to reflect those balances too.

In the spirit of the standard, we could also included batch operations in the non-standard functions, such as _mintBatch. also it is recommend to use onlyOwner or similar access control modifiers to control unauthorised minting of tokens.

ERC1155 Token Contract Vulnerabilities

ERC 1155 Token is a relatively safe contract that have many added security features than prevous standards like ERC721 which don’t have the facility for reclaiming your assets if you transferred them to the wrong address. On the contrary, the ERC-1155 token standard offers a unique feature known as the ‘safe transfer’ function. The safe transfer function is a product requirement for evaluating a transaction’s validity and also enables hassle-free token transfers.

But still there are few things that can be taken care when writing a ERC1155 token contract that are same as ERC 20. visit : ERC20 Token Contract Vulnerabilities

Refrences

[1] EIP-1155: Multi Token Standard.
[2] ERC20 Token Contract Vulnerabilities

2 Likes