EIP-999: Restore Contract Code at 0x863DF6BFa4

These are really solid arguments to make, especially about the community being friendly and doing really awesome work, and how too much noise from recoveries would affect that.

My question is how do you stop requests like this? I think there an equally likely chance these kinds of requests continue to happen because the people who lost access to their funds are pretty well incentivized to continue trying any tactic that gets them what they want to accomplish. So we will keep seeing proposals like this occur from this hack and others like it where large quantities of valuable assets are lost.

What happens the next time an “economic threat to the entire ecosystem” occurs? What if Casper or Sharding contracts have a bug? What is the process for handling that? I think there’s balance to be struck where only the most important bugs and exploits are incentivized to go through a very complex and long-term process to ensure near-universal consensus on how the recovery should be handled.

That only happens if we are willing to discuss this as a community instead of pretending it will go away with time.


This EIP adds nothing of value to the chain. All it does is redistribute wealth from the current owners and give a little bit back to Parity. You can’t perform such an action without either tyranny of the majority or tyranny of the minority benevolent as the action may be.

Current consensus protocols are clear; put it to a vote to the miners. That’s the whole point of Proof-of-Work.

It seems incredibly, incredibly foolish to me to change the fundamental operating assumptions of a block change for an issue that negatively affects less than 1% of the total supply. I can’t believe it’s even a discussion.

im strongly against this EIP.


I am philosophically in favor of being able to perform actions such as EIP-999, but only after a very thorough analysis of potential outcomes and engaging in a very careful ethical and legal review.

Beyond being in favor of occasionally “intervening”, I would advocate that the community generally be prepared to alter the shared state in order to prevent harm to individuals or organizations.

Tools and governance processes need to be in place.

Still, I understand and appreciate that there is a widespread expectation for immutability in Ethereum. This is a special property which has many measurable benefits. However, immutability of information systems is unprecedented in human history. This property does not absolve us of moral or legal responsibility for what happens in the Ethereum network. It may be dangerous to enforce this immutability absolutely, or simply to be unprepared when we as a community must suddenly act to alter the shared state.

Perhaps with EIP-999 and other ether recovery EIPs we can attain and manage an extremely low mutability in our system instead of assuming immutability.


I oppose this EIP, and I oppose the way discussion has left GitHub and is now on this new site.

Ethereum is as immutable as you design it to be. The Parity contract was designed to have an immutable reference to a library that got deleted. What more is there to say?

Should someone get special treatment because they have a lot of money? I don’t think so. If this EIP goes towards a production state I will be the first person to maintain an Ethereum blockchain that has not been hardforked to restore the parity library.


In my opinion…

Decentralization is not an end in and of itself but a means to eliminate the risks that come with a centralized system. Specifically, decentralization provides the means to protect against centralized control that would otherwise threaten an individual’s right to control his or her own assets. Decentralized blockchain systems have value as a tool because they can protect private property rights in a way that was not previously possible. However, to the extent these new systems introduce new ways that prevent owners from accessing that which they own, they fail to be useful.

Also, the blockchain is not immutable, nor would it be of any use if it were. The current state of the blockchain mutates with every transaction. However, client logic is designed to prevent unauthorized changes. An account owner authorizes the client application to perform actions on his or her behalf by signing transactions, thus proving their ownership and intent to mutate their portion of the blockchain state. To be clear, owners grant permission to the client to modify the blockchain state on their behalf, not the other way around.

How, then, should a decentralized system behave when users are prevented from controlling the assets they own?

Proof of ownership and intent are of primary importance. If ownership and intent can be demonstrated (e.g. through signed messages, data on chain), what grounds do we have to prevent owners from controlling their assets? Why should we sacrifice the ends in support of the means?


But how much is occasionally? What schelling point are you advocating?

The reason “immutability” is popular, is because it’s an exceptionally good schelling point.

If you don’t have an equally good schelling point to offer, I don’t see how the community can be be prepared to alter shared state, no matter what harm might be the consequence.

1 Like

How much money do you need to lose for it to be news?

1 Like

Immutability is a far simpler schelling point. By choosing to manage low mutability we do incur costs and risks.

Perhaps a scheduled intervention should be so rare as to be newsworthy. This way, users can expect to a well-publicized notice about a proposed intervention that may affect them, and plenty of time in which to voice their concerns.

It may be appropriate to set the bar very low for how much individual damage of losses would oblige an intervention. If 10,000 people experience a very small loss correctible by shared state alteration, and performing a recovery has a very low cost in effort and risk to others, the only requirement may be ensuring due process and well-publicized notice.


I oppose this EIP.

For Ethereum platform to retain its value proposition retro-active irregular stage change should not be institutionalized or pushed through unless the entire platform is in jeopardy. EIP should be for protocol improvement only, not for retro-active correction of a selected sub-set of errors that have been made by some vested interests.

I believe funds currently locked would have benefited the ecosystem & good intention of EIP-999 proponents but can’t say the same about future actors that will try to go down that path again.

Internet services got hacked zillions on time and the internet is still being used. Planes crash every now and then but the airline industry has been flourishing.

Work should be done to make Ethereum / DLT tech much safer and usable doesn’t equate to irregular retro state changes should be made in this specific situation. There are plenty of other ways to make DLT much safer:
Solution 1: Mutualisation of risk: Companies & ICOs can create common issuance pools to cover part of the loss when missteps are made.
Solution 2 - Innovation at large: Formal verification, develop better practices, etc.


Do you think it is reasonable we will be able to restore any and all lost funds, including a single dollar in a failed testing application? No? I agree, that would be completely unworkable. So there would need to be some kind of cut-off what will be restored and what not. This is the dangerous part. Who will decide what should be restored and what should not? How do we prevent these entities from being bribed or extorted? Again, a blockchain where extortion and bribery is possible is not useful to me.

And that is not the only issue with that. There are more nuanced and indirect consequences of such a system. The fact that only some funds will be restored, because they are worthwhile (hundreds of millions vs a single dollar) means there will be a preferential treatment by definition. And this will bring forward a “too big to fail” mentality. Assume for a moment there is party A that runs a smart contract for multisign wallets and is the largest by far. Then party B comes with a new smart contract for multisign wallets. People like how it’s used, however, why should you use this new smart contract that is dealing with much less funds? Due to preferential treatments and “too big to fail” mentality it would be better to use an older, perhaps even inferior version, simply because it is dealing with larger amounts of money and hence in the event of lost funds, there is a greater chance they will be bailed out. This would then be a very strong force that leads to monopolies (centralization) and uphold these monopolies.

This “too big to fail” mentality reminds me one thing: Banks. And not in a good way. Please, for the love of Blockchain, let’s keep such a mentality away from Ethereum. We need real, workable and sustainable solutions: Formal third party code audits. If Parity had done their due diligence this would never have happened. And I agree, even with formal audits, things like these might still happen. So let’s solve this in a fair way: Insurance. Decentralized insurance funds could easily work for insuring against these kind of code bugs. And they’ll bring about loads of other positives: They will probably enforce code audits, or they refuse to insure a smart contract. They can be used by large parties, but also by smaller parties, hence no preferential treatment. And most importantly, disputes will be handled between the insurance fund and the affected party, instead of being handled at Ethereum’s base layer, which brings decreased immutability for everybody.


I fully agree. What’s the point of making this mistake, and not learning from it, but adjusting one of the key principles of the technology? Seems like a step in a very bad direction…

@maurelian this is definitely not how decisions are made. Most of the people at the core dev meeting know how to ignore the noise and listen to the distinct arguments. The ones that don’t know how to do that are generally overruled by those that do. Just because people all are making a lot of noise doesn’t mean the noise matters. If you have a novel argument to propose, or don’t believe a particular argument has been heard/addressed, certainly add it! But if you are just joining in the shouting your original strategy is the right one.

1 Like

@fubuloubu There is active discussion about how to potentially change the governance process elsewhere in this Discourse group. If you are interested in the topic, I encourage joining in those other discussions! This EIP is not the right place to advocate for changes to the governance process though, and any attempts to do so will likely result in your voice not being heard (because it is the wrong place to advocate for changes in process).

I disagree, this EIP and others like it is describing a Governance problem. Basically, we need to set a very strong signal one way or the other how to handle this situation of thing so that either we have a good process or recommendations like these stop getting made.

I appreciate you trying to ensure that my voice is heard in the right place, but I simply disagree with you here that this is not a governance issue.

1 Like

I am working on efforts for both these regards (standards and insurance) and I agree that they will reinforce each other and improve smart contract design overall.

I also hear you on the point that enabling even a rare recovery effort would enforce a too big to fail mentality, and that’s definitely not what anyone wants. It’s the whole reason we’re building stuff like this!

I worry that such an unforgiving environment will also weed out smaller actors from producing innovation, but you definitely can’t have both and I think erring on the side of immutability is the best decision, thank you for swaying me that way again. Any sort of recovery process can be corrupted and that’ll get us into the same mess that we’re in now with traditional systems.

Question is, how do we stop these proposals from continuing to be made?

@fubuloubu This EIP is following the current governance process. Many people do not like this governance process, and that is fine and reasonable but this isn’t the place to change the governance process. If you want to argue that this EIP is not following the governance process this is “the right place” but that has been debated pretty extensively and I believe most of the EIP editors and core dev team agree that this EIP is correctly following the current process.

Sorry! I think you misunderstand. I am not advocating for a change in the current governance process at all. This EIP and ones like it I believe arise from a deficiency in the governance process overall, and that’s the context I am discussing changes from. I am simply brainstorming solutions to what the problems might be in order to scope out what the problem is. There are no concrete recommendations I am suggesting to the current EIP process, and I think the discussion here is very relevant. My apologies for the confusion!

1 Like

You are certainly not alone in this regard, and this Discord group (ethereum-magicians.org) is definitely the right place to participate in such discussions. But if there is a deficiency in the current governance process, you are likely to not be heard or taken seriously by expressing it in this thread. I (and I suspect others) would love to see you voice your concerns in some of the other governance related threads though!

The things that do make sense in this thread are arguments for or against this change being implemented (e.g., why is it bad, why is it good, etc.) as well as technical arguments discussing implementation details, optimizations, potential consensus issues, etc.

The stuff that isn’t adding value to this thread (and should go elsewhere) are things like:

The fact that we haven’t taken a vote on this is bad

the community has spoken and this should be summarily rejected" (the current process doesn’t have a mechanism for actually measuring the community).

I hope everybody considers sound principles for blockchains when deciding EIP-999 and restoring funds in general: 1. Trust minimization, 2. immutability, 4. finality, 9. least authority and 10. adherence are the key ones in this debate.

10 Principles for Blockchain Governance:

  1. Trust Minimization: To reduce the reliance on trusted third parties for entering, processing and finalizing transactions and smart contracts.

  2. Immutability: Accounts, balances and smart contracts cannot be modified except by holders of corresponding private keys by entering transactions according to protocol rules.

  3. Fungibility: Native tokens must all be the same and interchangeable globally.

  4. Finality: Transactions and executed smart contract code cannot be reversed once entered, processed and finalized according to protocol rules.

  5. Censorship resistance: As long as they are compliant with protocol rules, transactions or smart contracts cannot be prevented from being entered, processed and finalized.

  6. Permissionlessness: As long as they are compliant with protocol rules, anyone from any place in the world can create accounts, enter transactions and smart contracts, or participate in the network as a competent developer, miner, validator, node operator, user, or any other prescribed participant or stakeholder.

  7. Auditability: Transaction and smart contract history must be analyzable and reconcilable by anyone or by holders of corresponding private keys.

  8. Reconcilability: Transaction and smart contract history must match mathematically to the latest and all future states according to protocol rules.

  9. Least authority: Developers, miners, validators, node operators, users, and all other prescribed participants and stakeholders must limit their participation to practicing only the functions of their roles in accordance with protocol rules and these common principles.

  10. Adherence: Developers, miners, validators, node operators, users, and all other participants and stakeholders must make sure they collectively decide and implement future changes to the protocol in accordance with these common principles.

This video explains it further: https://youtu.be/2Se97PBrMj4