EIP-XXXX: Orphaned DELEGATECALL Library Restoration

EIPs
1

[RFC] EIP-XXXX: Orphaned DELEGATECALL Library Restoration — A Governance-Critical Proposal Before State Expiry

Category: EIPs / Core

Status: Request for Comment — Draft EIP forthcoming

tl;dr: A hard-fork mechanism to restore bytecode to selfdestructed shared DELEGATECALL library contracts destroyed by an unauthorized third party. The design follows the class-based, mechanically-applied framework Vitalik Buterin proposed in EIP-156 (2016) — a community adopts the rule once; the protocol applies it automatically whenever a candidate satisfies the criteria. The Verkle fork is a concrete signal that time is running out on this question — not only because it unlocks state expiry and the dormant wallet contracts are precisely what expiry targets, but because Verkle’s new code storage model (chunked code in the trie) means that bytecode restoration becomes technically more complex after Verkle ships. Both the governance window and the simpler implementation path close at the same moment.

What This Proposal Is About

In November 2017, a shared library contract was permanently destroyed through an exploit. Approximately 587 multisig wallets holding over 500,000 ETH became permanently inert — not because their owners did anything wrong, not because their code executed in an unintended way, but because a single anonymous address with no authorized relationship to the library exploited a context-dependency vulnerability, declared itself owner, and called kill().

The ETH frozen in those wallets has been irrecoverable at the protocol layer ever since.

I want to be direct about something that tends to get lost in discussions of this incident: the vast majority of affected parties were not Parity Technologies. They were individual developers, DAOs, multisig treasuries, and projects — community members who chose a well-regarded, audited wallet standard and entrusted it with funds. They did not write the shared library. They did not control it. They had no mechanism to prevent or recover from its destruction. The governance conversation has sometimes been framed as “should we bail out Parity?” That framing is factually incorrect, and it has been an obstacle to an honest evaluation of the underlying question.

This post introduces a formal EIP — the Orphaned DELEGATECALL Library Restoration (ODLR) protocol — and explains why the timing of this proposal is not arbitrary. There is a specific, approaching window after which the question cannot be decided at all.

The Technical Situation

The Parity WalletLibrary contract’s initWallet() function was designed to be called only via DELEGATECALL from wallet stub contracts. In that context, the calling wallet’s storage already contained an initialized owner list, making re-initialization a no-op. Called directly (not via DELEGATECALL), the function ran against the library’s own empty storage — allowing any caller to install themselves as owner. The attacker then called kill(), triggering SELFDESTRUCT. (As a note for the broader discussion: SELFDESTRUCT no longer exists in the protocol following EIP-6780 — this particular class of bug cannot recur. We return to that point later.)

Every dependent wallet routes its execution through DELEGATECALL to the library address. With no code there, every call is a permanent no-op. There is no application-layer recovery path. The Ethereum Fund Recovery Protocol (EFRP, November 2025) offers compensatory synthetic tokens backed by voluntary donors, which is admirable, but it is not restitution — it requires third parties to fund a harm they did not cause.

ODLR’s proposed fix is technically minimal: restore the runtime bytecode at the library address to its pre-destruction state. No ETH moves. No storage is modified. No account is deleted or created. The restoration bytecode is independently verifiable from canonical chain history by any party replaying from genesis. The implementation in any client amounts to a handful of SetCode and SetNonce calls.

Why This Proposal Matters Now: The Deliberate Governance Imperative

This is the argument I most want the community to engage with seriously.

The affected parties’ claim is currently justiciable. The window is open. The community has not said yes to recovery, but it also has not — under current circumstances, with a properly specified proposal — said a deliberate no. The 2018 vote against EIP-999 was a vote against a specific design: one that named a specific address, required a standalone hard fork, included no consent mechanism, no challenge protocol, no eligibility criteria, and no scope controls. ODLR differs from EIP-999 on every one of those dimensions. The question of whether ODLR, with its significantly different design, should be adopted has never been put to the community. The claim is open.

The Verkle fork is not background context. It is the signal that time is actually running out — and it does so on two distinct fronts.

The first is governance. The Verkle trie migration (EIP-6800) is the prerequisite for partial state expiry — the mechanism by which Ethereum will prune dormant state from the active trie. Once Verkle ships, state expiry is no longer a roadmap aspiration; it is an active engineering project with its critical dependency satisfied. The frozen wallet contracts have had zero on-chain activity since November 2017. The library address holds no code and zero nonce. These are precisely the categories state expiry is designed to target. If state expiry is applied before the community makes a deliberate decision on ODLR, the affected parties’ claim is not rejected — it is dissolved. Their wallets would be pruned not because the community decided they should not be recovered, but because a storage optimization was applied with the recovery question unresolved.

The second front is technical — and this one is independent of state expiry entirely. The Verkle migration changes how contract code is stored at the protocol level. In the current hexary trie, code exists as a separate blob referenced by codeHash. In the Verkle trie, code is stored as 31-byte chunks embedded directly within the trie structure. The SetCode operation that ODLR requires is a clean, well-understood mechanism against the current model. After Verkle, a bytecode restoration would require writing chunked code into the new trie format — technically achievable, but materially more complex, requiring a different state transition specification and additional client surface area. The Verkle fork is therefore not only the governance deadline; it is the natural implementation boundary, the last point at which ODLR can be resolved with both the window open and the simplest available technical path.

These two fronts converge on the same conclusion. The Verkle fork is the decision point — after which addressing this question becomes harder in every dimension simultaneously.

There is a meaningful difference between a considered “no” — the community evaluates a well-specified proposal and declines it on the merits — and a procedural outcome where an open question is foreclosed by an unrelated upgrade, without anyone having specifically addressed it. Both lead to the same permanent result. Only one is a genuine answer to the people who have been asking for nearly a decade.

The affected parties are owed exactly two things: a deliberate yes, or a deliberate no. What they are not owed is the silent closure of the question by a protocol change that was never intended to adjudicate their claim.

This creates a clear choice for the community. Before implementing state expiry, one of the following should happen:

  1. Adopt ODLR, resolving the open question with a yes.

  2. Reject ODLR explicitly, on its merits, with full awareness that doing so permanently forecloses recovery — a deliberate no.

  3. Design state expiry to preserve ODLR-class restorations, keeping the question justiciable even after expiry ships.

These three paths are the ones consistent with deliberate governance. Implementing state expiry without having taken any of them extinguishes the affected parties’ claim without ever specifically addressing it.

This argument is not a veto on state expiry. State expiry is a valuable improvement. This proposal does not oppose it. The argument is about sequencing: resolve ODLR first, then proceed with state expiry unconstrained. The Verkle hard fork is the natural coordination point for that sequencing — not arbitrarily, but because it is the last scheduled upgrade before the governance window closes and the implementation complexity increases.

How ODLR Is Different From a “Bailout”

A bailout involves pooled or external resources compensating a party for losses arising from their own decisions. ODLR satisfies none of those criteria:

  • No resources are consumed. Writing bytecode to an address costs nothing. No ETH is debited from any account.

  • The affected parties did not cause the loss. They held private keys to wallets that worked correctly until an unrelated third party with no authorized relationship to the library destroyed shared infrastructure they did not write and could not modify.

  • The mechanism is general. ODLR defines a class of eligible contracts by objective on-chain criteria. No address is named. Any contract meeting the criteria is eligible; any contract not meeting them is not.

What ODLR Proposes

The draft EIP specifies:

Six binary eligibility criteria that define an Orphaned DELEGATECALL Library (ODL):

  1. Empty code at the address (codeHash == EMPTY_CODE_HASH)

  2. Zero nonce (consistent with pre-EIP-6780 SELFDESTRUCT semantics)

  3. At least one dependent wallet with non-zero balance and a hardcoded DELEGATECALL reference to the library address

  4. Verifiable creation transaction in canonical chain history

  5. Destructive call sequence initiated by an address with no prior authorized relationship to the library or any dependent wallet

  6. SELFDESTRUCT reachable only through an access-control vulnerability, not through a legitimately authorized call

An Owner Verification Specification (OVS): A structured, challengeable on-chain declaration that specifies how to determine authorized owner addresses for dependent wallets from their storage, independent of the restoration bytecode’s ABI. This makes the mechanism general — not tied to any single library’s ownership model.

A dual-threshold consent mechanism with two paths:

Primary Consent Path: ≥50% of total affected ETH by value must have registered cryptographic consent via EIP-712 signatures; <10% may have registered explicit opposition.

Participation Quorum Path (alternative): ≥30% of affected ETH by value has signaled (either consent or opposition); of the signaled portion, ≥83% consents and <10% opposes. This path exists because many wallets have owners who lost keys or are otherwise unreachable — their silence is an abstention, not an objection. Any minority controlling more than 10% of signaled ETH and meeting the applicable quorum threshold can block inclusion entirely.

For multisig DWs, opposition registration requires signatures from at least M verified CES owners (the wallet’s own quorum threshold) before the DW counts toward opposition. A single verified owner’s consent is sufficient — asymmetric by design, since any owner may independently choose restoration while blocking restoration affects all co-owners.

A formal nomination and prerequisites process: Any party may nominate a candidate address by submitting a complete evidence package — candidate address, proposed restoration bytecode, CES block, reference tool outputs for conditions 5 and 6, and proposed OVS — to the public governance record, no later than 120 days before the intended activation block. Client maintainers verify, not nominate. Eight defined deliverables (reference tools, bytecode analyzer, OVS interpreter, client implementations, Opt-In Registry contract, and full test suite) must be published and reviewed before this EIP can advance to Final status.

A 30-day public challenge period on the eligible address list, with six enumerated challenge types: eligibility (on-chain evidence), bytecode (hash proof), OVS (EIP-1186 storage proof at the CES block), CES block number, condition 5 tool output, and condition 6 tool output. All challenges are resolved by on-chain evidence only — no social, historical, or off-chain intent arguments are admissible. The finalized list is published no later than 90 days before activation.

State transition: At the activation block, SetCode(address, restorationBytecode) and SetNonce(address, 1) are applied atomically. No balance transfers. No storage writes.

Proposed activation vehicle: The Verkle hard fork (EIP-6800) — not because Verkle and ODLR are philosophically related (they are not; Verkle is semantics-preserving, ODLR is a state mutation), but because the Verkle fork is the last scheduled upgrade before the state expiry roadmap becomes viable. ODLR has no technical dependency on Verkle and could activate in any scheduled hard fork, but the governance sequencing argument makes the Verkle fork the appropriate and potentially final venue.

On Precedent

This proposal establishes a rule, not an exception. Stated precisely:

The Ethereum protocol will restore the bytecode of a shared DELEGATECALL library contract when: (1) the library was destroyed by an address with no prior authorized relationship to it or its dependent wallets; (2) the destruction exploited an access-control vulnerability, not an authorized call path; (3) the dependent contracts are permanently inert with no application-layer recovery path; (4) the Restoration Bytecode is independently verifiable from canonical chain history; (5) opposition registrations meeting the dependent wallet’s quorum threshold represent fewer than 10% of signaled affected ETH by value; and (6) the participation and consent thresholds defined in this EIP are met.

This rule cannot be satisfied by reentrancy exploits, oracle manipulation, governance attacks, private key loss, or any scenario where: the affected party had an authorized relationship to the contract; the contract executed on an authorized call path; or an application-layer remedy exists. It is not a general “funds recovery” mechanism. It is a narrow rule for a specific, distinguishable failure mode.

This design has a direct intellectual ancestor. EIP-156 (2016), authored by Vitalik Buterin, proposed a general framework for reclaiming ETH from common classes of stuck accounts through mechanically-applied protocol rules — rather than case-by-case governance deliberation. Its central insight: the community defines the class once, and the protocol executes it automatically. ODLR is a direct application of that framework, providing a complete specification for one specific class — the DELEGATECALL library destruction pattern — that EIP-156 identified as a candidate but left unspecified.

EIP-161 deleted thousands of accounts without individual consent as a state cleanup measure. The 2016 DAO fork moved 3.6 million ETH. ODLR proposes a mutation less interventionist than either: no ETH moves, consent is required, and a public challenge protocol governs eligibility.

The Claim Has Been Actively Pursued for Nearly a Decade

It is worth being explicit about the governance history. The affected parties submitted EIP-999 in 2018. They formed the Locked Ether Collective in early 2024. They supported the EFRP proposal in November 2025. They are now bringing this proposal. This is not a dormant or abandoned claim. It is a claim that has been actively and persistently pursued through every available legitimate channel for eight years.

A claim that meets that standard — actively pursued, technically specified, procedurally compliant — deserves a deliberate answer. The approaching state expiry roadmap means that the window for that answer is finite. This is the moment to have the conversation.

Invitation to the Community

I am posting this to open a substantive discussion before the draft EIP is submitted to the EIP editors. I am specifically interested in engagement on:

  • The governance sequencing argument. Is the framing of “deliberate governance vs. procedural default” compelling? Are there flaws in the argument that state expiry without ODLR resolution constitutes a governance failure?

  • The eligibility criteria. Are the six ODL conditions precisely specified? Are they over- or under-inclusive?

  • The consent mechanism. Does the dual-threshold design — primary path (50% of total ETH consents, <10% opposes) plus Participation Quorum path (30% signaled, 83% of signaled consents, <10% of signaled opposes) — adequately protect both the majority and minority of affected owners? Is the 83% supermajority among signaling wallets the right threshold?

  • The OVS approach. Is the Owner Verification Specification model sufficiently general and resistant to manipulation?

  • The precedent statement. Does the six-condition rule sufficiently distinguish this action from actions the community would not want to authorize as precedent?

The full draft EIP will be linked in a follow-up post. I welcome technical critique, governance objections, and alternative framings.

The affected community members have waited long enough for a deliberate answer. Let’s give them one.

*This post was authored on behalf of affected parties and supporters of ODLR. Questions, critiques, and endorsements welcome in the replies. *

3 Likes
Ethereum Fund Recovery Protocol (EFRP)
2
3

Three prior efforts have addressed the Parity fund recovery question. EIP-999 (2018) asked the community to vote on a specific named address; the political framing consumed the technical substance and the proposal failed on grounds that a better-specified version would not share. The Locked Ether Collective has kept the claim alive through persistent advocacy, which is genuinely valuable but is not a protocol outcome. EFRP (November 2025) offers compensatory synthetic tokens funded by voluntary donors — it is restitution-adjacent, but it requires indefinite social coordination rather than code, and asks third parties to fund a harm they didn’t cause.

ODLR reduces human involvement at execution time to zero. The community deliberates once — on whether the criteria are correct. After that, execution is mechanical: any address satisfying all six on-chain eligibility conditions and the consent thresholds activates the state transition automatically. No vote on the specific address. No round of instance-level politics. No organizers who have to keep showing up. This is what distinguishes ODLR structurally from every prior proposal — not just improved procedure, but a different relationship between governance and execution.

The timing argument is structural, not manufactured. The Verkle fork closes two windows simultaneously: it is the last scheduled upgrade before state expiry becomes a near-term engineering project (after which the frozen wallet contracts are precisely the dormant state that expiry mechanisms target), and it is the last point at which bytecode restoration uses a clean SetCode against the hexary trie model (Verkle’s chunked code storage requires a materially different state transition specification). Both constraints expire at the same moment.

I would ask reviewers to focus specifically on: the governance sequencing argument in Motivation §3 — is “deliberate no vs. procedural default” a compelling framing?; conditions 5 and 6 and the INDETERMINATE semantics; the dual consent threshold design; and the six-condition rule statement in the Rationale, which is the actual precedent this EIP sets and deserves close scrutiny.

3 Likes
4

Bumping this. The draft EIP has been available for several weeks and the thread needs substantive engagement. Here is the sharpest version of what I’m asking the community to decide.

The discomfort people have with recovery proposals is mostly this: they require the protocol to act as a player in a social dispute — to judge the case, vote on the address, keep revisiting the question. That discomfort is legitimate. ODLR is designed to eliminate it. The community adopts a rule; the protocol applies it mechanically. No address-level politics. No recurring deliberation. No social momentum that has to be sustained. The protocol becomes a game — neutral, rule-bound — rather than a participant in the dispute. This is what distinguishes ODLR from EIP-999 (a named-address vote), from EFRP (voluntary compensation requiring indefinite coordination), and from the Locked Ether Collective’s advocacy (which is valuable but is not code). The difference is structural, not cosmetic.

The Verkle fork is the decision point. Once it ships, state expiry becomes a near-term engineering project — and the frozen wallet contracts are precisely the dormant state expiry targets. If that happens before this EIP is resolved, the affected parties’ claim is not rejected. It is dissolved by default, by a protocol change that was never intended to adjudicate it. A deliberate no is a legitimate governance outcome. A procedural default is not.

The specific things that need review: the six-condition eligibility rule in the Rationale (that is the precedent, read it carefully), the INDETERMINATE semantics in conditions 5 and 6, and the dual consent threshold design. If the criteria are wrong, this is the moment to say so. After Verkle planning locks in, it isn’t.

The thread is open. Please engage.

1 Like
5

It’s highly likely that developers won’t pay much attention to this proposal because it would set a precedent. It’s highly likely that developers won’t pay much attention to this proposal because it would set a precedent. Try brute force salt using CREATE2, and one day the target code will be reset there. Because the current Ethereum address only has 20 bytes, we are much more likely to achieve this at a significantly lower cost in the future.

2 Likes
6

Special thanks to the commenter for raising this — the CREATE2 point in particular is more technically interesting than it might first appear.

The CREATE2 suggestion is worth engaging seriously, because the mechanism is actually coherent in a way that is not obvious.

After SELFDESTRUCT (under pre-EIP-6780 semantics), the WalletLibrary address has empty code and a zero nonce. EIP-684’s redeployment check fails only if the target address has either non-zero nonce or non-empty code — so the guard passes here. A CREATE2 deployment to that address is technically permitted by the protocol. And since the WalletLibrary is a stateless logic contract — all owner data, spending limits, and multisig parameters live in the dependent wallets’ own storage, accessed via DELEGATECALL’s storage context-switching — deploying the original runtime bytecode at the collision address would genuinely restore wallet functionality. The mechanism is not broken in principle.

The problem is the search cost. The CREATE2 address is derived as:

keccak256(0xff || sender || salt || keccak256(initcode))[12:]

Finding a (sender, salt) pair such that this expression produces the specific 20-byte WalletLibrary address is a preimage search in a 160-bit output space — not a birthday attack. The birthday bound (~2^80) applies when both sides of a collision can be chosen freely; here one side is fixed at the exact address the dependent wallets are hardcoded to call. That asymmetry doubles the exponent. Even at 10^9 keccak256 operations per second per GPU, a million-GPU cluster hits expected completion in roughly 10^27 years. Grover’s algorithm, applied to a fault-tolerant quantum computer optimistically achieving 10^12 operations per second, reduces the expected search to something in the range of 10^8 years. The “20 bytes makes this cheaper in the future” intuition imports the birthday bound into a preimage problem where it does not apply.

I have looked at this path. The mechanism is real; the search cost is not a matter of degree but of kind.

This matters for the governance question in a specific way. Even in the most optimistic scenario — a quantum speedup that brings the effective search space from 2^160 to 2^80 — the timeline runs into the state expiry clock before it runs into viability. The Verkle migration satisfies the critical dependency for state expiry; once that is deployed, the frozen wallet contracts are precisely the dormant state that expiry mechanisms are designed to prune. The CREATE2 path, on any honest projection, does not close before the governance window does.

On the precedent concern: I think this is the right objection to push on, and the standing rule in the Rationale is meant to answer it directly. The rule is: the protocol will restore a library’s bytecode when the library was destroyed by an address with no prior authorized relationship to it or its dependents, through an access-control vulnerability rather than an authorized call path, with no application-layer recovery path, verifiable restoration bytecode from chain history, and consent thresholds met. That rule cannot be satisfied by reentrancy, oracle manipulation, governance attacks, private key loss, or any scenario where the exploiter had a prior authorized relationship to the contract. The precedent value of ODLR is exactly as broad and as narrow as those six conditions. Future proposals that invoke it as precedent can be evaluated against whether they satisfy the same criteria — and the criteria explicitly exclude the scenarios the community would not want covered.

Developer attention is a question of prioritization, not of validity. If the criteria are wrong — over-inclusive, under-specified, or dangerous — that is worth arguing on the merits. But if the standing rule is narrow and distinguishable, as I believe it is, then “developers are unlikely to prioritize this” is a prediction about process, not a judgment on the question itself. The claim has been actively and persistently pursued through every available channel for eight years. The governance window is genuinely finite. Those two facts together suggest the right response is to engage now, not to predict that others won’t.

1 Like
7

I’m not an expert in cryptography, but I know there are a few other potential approaches you can consider.

One is based on the idea of ​​EIP-3607: if a suitable ECDSA key can be found, put the EIP-7702 code into it.

The second is based on Nick’s method combined with EIP-7702.

8

The EIP-3607 + EIP-7702 path and the Nick’s method + EIP-7702 path both ultimately require finding either a private key or a signature recovery that produces the specific WalletLibrary address. That is a 160-bit preimage search — the same computational wall as the CREATE2 approach, and for the same reason: the target address is fixed, so this is a preimage attack, not a birthday attack. “20 bytes” does not make any of these cheaper on any near-term horizon.

That said, Nick’s method’s core insight is genuinely applicable here, just at a different layer. ODLR currently has an implicit trust assumption: someone has to deploy the Opt-In Registry (where wallet owners register consent) and the eligibility analyzer contracts. Whoever does that deployment is a trusted party by default, which is exactly the kind of centralization Nick’s method was designed to eliminate. Deploying both via keyless pre-signed transactions means the registry has no owner, the tools have no deployer, and any party, including critics, can verify they are running against the canonical versions. The consent process becomes as credibly neutral as the restoration mechanism itself.

So the computational approaches don’t change the picture, but Nick’s method does improve the proposal in a meaningful way. So thank you!

1 Like
9

Yes, it is an essential framing. All previous proposals have foundered on the need for a deliberate process.

3 Likes
10

I want to express my sincere appreciation for this proposal. It is clear a great deal of time and thought went into it, and from a technical perspective this is the cleanest solution to the Parity freeze I have seen in all these years. No ETH moves, no storage changes, restoration verifiable by anyone from chain history — restoring what was destroyed, nothing more. You also make a point that deserves more attention than it has received so far: this is only possible now. Once Verkle and state expiry ship, the affected contracts are precisely the dormant state that pruning targets, and the question would be closed forever without the community ever having answered it. A deliberate yes or a deliberate no is the least the affected are owed.

I would add one argument in support. With the Dencun upgrade, and specifically EIP-6780, the community effectively acknowledged that SELFDESTRUCT was a problematic opcode — the one opcode that broke code immutability, and the direct cause of all this misery. It was rightly neutralized, but only for the future. The logical consequence of that acknowledgment is to also repair the considerable damage this opcode has already inflicted on innocent victims. A technical failure deserves a technical remedy, and the ODLR is the most logical and precise instrument to do exactly that.

You have my support. I hope this proposal gets the serious, substantive evaluation it deserves.

I have also mentioned your proposal as one of the 3 choices facing the ETH community regarding this matter.

3 Likes