Hi,
Suppose a bunch of native assets (nfts) were minted and policy is not locked. They are now distributed amongst many holders.
Would it be possible to change the metadata on any of those native assets by the policy holder? Or all they can do is mint more. What power does the policy owner have while the policy remains unlocked?
Thanks !
Yes. I actually had to do this for an NFT artwork project. We had a script that generated all the JSON metadata but found out after distribution that some of the data was generated incorrectly. Most of the tokens were in other peoples wallets by the time we found out…so we minted everything again (there were briefly 2 of each token instead of 1) with the correct metadata, then burned the ones we had just minted. This did fix the metadata for the tokens without us having to actually have to token in our possession.
Credit to Stale of CNFT for informing us we could do this.
late reply, but good to know. thanks!! 
Could you elaborate on how you were able to burn and remove tokens from wallets you did not own?
This sounds like you had never generated NFT at all to begin with as the policy was left open. I would assume CLI was was the culprit as a proper smart contract would not allow this “my bad, nuke them all” correction after minting.
It is worth discussing as I postulate there is not such thing as CNFT generated from CLI …
It will be difficult for me to explain why it works. But they way we did it was pretty straight forward.
We had a project where we released 3742 NFTs. After an hour into the presale, we saw some messages popping up concerning the metadata and what the values were saying for the background key in the meta data. After we looked into, it turned out that the metadata was incorrect. This was because we need to change a name in the metadata for all tokens that had that value, so we ran a simple python script to quickly change everything…however this actually messed up the metadata a lot more, but we didn’t notice.
Once we had found out there was a problem, we started asking around trying to figure out what to do. Stale, of CNFT, had informed us that you could change the metadata of an NFT that wasn’t in your wallet by simply minting a duplicate (same asset name/policy id). Once you mint the duplicate, there are now 2 of the NFT. Then we burned the duplicate we had just minted and had possession of, and this in turn changed the metadata of the remaining NFT that was in someone else wallet.
Then to fix all of them, we just minted all 3742 again into our wallet (with correct metadata)…wrote a script to automate the burning of those 3742 and burned them…sure enough all the metadata was corrected…even if we didn’t have the specific NFT in our wallet.
The policy is set to lock, we just didnt lock it right away. I believe for that project we had set the policy to lock at the end of this year.
If you think about it the policyId and assetName make a unique hash ID. The ledger does not particularly care about the slot or transaction it was in as the entire history is maintained by the blockchain. Minting identical token IDs with new meta data caused the most recent consensus to become the current meta data. By burning the duplicates the new meta data from the most recent minting transaction still remained in history but the original tokens and all of their transfers from the original minting transaction could also be referenced and maintained. The only thing missing is the “update tokens” which were burned for integrity.
Golf clap
This is actually quite intentionally genius … also the best argument for leaving policies open I have seen.
Edit: Sorry, I am nerding out on this …
Q: How does one update immutable state?
A: Publish a draft that creates a new immutable state without being persisted itself.
Hey I’m jumping in because we are facing the same issues I need to modify the metadata of some of our nfts
With this technique it is possible to add or just update current metadata ?
You could change the whole metadata.json, but only if the policy still allows it.
In the case described by @Tylert16, they had allowed new minting/burning transactions until the end of the year, so it was still possible.
If you wrote a shorter period in your policy (the "before" element) and this slot has already passed, you will not be able to do it.
Yes we have set a before date in 2023
Then just change the metadata.json, make sure it’s completely correct this time, mint them all again to your minting payment address and immediately burn them again from there. Should be possible in just two transactions.
(2023? Not very “NF” your “T”, are they?)
it’s not my call
Thank you
Up until today I thought the NFT who’s metadata you want to modify had to be in a utxo of the original wallet where minting took place. DinoDude tried to tell me. Learn something new every day. Thanks @DinoDude !
I think that because burning a token had to be in the original wallet that this applied to reminting too.
So, if there was an NFT that represents a packaging being delivered from Source to Destination, and there are several steps in the process of this transportation such as being packaged, being sent to an exit port, in transit, received at destination port, customs, and finally on it’s final leg to it’s destination, then all this extract data could be updated in the NFT as you’ve just mentioned?
Like the NFT represents a blob of related data in a database?
Can only the original minter of the NFT Update the NFT? How does that work?
Hello @podsly
This is a really old topic. There are new NFT/FT standards now. You should just start a new topic with any questions you have. That way you get up to date and relevant info. 
(Maybe outdated topics like these should be locked with link to updated ones)