Would the published requirements have flagged real incidents?
We read 55 incidents from our public postmortems against the six requirements the oracle publishes for every contract. Most are bugs the score cannot see. For the 7 that are about who controls a contract, the requirements flagged 2, missed 2, and could not be applied to 3. We publish the misses next to the hits.
55incidents read, $1.2B lost
48outside what an authority score can see (code bugs, price oracles, bridge verification, custodial or unexplained wallets)
7about who controls a contract, $356.9M lost
2flagged by a published requirement, $297.7M of the $356.9M
Drift Protocol: Fails the published requirement "at least a 3-of-5 multisig" and the requirement "a confirmed delay before changes apply".
Fetch.ai / NuNet: Fails the requirement "admin power is not a bare key".
AFX Bridge: 5 of 7 would pass the "at least 3-of-5" requirement. The failure was the keys of the signers, which a threshold does not show.
Term Finance: A confirmed delay existed. What failed was who held the voting power.
BarnBridge: The write-up does not give the configuration before the takeover.
Virtue (IOTA): The keys belong to an oracle provider, not to a contract admin the oracle scores.
Ostium: The write-up does not say whether the signer was a plain key or a multisig.
The Drift case, start to end
The setup. Drift's program admin was a Squads multisig of five signers where two approvals were enough, with no timelock between an approval and its effect.
The preparation. Two signers were tricked, weeks earlier, into pre-signing transactions that use a durable nonce, which stay valid until used.
The day. On 1 April 2026 the attackers broadcast them: the program admin was overwritten in one go, a fake token was listed as collateral and the withdrawal guards were raised. About $295.7M left (press: $285M).
What the published requirements say about that setup. "At least a 3-of-5 multisig": not met, because two of five were enough. "A confirmed delay before changes apply": not met, because there was none. A reader who looked at the setup, not at the attack, had two reasons for concern the day before, and a month before.
What they do not say. They do not see a signature that was collected off-chain and not yet used: a pre-signed transaction is invisible on-chain until it is broadcast, so the watch could not have raised an alert about the attack itself. The requirements flag the setup that made it possible, not the attack.
Not a score at the time. No historical on-chain state was re-read. The setup is the one the write-up gives; "flagged" means the published requirements would have been unmet on that setup, not that the oracle showed a particular number.
Small numbers. 7 cases are cases, not statistics.
Classification. 55 write-ups from RealSpap/onchain-postmortems read by automated readers, the 7 in-scope ones re-read by hand against the text; pre-incident configuration taken from the write-up only (stated, inferred or not stated); no historical on-chain state was re-read.
A hit is not protection. Two incidents passed the requirements and still lost money: a score about authority does not replace the security of whoever holds the keys.
A neighbour, and what differs
QuillAudits' Multisig Inspector publishes a retrospective on 11 multisig attacks, judging whether its own tool would have helped. Here the yardstick is the six requirements published for every contract, the set is 55 incidents, the misses are kept, and the raw data is below.