This question already has an answer here:

Just read about the today issue with parity multisig wallets,


where as far I can understand the problem is that a library linked to many wallets was hacked, transformed to a contract and finally suicided causing all the wallets to freeze forever. However, this comes with some surprise for me as I assumed that like in traditional languages, linking a library to a contract was a compile time process where once the compilation is done you'd expect a bytecode containing contracts and libraries to be deployed to some address. Instead, in the docs I read that libraries have their own ethereum address. The library hacked today seems in fact to live at some address in the blockchain and then linked to many contracts. This puzzles me a bit, then when I use SafeMath.sol in my code what is my contract linking to? A bytecode I've just compiled or some instance already deployed?

Can anyone explain how the linking mechanism works?

marked as duplicate by Ismael, Richard Horrocks, Malone, maurelian, Achala Dissanayake Nov 9 '17 at 7:28

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • This question is older, the other is a duplicate of this one – Davide C Nov 8 '17 at 9:39
  • Sorry, but the other has a better more complete answers. Merging both question should be ideal, but I do not think that is possible. – Ismael Nov 8 '17 at 16:35

Library-driven development involves deploying what's defined as a library contract. You can link a child contract to it using the keyword using, or by replacing all references to the library contract in the child contract with the address of the deployed library.

With the keyword using, a function in the library contract can be called as a method of its first parameter, making it look like it is a proper method. When you link a library contract using the deployed libraries address, it is employing what is known as DELEGATE_CALL's to call methods on the library contract.

The Rub™

Library contracts can't be upgraded or modified.

This means, if you call selfdestruct on a library contract that other smart contracts link to, and those smart contracts can't be modified to link to another library...you just obliterated all those dependent smart contracts functionality.

This is what happened with the Parity Multi-Sig hack; an anonymous user took control of their universal library contract and selfdestruct'ed it, obliterating ~500 Parity multi-sig wallets functionality and freezing ~$150M. Source

  • Does still ~$150M in freezing stage? Is there any ongoing project to save that money, or is it possible to rescue that money? @valkn0t – alper Sep 20 '18 at 11:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.