Parity's multisig wallets were smart contracts. To save space, they did not each carry their own logic. They all pointed at one shared library contract that held it.
On 6 November 2017, a user known as devops199 called an initialisation function on the library itself, which had never been initialised, and became its owner. Then they triggered its self-destruct.
The library was gone. And with it, the code that 587 wallets needed in order to move anything.
513,774.16 ETH, plus tokens, became unreachable.
Nothing was stolen. Nothing moved. The ether is still sitting at those addresses right now, visible to anyone with a block explorer, belonging to people who cannot touch it.
A contributor had reported the underlying flaw in August 2017. It was classified as a convenience enhancement rather than a security bug.
Proposals to recover the funds by changing the protocol were debated and not adopted, which is F101-03's coordination cost seen from the losing side.
The lesson is precise. The funds became unreachable because the account's ability to sign had been delegated to code, and the code could be removed. An externally owned account cannot fail this way, because there is nothing there to remove.
Everything in F103 so far has described one kind of account: a key signs, the protocol checks the signature, the transaction executes. That has been the model since the beginning, and it is unforgiving in ways the last two lessons have made concrete.
Smart accounts change the rule about what makes a transaction valid. That is a genuine improvement and it is not free, and this lesson is about the trade.
Two kinds of account
An externally owned account, an EOA. Controlled by a private key. A transaction is valid if the signature matches the key. The rule is fixed by the protocol, identical for everybody, and cannot be modified.
A smart account. Controlled by a contract. A transaction is valid if the contract's own code says it is. The rule is whatever was written.
That single change is the whole subject. Validity moves from a protocol constant to a program, and once it is a program it can express anything: two of three signatures, a daily limit, a time lock, a guardian who can rotate the key, a session that expires.
It also means the program is now part of your security model, permanently, which is the autopsy.
Four things they buy
Recovery without a seed. A smart account can name guardians who, collectively and usually after a delay, rotate the signing key. This directly addresses the largest cause of loss in this Academy, which is not theft but people losing access. It is the one genuinely transformative capability here.
Policy enforced on-chain. Daily limits, allow-listed destinations, amounts above a threshold requiring a second approval. F105 teaches you to enforce these by discipline; a smart account can enforce them by code, at the moment of signing, whether or not your discipline held that day.
Batching. Several actions approved as one atomic unit. Approve and swap in one signature instead of two. Genuinely better, and note carefully that it means one approval now authorises a sequence, which F103-05 shows being weaponised almost immediately.
Fee flexibility. Paying gas in a token you hold rather than the native asset, or having an application pay it for you. Mostly a usability improvement and a real one, because "you own the token but cannot move it without also owning the gas asset" has stranded a lot of beginners.
What each one costs
Recovery costs you a guardian set. Whoever can rotate your key can take your account, given the delay and the threshold. You have not removed the trust question, you have made it explicit and chosen the parties. That is an improvement over hoping, and it is not the absence of a counterparty.
Policy costs you flexibility at the worst moment. A limit that protects you on a normal day is a limit you cannot exceed on the day you urgently need to move everything, which is exactly what a compromise looks like.
Batching costs you legibility. One approval covering five actions is harder to read than five approvals, and F105-02's whole discipline is reading what you sign.
All of it costs you code. This is the one that does not have a mitigation, only a management strategy. Your funds now depend on a contract continuing to exist and behave. Parity is what that dependency looks like when it fails, and it failed without an attacker.
Compare the two arrangements by listing every party or artefact that must not fail.
An EOA with a hardware wallet:
- Your private key stays secret
- The chain's signature scheme is not broken
That is 2 dependencies, and the second is F103-01's arithmetic, which is to say it is not a real risk.
A smart account, typically:
- Your signing key stays secret
- The chain's signature scheme is not broken
- The account contract has no fatal bug
- Any library or implementation it delegates to still exists and behaves
- Whoever can upgrade the contract does not act against you, or nobody can
- The relaying infrastructure that submits your intent stays available and honest
- Your guardians do not collude, and remain reachable when you need them
That is 7, of which five are new, and every one of the five is a party or a piece of code rather than a mathematical fact.
Now the honest half of the comparison, because a raw count would be misleading. Dependency 1 in the left column is doing enormous work. Losing that key is unrecoverable, and F103's opening survey found 31 percent of people who lost access never got it back. Dependency 7 in the right column exists specifically to remove that.
So the trade is not "fewer dependencies is better". It is: you are exchanging one catastrophic single point of failure for five recoverable ones. Whether that is a good exchange depends on which failure you think is more likely for you, and for a great many people, honestly assessed, it is the lost key.
What is not defensible is holding seven dependencies and believing you hold two.
How they are actually implemented
Two approaches, and the distinction matters because they carry different risk.
Deployed contract accounts, under the EIP-4337 pattern, put your funds at an address that is a contract from the beginning. Your intent goes to shared infrastructure that relays it. This is the fuller version and it is the one where dependencies 3 to 6 above are most real.
Delegation from an existing EOA, under EIP-7702, keeps your ordinary account and lets you point it at code that runs on its behalf. Lighter, no migration, and it grants a live account the properties of a smart one. F103-05 is about what happened when that shipped.
The practical questions to ask of either are the same, and they are F101-03's chokepoints in a new costume: who can upgrade this, what happens to my funds if the provider stops operating, and can I exit to a plain address without their cooperation? A smart account whose answer to the last question is no has recreated a custodian with extra steps.
Smart accounts are strictly better, so the seed phrase is obsolete.
The capabilities are real and the recovery one addresses the single largest cause of loss in this field. Treating that as making the old model obsolete gets the risk exactly backwards.
An EOA's failure mode is that you fail: lose the key, sign the wrong thing. It is unforgiving and it is entirely within your control, and it has no dependency that can be withdrawn by anybody else.
A smart account's failure modes include ones you cannot influence at all. Parity's users did nothing wrong on 6 November 2017. They had followed the instructions, used a respected implementation, and their funds were made permanently unreachable by a stranger interacting with a contract they had never heard of.
Notice also which model each layer of this Academy assumes. The seed phrase is not obsolete because most smart accounts still have a key underneath them somewhere, and because the assets that hold the most value for the longest are usually held in the simplest way available.
The reasonable position is the one F104 builds toward: different tiers can use different account types. A daily-use account with policy limits and guardians is a good fit for a smart account. A vault holding what you cannot replace has one job, which is to still be there in ten years, and code that must keep existing is a worse bet than mathematics that does not change.
An EOA is valid when one signature matches one key, decided by the protocol; a smart account is valid when its own code says so, which makes validity programmable and makes the code part of your security model forever. That buys recovery without a seed, policy enforced on-chain, batching and fee flexibility, and it costs you a guardian set, rigidity at the wrong moment, harder-to-read approvals, and a permanent dependency on code continuing to exist. Parity is what that last one looks like: 513,774 ETH across 587 wallets, still sitting at their addresses, unreachable because a shared library was deleted by someone the owners had never heard of. Count your dependencies honestly, because trading one catastrophic failure for five recoverable ones can be a good exchange, and believing you have two when you have seven never is.