Feature/supply key adapt metadata of nft

[HGraphPunks]

Description:

Related issue(s):

Fixes #

Notes for reviewer:

Checklist

• [ ] Documented (Code comments, README, etc.)
• [ ] Tested (unit, integration, etc.)

[netlify[bot]]

✅ Deploy Preview for hedera-hips ready!

Name	Link
🔨 Latest commit	b5548daf5850256ce84927e57f3329dd7c598bad
🔍 Latest deploy log	https://app.netlify.com/sites/hedera-hips/deploys/63f7872864d3290007efa872
😎 Deploy Preview	https://deploy-preview-680--hedera-hips.netlify.app/hip/hip-680
📱 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 settings.

[HGraphPunks]

@mgarbs let me know if I need to adapt anything on this PR to get it past the apporvals

[Ashe-Oro]

The Engineering team has expressed quite a bit of concern over making a once immutable NFT mutable by overloading the supply key.

On Wed, Feb 22, 2023, 7:46 PM Patches @.***> wrote:

@mgarbs https://github.com/mgarbs let me know if I need to adapt anything on this PR to get it past the apporvals

— Reply to this email directly, view it on GitHub https://github.com/hashgraph/hedera-improvement-proposal/pull/680#issuecomment-1441076449, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMEGCHW67DVIZ2JFCF5253WY2XNBANCNFSM6AAAAAAU6NUGD4 . You are receiving this because you are subscribed to this thread.Message ID: @.*** com>

[HGraphPunks]

The Engineering team has expressed quite a bit of concern over making a once immutable NFT mutable by overloading the supply key.

What would be the best venue to engage in dialogue about the opposing opinions? I haven't seen any feedback that wasn't responded to in the discussions

[bugbytesinc]

While I empathize with the problem this is trying to solve (the perceived value of an NFT’s serial number is greater than its metadata) I do not believe this HIP should be implemented.

This changes the rules for existing NFTs and the tokenomic assumptions around them for both creators and owners.

Once the sister HIP (metadata key) is implemented, why not just offer to burn and re-mint fungible metadata NFTs instead. You can always swap serial number for serial number?

[HGraphPunks]

While I empathize with the problem this is trying to solve (the perceived value of an NFT’s serial number is greater than its metadata) I do not believe this HIP should be implemented.

This changes the rules for existing NFTs and the tokenomic assumptions around them for both creators and owners.

Once the sister HIP (metadata key) is implemented, why not just offer to burn and re-mint fungible metadata NFTs instead. You can always swap serial number for serial number?

I would agree with you 95% (could you elaborate on how this would affect tokenomics?) if the only focus and benefit was to create a method for backwards compatibility for adaptation of NFTs without burning.

The functionality that Hedera is uniquely positioned to implement is to have trustless immutability in distribution and mutable data in treasury wallet.

I believe use cases from gaming to legal contracts to PFP projects would benefit from being able to guarantee no manipulation of data outside of the owner sending their NFT to the treasury wallet. It also is a step closer to secure methods of adaptation than just the boolean with the METADATA key: ALL data can be edited all the time or none of the data can be edited ever. This addition would innovate a new state that's flexabile, and has trustless protection to holders.

Addressing the security concerns: I understand and appreciate the concern over changing the scope of a key in production that affects many projects that are already minted. I agree changing rules under users on a DLT should be done rarely and with extreme caution. Mitigation of malicious actions that could be performed is paramount to trust in the network.

That coupled with the fact that almost all token Ids have a supply key since that's required to mint does make this more of a risk.

All that said, I see the risks as extremely low.

Points of attack from a malicious actor:

1. Trick users to send their NFT back to the treasury, then creator changes the data If a creator is malicious, the user is in danger of not even receiving a NFT back from sending it to the treasury. If the creator wants to degrade data on the NFT, they could but it requires the user to sign a transaction first to hand over custody.

2. NFTs already in treasury wallet are changed before sent to users who are owed them This can be an issue if the user sees on the mainnet / explorers that this is the NFT they want. Creator could manipulate it right before, devaluing the NFT compared to what the user expected the value to be for the purchase.

This requires the seller to be a malicious creator, to hold the NFT, and to devalue serial numbers of their own project for short term gains. The ramifications of this action would also cause a lot of uncertainty in whatever platform or creator was doing this.

My main retort to security issues: The risk that adding update functionality to the SUPPLY key is extremely low, and unlikely to affect users in production. All risks defined above are not additions to risks holders have today as the SUPPLY key can burn an NFT in the treasury wallet. Furthermore, creators are using HTTP and centralized servers to get functionality they want with the current state of Hedera Network, bringing more risk than what would change with this HIP.

A HTTP uri can change any data at any time for any NFT (much like a METADATA key). Most users don't understand the storage implications and developers are already using HTTP to get the benefits of this HIP which expose holders to more risk IMHO.

I do believe there's a lot of benefits and innovation this HIP would bring. A new dynamic of more granular adaption of NFTs and more trustless immutability to users.

[mgarbs]

While metadata mutation for NFTs has potential benefits, it's important to consider the drawbacks. Some of the things that have been discussed with engineering:

• Introducing this feature could undermine trust in NFTs, as users expect immutability.
• Tracking provenance and history could become more challenging.
• Potential for fraud and manipulation is introduced, even though the chance is very small, it still exists and would be introduced by this hip.

[mgarbs]

Being replaced with - https://github.com/hashgraph/hedera-improvement-proposal/pull/850