A shared library's deletion froze wallets it did not own

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

What happened on 6 November 2017

On 6 November 2017, an account called an uninitialised function on a shared library contract used by Parity's Ethereum multi-signature wallets, becoming its owner, then triggered the contract's self-destruct function. The user's own bug report, filed the same day as a critical issue titled 'anyone can kill your contract' in Parity's repository and now showing under a deleted account, states only: 'I accidentally killed it.' Etherscan's record for the affected contract labels it 'WalletLibrary' and identifies it as the address that triggered the Parity bug, with a transaction at that address dated 6 November 2017. Because every Parity multi-signature wallet deployed after 20 July 2017 called out to this one shared library to execute its logic, deleting the library left each of those wallets unable to move the ether they held. A contemporaneous secondary report, drawing on Parity's own published analysis, put the frozen total at approximately 513,774 ether; that figure is not independently confirmed here against Parity's original postmortem, which this draft was unable to open directly.

Why a shared dependency turned one mistake into many

The wallets themselves were not individually broken; each one still existed, with its balance intact and its logic unaltered. What broke was a piece of infrastructure every one of them depended on to actually execute a transaction. This is the same pattern as a single vendor's outage taking down many otherwise unrelated services at once: the failure is not in any individual contract's code but in a dependency shared across all of them, a concentration of risk invisible until the shared component itself fails.

What custody means when it runs on code

A multi-signature wallet is usually presented as an improvement on custody: no single key controls the funds, several signers must agree. That protection held here, in the narrow sense that no signer's individual key was compromised. But the funds were still frozen, because the contract logic that interprets those signatures was destroyed. Multi-signature protects against a compromised or malicious signer; it does not protect against the code executing the signers' instructions being deleted. The distinction between key custody and contract dependency is easy to lose in marketing that describes multi-signature wallets simply as 'more secure'.

Questions to carry forward

• Does a wallet or contract depend on another deployed contract to function, and was that dependency initialised and secured?
• What happens to funds if a shared library, oracle, or bridge contract they rely on is altered or destroyed?
• Is a multi-signature scheme's security described in terms of signers alone, or does it account for the code executing those signatures?

The frozen ether was never stolen; it sat, and largely still sits, in wallets whose owners can be identified but whose funds cannot be moved without a further upgrade nobody has forced through. That outcome, immobility rather than theft, is its own answer to what dependency risk actually costs.