---
# System prepended metadata

title: Single governance spec (Plan B)

---

# Single governance specification (plan B)

Signle Governance (SG) is a governance subsystem that sits between the Lido DAO, represented by various voting systems, and the protocol contracts it manages. It protects protocol users from hostile actions by the DAO by allowing to cooperate and block any in-scope governance decision until either the DAO cancels this decision or users' (w)stETH is completely withdrawn to ETH.

## System overview

![image](https://hackmd.io/_uploads/rywEvPFUR.png)

The system is composed of the following main contracts:

- `SingleGovernance.sol` is a singleton that provides an interface for submitting governance proposals and scheduling their execution, as well as managing the list of supported proposers (DAO voting systems).
- `EmergencyProtectedTimelock.sol` is a singleton that stores submitted proposals and provides an interface for their execution. In addition, it implements an optional temporary protection from a zero-day vulnerability in the dual governance contracts following the initial deployment or upgrade of the system. The protection is implemented as a timelock on proposal execution combined with two emergency committees that have the right to cooperate and disable the dual governance.
- `Executor.sol` contract instances make calls resulting from governance proposals' execution. Every protocol permission or role protected by the DG, as well as the permission to manage this role/permission, should be assigned exclusively to one of the instances of this contract (in contrast with being assigned directly to a DAO voting system).

## [Proposal flow](https://github.com/lidofinance/dual-governance/blob/develop/docs/specification.md#proposal-flow)

## [Proposal execution and deployment modes](https://github.com/lidofinance/dual-governance/blob/develop/docs/specification.md#proposal-execution-and-deployment-modes)

## Upgrade to Dual Governance


### Contracts upgrade

To upgrade the system from `SingleGovernance` to `DualGovernance`, several steps are required:

#### Upgrade `Configuration` (not mandatory)

Deploy a new `Configuration` contract if any parameters need to be changed. If no changes are needed, the old contract might be used.

`ConfigurationProxy` implementation should be changed by `Executor`. 

#### `Escrow` master copy deployment

This deploy has to be done before `DualGovernance` deployment. No contracts affected.

Required params:
- `steth` address
- `wsteth` address
- `WithdrawalQueue` address
- `Configuration` address

#### Committee preparing

`Tiebreaker`/`Reseal` committee TBD.

#### `DualGovernance` deployment

Required params:
- `Configuration` address
- `EmergencyProtectedTimelock` address
- `EscrowMasterCopy` address
- `adminProposer` address

### Setup

For `SingleGovernance` to `DualGovernance` few steps required:

1. Change `Aragon` and `EasyTrack` proposal target from `SingleGovernance` to `DualGovernance` (or change Proxy implementation);
2. Call `setGovernance` on `EmergencyProtectedTimelock` to change switch proposer.

### Roles transfering

All roles should be granted to `Executor` contracts. There is no specific roles on contracts between Aragon/EasyTrack and `Executor`.