Mutable metadata fields for dynamic NFTs

[HGraphPunks]

Problem
When trying to adapt a NFT after it’s created there is not currently a way to update the metadata natively through the Hedera Network.

Current Solutions

• Create an NFT with a http link to a file you can update
• Have the user send the NFT to the treasury wallet, burn that serial number, mint a new serial number with the new data using the supply key, send back to the user
• Add wipe keys onto the token and wipe the old nft out of a wallet and airdrop the new one on the same token id

Use cases
Dynamic NFTs can have a lot of use cases as seen on other chains

Example:

• A game piece that the character gains equipment and stats, that are then represented in the metadata
• An NFT that has it’s image update based on the time of day
• A legal agreement NFT that requires updating after mint to reflect new parameters agreed by both parties

Initial HIP idea

• Create a new key called a METADATA key that allows a treasury wallet of an NFT collection to update a serial number's metadata link remotely.

• Allows creators to start providing new interactions and new creators from other chains get parity on functionality they’d expect with NFTs

• Allow SUPPLY key to update and adapt the metadata of a NFT serial number that is in the treasury wallet.
  This would provide backwards compatibility with the many projects already minted and that are unable to add a METADATA key. The requirement of the NFT needing to be in the treasury wallet would protect against any malicious activity with remote changing of a project already distributed.

[kantorcodes]

+1

[seancuscus]

interesting! Could on chain mechanics not also be done through the hedera file service?

[HGraphPunks]

Though I like the idea of using Hedera File Service, the main issue is cross-chain compatibility and support in the ecosystem. With Hashport and other bridging tools, a Hedera File Service path to the metadata would not be understood by other networks and would limit the ability of NFTs being able to move cross networks.

The format of a Hedera File Service path like hedera://0.0.123456 as the metadata string is also not supported on any platform that displays data of NFTs currently in the eco-system. Most platforms expect IPFS and all the minting tools on the network that I know of currently require it.

The standard of using IPFS CIDs in the metadata string is fairly consistent across networks and having the ability to update that metadata string remotely with a new key would give the Hedera Network functional parity.

[seancuscus]

Fascinating! I appreciate the info.
So you're still suggesting IPFS for mutable NFT's if we were to do it the way you're suggesting!?

[HGraphPunks]

Yes, though the scope of this proposal is a little beyond the string content.

This proposal is suggesting developers should be able to remotely update the metadata string of NFTs as that's a function most other networks have. The contents could be a HFS link, or IPFS, or even HTTP. I believe the ability to change that string is what is important for versatility in dynamic NFTs on Hedera.

[Cooper-Kunz]

While I think adding a dedicated metadata field makes sense, as well as having a specific key attached to it would be valuable (should probably be editable by an adminKey rather than a supply key...). But nonetheless, you definitely could use the file service for storing metadata references, if you wanted to. We outline this model in HIP-405 for fungible tokens, as well as more specifically in this blog post https://calaxy.medium.com/immutability-persistence-of-token-metadata-e994600cd77

…

On Sun, Oct 23, 2022 at 1:47 PM Sean ***@***.***> wrote: interesting! Could on chain mechanics not also be done through the hedera file service? — Reply to this email directly, view it on GitHub <#607 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACZ3HKTTWNAV3KIYNCMQWNDWEUJTBANCNFSM6AAAAAARLSMBIM> . You are receiving this because you are subscribed to this thread.Message ID: <hashgraph/hedera-improvement-proposal/repo-discussions/607/comments/3943221 @github.com>

[Cooper-Kunz]

I'm pretty sure that adminKeys can add/remove all other keys as it pleases.. But I don't believe an adminKey itself can be removed. Better documentation explaining all the secondary/tertiary interactions here would be valuable, e.g. I assume deleting a token removes it from all holder's wallets?

Makes sense generally though - I'm onboard with the proposal ✅

[HGraphPunks]

It may be in the nuance, but I didn't think change meant remove, only update. I also thought there was a HIP to allow the admin key to remove itself, but I'm not 100% sure, maybe that was just a discussion.

[HGraphPunks]

Fantastic! Great conversation and questions 😄

Makes sense generally though - I'm onboard with the proposal ✅

[Cooper-Kunz]

Hm, interesting. Better docs would be lovely.

Yes I was working on that HIP, you should be able to remove any keys you want - there's a separate PR open, too. 🤷

[littletarzan]

I'm late to the party but @Cooper-Kunz you can set the admin key to an empty keylist with the existing admin key.

[Ashe-Oro]

I support this HIP and agree that:

1. A new METADATA key is a clean solution for updating the metadata value of any NFT within a Collection (ie token_id). This applies to NFTs in any wallet on the network, not only NFTs held in the Treasury account.
2. To achieve some backwards compatibility, allowing the SUPPLY key to update the metadata field for NFTs held in the Treasury account seems simple enough.

...that said, it does seem that if an ADMIN key is present, it should be able to update the metadata value as well as long as the NFT is held in the Treasury account. This would increase the likelihood of backwards compatibility, altho adds a bit more complexity. For NFT Collections which still have an admin key, but have removed the SUPPLY key this would offer similar functionality as #2 above.

I'm curious for feedback on the ADMIN key note above. @HGraphPunks @bugbytesinc @Cooper-Kunz @rocketmay @michielmulders

[Ashe-Oro]

I would love to hear your thoughts (and everybody else's) on my final proposition. Can't this all be solved by infrastructure? Not against adding more flexibility at all, but interested in why a new key is better than simply moving to a mutable storage location which would achieve the same effect. It is the only convention that metadata on a given serial points to an immutable link; why not solve it here vs adding a new key?

With centralized infra there's no history of the changes whereas with a metadata key there is. Sure if no metadata key, but centralized infra, the NFTs metadata can be changed but without audit trail. Without a metadata key, we push dNFTs to only use centralized infra.

[Ashe-Oro]

That will allow this METADATA key HIP go forward and start being added to the network which will greatly expand innovation and usability for use cases :)

I think this is the right approach. Having both convos in the same HIP is impeding the progress of both ideas.

[Burstall]

I would love to hear your thoughts (and everybody else's) on my final proposition. Can't this all be solved by infrastructure? Not against adding more flexibility at all, but interested in why a new key is better than simply moving to a mutable storage location which would achieve the same effect. It is the only convention that metadata on a given serial points to an immutable link; why not solve it here vs adding a new key?

With centralized infra there's no history of the changes whereas with a metadata key there is. Sure if no metadata key, but centralized infra, the NFTs metadata can be changed but without audit trail. Without a metadata key, we push dNFTs to only use centralized infra.

I like this point - if the implementation allows for easy traversal of the prior metadata then it would be great; at least the user can voice their complaint if metadata shifts under them (I still prefer to protect the user of course hence I hope we can get both options). If we only get an audit trail in the sense of a metadata update transaction occurred then it is less great. I guess that's down to the technical proposal.

[nickpoorman]

Infrastructure providers will need to revisit their caching mechanisms either way if metadata data links can change with a key or if a mutable storage endpoint is used (or an Oracle or HCS etc. etc.).

This is a real concern. I suppose we may want to configure the responses from Mirror Node to include how long data should be cached for and operators are going to have to deal with this. Also, downstream consumers doing ETL may have stored this data in an immutable data store.

[Ashe-Oro]

Infrastructure providers will need to revisit their caching mechanisms either way if metadata data links can change with a key or if a mutable storage endpoint is used (or an Oracle or HCS etc. etc.).

This is a real concern. I suppose we may want to configure the responses from Mirror Node to include how long data should be cached for and operators are going to have to deal with this. Also, downstream consumers doing ETL may have stored this data in an immutable data store.

I've mentioned to the community on Twitter, Slack, Github and privately about potential issues regarding initial design patterns due to a previously immutable field now becoming mutable and did not receive a single concern back. I think we can risk accept this.

As for the mirror node, I don't understand how it can include "how long data should be cached for". Would the mirror node not simply return the current value? Or are you referring to some type of event that signals that the metadata value has been updated?

[web3-nomad]

Hi.
I was wondering if another option would be to use HCS to manage the dynamic aspects instead of HTS.

this way people can setup the HCS service to match the dynamic aspects of the game, see history, etc etc etc.

[Ashe-Oro]

sure, and others have done this. The difference is that many aren't familiar with HCS and want a solution that a bit more general. Right now dNFTs are supported by having the metadata on centralized hosting providers (ie AWS). Having a metadata key will allow creators to continue using IPFS, but update the path/pointer to a new CID.

[Burstall]

It may come down to how this is 'taught'. There was a period where the nascent community froze as people suddenly realised that many NFT mints had a wipe token so that you could lose the NFT anytime. Enabling a key to adjust metadata unilaterally is a close analogue to me (sure, the NFT as a token exists, but the rare trait(s) I paid for can be taken from me anytime).

Explaining the key usage and trust implications may go a long way to avoid a nasty shock. Not as good as having actual user protection whilst in their wallet but still maintaining flexibility (supply key overload) as well as a metadata key that is all powerful for the same crowd that thinks wipe keys are fun; I am being flippant, wipe keys have solid, relevant use cases, especially when structured in a decentralised manner but need more thought given trust implications.

[Ashe-Oro]

Enabling a key to adjust metadata unilaterally is a close analogue to me (sure, the NFT as a token exists, but the rare trait(s) I paid for can be taken from me anytime).

Nothing is protecting the user if their NFTs metadata is hosted centrally. Think of the metadata key as the admin key on a ERC721 contract. If it's set, then ur NFT carries higher risk. This is one of the reasons that we built the Rick Calculator in the recently released hedera-nft-utils SDK.

[Burstall]

I agree.
I don't want to have the data stored centrally. Neither do I want the project to be able to change the metadata without my consent (as a general rule). Same as wipe keys. If I see one, I want to understand why the project thinks it needs it else I am taking risks where not needed.

---

That is a fair point on ERC721, in my experience most (?) collectors of NFTs, are unaware of the risks they are taking; the new trend of proxy deployment and ERC1155 takes that to whole new extremes. Decentralization and immutability are often a narrative. If we see only the Metadata key (and not the ability to update metadata with the supply key in treasury). We risk Hedera NFTs falling down the same traps as every project just implements the metadata key for optionality.

I will have to go look for the Risk Calculator. Thanks for the tip.

[littletarzan]

The SaucerSwap team supports this HIP. We ask that smart contract integration be a requirement for cases where a ContractId is the supply/treasury/admin key for an NFT. Immutable metadata field is a major blocker in the way of truly generative on-chain NFTs. Ideally the maximum size of the metadata field is increased beyond 100 bytes because that isn't much room to store data for this purpose.

[Ashe-Oro]

hi @littletarzan thanks for the feedback. How many bytes of data would you recommend? Also, is the purpose of the increased bytes limit to support on-chain metadata rather than pointing to a json file off-chain?

Should mention that increasing the available bytes in the metadata field should be broken out into a new, independent HIP.

[littletarzan]

Hello, @Ashe-Oro, I don't have an exact number for you since each use case is different, but for the one I have in mind I would be comfortable with 150 bytes. A system where auto-renew pays for extra bytes would be pretty cool.

Also, is the purpose of the increased bytes limit to support on-chain metadata rather than pointing to a json file off-chain?

That's right, we could encode data as bytes in the metadata field and read/modify in contracts or render an image from those bytes off chain.

[Ashe-Oro]

ok understood on the metadata bytes. I do suggest creating a new HIP discussion for it to keep the metadata HIP as simple as possible.

[AdrianKBL]

Kabila Team support this HIP also! Hedera needs it!

[Ashe-Oro]

this discussion was broken out into 2 separate. Which are you expressing support for (or both)?

1. metadataKey - Mutable metadata fields for dynamic NFTs  #657
2. supplyKey - Allow SUPPLY key to adapt metadata of an NFT in the treasury wallet #660

[nickpoorman]

I support this HIP. The Metadata Key feels like the right direction. We would need to ensure that previously minted NFT's metadata cannot be modified. I think the HIP needs to clearly define the behavior when NFTs sent back to treasury, should this only be for newly minted NFTs going forward, etc..

[Ashe-Oro]

I support this HIP. The Metadata Key feels like the right direction. We would need to ensure that previously minted NFT's metadata cannot be modified. I think the HIP needs to clearly define the behavior when NFTs sent back to treasury, should this only be for newly minted NFTs going forward, etc..

I think this is a good example of confusing an outdated discussion with the up-to-date HIP PR (https://github.com/hashgraph/hedera-improvement-proposal/blob/main/HIP/hip-657.md).

You'll see that the Treasury account and SUPPLY key functionality has been completely removed from the actual HIP-657 PR.