Is initializer no longer recommended in the latest implementation of OpenZeppelin Contracts?

I’ve been using Ownable contract in my project, which is a relatively old version.

The Ownable has the initialize function that can set up the ownership only once. It is useful to call the initializer instead of constructor especially when I use an upgradable proxy contract. The proxy contract can recognize the ownership of the implementation by calling the initializer when linking the implementation address with its proxy. If the address of the owner is set by calling its constructor, the proxy contract cannot find the owner address after linking.

However, in the latest implementation which is 0.6.x, I found many of the contracts on libraries use a constructor instead of an initialize function. Is it recommended that we should use constructor? How can we avoid the problem that proxies cannot see the ownership value, which is saved on the implementation’s storage?

1 Like

Hi @shunp,

Welcome to the community :wave:

For upgradeable smart contracts you should use OpenZeppelin Contracts Ethereum Package.

from OpenZeppelin Contracts Ethereum Package:

This package contains the same contracts as the vanilla OpenZeppelin Contracts, but modified for use with upgradeable contracts. The main difference is that all contracts in this package are potentially upgradeable : you will notice that no contracts have constructors defined, but use initializer functions instead. Also, this package is set up as an Ethereum package, and provides a small set of pre-deployed logic contracts that can be used directly via the OpenZeppelin SDK, without needing to deploy them again.

All contracts have an UpgradeSafe suffix to avoid confusion with their counterparts in OpenZeppelin Contracts. For example, ERC20 becomes ERC20UpgradeSafe .

All in all, you should use this package instead of @openzeppelin/contracts if you are creating upgradeable contracts .

I created an example of using Ownable in an upgradeable contract to a recent question:

I also recommend looking at Role-Based Access Control for more finely grained access control.

Hi @abcoathup,

Thank you for your quick response!

I just thought the OpenZeppelin Contracts Ethereum Package would be deprecated after 0.6.x, and should use this one:, but it seems I was wrong and select the former one in our project.

Thank you for teaching me. I look forward to using upgradeable proxy contracts on 0.6.x.

1 Like

Hi @shunp,

The ideal would be to have a single OpenZeppelin Contracts that could be used with both regular and upgradeable contracts. Though that would mean having both constructors and initializers in contracts, requiring extra gas and could be confusing to the community. For now we have OpenZeppelin Contracts and then a fork for upgradeable contracts OpenZeppelin Contracts Ethereum Package.

1 Like