Proxy upgradeability deadlines and time limits

Sorry, I have butchered a bit your upgradeability contracts, created my own version out of it:
So the difference is that it has _deadline variable, which is a block after which it is impossible to upgrade the contract anymore, and another variable is _upgradeBlock, which restricts frequency of upgrades.
These changes help me to support investors’ confidence, so that they won’t need to actually trust me after a certain point, and I won’t be able to freely upgrade the protocol maliciously, or no fiasco like what recently happened with PAID network will happen. Upgradeability is a potential point of failure and has to have some sort of restrictions. If it is possible, will OpenZeppelin library have an official implementation of this functionality?

1 Like

Hi @SamPorter1984,

Welcome to the community :wave:

Some interesting ideas for controlling upgrades.

I would suggest rather than modifying the proxy, that you place any required logic at the upgrades admin level.

If you modify the proxy, then you should appropriately test and audit the code. You won’t be able to use OpenZeppelin Upgrades Plugins for deploying and upgrade safety checks. Though you could use the Upgrades Plugins for testing and this could be used for upgrade safety checks.

We recommend that the upgrades admin (owner of ProxyAdmin contract) should be a multisig.

We have a guide on how to upgrade via a multisig using OpenZeppelin Defender:

We also have guides upgrading via Gnosis Safe:

OpenZeppelin Defender also supports a PartiallyDelayedMultisig variant developed by dYdX.

You could also look at using TimelockController to add timelocks to actions

From the PAID network postmortem it sounds like they had a single key controlling the upgrades admin which was compromised, rather than using a multisig.

For investor confidence you could have some of your investors and or community be owners of the multisig controlling the upgrades.

As an example, the Graph Council has a mix of stake holders for their multisig. See some of our Multi-signature wallet resources.

I suggest checking out OpenZeppelin Defender (if you haven’t already):

1 Like

Thanks for the warm welcome.
Yeah, the project will definitely require OpenZeppelin audit. After a bit while, I guess.
I am not sure about multisig just yet, because investors are anonymous, and the governance is not ready yet. I however would probably use multisig with myself for the time being, while the governance is not ready.
So I have updated the contract and it’s now trust minimized. The thing is that the logic is not being set suddenly, right, and instead it’s being stored in NEXT_LOGIC_SLOT for a month, so that the investors can review it and maybe exit if developers or the governance is malicious.
Basically I believe it solves so-called “upgradeability bug”, and Consensys won’t be so smug about it anymore.

1 Like

Hi @SamPorter1984,

My recommendation would be to use the proxies as is with OpenZeppelin Upgrades Plugins and use a multisig for the upgrades admin, ideally with multiple team members.

I would be very cautious with custom proxies due to the risk of adding a vulnerability or managing to lock yourself out. I would recommend appropriate (100% coverage) testing and auditing if you do go down this path.

For governance you could look at the discussions on Ideas for Snapshot voting integration with Defender Admin.

1 Like

Thank you for strongly suggesting an audit. I just realized that I forgot about storage collisions completely and cringed at my op post. This is worst, it seems like writing immutable code is the hardest thing ever. But at the same time most fun. Fixed it now. Sure I will probably have an audit, and not one probably. Certainly wouldn’t recommend using it for anybody lurking around.

1 Like