You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am proposing that the new NFT standard is build in a way to allow multiple update authorities on the same token. In order for an update to be made on a token, each of the update authorities would need to sign/approve the same message/transaction. This solution would improve the state of mutable tokens in the crypto space.
What users have asked for this feature?
Users are currently faced with the dilemma of not truly owning their NFT if it is mutable, as the update authority could change anything on the NFT when they would like.
With this proposal, we would solve the problem of non consensual updates on users tokens. In order for an authority to update a token, the user would need to approve this. The other way is also true, if a user wishes to update their token, they are able to with the approval of the other update authority(s).
What is the developer experience going to be?
Ideally when a NFT is minted, the user that mints the NFT is added to that NFT as an update authority, or when a NFT is transferred to another wallet.
What is the user experience going to be?
A user would need to use the Origin-Byte SDK or API to make changes on their NFT (unless a front-end is available). The user would receive a notification in their wallet/dapp regarding changes that need to be approved.
The text was updated successfully, but these errors were encountered:
Sorry for the late reply! We've been busy consolidating a new NFT design over the last weeks, which we are currently working on stabilizing on the develop branch.
We feel that this new design achieves what you are proposing, so we would appreciate your feedback!
Basically, what we've done is allowed creators to register "domains" on an NFT. A domain is in essence a dynamic field on an NFT that can be registered by any Move package with the permission of the owner of the NFT. Such a domain is only mutable for the package that created it, with the optional possibility to expose a public mutable API.
This model provides a multi-authority system, such that the owner cannot modify the domain without using the package that defined it, and the package requires permission from the owner to mutate the NFT. We can opt out of this behaviour by making the NFT a shared object, allowing packages to freely mutate it.
Does this sound like it covers your use cases, or perhaps some additional functionality would be required?
We'll revisit this issue once we can provide more concrete examples of this in action!
What/Why
What are you proposing?
I am proposing that the new NFT standard is build in a way to allow multiple update authorities on the same token. In order for an update to be made on a token, each of the update authorities would need to sign/approve the same message/transaction. This solution would improve the state of mutable tokens in the crypto space.
What users have asked for this feature?
Users are currently faced with the dilemma of not truly owning their NFT if it is mutable, as the update authority could change anything on the NFT when they would like.
https://looksmutable.com/mutable-nfts
What problems are you trying to solve?
With this proposal, we would solve the problem of non consensual updates on users tokens. In order for an authority to update a token, the user would need to approve this. The other way is also true, if a user wishes to update their token, they are able to with the approval of the other update authority(s).
What is the developer experience going to be?
Ideally when a NFT is minted, the user that mints the NFT is added to that NFT as an update authority, or when a NFT is transferred to another wallet.
What is the user experience going to be?
A user would need to use the Origin-Byte SDK or API to make changes on their NFT (unless a front-end is available). The user would receive a notification in their wallet/dapp regarding changes that need to be approved.
The text was updated successfully, but these errors were encountered: