Dual Governance Rollout plan

[kadmil]

Abstract

In a particular way, Dual Governance rollout is a one-way decision: any mistake made in tweaking the upgradability of the protocol risks causing irreparable damage. To make sure the rollout is safe to propose, Contributors have made specific preparations in order to make sure that 1) the deployed code functions as expected; 2) the rollout itself is doubly and triply checked.

Beyond code audits: preparing the deployment

It’s worth mentioning that the spec, code and parameters going to the Dual Governance proposal had been thoroughly audited by a bunch of third parties. Mechanism specification had seen the review by Certora and RV; code was formally verified by Certora and RV and audited by StateMind and OpenZeppelin, and parameters chosen had been challenged and tested by 20 and CollectifLabs

What’s usually left to check is:

• If the code deployed matches the audited version.
• If the protocol roles and parameters required are set correctly (and what specifically “set correctly” means).
• If the vote for switching the mechanism on is correct.

Smoke test

Usually, Lido Contributors strive to have as ready-for-vote deployment as possible. What that means is: contracts are deployed, potentially have a handful of calls made to set everything up — and left as-is for the DAO vote.

In the case of Dual Governance, though, a more thorough mainnet smoke test was performed. Dual Governance makes use of Emergency Committee: there are methods allowing a dedicated multisig to pause Dual Governance pipeline or even reset it fully in case of unforeseen technical vulnerability getting detected. In order to ultimately check the emergency brake works, it simply had been triggered after the mainnet contracts deployment. This smoke test served two purposes:

• Check the brakes work on the specific bytecode at specific Ethereum addresses — as an ultimate functional test.
• Make sure Emergency Committee members know and understand how to act in case their action is required.

After Emergency reset had been triggered, the temporary governance (in this case, a Contributors multisig) had set the DG parameters to the final state and had renounced any access or roles in Dual Governance it had.

Roles, rights, and ownership

In order for Dual Governance to be useful, 1) it must “guard” DAO’s access to high-leverage roles and rights; 2) with no way to circumvent the guard. Contributors have compiled the list of roles, rights, and permissions among Lido-related smart contracts: dual-governance/docs/permissions-transition/permissions-transition-mainnet.md at feat/deploy-plan · lidofinance/dual-governance · GitHub. On a high-level:

1. Aragon Voting passes all the roles (except treasury management, insurance fund, and all roles related to Voting and TokenManager contracts) and ownerships to Aragon Agent.
2. Aragon Agent:
   1. Grants a role for Agent.forward to Dual Governance Executor contract.
   2. Revokes a role for Agent.forward from Voting.
3. EVMScriptExecutor/EasyTrack remains as-is (Voting is owner of EVMScriptExecutor and holder of DEFAULT_ADMIN_ROLE for EasyTrack, but given Voting isn’t role manager / admin on things which need to be under DG — Voting can’t grant permissions necessary to breach “DG protection”).
4. Committees remain as-is to maintain business continuity.
5. Immutable variables remain as-is until future updates.
6. All EasyTrack factories remain as-is until future updates.

The document referenced has a full-blown list of actions and role changes required for the implementation. Need to note that even for a “do as little as possible” markup 50 different vote actions are required only to make minimal viable roles shift.

DAO Vote markup

50+ action items in the vote are tough to manage for anyone. In order to make sure no operational error has slipped in, a couple of ideas were implemented:

1. Vote actions are stored in a “read-only” smart contract onchain (DGLaunchOmnibusMainnet | Address 0x1DB8a9313785b78f7d0a201C5E0BE007f1eb63b4 | Etherscan). That allows for auditability, as well as has a method to check if the vote number X match the expected plan.
2. There’s an on-chain contract (DGRolesValidatorMainnet | Address 0x31534e3aFE219B609da3715a00a1479D2A2d7981 | Etherscan) to make an acceptance test on roles, rights, and ownership transferred during the vote. It’s called by the end of the vote, reverting the vote execution transaction in case anything unexpected is detected.
3. There’s an on-chain contract (DGLaunchStateVerifier | Address 0xd48c2fc419569537Bb069BAD2165dC0cEB160CEC | Etherscan) to check the Dual Governance state during the vote execution. In case any part of the setup ends up in other-than-expected state, the vote execution would get reverted as well.
4. Given the dynamic nature of the Dual Governance timelock, operational smart contract (TimeConstraints | Address 0x2a30F5aC03187674553024296bed35Aa49749DDa | Etherscan) preventing vote execution at random times during the day are implemented. Long story short — that way one can enforce specific operational concerns on timing without making the core mechanics more complex.

All contracts used in the vote had been reviewed by auditors, providing third party verification not only for mechanics implementation, but to the rollout plan as well.

Switching Dual Governance on

The onchain vote to switch Dual Governance on is scheduled for the 25th of June. Feel free to ask any questions here, and if you hold LDO — please, make sure to send your vote =)

[kadmil]

To “switch on” Dual Governance, a number of roles must be transferred between the Aragon Voting and Aragon Agent contracts. The detailed plan for this transition is outlined here.

The vote consists of 57 action items that will:

I. Reassign roles according to the specification (items 1-50)
II. Perform minor cleanup related to the RecoveryVault app in the DAO Kernel contract (items 51-53)
III. Trigger on-chain checks to verify the state of role assignments (item 54)
IV. Submit the Dual Governance motion to finalize the role transition by revoking the Aragon Agent’s RUN_SCRIPT_ROLE and EXECUTE_ROLE from the Aragon Voting contract (item 55)
Note: Until this motion passes and is executed, the Aragon Voting contract retains direct access to roles and permissions on the Aragon Agent contract.
V. Trigger on-chain checks to verify the state of Dual Governance (item 56)
VI. Enforce the vote execution timeframe with on-chain call to TimeConstraints smart contract (item 57)

As an additional safety measure, the voting script has been embedded into the on-chain smart contract at address 0x1DB8a9313785b78f7d0a201C5E0BE007f1eb63b4, which was reviewed along with the deployment verification by Statemind team. The contract includes a read-only method isValidVoteScript which will return True for vote #189 if the calls included in that vote match the list reviewed by Statemind.

[zuzu_eeka]

On-chain Voting has started!

We’re excited to announce that voting has officially begun for a Dual Governance proposal: Vote #189!

This is a historical moment in Lido’s journey toward strengthening decentralization and aligning long-term incentives. Many contributors have dedicated significant time and effort to bring this proposal to the current stage.

Vote #189 is now live, and your participation is crucial!

Voting closes:
Main voting phase ends on Jun 28 at 14:00 UTC.

Cast your vote Yes or No for the proposal by the deadline to make your voice heard.

To learn more about the proposal and how to verify the vote items, please follow the instructions outlined in this guide.