Sorry, I have butchered a bit your upgradeability contracts, created my own version out of it: https://github.com/SamPorter1984/RAID/blob/main/contracts/CustomProxy.sol
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?
Hi @SamPorter1984,
Welcome to the community 
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.
https://docs.openzeppelin.com/learn/preparing-for-mainnet#set-admin
We have a guide on how to upgrade via a multisig using OpenZeppelin Defender:
https://docs.openzeppelin.com/defender/guide-upgrades
We also have guides upgrading via Gnosis Safe:
- OpenZeppelin Upgrades: Step by Step Tutorial for Truffle
- OpenZeppelin Upgrades: Step by Step Tutorial for Hardhat
OpenZeppelin Defender also supports a PartiallyDelayedMultisig variant developed by dYdX.
https://docs.openzeppelin.com/defender/admin#gnosis-multisigwallet
You could also look at using TimelockController to add timelocks to actions
https://docs.openzeppelin.com/contracts/3.x/api/access#timelock
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):
https://defender.openzeppelin.com/
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.
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.
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.