# LIP-37: Execution Delegation Framework (EDF) **URL:** \ **Category:** The LIP - Lido Improvement Proposal - Process\ **Created:** [July 17, 2026, 1:25pm UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746 "2026-07-17T13:25:03Z")\ **Posts on this page:** 13\ **Page:** 2
**Author:** ![chasing.rainbows](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/chasing.rainbows/32/5689_2.png) [@chasing.rainbows](https://research.lido.fi/u/chasing.rainbows)\ **Post date:** [September 7, 2026, 3:07pm UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/21 "2026-09-07T15:07:29Z")
**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 ---
**Author:** ![Abdul\_Khan](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/abdul_khan/32/7100_2.png) [@Abdul\_Khan](https://research.lido.fi/u/Abdul_Khan)\ **Post date:** [September 8, 2026, 9:05am UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/22 "2026-09-08T09:05:00Z")
**Operator : Bitwise Seat :** Lido Oracle **DelegationContract :** 0x56b3ea8016da18c6e8cd8135492d242f0de0dbbc **Owner multisig. :** 0x6057526Da2Dc9Bd23a3C6F1b15C74De2D7593378 **Delegate EOA. :** 0x5416CAAb6f37BF81cb2dc7ce0a363AfB9DD92d57 ```auto - [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 ``` ---
**Author:** ![carlo\_blxr](https://avatars.discourse-cdn.com/v4/letter/c/d26b3c/32.png) [@carlo\_blxr](https://research.lido.fi/u/carlo_blxr)\ **Post date:** [September 8, 2026, 6:59pm UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/23 "2026-09-08T18:59:28Z")
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 ---
**Author:** ![chasing.rainbows](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/chasing.rainbows/32/5689_2.png) [@chasing.rainbows](https://research.lido.fi/u/chasing.rainbows)\ **Post date:** [September 9, 2026, 1:37pm UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/24 "2026-09-09T13:37:28Z")
**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 ---
**Author:** ![chasing.rainbows](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/chasing.rainbows/32/5689_2.png) [@chasing.rainbows](https://research.lido.fi/u/chasing.rainbows)\ **Post date:** [September 9, 2026, 4:39pm UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/25 "2026-09-09T16:39:51Z")
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](https://github.com/lidofinance/core/blob/e4d0404c85b043b1b9fb1dd42d85c2535a7f30d8/deployed-mainnet.json) 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. ---
**Author:** ![chasing.rainbows](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/chasing.rainbows/32/5689_2.png) [@chasing.rainbows](https://research.lido.fi/u/chasing.rainbows)\ **Post date:** [September 11, 2026, 3:34pm UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/26 "2026-09-11T15:34:34Z")
## 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](https://research.lido.fi/t/proposal-add-easy-track-factory-for-deposit-reserve-target-management-by-cmc/11827). DSM v5 is already deployed with the guardian set moved to DelegationContracts (see the [deployment post](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/25)), 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 | [0xD624B08C83bAECF0807Dd2c6880C3154a5F0B288](https://etherscan.io/address/0xD624B08C83bAECF0807Dd2c6880C3154a5F0B288) | 5 | | 2 | ValidatorsExitBusOracle | [0x7FaDB6358950c5fAA66Cb5EB8eE5147De3df355a](https://etherscan.io/address/0x7FaDB6358950c5fAA66Cb5EB8eE5147De3df355a) | 5 | | 3 | CSFeeOracle | [0x71093efF8D8599b5fA340D665Ad60fA7C80688e4](https://etherscan.io/address/0x71093efF8D8599b5fA340D665Ad60fA7C80688e4) | 5 | | 4 | Curated Module FeeOracle | [0x902D64c93F6595339aA46105627a085591051aFb](https://etherscan.io/address/0x902D64c93F6595339aA46105627a085591051aFb) | 5 | ### Oracle members (the same rotation on every committee) | # | Operator | Removed EOA | Added DelegationContract | | --- | --- | --- | --- | | 1 | Instadapp | [0x73181107c8D9ED4ce0bbeF7A0b4ccf3320C41d12](https://etherscan.io/address/0x73181107c8D9ED4ce0bbeF7A0b4ccf3320C41d12) | [0xE75A431A98487DC69A14Bdd13d858E3238e9C1b3](https://etherscan.io/address/0xE75A431A98487DC69A14Bdd13d858E3238e9C1b3) | | 2 | Caliber | [0x4118DAD7f348A4063bD15786c299De2f3B1333F3](https://etherscan.io/address/0x4118DAD7f348A4063bD15786c299De2f3B1333F3) | [0xc77d0Bf3AA4778E36a89CDC8bbc9c34d8060637d](https://etherscan.io/address/0xc77d0Bf3AA4778E36a89CDC8bbc9c34d8060637d) | | 3 | Staking Facilities | [0x404335BcE530400a5814375E7Ec1FB55fAff3eA2](https://etherscan.io/address/0x404335BcE530400a5814375E7Ec1FB55fAff3eA2) | [0xc7442d4d8F3FfEa0fA4a18Ad3062c8137cE21749](https://etherscan.io/address/0xc7442d4d8F3FfEa0fA4a18Ad3062c8137cE21749) | | 4 | Chorus One | [0x8dB977C13CAA938BC58464bFD622DF0570564b78](https://etherscan.io/address/0x8dB977C13CAA938BC58464bFD622DF0570564b78) | [0x56B3eA8016Da18C6E8CD8135492d242F0dE0DBBC](https://etherscan.io/address/0x56B3eA8016Da18C6E8CD8135492d242F0dE0DBBC) | | 5 | P2P | [0x007DE4a5F7bc37E2F26c0cb2E8A95006EE9B89b5](https://etherscan.io/address/0x007DE4a5F7bc37E2F26c0cb2E8A95006EE9B89b5) | [0x4E3F2DEeb59eB9a205D82D17647b3e56422e0FEe](https://etherscan.io/address/0x4E3F2DEeb59eB9a205D82D17647b3e56422e0FEe) | | 6 | ChainLayer | [0xc79F702202E3A6B0B6310B537E786B9ACAA19BAf](https://etherscan.io/address/0xc79F702202E3A6B0B6310B537E786B9ACAA19BAf) | [0xd524101C3c40f71Fce7B9312D299603880a06Bdb](https://etherscan.io/address/0xd524101C3c40f71Fce7B9312D299603880a06Bdb) | | 7 | bloXroute | [0x61c91ECd902EB56e314bB2D5c5C07785444Ea1c8](https://etherscan.io/address/0x61c91ECd902EB56e314bB2D5c5C07785444Ea1c8) | [0x99Cd2EF33040879D40BBC77Df81863D97f13C64d](https://etherscan.io/address/0x99Cd2EF33040879D40BBC77Df81863D97f13C64d) | | 8 | MatrixedLink | [0xe57B3792aDCc5da47EF4fF588883F0ee0c9835C9](https://etherscan.io/address/0xe57B3792aDCc5da47EF4fF588883F0ee0c9835C9) | [0xC4f2704273598d51A0ec76A31C12553ec8f5A891](https://etherscan.io/address/0xC4f2704273598d51A0ec76A31C12553ec8f5A891) | | 9 | Stakefish | [0x042a9e5acCfa17e28300F1b5967f20891E973922](https://etherscan.io/address/0x042a9e5acCfa17e28300F1b5967f20891E973922) | [0x5e8Ed9f10307eD6FA793A347e4D0f407D00B9C6f](https://etherscan.io/address/0x5e8Ed9f10307eD6FA793A347e4D0f407D00B9C6f) | ### 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 | [0x5fd0dDbC3351d009eb3f88DE7Cd081a614C519F1](https://etherscan.io/address/0x5fd0dDbC3351d009eb3f88DE7Cd081a614C519F1) | [0x915F0Fa50E1af761B113b41c79ab33Bf4734C36E](https://etherscan.io/address/0x915F0Fa50E1af761B113b41c79ab33Bf4734C36E) | | 2 | P2P | [0xa56b128Ea2Ea237052b0fA2a96a387C0E43157d8](https://etherscan.io/address/0xa56b128Ea2Ea237052b0fA2a96a387C0E43157d8) | [0xe387Ba1d5C9f6306eCe9ac949C7fB6233dD5411E](https://etherscan.io/address/0xe387Ba1d5C9f6306eCe9ac949C7fB6233dD5411E) | | 3 | Staking Facilities | [0xf82D88217C249297C6037BA77CE34b3d8a90ab43](https://etherscan.io/address/0xf82D88217C249297C6037BA77CE34b3d8a90ab43) | [0x35506190Ca6df385aA6Bc4a970646dd4f49426c1](https://etherscan.io/address/0x35506190Ca6df385aA6Bc4a970646dd4f49426c1) | | 4 | Blockscape | [0x7912Fa976BcDe9c2cf728e213e892AD7588E6AaF](https://etherscan.io/address/0x7912Fa976BcDe9c2cf728e213e892AD7588E6AaF) | [0xDc1579636686C082fc3b00B9EB25259A110D0C44](https://etherscan.io/address/0xDc1579636686C082fc3b00B9EB25259A110D0C44) | | 5 | Stake.fish | [0x4B87F16B8d32cb5a859a4C48a88edB5adBe3498E](https://etherscan.io/address/0x4B87F16B8d32cb5a859a4C48a88edB5adBe3498E) | [0x031E597BcF680f1f2293b119b4b2B14096B15497](https://etherscan.io/address/0x031E597BcF680f1f2293b119b4b2B14096B15497) | | 6 | Stakely (takes the seat of Kiln) | Kiln [0x6d22aE126eB2c37F67a1391B37FF4f2863e61389](https://etherscan.io/address/0x6d22aE126eB2c37F67a1391B37FF4f2863e61389) | [0x6A22d74a816662078f2371A7138E7614874cd61d](https://etherscan.io/address/0x6A22d74a816662078f2371A7138E7614874cd61d) | ### Contracts and roles | What | Before | After | | --- | --- | --- | | DepositSecurityModule (LidoLocator entry) | v4 [0xF573E9E3de1f86B085417ab294f56E7920B4e9Be](https://etherscan.io/address/0xF573E9E3de1f86B085417ab294f56E7920B4e9Be) | v5 [0x39BB5d491e98A44D1bfe8047A737a81E296a63E0](https://etherscan.io/address/0x39BB5d491e98A44D1bfe8047A737a81E296a63E0) | | LidoLocator implementation | [0xF2Ffb952e129a63F0614Ff87126E1d4a494A2313](https://etherscan.io/address/0xF2Ffb952e129a63F0614Ff87126E1d4a494A2313) | [0x60E09F1791F1168d0450E4F100616B4a3F95119C](https://etherscan.io/address/0x60E09F1791F1168d0450E4F100616B4a3F95119C) | | STAKING\_MODULE\_UNVETTING\_ROLE on StakingRouter | DSM v4 | DSM v5 | | TOP\_UP\_ROLE on TopUpGateway | depositor bot EOA [0xF82aC5937A20dC862F9bc0668779031E06000f17](https://etherscan.io/address/0xF82aC5937A20dC862F9bc0668779031E06000f17) | depositor bot DelegationContract [0x6Aa249bA53A3abcaC52F91146583B3eE2Ee4C7F5](https://etherscan.io/address/0x6Aa249bA53A3abcaC52F91146583B3eE2Ee4C7F5) | | BUFFER\_RESERVE\_MANAGER\_ROLE on Lido | Agent | Agent and Easy Track EVMScriptExecutor [0xFE5986E06210aC1eCC1aDCafc0cc7f8D63B3F977](https://etherscan.io/address/0xFE5986E06210aC1eCC1aDCafc0cc7f8D63B3F977) | | Easy Track factories | - | SetDepositsReserveTarget [0x62E9Dc68BDCBC46362f40e0bb9c154C9a42E62b0](https://etherscan.io/address/0x62E9Dc68BDCBC46362f40e0bb9c154C9a42E62b0), trusted caller CMC multisig, cap 9,600 ETH | The vote script and the fork tests: [lidofinance/scripts#682](https://github.com/lidofinance/scripts/pull/682). ---
**Author:** ![Otar](https://avatars.discourse-cdn.com/v4/letter/o/9e8a1a/32.png) [@Otar](https://research.lido.fi/u/Otar)\ **Post date:** [September 14, 2026, 10:22am UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/27 "2026-09-14T10:22:44Z")
Following the [single-stage vote process](https://research.lido.fi/t/no-drama-dao-where-snapshot-mirrors-aragon-put-it-all-onchain/11415), the vote text for [LIP-37: Execution Delegation Framework (EDF)](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-37.md) has been finalized and [frozen on IPFS](https://bafybeigbjuddcjouak3y3fwxwppo6cy4dxw7fli2idvvvcpulkes2gab6m.ipfs.inbrowser.link/) - 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. ---
**Author:** ![Maksim\_Kuraian](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/maksim_kuraian/32/3204_2.png) [@Maksim\_Kuraian](https://research.lido.fi/u/Maksim_Kuraian)\ **Post date:** [September 14, 2026, 3:49pm UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/28 "2026-09-14T15:49:35Z")
**EDF audits finalized:** - [MixBytes Lido EDF On-chain Audit Report 09-2026.pdf](https://github.com/lidofinance/audits/blob/main/MixBytes%20Lido%20EDF%20On-chain%20Audit%20Report%2009-2026.pdf) - [Composable Security Lido EDF On-chain Audit Report 08-2026.pdf](https://github.com/lidofinance/audits/blob/main/Composable%20Security%20Lido%20EDF%20On-chain%20Audit%20Report%2008-2026.pdf) - [Composable Security Lido Oracle V8\_1 Audit Report.pdf](https://github.com/lidofinance/audits/blob/main/Composable%20Security%20Lido%20Oracle%20V8_1%20Audit%20Report.pdf) ---
**Author:** ![Otar](https://avatars.discourse-cdn.com/v4/letter/o/9e8a1a/32.png) [@Otar](https://research.lido.fi/u/Otar)\ **Post date:** [September 16, 2026, 12:14pm UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/29 "2026-09-16T12:14:34Z")
The **[on-chain vote #205](https://dao.lido.fi/vote/205)** is now live and includes the proposals to complete the **[LIP-37: Execution Delegation Framework (EDF)](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746)** rollout. The vote will be open for your “For” or “Against” input until the end of the main phase: **Sept 21, 13:45 UTC**. For instructions on how to verify the vote items, please follow [this guide](https://enchanted-direction-844.notion.site/How-to-check-the-Lido-DAO-on-chain-vote-205-EDF-LIP-37-Kiln-Stakely-DSM-rotation-Deposit-Res-3dbbf633d0c98049a597e53d4d78406f). ---
**Author:** ![cp0x](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/cp0x/32/4886_2.png) [@cp0x](https://research.lido.fi/u/cp0x)\ **Post date:** [September 17, 2026, 3:34pm UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/30 "2026-09-17T15:34:00Z")
We verified the vote script and all sixteen DelegationContracts on-chain before voting: nine oracle seats, six DSM guardians, and the depositor bot’s contract, which takes over TOP\_UP\_ROLE in the same script. Everything matches the published plan and the custody policy. Thanks for the level of preparation here: the published tables, the operator checklists and the verification guide made this vote unusually easy to check. The question below is not about the implementation but about one part of the model that we may be missing. It concerns the case where what is compromised is not a hot key but the owner multisig itself. TheDZhon made the point earlier in this thread that terminate() lets a participant cut itself off rather than having the protocol pause components around a party it no longer trusts. We agree, and our question is about the narrower case where the owner is no longer in a position to make that call. terminate() is invoked by the owner, as are revokeDelegate() and nominateDelegate(). While a single signer is compromised this works, because the remaining honest quorum still controls the Safe. Once the threshold itself is taken, the operator can do nothing, and §6.2 of the policy no longer covers the case. From there governance has to act. The LIP-37 specification describes the cooldown in exactly those terms: a hostile nomination is visible on-chain for the whole window, so monitoring and governance can react before the swap takes effect. The custody policy in §3.6 calls the same window the owner’s only window to react, which is noticeably more modest. We tried to work out what governance can actually do within those 48 hours, and so far the answer seems to be nothing. We checked the roles on the four HashConsensus contracts: - MANAGE\_MEMBERS\_AND\_QUORUM\_ROLE is held only by the Aragon Agent - DISABLE\_CONSENSUS\_ROLE has no holders at all, zero on all four committees - MANAGE\_FRAME\_CONFIG\_ROLE is empty as well CircuitBreaker covers the Withdrawal Queue, VEBO, TWG, VaultHub and Predeposit Guarantee, but not the HashConsensus contracts or the Accounting Oracle. Emergency Brakes holds PAUSE\_ROLE over Easy Track. The Dual Governance emergency committees are scoped to vulnerabilities in the DG contracts themselves, not to changing committee membership. That leaves a full Aragon vote through the Agent plus the Dual Governance timelock, roughly ten days. This is the same figure LIP-37 names in its motivation as the problem EDF was created to solve. So the window lasts 48 hours while the fastest available response is five times longer. There is also a faster version of the same problem. An attacker holding owner multisigs does not need to nominate anything: revokeDelegate() and terminate() both take effect immediately. Five disabled oracle seats leave four signers against a quorum of five, and because each operator’s contract sits in all four committees, consensus stops in all of them at once. Here there is no 48-hour window at all. Restoring service means either lowering the quorum or replacing members, both of which run through MANAGE\_MEMBERS\_AND\_QUORUM\_ROLE and therefore through a full vote; with terminate() it also means deploying a new contract per seat. Even a single terminated seat is unrecoverable without a vote. These are two different failure modes and they need two different primitives. Against a hostile majority, disableConsensus() freezes the committee by raising the quorum out of reach. But DISABLE\_CONSENSUS\_ROLE is held by nobody, and granting it goes through the Agent, which means a vote again. It becomes a fast brake only if it sits in advance with a committee that can act within hours. Against disabled seats it does not help at all, since consensus has already stopped and freezing it further changes nothing. Recovery needs removeMember or setQuorum, a far more sensitive role to hand to a fast-moving committee. DSM guardians do not have this problem, since any honest guardian can halt deposits with a single signature, and that is built into the design as protection against collusion. For oracle seats we could not find an equivalent emergency path. Are we right that until removal through governance, the only containment mechanism at the HashConsensus level is the 5-of-9 quorum? We do take downstream limits such as the OracleReportSanityChecker into account, but they bound what a report may contain rather than allow a compromised committee member to be removed or disabled. We deliberately do not go into how an owner multisig might be compromised. The method does not matter here: custody requirements raise the cost but do not guarantee it will not happen. None of these questions changes our support for the vote. Holding a protocol permission directly on a hot key that cannot be replaced quickly without governance is worse on every one of these counts. We are not proposing to redesign anything. We would like the response path for a threshold compromise of an owner multisig to be defined in advance: who neutralises a compromised oracle seat, and by what mechanism, when the owner is already lost and the normal governance process does not fit inside the 48-hour cooldown. ---
**Author:** ![Maksim\_Kuraian](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/maksim_kuraian/32/3204_2.png) [@Maksim\_Kuraian](https://research.lido.fi/u/Maksim_Kuraian)\ **Post date:** [September 18, 2026, 10:58am UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/31 "2026-09-18T10:58:51Z")
The new framework addresses exactly the issues Raman outlined at the beginning of this post. Under the EDF framework, only the delegate key is stored on each holder’s machine. If a machine running the Oracle or Council Daemon is compromised, this key can be quickly replaced through the Delegation Contract. This significantly improves the security model by eliminating the need for key rotation through a full on-chain governance vote, which takes approximately 10 days. The risk of cold-key compromise remains, but it is now significantly lower. As a result, the risk of losing quorum or even having the quorum compromised is also substantially reduced. However, the mitigation process for such severe incidents remains the same as it was before the EDF release. ---
**Author:** ![Otar](https://avatars.discourse-cdn.com/v4/letter/o/9e8a1a/32.png) [@Otar](https://research.lido.fi/u/Otar)\ **Post date:** [September 21, 2026, 12:52pm UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/32 "2026-09-21T12:52:45Z")
The **[on-chain vote #205](https://dao.lido.fi/vote/205)** has been enacted. The EDF rollout will follow the **[Dual Governance Proposal #14](https://dao.lido.fi/dg/proposals/14)** **execution** , expected on September 25th. ---
**Author:** ![Otar](https://avatars.discourse-cdn.com/v4/letter/o/9e8a1a/32.png) [@Otar](https://research.lido.fi/u/Otar)\ **Post date:** [September 25, 2026, 1:06pm UTC](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746/33 "2026-09-25T13:06:43Z")
**[Dual Governance Proposal #14](https://dao.lido.fi/dg/proposals/14)** has been executed - the [EDF](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746) rollout has been completed. [Previous page](https://research.lido.fi/t/lip-37-execution-delegation-framework-edf/11746.md?page=1)