Is it safe to use Crowdsales (OpenZeppelin Contracts 2.x) together with the upgradable version of ERC20?

Support Contracts
1

hi there!

we are planning to do a Crowdsale and we wanted to use the library of OpenZeppelin. I understand that it won’t be migrated to Solidity 0.6 (Where are Crowdsale contracts in OpenZeppelin Contracts 3.0?), but is it safe to use the old version together with the upgradable version of ERC20?

thanks.

1 Like
2

Hi @Cris,

Welcome to the community :wave:

As you are creating a fungible token, I suggest looking at Points to consider when creating a fungible token (ERC20, ERC777)

When creating an upgradeable token, you should also consider the governance around when and how an upgrade would be made.

In general you should be able to use an ERC20 from OpenZeppelin Contracts 3.x with a Crowdsale from OpenZeppelin Contracts 2.x, though you would need to have the Crowdsale and Token in separate projects due to the differing Solidity versions.
:warning: You should appropriately test and audit any such solution.

Areas to watch out for is any functionality not covered by the EIP such as minting if you were using a MintedCrowdsale.

3

Hey @abcoathup!

Thank you very much for that quick response. And yes, we already created an ERC20 token using OZ 3.0. And we actually plan to create a new project, a separate one, for the Crowdsale contracts.

Excuse my ignorance, what do you mean by when you say “When creating an upgradeable token, you should also consider the governance around when and how an upgrade would be made.”

thanks.

2 Likes
4

Hi @Cris,

When a contract is upgradeable, whomever controls the upgrade can change functionality in that contract. In terms of a token, this could include changing or freezing balances of any token holders, or changing the total supply/minting additional tokens.

The community has to place trust in whomever has the control.

This is why it is a good idea to decide ahead of time the circumstances under which an upgrade would occur and discuss this with your community, including documenting this.

Upgrades governance could be via a multisig. Some of the signatories could be token holders not part of the project. Some of the signatories could be from the wider community. The upgrade could be controlled by a DAO.

OpenZeppelin Upgrades: Step by Step Tutorial for Truffle shows transferring control of upgrades to a Gnosis Safe.

5

Hi @abcoathup,

I see what you mean. Yeah, we are actually looking into that. So your recommendation is to transfer control of upgrades to a Gnosis Safe? Or are there other options?

Thanks.

1 Like
6

Or shall we also do it this way. During development, we make it upgradable contract, but before the final deployment, we convert it to non-upgradable to avoid any issues on the governance. Besides, is it practical to have an upgradeable ERC20 smart contract?

Thanks.

1 Like
7

Control of upgrades needs to be kept secure (due to what you can do with upgrades). Transferring control to a multisig such as Gnosis Safe is recommended.

You could use a DAO. It depends on what governance you want/need.

It really depends on your use case. Using upgrades your community have to trust you, so it depends what the token is being used for and what value it has.

You should consider what would you upgrade in your ERC20 smart contract. My personal preference is to keep ERC20 tokens as simple as possible but future support for meta transactions/permit as an example could be a candidate. You may also want to consider any scaling needs, whether your solution requires layer 2 and what you may need for that.

8

hi @abcoathup! thank you for all these information. yeah I guess we should keep it simple this time. I got your point. thanks so much for the advice.

1 Like