Create hip-850.md

[ty-swirldslabs]

Description:
This PR introduces the implementation of the proposed HIP for enhancing the Supply Key functionality in NFT updates within the treasury wallet. The goal is to enable dynamic, secure updates to NFT data, ensuring data immutability post-distribution. This change is essential for supporting evolving use cases in the Hedera ecosystem.

• Implement Supply Key functionality for NFT data updates in the treasury wallet.
• Ensure data immutability of NFTs post-distribution.
• Add necessary code for controlling NFT updates via the Supply Key.

Discussions Link:
Discussion 660

[netlify]

✅ Deploy Preview for hedera-hips ready!

Name	Link
🔨 Latest commit	54993c0
🔍 Latest deploy log	https://app.netlify.com/sites/hedera-hips/deploys/665755a85773010008169c58
😎 Deploy Preview	https://deploy-preview-850--hedera-hips.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[Nana-EC]

Some questions

[Nana-EC]

Q: A few more suggestions and waiting on some clarifications.

[Nana-EC]

Can we expand on this section?
Which existing transaction are we tapping into. Is it just TokenUpdate or some other flow. We just want to be explicit here.

[Nana-EC]

@ty-swirldslabs this part could be expanded on

[Nana-EC]

Protobuf and docs.hedera.com should explicitly be updated to note the presence of a supply key may imply metadata modification for NFTs should they be sent back to the treasury

[jascks]

And, how this interacts with the HIP-657 metadata key.

[Nana-EC]

@ty-swirldslabs can you address these comments in the HIP

[Nana-EC]

Still a few items to address for clarity.

Specifically it would be good to clarify how this works on top of the approved HIP 657 you also proposed 🙌🏾.

[ty-swirldslabs]

After some more internal discussion, it's quite hard to get consensus on the best strategy to enable this feature of only being able to adapt metadata of a NFT that's in the treasury wallet.

There's been three different solutions proposed and the next step is to ask the community about the feature and see what they'd prefer out of the paths forward.

The options for this feature to be implemented are:

1. The supply key gains a new functionality as proposed in this HIP.
2. A new key is created that is on the token level and that key has the functionality described in this HIP
3. The metadata key is updated to have a enum value. If 0, the key can only adapt NFTs metadata if the NFT is in the treasury wallet. If 1, the metadata key functionality is as it works today.

[Burstall]

So happy to see this functionality coming back for discussion. I can see opinion is divided.

It seems natural to me that it is added to the Supply Key to add 'controlled mutability':
Pros

1. The Supply Key can burn/remint the NFT anyway, so power lies within bounds already (granted token serial would change).
2. This makes it fully retroactive, opening up the design space for existing collections without forcing them to conduct a token swap.
3. No owner is impacted, as they have a choice not to send NFTs to the treasury
4. Going forward, there is a clear delineation between collections that can only have the metadata adjusted with users' explicit permission by sending the token to the treasury [neat implementation would be a Smart Contract as the Treasury to allow users to interact and 'upgrade' the metadata in an atomic manner] vs. those tokens where the user must trust the team as 'remote' metadata shifts can be conducted without their consent.
5. Less complexity on the metadata key that may be harder for users to understand.
6. Less 'deleted' serials for a token as mistake / bad mints can be updated rather than deleted and reminded on a new serial.

Cons

1. I am stuck on the cons.... the metadata key can change the metadata anyway.

[Nana-EC]

So happy to see this functionality coming back for discussion. I can see opinion is divided.

It seems natural to me that it is added to the Supply Key to add 'controlled mutability': Pros

1. The Supply Key can burn/remint the NFT anyway, so power lies within bounds already (granted token serial would change).
2. This makes it fully retroactive, opening up the design space for existing collections without forcing them to conduct a token swap.
3. No owner is impacted, as they have a choice not to send NFTs to the treasury
4. Going forward, there is a clear delineation between collections that can only have the metadata adjusted with users' explicit permission by sending the token to the treasury [neat implementation would be a Smart Contract as the Treasury to allow users to interact and 'upgrade' the metadata in an atomic manner] vs. those tokens where the user must trust the team as 'remote' metadata shifts can be conducted without their consent.
5. Less complexity on the metadata key that may be harder for users to understand.
6. Less 'deleted' serials for a token as mistake / bad mints can be updated rather than deleted and reminded on a new serial.

Cons

1. I am stuck on the cons.... the metadata key can change the metadata anyway.

Very useful perspective, thanks @Burstall.
I like the idea and the final functionality seems to really open up what NFT collections can do especially in gaming and RWA applications as @ty-swirldslabs has highlighted.

Some considerations regarding your pros that I'm curious about

1. Agreed, but currently the supply key controls create and delete only and therefore supply. Granted when minting the metadata of an NFT is specified. Mutability of an existing entity could be seen as a different and new power.
2. Indeed and therefore has a backwards compatibility concern. The supply key would now do more than initially stated. Might this have business impacts on a dev or company that concluded supply key can only affect supply quantity by via mint or burn? Is there a heavy desire to use the supply key over metadata key to enable the functionality on older tokens and avoid a token collection owner/community having to migrate to a new token?
3. Agreed
4. Hmm, what about when both keys are present on a token? The flow you layout is pretty interesting. In the SC case a user would view this functionality as submitting their NFT back for some kind of an upgrade or touch up upon some agreed logic. NFT collection owners would support this by utilizing the treasury account and supply key. 🤔 Sounds fun
5. I think the opposite could also be argued. One could says it's less complexity because you know only a metadata key could ever modify metadata in any circumstance. If we add the supply key modification case the community needs education to know that for a token collection with a supply key individual NFT serial metadata can be modified by the metadata key at any time if present and/or by the supply key if the NFT is in the treasury balance.
6. Agreed this is a pro. Note, this is the case for either solution - metadata or supply key.

All in all we just want to ensure the feature has a consistent feel that scales for devs and users when interacting with HTS

[Burstall]

So happy to see this functionality coming back for discussion. I can see opinion is divided.
It seems natural to me that it is added to the Supply Key to add 'controlled mutability': Pros

1. The Supply Key can burn/remint the NFT anyway, so power lies within bounds already (granted token serial would change).
2. This makes it fully retroactive, opening up the design space for existing collections without forcing them to conduct a token swap.
3. No owner is impacted, as they have a choice not to send NFTs to the treasury
4. Going forward, there is a clear delineation between collections that can only have the metadata adjusted with users' explicit permission by sending the token to the treasury [neat implementation would be a Smart Contract as the Treasury to allow users to interact and 'upgrade' the metadata in an atomic manner] vs. those tokens where the user must trust the team as 'remote' metadata shifts can be conducted without their consent.
5. Less complexity on the metadata key that may be harder for users to understand.
6. Less 'deleted' serials for a token as mistake / bad mints can be updated rather than deleted and reminded on a new serial.

Cons

1. I am stuck on the cons.... the metadata key can change the metadata anyway.

Very useful perspective, thanks @Burstall. I like the idea and the final functionality seems to really open up what NFT collections can do especially in gaming and RWA applications as @ty-swirldslabs has highlighted.

Some considerations regarding your pros that I'm curious about

1. Agreed, but currently the supply key controls create and delete only and therefore supply. Granted when minting the metadata of an NFT is specified. Mutability of an existing entity could be seen as a different and new power.
2. Indeed and therefore has a backwards compatibility concern. The supply key would now do more than initially stated. Might this have business impacts on a dev or company that concluded supply key can only affect supply quantity by via mint or burn? Is there a heavy desire to use the supply key over metadata key to enable the functionality on older tokens and avoid a token collection owner/community having to migrate to a new token?
3. Agreed
4. Hmm, what about when both keys are present on a token? The flow you layout is pretty interesting. In the SC case a user would view this functionality as submitting their NFT back for some kind of an upgrade or touch up upon some agreed logic. NFT collection owners would support this by utilizing the treasury account and supply key. 🤔 Sounds fun
5. I think the opposite could also be argued. One could says it's less complexity because you know only a metadata key could ever modify metadata in any circumstance. If we add the supply key modification case the community needs education to know that for a token collection with a supply key individual NFT serial metadata can be modified by the metadata key at any time if present and/or by the supply key if the NFT is in the treasury balance.
6. Agreed this is a pro. Note, this is the case for either solution - metadata or supply key.

All in all we just want to ensure the feature has a consistent feel that scales for devs and users when interacting with HTS

Good questions.

1. I think some of this is a philosophical difference. The supply key can burn and remint a token, which is an opportunity to adjust the metadata. The distinction is that the serial will be updated, and the original will be marked as deleted. This process can only happen with user consent; they must send it back to the treasury. In effect, we can already do this now, with the downside of the serial adjusting. We have established that users prefer to keep serials sometimes, so it would be great to let them. The change proposed 'does no harm' as the owner of an NFT has the choice not to engage. As such, I would argue expanding the design space without forcing a choice on a user and keeping the NFT immutable if they choose not to engage is a great choice.

2. As in 1) I would make the case that the adjustment of metadata is a subset of the power the supply key already has. Forcing a project to have a metadata key forces the collectors to trust the team not to change the metadata. I agree this new metadata key has some solid use cases, but it involves the trust of the team and their key management - I don't think there should be an option where the design space is open without the need for that trust as the user retains control.

3. 👍

a) I'm glad you like my use case - I would love to roll that Smart Contract NFT minter/treasury out to add such functionality (right now, all I expose is a burn - this would be a fun enhancement).
b) Back to the feedback, as a collector - I dare not mention how many I have collected other than to say I was relieved when you took off the 1k association cap so I could consolidate wallets - being able to collect tokens and knowing they are immutable unless I explicitly give permission [the supply key route] is far superior than being forced to trust the team if they convince me they should have metadata control [metadata key only]. Rugs are perhaps a moot point as the token may hold no value over and above historical significance; however, a rugging team can potentially upgrade your metadata as a 'poison pill' on the way out. Given it is hard for a user to get rid of a token (especially if there are fallback fees!), then having an NFT with a toxic image stuck in your wallet due to a griefer would always make me think twice before buying a token with a metadata key. Similarly, there have been many instances of teams losing control of keys which could see similar impacts; sidenote, hopefully hardware walle support for native HAPI calls and a solid multisig implementation (we use scripts that are functional if not pretty to lock down team wallets) might ease some of that if project creators realise how to use such keys for their tokens.

5. Fair. I was not clear. I meant the metadata key with an enumeration to have a subtle but important difference is tough to expect the 'average user' to grok. I say this from the number of times I have tried to explain keys or, indeed, the Hedera native royalties to people. Our 'average' user base has not read the API docs.

6. 👍

[Nana-EC]

So happy to see this functionality coming back for discussion. I can see opinion is divided.
It seems natural to me that it is added to the Supply Key to add 'controlled mutability': Pros

1. The Supply Key can burn/remint the NFT anyway, so power lies within bounds already (granted token serial would change).
2. This makes it fully retroactive, opening up the design space for existing collections without forcing them to conduct a token swap.
3. No owner is impacted, as they have a choice not to send NFTs to the treasury
4. Going forward, there is a clear delineation between collections that can only have the metadata adjusted with users' explicit permission by sending the token to the treasury [neat implementation would be a Smart Contract as the Treasury to allow users to interact and 'upgrade' the metadata in an atomic manner] vs. those tokens where the user must trust the team as 'remote' metadata shifts can be conducted without their consent.
5. Less complexity on the metadata key that may be harder for users to understand.
6. Less 'deleted' serials for a token as mistake / bad mints can be updated rather than deleted and reminded on a new serial.

Cons

1. I am stuck on the cons.... the metadata key can change the metadata anyway.

Very useful perspective, thanks @Burstall. I like the idea and the final functionality seems to really open up what NFT collections can do especially in gaming and RWA applications as @ty-swirldslabs has highlighted.
Some considerations regarding your pros that I'm curious about

1. Agreed, but currently the supply key controls create and delete only and therefore supply. Granted when minting the metadata of an NFT is specified. Mutability of an existing entity could be seen as a different and new power.
2. Indeed and therefore has a backwards compatibility concern. The supply key would now do more than initially stated. Might this have business impacts on a dev or company that concluded supply key can only affect supply quantity by via mint or burn? Is there a heavy desire to use the supply key over metadata key to enable the functionality on older tokens and avoid a token collection owner/community having to migrate to a new token?
3. Agreed
4. Hmm, what about when both keys are present on a token? The flow you layout is pretty interesting. In the SC case a user would view this functionality as submitting their NFT back for some kind of an upgrade or touch up upon some agreed logic. NFT collection owners would support this by utilizing the treasury account and supply key. 🤔 Sounds fun
5. I think the opposite could also be argued. One could says it's less complexity because you know only a metadata key could ever modify metadata in any circumstance. If we add the supply key modification case the community needs education to know that for a token collection with a supply key individual NFT serial metadata can be modified by the metadata key at any time if present and/or by the supply key if the NFT is in the treasury balance.
6. Agreed this is a pro. Note, this is the case for either solution - metadata or supply key.

All in all we just want to ensure the feature has a consistent feel that scales for devs and users when interacting with HTS

Good questions.

1. I think some of this is a philosophical difference. The supply key can burn and remint a token, which is an opportunity to adjust the metadata. The distinction is that the serial will be updated, and the original will be marked as deleted. This process can only happen with user consent; they must send it back to the treasury. In effect, we can already do this now, with the downside of the serial adjusting. We have established that users prefer to keep serials sometimes, so it would be great to let them. The change proposed 'does no harm' as the owner of an NFT has the choice not to engage. As such, I would argue expanding the design space without forcing a choice on a user and keeping the NFT immutable if they choose not to engage is a great choice.
2. As in 1) I would make the case that the adjustment of metadata is a subset of the power the supply key already has. Forcing a project to have a metadata key forces the collectors to trust the team not to change the metadata. I agree this new metadata key has some solid use cases, but it involves the trust of the team and their key management - I don't think there should be an option where the design space is open without the need for that trust as the user retains control.
3. 👍

a) I'm glad you like my use case - I would love to roll that Smart Contract NFT minter/treasury out to add such functionality (right now, all I expose is a burn - this would be a fun enhancement). b) Back to the feedback, as a collector - I dare not mention how many I have collected other than to say I was relieved when you took off the 1k association cap so I could consolidate wallets - being able to collect tokens and knowing they are immutable unless I explicitly give permission [the supply key route] is far superior than being forced to trust the team if they convince me they should have metadata control [metadata key only]. Rugs are perhaps a moot point as the token may hold no value over and above historical significance; however, a rugging team can potentially upgrade your metadata as a 'poison pill' on the way out. Given it is hard for a user to get rid of a token (especially if there are fallback fees!), then having an NFT with a toxic image stuck in your wallet due to a griefer would always make me think twice before buying a token with a metadata key. Similarly, there have been many instances of teams losing control of keys which could see similar impacts; sidenote, hopefully hardware walle support for native HAPI calls and a solid multisig implementation (we use scripts that are functional if not pretty to lock down team wallets) might ease some of that if project creators realise how to use such keys for their tokens.

5. Fair. I was not clear. I meant the metadata key with an enumeration to have a subtle but important difference is tough to expect the 'average user' to grok. I say this from the number of times I have tried to explain keys or, indeed, the Hedera native royalties to people. Our 'average' user base has not read the API docs.
6. 👍

Thanks, loving these details :)

1. Agreed it's a philosophical nuance. I think we'll have to agree to disagree, which is totally fine 😄. I think the similarity is only present when you aggregate the changes to the system and view it from the end users view which is at a higher level than the transaction level that a node and the network must consider. The impact is mainly around documentation and education, the dev exp is minimal. I'm okay deferring to community spec here.
2. The trust factor here is the swaying consideration for me. I like the clarity that a supply key only requires trust when you take the explicit step of sending a token back to the treasury. This can also be gated and specified through smart contract as you said so a user knows the logic ahead of time. The metadata_key on the other hands requires trust at all times when present. Thanks for this clarity.
3. 👍🏾
4. Looking forward to seeing this 🙌🏾
5. 😭 , I can appreciate this. For future readers please check out Hedera Docs and for a more technical deep dive see HAPI protobuf specs
6. 👍🏾

I love HIPs with community feedback and input, I'm excited to see the views here as it's a good example for others.

I'm gonna unblock my review here as the community has made the context more clear.
Thanks @ty-swirldslabs and @Burstall

[Nana-EC]

@ty-swirldslabs please update the rejected ideas section with the options other than using the supply_key.
Also a few open comments that need to be resolved and then I'm good to sign off

[Nana-EC]

LG
My concerns are addressed.