Upcoming Protocol Upgrade: DelegationManager (ELIP-019)
| Author(s) | ELHAJIN (amin), Nadir Akhtar (Eigen Labs) |
|---|---|
| Created | July 21, 2026 |
| Proposal | ELIP-019 |
| Status | Draft |
This is advance notice of an upgrade to the DelegationManager contract that we expect to execute in less than two weeks, tracked as ELIP-019.
What’s happening
We’re preparing a narrowly scoped, security-sensitive upgrade to DelegationManager. Per our standard practice for upgrades of this nature, we are not disclosing implementation detail ahead of execution. A full technical writeup — the change, our design rationale, and how we carried out the upgrade — will follow this post once ELIP-019 has been executed.
What you need to do
Nothing. No action is required from stakers, operators, or integrators before, during, or after the upgrade.
Delivery process
The upgrade ships as a proxy-implementation upgrade to DelegationManager, using our standard three-phase process: an initial on-chain preparation step, a multisig queue, and multisig execution after the standard 10-day timelock.
This is the same three-phase shape used for prior DelegationManager upgrades.
Protocol Council approval
Before this upgrade was queued, members of the Protocol Council reviewed ELIP-019 and the delivery process described above, and provided signed approval.
Each Council signer produced an off-chain signature over a fixed endorsement message using the same key that controls their seat on the Protocol Council Multisig:
I endorse the bug fix upgrade of the DelegationManager to pre-computed address 0x6a8BEd4062C895130E2d09bA442D3eCEAd5Df6c2 for ELIP-019
The message commits the Council to both the proposal and the exact address the new implementation will occupy. That address is pre-computed via CREATE2 with a salt that embeds the Protocol Council Multisig address and commits to the pinned release bytecode — only the Council can deploy to it, and any different code would land at a different address. Endorsing the address is therefore equivalent to endorsing the code that will live there. (The target address is public on-chain once the upgrade is queued, so nothing sensitive is disclosed here ahead of execution.)
Verify the signatures yourself
Anyone can independently check a Council signature using foundry’s cast:
cast wallet verify \
--address <COUNCIL_SIGNER_ADDRESS> \
"I endorse the bug fix upgrade of the DelegationManager to pre-computed address 0x6a8BEd4062C895130E2d09bA442D3eCEAd5Df6c2 for ELIP-019" \
<SIGNATURE>
The message must match exactly as written above — same casing, spacing, and address checksum, with no surrounding quotes or extra whitespace. The Council signer addresses and their signatures are published below:
| Address | Signature |
|---|---|
0x9229C290F60F303884073F28EB8E81F9B82506d5 |
0x7f6970cab965e536f404519fbdb0e0395a83010cbc62e82882973953298515f1423d0fcb654b40666e69aff081ac9b1740d10eac729649faf119a5381020c8781c |
0xc5280E368648b0e192b355c7d8330593bA7af700 |
0xf4a43629c3d90422a875ef55c3339dab282a0a6b306995a1d8581329f3806d765515c4ce085ba65d52216f7d760a378191fcfe0db281f36b0bc27061943afaf51b |
0x10d6CE86113D00CcF071D02C5289e420a14C963F |
0xd11592955feebfbdc88ac428d3214cc2f3b47f1531afb6223465a24548695bf524d04060032015cf0438cdd93fab36f7aee09d294b86bb724f375c3c437fc25d1b |
0xAe4ABA6838d4622aF1AD024EB351eA4D4FDE22B3 |
0x5f77391aadf7d865b6143ab9d935dd7221b71b2e4525ae2d2c73a2ad390af9035d4d27072924b76c9d00096961e19edbb9aeab858b881d7011ca49c93aa888021b |
What’s next
Once the upgrade has queued and executed, we’ll publish the companion post covering ELIP-019 in full: the change itself, why we approached it the way we did, and how the upgrade was carried out. We’ll link it here.
Questions are welcome in the replies.