Parity Multisig
- Technique
- Uninitialized Proxy
- Classification
- Access Control
- Target type
- DeFi Protocol
- Affected chains
- Ethereum
- Source
- No public source link
On November 6, 2017, an Ethereum account triggered a self-destruct on the shared library contract behind Parity's multi-signature wallet, instantly freezing roughly 513,000 ETH — about $150 million at the time — spread across close to 600 wallets, according to TechCrunch's reporting the following day. Nothing was stolen: the funds simply became permanently inaccessible, including a large share of the ETH the Web3 Foundation had raised in its ICO.
How the attack worked
Parity's multi-sig wallets were "thin" contracts with no logic of their own. Every wallet forwarded its calls via delegatecall to a single shared library contract, which actually executed ownership checks, signature counting and fund transfers. This design had already caused one incident four months earlier: in July 2017 an attacker called the library's initWallet function directly, made themself the sole owner of three specific wallets, and drained roughly 153,000 ETH, as documented in OpenZeppelin's postmortem of that earlier hack.
The patch Parity shipped after the July hack blocked re-initialization of already-configured wallets — but it never addressed the library contract itself, which had never been initialized and therefore still showed zero registered owners. In November, someone called initWallet on the library directly; the ownership check passed trivially because no owner had ever been set, so the caller became the library's owner. As owner, they then called the function that self-destructs the contract. Because the library held all the executable code and every dependent wallet only stored a pointer to it, those wallets were left pointing at an address with no code — permanently unable to move funds, as OpenZeppelin's second postmortem lays out. This is the "contract not initialized" pattern: the vulnerable state wasn't a user's wallet but the underlying library everyone silently assumed was already locked down.
What happened next
Parity proposed EIP-999, a one-time protocol change that would have redeployed the destroyed library's bytecode at its old address without moving any funds. The Ethereum community treated it less as a technical fix and more as a precedent-setting fork decision. A signaling vote came back 330 against and 300 in favor, and Parity's founders publicly ruled out pursuing a chain split over it, according to CoinDesk. With the proposal rejected, no code-level rescue followed, and the ETH remains locked at the dead library address to this day.
What follows
- Any architecture that concentrates logic in a shared library reachable via
delegatecallmakes that library, not the individual wallets built on top of it, the real attack surface — its own access control has to be at least as strict as any wallet's. - A patch that closes the reported exploit path without auditing every other public function on the same contract can leave a second, unrelated path open — the July fix locked one door and left another unlocked.
- There was no visible warning sign for holders: wallet owners had no way to know their funds depended on the health of a contract they never interacted with directly.
- Ethereum's governance treated "restore destroyed code via hard fork" as categorically different from earlier interventions like the DAO fork — evidence that code-is-law held firmer once the immediate crisis narrative had faded.
Sources
- A major vulnerability has frozen hundreds of millions of dollars of Ethereum — TechCrunch ↗
- On the Parity Wallet Multisig Hack — OpenZeppelin ↗
- The Parity Wallet Hack, Reloaded — OpenZeppelin ↗
- Parity Says No Intention to Split Ethereum Over Fund Recovery — CoinDesk ↗
- Ethereum Community Votes Down $330 Million Parity Refund Request — Bitcoinist ↗
Sources checked 07.08.2026
On-chain DeFi carries smart-contract risk. Keep core funds on a regulated exchange.