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. *

2