Q2 roadmap for OpenZeppelin Upgrades

Full text reproduced below.

Last quarter we focused most of our work on the CLI. We introduced regular deploys in CLI 2.8, and developed the first version of the upgradeability transpiler.

For this quarter, rather than jumping on to the ambitious SDK 3.0 project, we’ve decided to make a deep dive into the building blocks of our upgradeability offering and mostly focus on the @openzeppelin/upgrades library. After some consideration we think there’s a lot of untapped potential in this library and we want to take some time and give it the attention it deserves.

Moving Proxies to Contracts

For a while we’ve wanted to move the actual Solidity source code for the proxies to our OpenZeppelin Contracts library. We’ve finally decided to make the move now. We expect the contracts to receive more continued maintenance and reviews once they’re under the Contracts umbrella. We may also push towards more proxy standards being included over there.

Redesigning the JavaScript Library

The library has existed since the beginning of this project as an alternative to the CLI, but the focus has mainly been on improving upgradeability as managed through the CLI. Thus, several issues in the library haven’t been tackled and the experience of using it is not as good as we’d want it to be. We now think the library has value in itself, so we want to make it better and easier to use, in particular designing a good API that is flexible and powerful at the same time.

We think this is an essential building block for upgradeability, and we hope these improvements allow upgrades to be integrated into tools other than our own CLI, and other use cases that we haven’t thought of ourselves.

Standalone Transpiler

The “upgradeability transpiler” is a Solidity preprocessor that converts a contract’s constructor into an initializer functions, moving all of the storage initialization into it and taking other necessary precautions when deploying contracts behind proxies. See our guide on Writing Upgradeable Contracts to learn more.

We continue betting that the transpiler will become the standard way to get contracts ready for upgradeability. Since we will improve the use of the OpenZeppelin Upgrades library on its own, we’ve also decided to make the transpiler available as a standalone program, so that both can be potentially used in combination independently of the CLI.


Hi @frangio,

I’m super excited by the Q2 roadmap: Proxies in OpenZeppelin Contracts, JavaScript library and the transpiler!!

1 Like

Keep up the good work guys! Really looking forward to these changes.


Are we going to see the @openzeppelin/upgrades package support 0.6 anytime soon? I’m working with the new 3.0 contracts and there is a solc version conflict at the moment. I would love to know a timeline for Solidity 0.6 support!

1 Like

Some information about that in this issue (see my linked comment):

In summary, the proxies will be moved to OpenZeppelin Contracts 3.1, and the application contracts are being deprecated. I can’t give a precise timeline at the moment but it will be at least a few weeks.

Can you share what contracts you’re using?

1 Like

I’m using the ProxyFactory to instantiate minimal proxies. For the time being, I’ve simply copied the implementation from the solc-0.6 branch.

I tried to link to the branch directly in package.json but yarn doesn’t support linking to lerna packages.

1 Like

Copying those is good. We’ll let you know when we’ve migrated the proxies to Contracts! A factory will definitely be included as well.