LIP-37: Execution Delegation Framework (EDF)

Seat: DSM guardian (Lido council daemon)
DelegationContract: 0x915F0Fa50E1af761B113b41c79ab33Bf4734C36E
Owner multisig: 0x2E6e175F57D7a18b3CA5490844034600FC18EF83
Delegate EOA: 0x5ecf14e7a3831D44e2F7d4542Ba98C6c96E47420

  • I have read the EDF Operator Key Custody Policy and my setup follows it
  • I created a dedicated owner multisig, at least 2-of-3, with signers held by different people
    on different devices
  • The multisig is used for nothing except this delegation contract
  • I deployed my DelegationContract from the official DelegationFactory, with a 48-hour
    (172800 s) cooldown
  • I verified on-chain that owner(), getDelegate(), getCooldown() and isTerminated() are what I intended
  • I set up 24/7 alerts on DelegateNominated, DelegateRevoked and Terminated

Operator : Bitwise
Seat :
Lido Oracle
DelegationContract : 0x56b3ea8016da18c6e8cd8135492d242f0de0dbbc
Owner multisig. : 0x6057526Da2Dc9Bd23a3C6F1b15C74De2D7593378
Delegate EOA. : 0x5416CAAb6f37BF81cb2dc7ce0a363AfB9DD92d57

- [x] I have read the EDF Operator Key Custody Policy and my setup follows it
- [x] I created a dedicated owner multisig, at least 2-of-3, with signers held by different people on different devices
- [x] The multisig is used for nothing except this delegation contract
- [x] I deployed my DelegationContract from the official DelegationFactory, with a 48-hour(172800 s) cooldown
- [x] I verified on-chain that owner(), getDelegate(), getCooldown() and isTerminated() are what I intended
- [x] I set up 24/7 alerts on DelegateNominated, DelegateRevoked and Terminated
1 Like

Operator: bloXroute
Seat: Lido Oracle
DelegationContract: 0x99Cd2EF33040879D40BBC77Df81863D97f13C64d
Owner multisig: 0x9462A9FfF5646d0b6517D8eac49de49277e89dB9
Delegate EOA: 0x375ABa35EA2011Af97b51bd395494C827d1C39BD

I have read the EDF Operator Key Custody Policy and my setup follows it
I created a dedicated owner multisig, at least 2-of-3, with signers held by different people on different devices
The multisig is used for nothing except this delegation contract
I deployed my DelegationContract from the official DelegationFactory, with a 48-hour (172800 s) cooldown
I verified on-chain that owner(), getDelegate(), getCooldown() and isTerminated() are what I intended
I set up 24/7 alerts on DelegateNominated, DelegateRevoked and Terminated

2 Likes

Seat: Lido Depositor Bot
DelegationContract: 0x6Aa249bA53A3abcaC52F91146583B3eE2Ee4C7F5
Owner multisig: 0x2E6e175F57D7a18b3CA5490844034600FC18EF83
Delegate EOA: 0x2df4013EF30b09100A027192E700114cD0D13900

  • I have read the EDF Operator Key Custody Policy and my setup follows it
  • I created a dedicated owner multisig, at least 2-of-3, with signers held by different people
    on different devices
  • The multisig is used for nothing except this delegation contract
  • I deployed my DelegationContract from the official DelegationFactory, with a 48-hour
    (172800 s) cooldown
  • I verified on-chain that owner(), getDelegate(), getCooldown() and isTerminated() are what I intended
  • I set up 24/7 alerts on DelegateNominated, DelegateRevoked and Terminated

Hi everyone!

The core contracts for the EDF upgrade have been deployed on Ethereum mainnet:

  • DepositSecurityModule v5: 0x39BB5d491e98A44D1bfe8047A737a81E296a63E0
  • LidoLocator implementation: 0x60E09F1791F1168d0450E4F100616B4a3F95119C

Deployed from lidofinance/core, branch feat/edf, commit e4d0404: core/deployed-mainnet.json at e4d0404c85b043b1b9fb1dd42d85c2535a7f30d8 · lidofinance/core · GitHub

The new DSM is configured with 6 guardian DelegationContracts and a quorum of 4. Both contracts will be activated by the upcoming on-chain vote; until then the current DSM and Locator implementation stay in use.

1 Like

Upgrade process

The vote is a single Aragon vote with two items.

Item 1 submits one Dual Governance proposal that atomically switches the protocol to EDF and DepositSecurityModule v5 in a single Agent.forward call (78 actions):

  • for each of the four oracle committees and each of the nine oracle operators: remove the operator’s EOA hot key from the HashConsensus and add the operator’s DelegationContract, keeping the quorum of 5 (72 actions);
  • upgrade the LidoLocator implementation so that its depositSecurityModule entry points to the new DSM v5, all other entries stay the same (1 action);
  • move STAKING_MODULE_UNVETTING_ROLE on StakingRouter from DSM v4 to DSM v5 (2 actions);
  • move TOP_UP_ROLE on TopUpGateway from the depositor bot EOA to the depositor bot DelegationContract (2 actions);
  • grant BUFFER_RESERVE_MANAGER_ROLE on Lido to the Easy Track EVMScriptExecutor (1 action).

Item 2 is executed by the Aragon Voting directly: add the SetDepositsReserveTarget Easy Track factory with the permission limited to Lido.setDepositsReserveTarget(uint256), per the CMC deposit reserve target proposal.

DSM v5 is already deployed with the guardian set moved to DelegationContracts (see the deployment post), so the vote does not touch the guardians: it only switches the protocol to the new module. The guardian quorum stays 4 of 6, Stakely takes the seat of Kiln.

Oracle committees

# Committee HashConsensus Quorum
1 AccountingOracle 0xD624…B288 5
2 ValidatorsExitBusOracle 0x7FaD…355a 5
3 CSFeeOracle 0x7109…88e4 5
4 Curated Module FeeOracle 0x902D…1aFb 5

Oracle members (the same rotation on every committee)

# Operator Removed EOA Added DelegationContract
1 Instadapp 0x7318…1d12 0xE75A…C1b3
2 Caliber 0x4118…33F3 0xc77d…637d
3 Staking Facilities 0x4043…3eA2 0xc744…1749
4 Chorus One 0x8dB9…4b78 0x56B3…DBBC
5 P2P 0x007D…89b5 0x4E3F…0FEe
6 ChainLayer 0xc79F…9BAf 0xd524…6Bdb
7 bloXroute 0x61c9…a1c8 0x99Cd…C64d
8 MatrixedLink 0xe57B…35C9 0xC4f2…A891
9 Stakefish 0x042a…3922 0x5e8E…9C6f

DSM guardians (already set on DSM v5, not changed by the vote)

# Operator DSM v4 guardian EOA DSM v5 guardian DelegationContract
1 Lido dev team 0x5fd0…19F1 0x915F…C36E
2 P2P 0xa56b…57d8 0xe387…411E
3 Staking Facilities 0xf82D…ab43 0x3550…26c1
4 Blockscape 0x7912…6AaF 0xDc15…0C44
5 Stake.fish 0x4B87…498E 0x031E…5497
6 Stakely (takes the seat of Kiln) Kiln 0x6d22…1389 0x6A22…d61d

Contracts and roles

What Before After
DepositSecurityModule (LidoLocator entry) v4 0xF573…e9Be v5 0x39BB…63E0
LidoLocator implementation 0xF2Ff…2313 0x60E0…119C
STAKING_MODULE_UNVETTING_ROLE on StakingRouter DSM v4 DSM v5
TOP_UP_ROLE on TopUpGateway depositor bot EOA 0xF82a…0f17 depositor bot DelegationContract 0x6Aa2…C7F5
BUFFER_RESERVE_MANAGER_ROLE on Lido Agent Agent and Easy Track EVMScriptExecutor 0xFE59…F977
Easy Track factories - SetDepositsReserveTarget 0x62E9…62b0, trusted caller CMC multisig, cap 9,600 ETH

The vote script and the fork tests: lidofinance/scripts#682.

5 Likes

Following the single-stage vote process, the vote text for LIP-37: Execution Delegation Framework (EDF) has been finalized and frozen on IPFS - this is the exact text the DAO will vote on.

The on-chain vote is planned to start on Wednesday, September 16. Once the vote is live, a link to it and instructions for verifying the vote items will follow in this thread.

2 Likes

EDF audits finalized:

2 Likes