0

I'm trying to implement an ERC721 smart contract with some NonFungible token. Some attribute will never change, about "layout/traits" composition, and others will evolve like XP.

Immutable attributes

For that, it's simple. I just have to upload metadata files into an IPFS bucket and put CID into my contract as constant variable (so even me, the owner of the contract, will not be able to update them).

In this case, the tokenURI will be simple and always return the same result.

Updatable attributes

I read about updatable metadata, and 2 solutions exists:

  1. Re-upload another metadata file in IPFS and update the smart-contract to link another URI for the concerned token.
  2. Use a centralised database to store all variables and generate the metadata file on requests.

Both solutions will works fine, but owner of my NFTs will have to trust me, and i could update attributes as I want (even decide to transform an extremely rare NFT to a basic one..)

Solutions to have Immutable and Updatable attributes ?

Do we know something who can assure both features ?

I add some ideas, but each one have issues:

Combine JSONs

I add an idea where the smart contract could look for both Json (immutable data from IPFS and updatable data from centralized server) and send a merged version of the, but I don't think this is possible. I never ear about a Solidity file fetcher or even JSON parser.

Generate 2 tokens linked each other

When a user will mint a token, I'll in fact mint 2. The first one is related to rarities and immutable data on IPFS and the second one contain only attributes like XP from my centralised server. This solution look good but opensea (and others) will not be able to link them together, So will only retrieve data from a single one. Even worse, a user will be able to sell only one of the both token (Or I just make the first salable ? but will not fix the first issue)

Any other solution ?

I may miss something during my search ?

If anyone have any idea, I'll be glad to ear.

2 Answers 2

2

You could have some publicly readable data structure or mapping within your ERC-721 contract that allow other smart contracts and centralized applications to read the mutable values.

So basically keep it outside of metadata JSON. Also update/modify the values via smart contract functions if needed.

Downside to this is that OpenSea won't be able to show those attributes as "traits" as it only looks inside getUri JSON object as far as I'm aware.

1
  • Okay I think I see your point. So basically I'll have all immutable metadata into an IPFS with a CID as constant on the smart contract (and so nobody can udpate that). And additional mutable data as mapped struct into my contract. It look like the solution where mutable data as stored into a centralised database but will cost more in gas (upside: will not depend on my centralised server to store data).
    – Arthur
    Commented Dec 23, 2021 at 7:58
0

There are some notes about this topic in the NFT School docs (by Protocol Labs). Essentially, you have to do one of the following:

  • Create a method so that you can update tokenURI upon metadata changes (e.g., push a new file to IPFS -> update the NFT's CID so that tokenURI now points to the new value)
  • Put the data on-chain -- which isn't all too feasible for cost purposes and is often used for "freezing" metadata (e.g., steady state NFT without mutability)
  • Centralized server hosting the metadata -- this limits the composability aspect and value of web3, in general
  • Use something like Tableland as a web3-native database where creating and updating metadata happens on-chain (using cheap events/calldata instead of storage), but reading it (e.g., marketplaces) happens off-chain with built in SQL composability

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.