search

algorand / go-algorand

Algorand's official implementation in Go.
https://developer.algorand.org/
Other
1.35k stars 473 forks source link

Make non-critical ASA fields mutable #5305

Closed grzracz closed 1 year ago

grzracz commented 1 year ago

Status

Currently created assets are immutable after they are created. This includes fields like name, ticker and most confusingly, url. Only the manager field is mutable.

Expected

Non-critical asset values should be mutable. By non-critical, I mean:

Critical fields (like decimals and ID) should understandably not be mutable.

Reasoning

The need for making non-critical asset values mutable stems from the fact that real-world circumstances and needs change over time. Ensuring that certain asset properties are mutable can greatly benefit asset holders and the overall user experience on the Algorand platform, without posing any significant additional risk. The key reasons are outlined below:

Flexibility: Allowing changes to non-critical asset values, such as the asset name, ticker, and URL, provides asset creators and managers with the flexibility to adapt to evolving situations. For example, a company might undergo rebranding, necessitating changes to its asset name or ticker. Similarly, the project's website may move to a different domain, requiring an update to the URL. By enabling these modifications, we avoid creating unnecessary confusion for asset holders and potential investors.

Cost and Time Efficiency: If the asset properties are immutable, the only way for asset creators to modify them would be to create a new asset and perform a token swap with the existing asset holders. This process can be time-consuming, expensive, and may also involve legal and regulatory challenges. By allowing non-critical asset values to be mutable, we can significantly reduce the friction and cost involved in such changes.

Risk Mitigation: Granting the ability to modify non-critical asset values only to the creator address helps mitigate any potential risk associated with these changes. By restricting this capability to the creator address, we ensure that only authorized parties can make modifications, thus minimizing the risk of unauthorized changes or malicious activities. If the creator address private key is compromised, most often the projects needs to recreate the token anyway.

Transparency and Trust: Allowing asset creators to update non-critical asset values as needed can help maintain transparency and trust among asset holders. For instance, an outdated URL may lead to suspicions about the project's legitimacy. By keeping the asset information up-to-date, asset holders can have confidence in the asset's integrity and the project's commitment to the community.

Enabling the modification of non-critical asset values, such as the asset name, ticker, and URL, enhances the overall user experience. It allows asset creators to adapt to changing circumstances, saves time and money, mitigates risk, and fosters transparency and trust. By implementing this feature, we can create a more robust and adaptable ecosystem for asset management on Algorand.

Solution

Since manager field is already mutable, it is a matter of extending this mutability to other fields.

Dependencies

No extra dependencies.

Urgency

This would greatly improve the flexibility of assets and is a worthwhile change, albeit not urgent.

barnjamin commented 1 year ago

related https://github.com/algorand/go-algorand/issues/5264

jannotti commented 1 year ago

There could be any number of apps, on-chain or off, that depend on the current guarantee of immutability. A blockchain can't change important guarantees about data integrity.

grzracz commented 1 year ago

Are there examples of Mainnet smart contracts that check for specific tickers and/or names? As far as I am aware every self-respecting developer uses asset IDs, as they should. As for off-chain apps, I believe this to be a non-issue. These systems can easily adapt and showing an "outdated" name is a very mild inconvenience.

jannotti commented 1 year ago

Every single NFT that uses the URL (especially to hold a URL containing a hash) is promising that it is impossible for this NFT to change. That's an important guarantee. This proposal is very close to saying "Let's add clawback to every NFT on Algorand, after the fact."

On Fri, Apr 14, 2023 at 8:34 AM Grzegorz Raczek @.***> wrote:

Are there examples of Mainnet smart contracts that check for specific tickers and/or names? As far as I am aware every self-respecting developer uses asset IDs, as they should. As for off-chain apps, I believe this to be a non-issue. These systems can easily adapt and showing an "outdated" name is a very mild inconvenience.

— Reply to this email directly, view it on GitHub https://github.com/algorand/go-algorand/issues/5305#issuecomment-1508439402, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADL7T2KKU6DX77XV3IEF3TXBE74FANCNFSM6AAAAAAW6LLOYI . You are receiving this because you commented.Message ID: @.***>

grzracz commented 1 year ago

A valid argument. Could be solved by a requirement of being the creator and holding more than 50% of supply of a given asset. Therefore if you own the 1/1 NFT, you don't have to worry. If more than 50% of them have been sold out you don't have to worry either.

This makes me wonder how to make it so people could pool their supplies together to accept such a change. Perhaps a smart contract where people could deposit their assets, then in one transaction its sent to the creator address, the name is changed and then its sent back to the SC for people to claim it back?

I agree then it's not as simple as extending mutability, however this still should be possible (with enough security precautions).

bbroder-algo commented 1 year ago

Interesting consideration but not for now.