Comment on page
We will use the
UpgradeBeaconpattern to implement three upgradable contract types:
Each upgradable contract will have:
- the permanent address of the contract that external entities interact with
- holds the storage of the contract
- uses the logic specified by
delegatecallto forward contract calls from
- stores the (mutable) address of the
- accepts new
Implementationaddresses from its
Controller(thereby performing upgrades for all
- specifies the logic of the contract
- code is the same as a normal, non-upgradable contract implementation (though it should use upgrade-safe storage)
Each of the three
UpgradeBeaconcontracts will share a the same
Controller— the contract with the power to perform upgrades.
The Controller contract will have two roles: controller and saver.
- is a transferrable role that should be performing upgrades in almost every case.
- will be set to the
GovernanceRouter Proxy, so that the Governance xApp ultimately controls the upgrades of the entire system. Note that this creates a circular dependency which makes upgrades of the
GovernanceRouter Implementationparticularly sensitive.
- is a transferrable(?) role that is responsible for recovering the system in a catastrophic failure case. Actions performed by the
saverwill be subject to a timelock enforced by the Controller contract.
- will be set to a multisig contract where the signatories are a set of known / trusted community members. the signatories for the
savermultisig be the same on every chain
Upgrade Setup Diagram 1
Upgrade Setup Diagram 2