Add string data to ERC1155

Hi All,

The boilerplate guides around ERC115 implementation have been fantastic. To implement the type of NFT I want, I need to add in a few short additional strings that should stay on-chain (over simply being accessible via uri).

I’m wondering if adding those fields via contract extension or using the _data fieId is better. In my case, I could see either working, but it seems embedding in the data field might be better given the contract’s compatibility with third-parties would be better.

As a specific use case, I would like to include an encrypted secret signed with the receivers public key (so that only receiver would be able to decrypt secret. I’m always intimidated by using open-data fields with no format because I’m left wondering if there is a more optimal approach. While there’s no required format, is there a recommended one?

Bonus question follow-up: is there any easy possibility of baking the above “encrypting secret with receivers public key” into an on-chain contract function? I guess the vulnerability with that would be if transaction gets reverted after secret is exposed?

Thanks in advance.

1 Like

Hi @Garrett_C,

Welcome to the community :wave:

It really depends on your use case.
Please note the data is not stored in the OpenZeppelin Contracts ERC1155 implementation. You would need to store this information when you extend ERC1155 if you wanted to be able to retrieve it.

For compatibility, you would want to make sure that you followed the EIP. I would think that making use of the data field when minting could be the way to go.

Also, storing data onchain is expensive, so you will want to minimize the amount of this that you do.

Curious to understand your use case.

You may want to look at not storing this information onchain due to cost. You could look at emitting an event, depending on how accessible the data needs to be.

For security, I assume you should encrypt off chain.

Whilst you could create a smart contract function to encrypt the data, it would depend on how you were connecting to the network (e.g. running your own node or using a third party provider) on how secure/insecure this may or may not be. It also depends on the value of the secret too.

Thanks Andrew, from all the posts I’ve seen I’m grateful you addressed mine because you are thorough.

Please note the data is not stored in the OpenZeppelin Contracts ERC1155 implementation. You would need to store this information when you extend ERC1155 if you wanted to be able to retrieve it.

Extending would break compatibility so I’ll aim for the data field approach. I wish I had been focused on this earlier on because it seems like this contract format doesn’t include enough on-chain support for preserving item/product ownership integrity given that it defers to URI and off-chain to define. Unless defined in the contract itself (like in your example with the sword and other objects), then the URI ends up having that say with limited/no cryptographic accountability - a key power of the blockchain.

Yep - encrypt off-chain is the only lightwieght since validators would be exposed to plaintext encrypted in an on-chain function.

1 Like

Hi @Garrett_C,

You can add custom data, but as it is not part of the standard, then only applications and services that support your custom data can use it. Which for the most part will only be your application.

Storing off chain whilst centralized is a lot less expensive when it comes to minting.

You could use decentralized storage for your metadata such as IPFS, so then you only need to store a hash onchain.