Changing name of ERC20 token in OpenZeppelin Contracts 3.x

Hello, may I revisit this please (Change name of deployed erc20 token)?

The above code for changing the name does work in v.2.3.0
but in 3.1.0, I am unable to override name() as it is not a virtual function in erc20.sol
Are there plans to change this function (and symbol() too) back to virtual?

Thanks

2 Likes

Hi @guiguy,

I would be cautious about changing things such as token name as users (as well as applications/services) may not expect this to change. (Though changing the name isn’t prohibited in the EIP).
I would recommend being clear with users under what circumstances these changes would occur.
Each application/service may handle metadata such as names their own way, so you may need to get the name updated on each application/service.

The code I provided worked in OpenZeppelin 2.x but OpenZeppelin 3.x uses Solidity 0.6 and doesn’t support overriding name().

There is discussion on making some functions virtual: https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2154

Can you share what your use case is for changing a token name?

Just thinking ahead in the event we need to rebrand but keeping the contract. It would probably be just the token symbol rather than the name that would need to be changed.

1 Like

Hi @guiguy,

At this stage it isn’t possible with OpenZeppelin Contracts 3.x (but you can do this in OpenZeppelin Contracts 2.x).

I would still caution against this if you can avoid it. You will likely have to change this (if you can) on mutliple applications/services.

If possible, choose a token name and symbol that is future proof.

My opinion, this is an unnecessary restriction on overriding. In my case this is a desire of my client to have token name changeable for potential rebranding. Already discussed with the client, still a desired feature, so I’m going to have to make my own copy of OpenZeppelin’s code to make it changeable. I believe it’s best to leave it up to developers whether or not they want to override such functionality, rather than completely restrict it.

1 Like

Hi @sapph1re,

Welcome to the community :wave:

There is an open discussion on virtual view functions.
Would you mind adding your use case to this?

I am cautious about changing name/symbol due to how this may be handled by applications/services but on the flip side, I dislike the community having to clone the OpenZeppelin Contracts ERC20 implementation if they want to support this.

1 Like