Pattern for generating dynamic ERC-1155 or ERC-721 metadata

Question

I am quite new to smart contract development so apologies in advance if this seems like a silly question.

I'm looking for some guidance on a usable pattern for the following use case.

I need to dynamically generate an ERC-1155 token's metadata upon minting (1 of several random images, stats etc). The metadata needs to also be able to change based off on-chain interactions. I'm struggling to think of a way to do it on the blockchain given my lack of experience.

As I understand it, I may need to leverage the use of oracles and IPFS? Possibly a custom server (which I would prefer to avoid if at all possible to keep things as non-custodial as possible)?

Is there a standard pattern for this sort of use case?

My initial thinking is:

1. Factory contract uses oraclize to generate random number stats.
2. TokenURI points to a custom server that receives stats via URI params.
3. Token is minted with this URI.
4. Custom server generates JSON metadata and returns it when that URI is called.

This will keep the necessary on-chain data and off-chain metadata in sync. If on-chain stats change then so too will the JSON returned from the URI.

Would this be considered an acceptable pattern?

Answer 1

The approach of using an IPFS address as the token URI is intended to ensure its immutability, since the generated hash within the IPFS address will be unique for the file you are pointing to.

In your case, if you need to dynamically change contents in the metadata, the URI can be pointing to an https file that you can update at any time. However, in my understanding, you lose the concept of immutability or even worst -if the site is attacked, you can be showing tampered data.

Just one precision: if you are referring to ERC1155, the URI is passed in the constructor when you create the NFT and remains unchangeable. Therefore, when you mint tokens for that NFT, the URI remains the same (which is different to ERC721, in which you pass the URI for every new NFT).

One alternative could be saving your dynamic data also in a smart contract, where you would have a mapping between the NFT and the additional information. In this case, you need to estimate how often you will update data and its associated cost of doing this on-chain.

The approach you take will depend on your needs: if you are talking about a unique collectible cards, you should be using an IPFS-like method to ensure immutability. On the other hand, if the tokens can have dynamic metadata, you might be pointing to external data (off-chain) that you will manage accordingly.