Multisig

What m-of-n enforces, precisely

The Security Alliance puts the protection in one clause: a multisig ensures that the compromise of a single private key is insufficient.¹ That is the whole of it. Everything else people believe about multisigs is an assumption layered on top.

The same guidance is direct about which variable actually carries the security. It is signer diversity, across organisational, geographic and operational lines, rather than the raw m-of-n number.¹ A 5-of-9 spread over nine employers, nine jurisdictions and nine device setups is a different instrument from a 5-of-9 spread over one office, and the configuration file reads identically in both cases.

Ronin: five of nine, one organisation

On 23 March 2022 the Ronin bridge required five of nine validator signatures. The attacker took direct control of four validators run by Sky Mavis. For the fifth, they used a permission granted back in November 2021, when Axie DAO temporarily allowed Sky Mavis to sign transactions on its behalf to help absorb transaction load, and which was never revoked. 173,600 ETH and 25.5 million USDC left the bridge.²

Nothing in the threshold arithmetic failed. Five signatures were required and five signatures were produced by keys the contract recognised. What failed was the assumption that nine keys meant nine independent parties, plus a delegated signing permission that had outlived its reason by four months because no process existed to review it. Neither of those is a cryptography problem, and neither shows up in an audit of the contract.

Three ways m-of-n gets defeated without touching the threshold

The first is organisational concentration, which is Ronin. The n keys collapse into a smaller number of real parties, and the effective threshold is the number of organisations rather than the number of signatures.²

The second is the contract underneath. Parity's security alert of 19 July 2017 told users that a vulnerability had been reported in a version of its multisig contract wallet source, and that anyone with funds in an affected wallet should move them immediately.³ The root cause was an initialisation function in the shared library that an attacker could call to take ownership and drain the wallet. Honest signers, uncompromised keys, a correctly configured threshold, and the funds went anyway.

The third is the signing surface. Bybit disclosed that on 21 February 2025 almost 1.5 billion dollars in ETH was taken from one of its Ethereum cold wallets, which it attributes to a compromised transaction and signing flow around its Safe multisig and links to the Lazarus Group.⁴ We report that as Bybit's own account of its own incident. We did not locate a Safe authored post mortem, a standalone FBI attribution document, or an independent forensics report confirming it, and a company's characterisation of its own breach is not the same as an independently established fact. The structural point holds regardless of attribution: if signers approve calldata that differs from what their screen shows them, the contract enforces the threshold correctly on a malicious transaction.

What the threshold number is really trading

Move m down and fewer keys have to be compromised. Move m up and the treasury freezes the week two signers are travelling with no signing device. Move n up and you buy independence at the cost of coordination time and a larger surface of people who can be targeted. There is no setting that is good in general, only a setting matched to what the wallet can do.

So we scale the threshold to blast radius rather than to a house style. Mint authority and upgrade keys sit behind a higher threshold and broader independence than routine parameter changes, and every capability is written into a matrix naming which multisig holds it and at what threshold. When that matrix does not exist, teams discover their real risk surface during an incident, which is the most expensive moment to learn it.

Multisig and timelock do different jobs

A multisig decides who is allowed to act. A timelock decides how quickly an approved action takes effect. They are frequently discussed as alternatives and they are not substitutes for one another in either direction. A multisig with no delay converts a signer compromise straight into an executed transaction with no window for anyone to notice. A delay guarding a single signer just postpones a single point of failure.

For anything with a large blast radius we specify both: the multisig approves, the timelock queues the operation publicly, and execution waits out the delay. Emergency powers get a separate path with a higher threshold and the shortest delay the team can defend in writing, because that fast lane is where these controls usually get quietly undone.

Six questions before signing off on a multisig

Who are the n, by name and employer. What device holds each key, and what is the backup. How many distinct organisations do those n keys represent. What happens if two signers are unreachable for a week. What can this multisig do without a governance vote, and what is the blast radius of each of those powers. And when was every delegated signing permission last reviewed and revoked.

That final question is Ronin, and it is the one nobody has an answer to. Permissions get granted during an operational crunch, the crunch ends, and the permission stays. Put a recurring calendar date on it and the whole class of failure goes away, which is an unusually cheap fix for a category with this much money in it.