4 February 2025. A macOS workstation belonging to a Safe developer is compromised, reportedly through a project file that had been downloaded to the machine.
19 February. Malicious JavaScript is injected into Safe's front-end assets.
21 February. Bybit executes a routine multi-signature transfer from a cold wallet. The altered interface shows each signer a normal transaction. Underneath, the transaction logic and the destination have been changed.
Every signer approved what they were shown.
More than $1.4B, including 401,347 ETH. The largest cryptocurrency theft recorded. Widely attributed to North Korea-linked activity, and linked by the FBI to the TraderTraitor cluster.
Now read what did not fail.
The delegation model worked exactly as designed. Multiple independent signers were required. All of them were legitimate. None was compromised. Each reviewed the transaction before approving it.
What failed is that every one of them reviewed it through the same interface.
The requirement for multiple approvals did not produce multiple checks. It produced multiple confirmations of a single lie.
F103-04 introduced smart accounts and F103-05 covered the new attack surface they created. This lesson is about the specific act of handing authority to something that is not you, whether that something is code or a group of people, and about the assumption that quietly breaks.
Two kinds of delegation
To code. A contract acts on your behalf according to rules: a spending limit, a session key, a guardian set, an automated strategy. You trust the code, whoever can upgrade it, and the infrastructure that relays your intent, which is F103-04's dependency count.
To people. A quorum of signers must agree. You trust that a threshold cannot be reached without you, which for most arrangements means trusting that the signers will not collude and will not all be compromised at once.
Both are usually presented as strictly safer than a single key, and both are, against the threat they were designed for. The autopsy is what happens against a threat neither was designed for.
What multi-signature actually protects against
Be precise about the guarantee, because the marketing is not.
It protects against one signer being compromised, or acting alone. That is real and it is the reason serious operations use it.
It does not protect against every signer being shown the same false information, because in that scenario the signers do not disagree. They agree, correctly, on what they were shown.
Requiring three approvals defends against one person being wrong. It does nothing against three people being wrong in the same way at the same time, and the mechanism that makes them wrong in the same way is that they are all looking at the same screen.
A three-of-five arrangement. Ask how many independent judgments are really being made.
The intended model. Five signers, each independently evaluating the transaction. An attacker needs to defeat three.
If each signer independently fails to detect a malicious transaction with probability p, and detection is independent, the chance that three specific signers all miss it is:
p x p x p = p^3
At p = 0.2, meaning each signer catches four out of five bad transactions on their own:
0.2^3 = 0.008, less than 1 percent
That is the number the arrangement is bought for.
The actual model, when all five use one interface. The interface either shows the truth or it does not. If it lies, the probability that a signer approves is no longer independent, because they are all reading the same corrupted source. Detection now requires a signer to check outside the interface.
If none of them does, the probability all three approve is not p^3. It is:
1.0
The arrangement did not degrade from 0.008 to something worse. It collapsed to certainty, and it did so without any signer behaving badly.
The transferable question is therefore not how many approvers you have. It is: what do all my approvers have in common?
Shared interface. Shared device type. Shared network. Shared source of truth about what a transaction says. Every shared element is a place where five judgments become one, and the count on the front of the arrangement stops describing anything.
Verifying outside the interface
This is the practical defence and it is the same instruction F104-01 gave about hardware wallet screens, arriving now with $1.4B behind it.
Read the transaction on a device the proposing interface does not control. A hardware wallet renders the destination and the decoded call from the transaction data itself, not from the web page. That screen is the one display in the stack that a compromised front end cannot write to.
Check the destination against a source you fetched separately. Not the address shown next to the button. An address you already had, in a note you wrote earlier, or an allow-list at the contract level.
Have at least one signer verify by a different route entirely. A different interface, a different machine, a command-line tool, a printed reference. The point of multiple signers is multiple perspectives, and identical tooling deletes the plural.
Treat any unusually large or unusual movement as an event. Slow it down, verify twice, and confirm out of band with another signer on a channel neither of you reached through the interface, which is F111-02's protocol applied to a transaction rather than to a person.
Every autopsy in this area reduces to the same thing: somebody approved a payload they could not read.
Sometimes it is unreadable because the device cannot decode it. Sometimes, as here, it is readable and false. The outcome is identical, because in both cases the signer's judgment is operating on something other than the transaction.
F103-05's standing rule applies without modification. If you cannot state in one sentence what a request does, from a source the requester does not control, do not sign it.
The uncomfortable corollary for delegation is that adding signers does not fix blind signing. It multiplies it.
When delegation to code is appropriate
Tie this back to F104-02, because the answer differs by tier and a single answer would be wrong.
Burner. Anything. That is what a burner is for, and experimenting with new delegation mechanisms is exactly the job.
Daily. A good fit for the genuinely useful features: spending limits enforced on-chain, session keys that expire, guardians who can recover access. The tier is bounded, the code failing is survivable, and F103-04's recovery capability addresses the most common cause of loss.
Vault. A poor fit, and the reasoning is F104-06's. The vault's only job is to still be there in ten years. Code that must keep existing and keep behaving is a worse bet than a key and a piece of metal, and Parity in F103-04 is 513,774 ETH sitting at addresses whose logic was deleted.
Multi-signature is a partial exception, because it addresses a real vault threat, which is a single key being compromised or lost. It brings the coordination problem from F110 with it, and it brings this lesson's autopsy, and it should be adopted with both understood rather than because it sounds stronger.
Multi-signature is strictly safer than a single key, so more signers is always better.
Adding signers reduces one risk and increases two, and the trade stops being favourable sooner than people expect.
It reduces the risk that one compromised or lost key is fatal. Genuinely valuable, and the main reason to use it.
It increases the chance you cannot reach the threshold. Every signer is a person who can become unreachable, uncooperative, incapacitated or dead. F103's opening survey says losing access is the more common failure, and a five-of-nine arrangement has nine ways to lose a key and requires five people to be available on the day you need them.
It increases the correlated-failure surface. More signers usually means more shared tooling, because coordinating five people on five different verification methods is hard and everybody converges on one interface. That convergence is the autopsy.
So the useful question is never how many signers. It is how many genuinely independent verifications happen before a transaction executes, and that number is frequently one regardless of the threshold.
Two signers using different tooling and verifying on separate hardware are stronger than five signers clicking the same page.
Delegation to code trusts the contract and whoever can change it; delegation to people trusts that a threshold cannot be reached without you. Multi-signature protects against one signer being compromised and does nothing against every signer being shown the same false thing, because that produces agreement rather than disagreement, which is how a three-of-five arrangement collapsed to certainty and $1.4B left Bybit with no signer behaving badly. So stop counting approvers and start asking what they have in common, verify the destination and the decoded call on a device the proposing interface does not control, and remember that adding signers does not fix blind signing, it multiplies it.