EIP-999: Restore Contract Code at 0x863DF6BFa4

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

EIP-867 was the most streamlined and simplified process we were able to imagine that met the primary constraints (ownership uncontested, required changes are fully specified, the way in which the required changes were determined is auditable by anyone). However, that certainly doesn’t mean it can’t be improved.

Really, I think you’re talking about three separate issues:

  1. Awareness: People have to know that such a process exists. If it’s a secret, then only some people will know it’s any option.
  2. Cost: Ideally, the cost should be (at minimum) equal to the amount of effort required by people to take whatever actions are needed. If you lose $1 on the train, it’s unreasonable to ask the train owners/staff to spend more than $1 worth of effort looking for it. In that case, you’re just transferring your loss to them (and then some).
  3. Difficulty: If the process is too complicated, some people won’t be able to execute it on their own. This is a common problem which happens all over the place in the economy. People generally don’t represent themselves in court, many people hire someone to do their taxes, etc. Sometimes these experts can be replaced with automation (e.g. TurboTax in the US), but not always. It really depends on how much each case looks like the one before it.

Item 1 is pretty easy to solve at the ~75% level, but there will always be people that are just unaware of their options. I don’t know what to do about that, but I don’t think it should stop us from providing the options in the first place. In any case, part of the motivation for writing the EIP was to make the process discoverable.

Items 2 and 3 were both important considerations for EIP-867, and in the end I think the proposed system does a decent job at removing a lot of complexity and cost. Can it be improved? Absolutely. However, optimizing it after the process is actually used a few times would be far easier.

My assumption was that a single ERP could handle many cases of the same type. This would make it possible for the cost of recovery for an individual case to be very low. Also, EIP-867 didn’t consider any particular examples. Instead, it was just meant to say “hey, if we do it this way, maybe we can consider smaller examples”


For sure. Perhaps committing to a ratio of little guy to big guy support would help quell a lot of suspicions here.