TL;DR
We propose the Execution Delegation Framework (EDF) — a minimal, audited, protocol-wide primitive for delegating the operational keys of permissioned actors. Governance grants a permission once to a per-entity DelegationContract; the contract’s owner (a cold key or a multisig) then chooses and rotates the active hot signing key freely, without a governance vote.
- A compromised hot key can be de-authorized by its owner immediately; a replacement becomes effective after a short safety cooldown. Today the same rotation requires a full on-chain governance vote (~10 days).
- Oracle committee members and DSM guardians are the first adopters. The lido-oracle daemon gains delegation support, and the DepositSecurityModule is redeployed to verify guardian signatures via a standard ERC-1271 check against the guardian’s DelegationContract.
- Migration is designed to be zero-downtime: operators prepare everything off the critical path, and a single DAO vote flips every prepared seat to delegation at once.
Motivation
Operational compromise is now the dominant cause of losses in the ecosystem. Of the roughly $972 million stolen across a record 207 crypto hacks in the first half of 2026, infrastructure and operational compromises — leaked private keys, compromised administrator credentials, and mishandled signers — accounted for approximately 76% of all funds stolen while representing only about 15% of incidents; smart-contract exploits, by contrast, made up the majority of incidents (125 of 207) but only a small share of the value lost (June Security Beat: Keys Over Code). The largest and least-recoverable losses now come from compromised signers, not flawed code.
Lido’s Oracle members and Deposit Security Module council members currently operate with hot EOA private keys stored directly in off-chain bots. By their very nature these bots must run with hot keys: the key lives on the machine, which makes it inherently exposed. And these keys:
- carry meaningful protocol permissions (report submission, pause/unvet signing, deposit message signing);
- may be long-lived with an unclear custody history;
- require a full on-chain governance vote (~10 days) to rotate — whether after a compromise or as a routine precaution.
That cost cuts both ways. It makes proactive, periodic rotation too expensive to do regularly, so keys live longer than they should. And when a key is suspected, the replacement is only authorized once the vote executes — leaving a potentially compromised key on-chain with its permissions intact, free to harm the protocol until governance acts.
Design
EDF consists of two non-upgradeable contracts:
- DelegationFactory.sol — a singleton that deploys a fresh DelegationContract per entity;
- DelegationContract.sol — a minimal delegation contract enforcing a one-owner / one-active-delegate model.
There are exactly two trusted entities:
┌──────────┬─────────────────────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Role │ Custody │ Capabilities │
├──────────┼─────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Owner │ Safe multisig or cold wallet │ Assign, reassign, and revoke the delegate; irreversibly terminate() the contract │
├──────────┼─────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Delegate │ Hot key in the off-chain daemon │ Call execute() to dispatch transactions (push); sign messages verified via the contract's ERC-1271 isValidSignature (pull) │
└──────────┴─────────────────────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Key properties:
- Immediate revocation, cooldown-gated assignment. revokeDelegate() drops a suspect key instantly. assignDelegate(newKey) schedules a replacement that becomes effective after the contract’s cooldown; during a planned rotation the old key stays effective until the new one activates, so routine rotation has no gap. The cooldown is a reaction window: an unexpected assignment (e.g. from a compromised owner) is visible on-chain for cooldown seconds before the new key can act, so monitoring and governance can react.
- The owner can never act as the contract. The owner manages the delegate’s lifecycle but cannot execute() or sign.
- Owner immutability. The owner address is fixed at deployment — there is no ownership-transfer function, so a compromised owner can never lock the legitimate operator out by transferring control. Rotating the owner means deploying a fresh contract and reassigning the seat.
- Irreversible termination. If the owner key itself is suspected compromised, terminate() permanently disables the contract — execute() and signature verification fail closed, and the role must be reassigned to a fresh contract.
- Why purpose-built rather than an existing framework: the delegation frameworks we looked into are far more complex and flexible than this role needs, and that unused flexibility is attack and misconfiguration surface. A minimal, non-upgradeable contract makes EDF’s guarantees structural and keeps the audited surface small.
Two integration patterns are supported, so any permissioned bot in the Lido ecosystem can adopt EDF:
- Push — the delegate calls execute(target, data); the protocol contract sees msg.sender == DelegationContract and authorizes it as the registered permission holder.
- Pull (ERC-1271) — the delegate signs off-chain; anyone relays the signature plus the DelegationContract address; the protocol verifies it via the contract’s isValidSignature, which resolves the current effective delegate and fails closed if there is none.
Adoption scope: Oracle and DSM
EDF ships together with its first adoption, because the contracts are inert on their own — the integration is what actually closes the hot-key risk:
- Lido Oracle (push). The lido-oracle daemon gains a DELEGATION_CONTRACT_ADDRESS setting; when set, all oracle contract calls route through the delegation contract’s execute().
- DepositSecurityModule (pull + push). Every guardian becomes a DelegationContract — EOA guardians are no longer supported. Since a contract guardian can’t be recovered from an ECDSA signature, the guardian address is now supplied explicitly alongside each signature, the signed digest binds the guardian address, and DSM verifies via the guardian’s ERC-1271 isValidSignature, additionally keep a direct path where the guardian’s contract calls DSM via execute().
- Validator ejector (node-operator side) must resolve the active oracle signing address via getDelegate(), since exit messages are always signed by the delegate EOA.
Migration
Migration is zero-downtime by construction. Operators deploy and publish their DelegationContracts, stage the daemon configuration, and the Lido team registers everything in monitoring — all while the current hot keys keep operating. A single DAO vote then reassigns each Oracle committee and DSM guardian seat to the corresponding DelegationContract address, and the pre-configured daemons begin routing through delegation without interruption. From that point on, hot-key rotation is a local operator action measured in minutes, with no further governance involvement.
Next steps
- Gather community, operator, and integrator feedback in this thread.
- Complete security audits of the DelegationFactory / DelegationContract system and the updated DepositSecurityModule.
- Testnet deployment and a coordinated dry-run of the operator migration process.
- On-chain governance vote to reassign the Oracle and DSM seats to delegation contracts.
We invite the community, Oracle and DSM operators, and integrators to review the full specification and share feedback before this moves to a vote.
