ERC1155 - Questions about ID, _data (or lack thereof) and onchain data

Support Contracts
1

Hi there,

I came across this forum while researching NFT standards and wanted to ask or at least firm up my understanding of a few things regarding the differences/capabilities of the standard and these contracts in general.

I have read through the other posts on here and I can understand the limitation but wanted to get peoples opinions on some ideas I had for onchain data and general minting rules.

Minting a token - Happy Path

As we see generally minting a token in an ERC1155 will give you back an id. (0x01) lets say. So this is ID of one type of contract and a qty of 1.

In this case I can have multiples minted of ID=0x01 and these can be assigned to multiple addresses?

Minting a token - single item per ID

How then to only have one ID=0x01 NFT issues? These are preminted with a total of 1?

Minting tokens - Where we have some uniqueness

I have seen some NFT examples where they place some constants in the contract to describe the ID types (card types for example, special, legendary etc). This would be good if all those cards were idempotent/similar stats/details so the ID resolves to a common JSON metadata file they all share.

What then if you wanted to say:

  1. Have some uniqueness in the stats off chain?
  2. Have some uniqueness in the stats on chain?

In this I mean, perhaps you generate a class of card (special card10) and then you have some element of random stats given to that card (XP boosts etc). At this point I think you are going to have to create a unique ID for each and every card in your universe?

Now the ID space is a 64 bit hex number so there are plenty in there so I think that would fine.

Would any issues come using such large numbers when packing and sending them onto other addresses or is the O(1) lookup and searching happening in the code here? There is no time costs to larger and larger IDs?

In the case of stats on chain, how best to store that? Say you wanted to store 4-6 values on the NFT on chain for some use in a smart contract in such a way the JSON metadata is not a possibility? Would you store that in the same NFT as an array to ID mapping or would you embed it in the ID using some kind of bitwise shift? (Top 3/4 of the ID are the monotonically incrementing ID counter and the bottom 1/4 is the array of stats in 4byte blocks or something).

summary

I hope these questions make sense, I’m trying to understand how the universe of NFTs can be generated and stored, any performance considerations along side using them.

And also, some on-chain data storage for pertinent data that we would like to have on-chain attached to an NFT, how best would that be achieved in a clear and concise manner that isn’t too costly.

1 Like
2

Yes, you can mint the same id again.

You can enforce this in your contract by overriding _mint. It's currently not super easy because ERC1155 doesn't have a totalSupply function that you could use to check supply remains at most 1. But keep an eye on https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2593 for the totalSupply function that will be released soon.

1 Like
3

There are no time costs to larger ids. The base cost of a transaction will be slightly more expensive, because sending non-zero bytes to the network in a transaction is more expensive than zero bytes.

If you can embed it in the id, that would be the best option. Otherwise, you will need to use additional storage and have a public function to query the data.

1 Like
4

Thanks @frangio

It’s kind of how I imagined it would work then.

One of the uses of this is to make the NFT usable in other situations and packing the ID seems like the most portable solution and doesn’t add any new depdenencies on my contract API so I can use plain ERC1155 interfaces.

The new api calls might be nice actually as well, whats eta/release version for these?

On the receiver side then say a SC that will implement the ERC1155 Receiver interfaces it can have the NFT transferred to it, decode the ID and unpack/unshift any pertinent info it needs.

Is anyone doing this out in the wild? Or would ERC721 be a better vehicle to use here? I feel ERC1155 seems more adaptable in terms of the randomness and making larger transfers (of 5-6 NFTs at a time) more efficient. It just seems its just not a popular a standard and not being used as widely yet.

Thanks again, I really appreciate the answers.

1 Like
5

Next release should include them!

I'm not sure if anyone is doing what you're suggesting. ERC721 is certainly more popular but ERC1155 also seems relatively well suported.

1 Like