EIP-999: Restore Contract Code at 0x863DF6BFa4

@alexvandesande addresses this question in his post. His proposal involves building an insurance marketplace where those tokens collect fees in the future.

If I’m following the argument correctly, it starts off with the assertion that the client dev teams (besides Parity) will not include recovery in a hard fork. That means the arguments it makes are not relevant to whether or not client dev teams should include recovery in a hard fork, which is what mast of the discussion is about.

As far as the token thing, it needs funding to be worth anything and each of the proposed funding items have problems:

  • Donation: This requires people giving free money away to people who lost their ETH. Human behavior studies have shown that humans won’t generally do this unless they believe everyone else is also going to do it, in which case they often will. Since the “community” has already decided not to recover in this scenario, there is no reason for users to believe that other humans will donate, thus they won’t donate.
  • Block reward: This is effectively no different from just restoring the ETH directly, but is more complicated. It just hides what is really happening in an obscure way, which I find to be a worse option than being transparent about what is being done.
  • Services: This is basically saying that Polkadot/Musiconomy should (effectively) just run another ICO. Why would people give those two products more money in this new round of funding? Presumably, the projects have already tapped out the funding source since at least Polkadot ran a dutch auction. This would also be disingenuous to the original token buyers who were promised that there would only be one round of funding.
  • Future Insurance of Contracts: This appears to be arguing that people with lost tokens should build a new insurance company, and use the profits from that insurance company to fund their losses. This isn’t a recovery at all, it is just a business idea.

I mostly agree with @MicahZoltu. While working on EIP-867, I saw many people say things like “I hope you’re considering non-hard-fork solutions as well”, so I asked around and tried to collect a list of recovery options that didn’t require a hard fork. The only two options I found were:

  1. Retroactive insurance payouts.
  2. Tokenization of losses.

I don’t see Option 1 as viable to address past issues. I didn’t really understand @alexvandesande’s point toward the end of the article about why an insurance company would voluntarily take on enormous liabilities on Day 1. Even if some well meaning person wanted to, what investor would fund them?

Also, even for future incidents I’m skeptical. Imagine an insurance company starts up and is wildly successful. It pays out some small claims while making a great profit. Everyone is happy. Then, the big one hits. Why wouldn’t it push for a fork? It would potentially have huge resources available to run an aggressive PR/legal campaign.

For Option 2, I had considered that the recovery token contract would be funded by future recovery. At best, this would postpone a fork, and at worst it would just dupe a lot of people into buying worthless tokens. Alex did not make this assumption, but I think some of my other pros/cons still apply.


  • Immediate liquidity for some projects that are desperate for funds
  • Does not require an immediate hard fork (block reward will require a hard fork)
  • A reusable solution


  • The allocation of recovery tokens will itself be controversial.
  • New allocations of recovery tokens could devalue existing tokens by a lot. Knowing even a few minutes in advance of a decision would present an enormous advantage and (in my opinion) a much bigger potential for abuse than something like EIP-999.
  • It does not address stuck tokens
  • There is always the possibility that there is some clever way to recover stuck funds. Imagine a future upgrade of the EVM which seems totally unrelated actually makes some type of class of stuck ether recoverable. What then?
  • Which accounts will receive tokens? Won’t this process look almost exactly like the ERP process? If not, how will it work?
  • What if the Recovery Token contract has a bug? Would people support a recovery fork in that case? Who is responsible for the recovery token contract?
  • Would recovery tokens be viewed as securities?
  • People that hold recovery tokens will have an incentive to make them more valuable – what sort of behavior might that encourage (e.g. fighting against every recovery issue that comes after you, spreading rumors about a huge loss to get people to sell before you, a large donation promised that never actually takes place)?

I’m not entirely opposed to this approach, but these are the reasons I originally dismissed it. In the end, I think if people are willing to allocate recovery tokens and then allocate blocks rewards to back them, I don’t see why they wouldn’t be willing to just recover the funds in one go and avoid all this complexity and risk.

1 Like

That’s simply not true - the fundamental difference of a blockchain isn’t that you can’t change it, it’s that you can’t change it without everyone’s involvement and consent.

Why would you fetishise ossification like that?

What losses are being socialized?

Doesn’t locking up ether “change the available supply in an unpredictable fashion”?

1 Like

Everyone’s? Taken literally, it’s exactly what I wrote

a decentralized system requires unanimous agreement

yet clearly you don’t agree. So what do you actually mean by ‘everyone’?

I think we aren’t being very clear with the description of what the blockchain can and cannot do. Here’s a start, but please feel free to suggest changes … I’m sure I’m oversimplifying or just plain wrong in some cases (although not as egregiously as three word marketing slogans), but it’s a start…

  1. A blockchain gives independent nodes an efficient way to determine if their local version of history agrees with another node’s version of history. If they are identical, the block hashes will match. If they aren’t, they won’t, and the two nodes will know that there is some discrepancy.

  2. Anyone is free to make any change they want, anytime time they want, without anyone’s permission. However, the change will be detected and rejected by other nodes unless they also make the same change. A single person can split the chain – the extent to which is matters to everyone else is dependent on how many other people use that version of the chain.

  3. The history of the blockchain is immutable only for a given block hash. In theory, there are actually many versions of history that could produce a given block hash, although we assume only one such sequence of blocks will ever be known, and it will only be known if the hash is computed from history (not the other way around).

  4. The ledger, as an ongoing concern, is not immutable. It mutates with every transaction that is included in a block. If it were immutable, everyone’s balance would be zero (and that multisig library contract if somehow it were able to appear on a truly immutable system could not have been deleted, right?). Claiming that a change cannot be injected into the blockchain in the future because “the blockchain is immutable” doesn’t make any sense.

  5. Changes to the blockchain are automatically permitted when a submitted transaction follows a pre-defined set of rules. i.e. if I hold the private key for account X, and I submit a transaction that will send ETH from account X to account Y. Note, in this case, the rules permit me to mutate Y’s account balance without Y’s consent. You could imagine a blockchain in which the rules do not permit this.

  6. The rules of the blockchain system are not necessarily fixed. This is especially true in the case of Ethereum, where plans to regularly hard fork to upgrade the chain were expected from the very beginning. That is, part of the rules were that you could change the rules.

  7. There are rules about changing the rules, but we probably can’t fully describe them.


Weird idea.

When Bitcoin Cash and Ethereum Classic forked the lesser-accepted chain settled at about 10-20% of the other chain’s value. Therefore, if Ethereum forks over this issue, participants in one or the other chain should probably expect a loss in the value of their holdings. Those who are holding locked ether would be better off than they currently are, but they would not recover the full ‘nominal’ value of the ether. The other side would probably see a diminution of their value as well because of the controversy. Both sides lose.

Alternatively, if the two sides agree not to fork, the locked ether could be recovered, but a “fencing” penalty could be extracted by burning 50% of the unlocked ether. An agreement such as this, I think, would be good for the community. The holders of the locked ether might expect to get a higher value than if the chain contentiously forks (if theirs becomes the lesser-accepted chain – the same argument can be made from the other side as well). Both sides might win.

I don’t think this will ever happen. Nor do I necessarily think it should, but I thought I’d throw it out there just to see what you’all think. If I had to express a preference, I would say do not recover the lost ether because the alternatives (including this idea) are worse.

I just listened to the April 20 core devs meeting recording. My opinion is that consensus on EIP 999 is not going to be achieved. There are at least a few highly motivated and vocal people who are consistently against any recovery of funds. I believe these people are a small minority, but I admit that it is hard to judge. That’s why I think consensus is unlikely. Since consensus is unachievable, I think we must embrace a contentious hard fork. I support EIP 999. I would like to see clients offer the option of EIP 999. I believe the vast majority of miners and other people who run clients will support EIP 999. Many of these people may be silent and prefer not to get involved in argument. That’s why I decided to speak up myself. I don’t want to argue about EIP 999. I just support EIP 999 and want to see it offered as an option that I think the vast majority of silent people will support.

Consider that it’s possible that the cost to ether stakeholders who didn’t use insecure smart contracts & lose funds in a parity multisig wallet would be greater in the event of a chain split than would be the value recovered by those with funds in the wallets in question. A chain split is simultaneously an act of creation (by means of creation of new tokens) & destruction (by means of dilution and the introduction of new problems of user confusion, which have real economic costs to users who didn’t lose funds). And I think a chain split is guaranteed to happen if we follow through with EIP-999. If the project of Ethereum is that we’re attempting to build, in some sense, an immutable actual free market, then using governance to introduce economic shocks into the system seems to defeat a huge part of the rationale which attracted many of us to Ethereum in the first place – namely, to design systems which could not be interrupted by even the tyranny of the majority – unless users consented to being governed by that majority. By holding the token, we have not consented to arbitrary violations of immutability, even ones decided by a governance process. The only thing users consent to by holding ether is participation in an immutable network which allows the transfer and use of that ether token.

If we’re speaking in general terms about the question of ‘under what circumstances should immutability be violated to protect users,’ where exactly do we draw the line? How is my accidentally sending funds to a non-existent address no less viable of a reason for eth users to come to social consensus on violating immutability to bail me out? As a community, do we have a standard on what activity qualifies for a bailout? If so, what is that standard?

I personally think ether should never be rescued for users with a governance process sanctioned violation of immutability. If a user wants to create a token on-chain with its own governance logic built in that allows for arbitrary violations of immutability to be made based on some vote of individuals who use the token, more power to them in building those systems and storing value that way in their own system with virtual governance. I think it should be enforced via community norms that users should understand that when interacting with the ethereum token & network, the ‘social contract’ we’re signing up to is that if we want to continue participating in the ethereum mainnet, we accept that contract code runs as it is written, with no recourse for bugs in contract logic available via violations of immutability in the EIP process.

I try to say this respectfully to all users who lost funds in a parity multisig wallet.

To understand why I support this EIP, I expose the premises my reasoning starts from.

  • Consensus always wins, the God of Code does not exist (yet). Changing blockchain state is always achieved by consensus, it’s already true for every block and transaction. Consensus is expressed by people, and people form a Community around those consensus rules
  • EIP is a good enough method to propose changes that require a hard fork. Different methods can be chosen to propose changes to the Community, but EIPs are already used to reach consensus about many different changes in the Ethereum ecosystem (Core, Networking, Interface, etc.). If we need to change something at chain level we need consensus, an EIP sounds to me a good enough method to try reaching such consensus
  • A precedent already exists at block 1,920,000 (20th July 2016), EIP779. Almost 2 years ago, because of some bugs in the DAO contract, someone moved 3.6M ETHs (of a grand total around 12M ETHs) from the DAO balance to its own account. After many days of discussion, the majority of the Ethereum Community agreed that the contract didn’t acted as intended by the DAO’s developers, and it chose to hard fork from the original chain to rescue funds of DAO’s investors, zeroing the hacker’s balance and giving funds to the original smart contract. This precedent demonstrated that the Ethereum Community tolerates changing the blockchain’s state in some specific cases. Ethereum Classic - the original chain - is still there demonstrating that Community matters and consensus mechanisms work
  • We can discuss about changing chain’s state because of errors in a smart contract. In this community this kind of discussions are allowed, and in case of success a hard fork is admitted restoring something that went wrong. The DAO’s hard fork, EIP779 and this EIP999 are here to demonstrate that. And it’s very good for me to have two communities that act differently, because I can choose which one is the best for each different use case

About this specific EIP

  • This seems to me a very reasonable fix. The DAO fix was very serious, and it changed the state at a very intrusive level: it essentially moved funds from an account - the hacker’s one, that has gained those ETHs following the bugged rules of the smart contract - to the DAO’s account. This is very far that case: here many people lost access to their own ETHs, but those funds gone nowhere: they are still there untouched inside each multisig wallets, but nobody can use them. And this because a piece of code - a library - some wallets rely on was deleted by the hacker. This EIP will enable those wallets to regain access to their own funds, giving wallet’s owners the ability to use those ETHs again

At the end this EIP simply restores a state of the chain where multisig wallets can work again, no one loses ethers, tokens or whatever and no one gains them. This seems legit enough to me, and this is why I support this EIP.


The problem with EIP 867 is that it only works for large holders. Someone losing 5 ETH in a provable fashion will be of much lower priority than someone losing 10000 ETH. EIP 867 will just spawn more EIP 999 style discussion. There will be disagreements over the intended semantics of contracts and the fairness of recovering funds.

Moreover, support of EIP 867 begs the question, how do you prove that the parity multi-sig wallet did not behave correctly. Is it absurd the fathom that a contract can burn collected ETH using the self-destruct mechanism?

I think the main problem people will have is that EIP 999 and even EIP 867 will be an example of a system working to absolve the errors of wealthy stakeholders, without regard to other stakeholder.

I believe that in the future Recoverable Tokens (EIP 1080) will be able to provide an opt-in solution for all who want the added safety.

What makes you believe this? The way 867 is written, it makes this explicitly not the case and a proper recovery proposal that recovered 1 attoeth would be more valid than an improper proposal that recovered 1 megaeth.

The plain nature of the situation is that people with more at state will have more incentives to comply technically and promote token recovery to debs.

EIP-999 is a great example of this.

I don’t think Jenny from the block would be able to get a core dev to even consider her proposal. Especially because it’s mostly not obvious what contract features are bugs and which are features or which transfers are purposeful and which are accidental.

There must be some barrier to entry to prevent spam/denial-of-service. Jenny can solicit help from others to craft the ERP, and whether a proposal is valid or not is what determines whether the core team will look at it, not how much ETH it recovers. It is the EIP editors’ job to give Jenny feedback on the ERP so that by the time it is in front of the core devs it is already well formed and ready to go. With a standardized mechanism for recovery, implementation by the various dev teams is near zero (after the first) because the ERP provides a standard format for recovery that the clients can just plug in.

The argument it sounds like you are making is that we should recover no one’s ETH because some subset of users do not have the means or motivation to complete the ERP process. This, IMO, is just catering to the lowest common denominator. Considering how easy (relatively) the proposed ERP process is I think that this is far too extreme of a position to take.

How do we define this barrier to entry, it’s very important to understanding 867.

Also, how do you prove to the core devs that a contracts semantics ought to be different that were written or that a transaction should have never happened? Sending Eth to the 0x or not-yet-created address are not sufficient tests as this is used to burn money or send money to people who haven’t broadcasted their account yet.

Moreover, if it weren’t for the popularity and marketing around the Parity Multisig wallet, I would have no way of knowing that people didn’t expect that self-destruct switch to be a sort of Eth burning mechanism. I only have a good level of certainty here because of the size and marketing around the players involved. (If only size and marketing came with auditing)

Without a definition of the barrier to entry, I am assuming that the process will take place in a similar fashion as recoveries through the core devs have always taken place. We have considered two recoveries: the DAO and EIP-999. No small recoveries were ever considered.

Thus I think this subset of users is the vast majority of users besides maybe the 20 top accounts.

This is because, I believe, crafting a PR to do a recovery is incredibly hard for the average user. The ERP process attempts to simplify that process significantly such that you do not have to be an Ethereum client developer to understand how to craft such a recovery. It still requires some understanding of how Ethereum works, in particular how trustless systems work (no one is going to just “take your word for it”, but it doesn’t require you to understand the inner workings of Ethereum clients.

This is the “reasonable human” test. For all of the proposed cases (big or small) for the ERP process none of them have resulted in someone truly believing that the losses were intentional. For example, there is no reasonable argument to a human of average intelligent that the ICO who posted a JavaScript truncated address to their website intended to do that in order to cause people to burn money that was intended to go to them. Similarly, there isn’t a reasonable argument that someone would intentionally send funds to an address that is off-by-one-byte from a real address that has seen real use. For the Parity case it is obvious to a reasonable human that the intent of the wallet wasn’t designed (by Parity) so that someone could burn everyone’s money (including the author’s). The wallet was clearly advertised and used (by the author) as a form of secure storage.

Part of the ERP process is to provide an argument as to why you believe your ETH should be recovered, which means providing an argument like the above examples (though of course more in-depth and well written). The purpose of this argument is to convince a reasonable human that the funds are inaccessible due to an accident. Anyone can refute your argument and it is up to reasonable humans to decide if the refutation instills enough doubt to block the recovery.

@bradleat Out of curiosity, would you be more open to this EIP if it were preceded by a successful recovery of one of the other causes of losses that effects more “normal” users (like off-by-one-byte address)? There is some ETH lost to address typos that could be recovered, but no one has bothered to draft a PR for it yet.

For those that say immutability at all costs, well, there’s not much to discuss—there simply exists no sufficient condition for recovery.

For those that do think there exists a sufficient condition for doing a recovery, what do we think of the “considerable example”, given in the EIP-867 spec? If this is deemed insufficient, what would be an even more compelling example? For reference, I reproduce it below:

Considerable example (concise, includes supporting evidence, no negative impact): A crowdsale run by XYZ incorrectly published the testnet address of their crowdsale contract to their public website at the start of their crowdsale on Jan 19, 2018. 501 ETH was sent by 328 users on the mainnet to the incorrect address between block 4,235,987 and 4,236,050. See here for the testnet contract, and see here for the transactions to the same address on the mainnet. See here for a statement made by XYZ on their website. Because there is a contract at this address on the testnet and the corresponding nonce for the creator address has already been used on the mainnet, it is considered effectively impossible that anyone coincidentally holds the private key. We have verified that all transactions came from addresses with no associated code, so there should be no issue returning eth to the senders.

I would like to come up with the most steelman’ed example(s) possible for recovering funds. We could then set an incredibly high standard of: “Unless your recovery meets this incredibly high standard, the answer is no.” This would allow us to have more clarity for what sort of recoveries would be done instead of the current vagueness.

For those into immutability (which include myself), we obviously want these recoveries to meet incredibly high standards. And when Plasma chains become more of a thing, it becomes more sensible for us to forbid recoveries on the main chain. But we aren’t there yet. So until then I would like to come up with the most steelman’ed example(s) possible that have the most support for recovery. And when the side-chains become a thing, then we can re-open the issue as to whether to forbid recoveries at all on the main chain.

I believe @phiferd has a Google doc with several examples of stuck/lost ETH that are reasonable targets for recovery. There are a handful that effect many average users rather than few big holders.


Please email this Google doc to me. I’m looking at buying a pollster to survey on the mood on these different scenarios. Email: i@virgil.gr

There’s a list here of actual cases:

The example in the EIP could have been better, although I was trying to come up with a realistic example that wasn’t an actual issue (that I was aware of). There’s certainly room for improvement.

The most convincing cases for me are:

  • The multisig issue. Requires no movement or ETH or tokens. Ownership is absolutely clear.
  • Off-by-one errors when sending funds. When sender A sends to address B’ (instead of B). A message signed by both A and B indicating where the funds should go (either back to A or to B) would be pretty solid. I don’t really see any room for abuse.
  • Contracts deployed with ETH but no code.

There are others as well – I don’t mean for the list to be exhaustive, but these are pretty solid cases.

1 Like