This question already has an answer here:

In recent news about the potential loss of 300M USD.

Could someone please explain how it is possible to "kill" a number multi-sig wallets by removing code?

As a programmer I fail to understand how fixing buggy code or even deleting code can affect peoples cryptocurrency wallets? This is particularly cumbersome to understand as the Ethereum is supposed to be a decentralized platform. Isn't that the whole point, that it should protect the system from simple hacks (or programmer "errors")?


Realizing I am not familiar with the jargon in the context of cryptocurrency development programming, I suppose the question may be simplified by instead explaining how the programming code is kept separate from the wallet contents (the addresses affected). How can a program change, affect some random account address? (Are you not testing development code on a non-production system?)


In trying to better grasp whats going on, I read the following that may prove more helpful to others.

"What is the ethereum virtual machine?":

With Ethereum, every time a program is used, a network of thousands of computers processes it. Contracts written in a smart contract-specific programming languages are compiled into 'bytecode', which a feature called the ethereum virtual machine (EVM) can read and execute. All the nodes execute this contract using their EVMs.

Bitcoin miners validate the shift of ownership of bitcoins from one person to another. The EVM executes a contract with whatever rules the developer initially programmed. Actual computation on the EVM is achieved through a stack-based bytecode language (the ones and zeroes that a machine can read), but developers can write smart contracts in high-level languages such as Solidity and Serpent that are easier for humans to read and write.

This is also explained fairly well here:


There are two types of accounts:

  1. Externally Owned Account (EOA): an account controlled by a private key, and if you own the private key associated with the EOA you have the ability to send ether and messages from it.
  2. Contract: an account that has its own code, and is controlled by code.

By default, the Ethereum execution environment is lifeless; nothing happens and the state of every account remains the same. However, any user can trigger an action by sending a transaction from an externally owned account, setting Ethereum's wheels in motion. If the destination of the transaction is another EOA, then the transaction may transfer some ether but otherwise does nothing. However, if the destination is a contract, then the contract in turn activates, and automatically runs its code.

marked as duplicate by SteveJaxon, Richard Horrocks, Malone, Ismael, Achala Dissanayake Nov 10 '17 at 5:51


  • Quite possible a duplicate, but a normal user would never google for those terms. – not2qubit Nov 9 '17 at 17:09

This has been already discussed a few times and there's a lot of info around, but here's a very short, general answer.

Contracts can call the selfdestruct function which basically removes the contract's code from the blockchain. I'm over simplifying here, but to makes thing simple, if a contract calls this function, the contract won't be usable anymore.

Of course, the developer of the contract should not allow anyone to call Selfdestruct just because so.

Parity's contracts referenced another library/contract so each of these contracts did't have to implement the same functions over and over and repeat code.

The library Parity was using, referenced by these multi-sig contracts, had a vulnerability that allowed anyone to become the owner of said library by calling a certain function on it. Also, this library contained a function that called selfdestruct, available to the owner of the library.

All this person had to do, now that he was the owner of the contract, was to call this function to remove the library's code making it unusable and, thus, all the contracts that depended on it, became unusable.

As a sidenote, being a decentralized platform doesn't have anything to do with protecting the system from simple hacks or programmer errors at all.

//UPDATED for the updated question:

Without entering in technical stuff, a multi-sig wallet is just another contract that more than one person (Address) controls. In Ethereum, contracts can also hold money (ether). So the multi-sig wallet is just a contract that holds a balance and that requires the approval of several people to move the funds around. That's why only those wallets were affected, as an Externally Owned Account (a person's address) can't affect their code, because they have none.

These multi-sig wallets were affected because being them contracts with some coded logic, if the logic is flawed and has a vulnerability, it can be exploited like it happened with Parity.

  • I guess, I'm missing too much fundamental understanding of how all this fit together. I'm definitely new to this type of coding, and simply do not see how the cryptographic objects relating to peoples wallets are mixed in with the code base. Or if it is not, why someone would run beta/development code on a live blockchain/environment and not in some test environment to prevent these kind of accidents? I'm afraid I will not understand your answer for quite some time and more studies. It's all jargon to me at this point. – not2qubit Nov 9 '17 at 17:28
  • Updated my answer. The fact that the code had a bug does not necessarily make it a beta. In an ideal world, yes, all released code should not need any fix and should never fail, but it is impossible. The problems, of course, get exacerbated here because we are dealing with millions of dollars lost and with code that can't be changed in order to fix this problem without doing a Hard Fork. – pabloruiz55 Nov 9 '17 at 18:51
  • To me this procedure seem rather incomprehensible. I.e. That "anyone" can push code changes into live system, without any team review, that then directly can affect peoples investments. – not2qubit Nov 11 '17 at 18:24
  • Code changes were not pushed. The code is immutable. The problem is that the code was faulty and allowed anyone to use it in a way not intended by the developers. – pabloruiz55 Nov 11 '17 at 18:39
  • So that doesn't make sense either and open up a Pandora box of other questions. How can the code be immutable? Who's in charge of verifying and merging pull requests etc? Neither of which seem to be in concordance with the info in the duplicate question/thread. Or are you saying that each contract is individually (programming) code based? (Perhaps we should add a discussion page to this question?) – not2qubit Nov 11 '17 at 18:54
