So we are getting ready to deploy a new contract for our application. The only thing we are uncertain about is how to use gnosis safe and the current admin attached to me .openzeppelin/mainnet.json file.
Ofc we could always deploy the contract and create a “new” admin, but we may also have new contracts in the future and this would just create more proxy admins when we could just delegate from the already existing one.
So the reiterate the question, since the deployer is the initializer thus is also the “proxy admin” how can i use my proxy admin which is set to a gnosis safe to deploy a new contract? Or maybe i’m thinking about this the wrong way?
Hello @Dellybro! There are four contracts/addresses involved in the deployment of an upgradeable contract with the plugins:
The implementation, a.k.a. logic contract
The proxy, a.k.a. storage/memory contract
The proxyAdmin contract, the only address able to operate with the proxy directly
The owner of the proxyAdmin
Due to how the Transparent Proxy Pattern works, while the proxyAdmin is the only one that can upgrade the proxy, the owner is the only one who can command the proxyAdmin to do so.
The first time you deploy an upgradeable contract in a project, a ProxyAdmin contract is deployed and its address is stored in your project’s manifesto under the .openzeppelin folder. Subsequent deployments will have this contract set as proxyAdmin too, but you shouldn’t worry too much about this technicalities.
What I’d suggest you do is to keep deploying upgradeable contracts using the same proxyAdmin (this is what happens by default) and in turn transfer ownership of that proxyAdmin to your Gnosis Multisig by using the transferProxyAdminOwnership function.
@martriay I appreciate the knowledge, as i have figured most of this out. So if i can just clarify what you are suggesting
Event though the admin inside of the .openzeppelin folder is no longer set to my original “deployer”, still use the “original deployer” as the account to launch the contract
After the contract is launched called admin.transferProxy to the gnosissafe
This should work without any issues? I think what i’m most confused about is the original deployer is no longer the “owner” of the proxy admin, our gnosis safe is. So if we launch using the deployer address and the admin attached to the .openzeppelin, i feel like the deployment would fail, but like i said i could be confused about something here.
If I understood correctly, you only changed the admin of a particular proxy but didn’t change anything about the ProxyAdmin, right? If so, the admin address in your manifest file should still be owned by your deployer address and work fine for future deployments.
No, my suggestion was to have your ProxyAdmin own all of your proxies and transfer its ownership (of the ProxyAdmin, not the proxies) to the multisig. Check the ProxyAdmin contract’s source code and you’ll see the kind of contract that is expected to own and manage the proxies.
Isn’t it? Did you execute transferProxyAdminOwnership() on your ProxyAdmin (1) or did you execute changeAdminForProxy() on one of your proxies (2)?
If you did the former, then your proxies are still owned by ProxyAdmin which in turn is owned by your multisig (this is the right thing to do!)
If you did the latter, then your deployer address is still owning the ProxyAdmin and one of your proxies is owned by the multisig (not ideal)
In any case, it doesn’t matter if your deployer address owns the ProxyAdmin or not, you can still deploy new upgradeable contracts managed by it. I strongly suggest you read more about the Transaprent Proxy Pattern before moving forward.
Ya so we called transferOwnership, so then when our deployer address launches a new contract, the proxy admin should be the current proxy admin and the gnosis safe should be the “upgrader” and in any case should be fine.
I have read all the documentation. The only issue with the documentation is it doesn’t show an example of what i’m doing. Which i feel like a lot of people would do.
Transfer ownership to gnosis safe
Launch more contracts as another layer for your previous contracts
It would be nice to update the documentation to specifically go over all possible scenarios. The documentation only shows the scenario of
But not adding more contracts to your network contracts.