You must have heard about cryptocurrency tokens. Various tokens out there play a vital role in the web3 ecosystem. These tokens represent ownership, wealth, credibility, and authority in cryptocurrency. The fun part is that you can also make your cryptocurrency token. 

These tokens are smart contracts involving various functions for various actions like transfer, balance checking, etc. You can make your token by creating a smart contract for it. Still, to ensure that your token is safe and attach a sense of trust to it, ERC 20 is the smart contract standard that is advised to be followed to create fungible tokens, and ERC 721 is the smart contract standard which is used to create non-fungible tokens(NFTs).

ERC 20 and ERC 721 are widely accepted smart contract protocols for token creation. They provide a safe and trustworthy environment for the tokens. And these protocols keep on improving and keep getting better. A step in that direction leads to the creation of a new ERC 1155 smart contract protocol for tokens. Let’s see what it is.

1. What is ERC 1155?

All ERCs, like 20 and 721, are just standards for creating smart contracts which fit different circumstances for NFTs. We have ERC 721, and fungible tokens like USDT and DAI follow ERC 20 standards. ERC 1155 is one standard involving ERC 20 and ERC 721 functions and properties.

Suppose you want to create a programme where you create multiple commodities. For example, you want to create a token named gold, another token named silver and one king, and the logic says the one with more gold and silver will be the king. There can only be one king. It is a simple protocol, but to create this, you will have to deploy 3 contracts just for assets, one for a gold token, another for silver and one for the king, which will be ERC 721. But what if you can deploy just one contract listing all those different tokens?

This is one such problem ERC 1155 solves. You do not need to deploy a contract for each one of the tokens you want on the blockchain. This was one such ERC 1155 contract example. Guess where we need this type of system with multiple assets, some fungible, some non-fungible. The answer is web3 games. ERC 1155 empowers Web3 game developers with scalability and smooth development for on-chain transactions.

1.1 Token IDs in ERC 1155

You must be aware of how the balance in different ERC 20 tokens can be checked, you can just call balanceOf(address _owner) function, and you can get how many tokens that address holds. But ERC 1155 deals with different tokens, so we need to provide different IDs to different tokens. Almost every function related to tokens takes into at least two parameters the tokenId(asset you want to enquire about) and the address about which you want to know.

For example, let’s say the contract has 3 tokens, gold, silver, and king. To know how much gold a particular address has in that protocol, you can call upon the function balanceOf(address _owner, uint256 _id) on the smart contract. Suppose the tokenId for gold is specified to be 1. Then you can call on balnceOf(0x4Bf9DeCE75Bc7C4a9054d5b3BB13D53543eE4096, 1).

2 Audit Guidelines for smart contract ERC 1155

ERC 1155 has been around for some time, and some features are not available in the regular ERC 20 or ERC 721 protocol, like batch transfer. Also, ERC 1155 is less prevalent in the market space, thus making this area a little less explored for many developers. QuillAudits shares crucial insights for the protocols looking to BUIDL on the ERC 1155, so they can help create a safer web3 ecosystem by safeguarding themselves. 

2.1 ERC 1155 Receiver Interface

When our ERC 1155 contract transfers assets to some other contract which is generally a requirement in web3 game protocol, it is IMPORTANT to have the ERC1155Receiver Interface in the receiving contract for successful transaction of the tokens.

Two functions which come under the ERC 1155 Receiver Interface are:-

• onERC1155Received(operator, from, id, value, data)
• onERC1155BatchReceived(operator, from, ids, values, data)

Both functions have almost similar functionality, the only difference being that the latter is when we are dealing with more than one transaction at a time, thus the name batch, there is a slight difference between the params and return values. But here we will only talk about onERC1155Recieved. 

This function MUST NOT be called outside of a mint or transfer process. To accept the transfer, it must return bytes4(keccak256(“onERC1155Received(address,address,uint256,uint256,bytes)”)) if the transfer is allowed.

Looking at the parameters:-

1. operator:- The address which initiated the transfer (i.e. msg.sender) 
2. from:- The address which previously owned the token
3. id:- The ID of the token being transferred 
4. value:- The number of tokens being transferred 
5. data:- Additional data with no specified format 

2.2 No approve() function?

If you ever worked with ERC 20 or ERC 721, you would have come across the approve() function, which permits some address to take the approved tokens from the owner’s balance. For example, if A wants to approve B of taking 100 tokens of DAI, then A can call on the approve function, saying that B is entitled to 100 DAI tokens, and later, B can do a transaction with that amount.

But ERC 1155 does not have an approve function for a single token. We have a setApprovalForAll(address operator, bool approved) function, which is called by the owner and takes in an address parameter operator, which is the address of the spender or the one we want to approve our tokens to. So, we cannot call an approve function or grant approval for a single token from our ERC 1155 list of tokens, but instead, all of the token access will be approved at once. The development team needs to be aware of this. If ignored, this can lead to massive losses and compromise the protocol.

2.3 Some Regular Checks

The above two sections explored two of the unique ERC 1155-related checks. In this section, we will go through some regular checks which do not need a very deep explanation.

1. Mind the IDs:- Every external function or interface that works with the ERC 1155 needs to have the token ID specified to take that as input.
2. Burn/Mint:- Whenever these functions are called, they must only alter the balance and totalSupply for the specified token Id.
3. ERC 20 resemblance:- Many properties are like ERC 20 token standard. Going through the security guidelines for ERC 20 will also help in this matter.
4. Re-entrance:- As discussed, ERC 1155 checks for supported interface in the transfer logic. Thus there can be various scenarios which may result in re-entrance vulnerability. It is advised to keep non-reentrancy guard modifiers on the applicable functions.

3. Conclusion

Web3 ecosystem sees continuous development in regular standards to enhance security and functionality. ERC 1155 is a step in that direction. But when the new standards are released, it creates a knowledge gap involving not-so-very-common standards in protocols and comes with a risk of smaller sample space for security measures. This is when QuillAudits come into the picture with a team of experts. We tackle, analyse, and find different ways the protocol may be compromised and secure our clients’ protocol with unbelievable results. Do visit our website and get your Web3 project secured!