Multisig Thresholds: Who Can Move Funds, and Who Cannot

Two numbers and one rule

A multisig account on Ethereum is a contract account with a list of owners and a threshold: the number of confirmations required before a transaction executes. Safe describes its default as multi-signature logic “where a threshold of owners must confirm a transaction before execution,” and states that once the threshold of owners has confirmed, the transaction can be executed.

The rule has two sides, and both matter:

• Any m owners can move funds.
• Any m − 1 owners cannot.

Everything else follows from those two sentences. A 2-of-3 means two signatures move the money and one signature never does. It also means two lost signers end access, because the one remaining signer is one short of the quorum.

Owners need not be ordinary wallets: Safe allows an externally owned account, another smart contract account, or a passkey. Each contributes a signature the account’s code accepts, and the account — not a private key — holds the funds.

Why one key is one signature

An externally owned account is controlled by a private key. Safe’s documentation puts the consequence directly: “If you gain access to that private key, you gain complete control of the account,” which makes the key “a single point of failure between you and your funds being lost.” There is no second check to pass and no co-signer to convince.

A contract account changes that by making validation a matter of code. The account can require several signatures, accept different signature types, and treat a signature from another contract as valid through EIP-1271, which defines a standard way for a contract to report whether a signature is valid on its behalf. Safe’s signature documentation lists exactly these paths: ECDSA signatures, eth_sign signatures, EIP-1271 contract signatures, and hashes pre-validated on-chain.

Distribution is the security property, and it is only as good as the independence of the signers. Three keys held by one person on one device, backed up to one cloud account, are one signer wearing three labels. The useful dimensions are device, vendor, location, key type and person; a 2-of-3 built from a phone, a hardware wallet and a third party’s smart account is a different construction from three browser profiles.

A multisig does not make any individual key safe. Each signer still holds a key that can be phished, extracted or lost; the threshold only limits what one compromised key achieves. The habits in seed phrase handling and the limits in what a hardware wallet protects apply to every signer.

What the threshold buys and costs

The three common configurations differ in ways that can be stated as arithmetic. The table uses n − m as the loss margin: the number of signers who can become unavailable before the account can no longer execute anything.

Safe’s guidance points at the same trade-off. It advises a threshold higher than one, so no single account can execute, and lower than the total number of signers, so one lost signer does not lock the account. Its common setup for an individual is three signers — one software wallet and two hardware wallets — with a threshold of two, the second hardware wallet stored away in case one of the other two is lost. For a group, it describes one signer per person with a threshold of three.

The table cannot show the quality of the signers. A 4-of-7 built from seven keys in one password manager is weaker than a 2-of-3 spread across a phone, a hardware wallet and a safe. The threshold sets the shape of the failure; the custody sets the probability.

The recovery trap sits inside the threshold

The awkward property of a threshold is that the rule protecting the account also governs its repair. Adding an owner, removing one, replacing a lost signer or changing the threshold are all transactions the account must approve, and approval means meeting the current threshold. Safe’s owner management documentation describes the functions — owners can be added, removed and replaced, and the threshold can be modified — but the mechanism is the same multisig rule, not an exception to it.

So the recovery question is not “can I recover?” but “how many signers can I lose and still recover?” For a 2-of-3, the answer is one. Lose a phone and a hardware wallet in the same fire, and the third key is not a quorum; the funds remain visible and unmovable. A 3-of-5 gives two losses of margin, a 4-of-7 gives three, and each step up buys margin at the cost of more keys to secure and more signatures per transaction.

The quieter trap is replacement itself: it requires the remaining signers to be reachable and willing. A signer who has died or disappeared cannot approve their own removal, and the others can only act if they still meet the threshold. The recovery plan has to name who they are and how they would coordinate, not just how many there are.

Safe provides a route for the cases where the threshold is not enough: modules. A recovery module can be granted the ability to act under defined conditions, and Safe’s module documentation describes social recovery modules that “may allow you to recover a Safe if you lose access to owner accounts.” The cost is real: modules can execute transactions, and Safe warns that “a malicious module can take over a Safe.” A recovery module is a second key to the account, and it has to be chosen and audited as one.

Who cannot move funds

The negative side of the threshold is where most of the security lives, so it is worth stating precisely.

One signer cannot. Below the threshold, a signature is a proposal, not a payment. This is the difference between a multisig and a wallet with a backup phrase: a stolen phrase from a single-key wallet is a completed theft, while a stolen key from a 2-of-3 is a failed attempt.

A removed signer cannot. Removal is recorded in the account, and a signature from an address that is no longer an owner is rejected by the same code that accepted it before.

A guard cannot move funds, but it can stop them. Safe’s guard mechanism checks whether a transaction should execute. The documentation warns that guards are security-critical because “a malicious guard could prevent transactions from being executed and block access to funds.” A guard is a veto, not a signer, and a veto held by the wrong party is its own kind of custody risk.

The account itself cannot initiate. A contract account can receive funds and send them in response to a transaction, but it does not start one. Something outside it — an owner or an enabled module — has to propose the action.

That is the asterisk on the model. An enabled module can execute transactions without the threshold, which is what makes allowance modules, recurring payments and account-abstraction modules useful. The honest answer to “who can move funds?” is therefore: any m owners, or any enabled module acting within its rules.

Choosing the numbers

Three questions produce a defensible threshold.

How many independent custody arrangements can you maintain? Not how many keys you can generate. A signer whose backup you have never restored has unknown reliability; a third hardware wallet that has sat in a drawer since setup makes the real configuration closer to 2-of-2 with a hope.

What loss can you survive? Set n − m to the number of signers you could plausibly lose at once — one device and its backup in the same burglary, two colleagues leaving in the same quarter. A 2-of-3 survives one loss, and only if the other two are truly independent. A 3-of-5 survives two.

What is the cost of a delayed payment? Every additional required signature is a delay and a coordination step. A treasury that moves once a month can afford 4-of-7. A wallet that pays for hosting every week will route around friction, and a workaround is usually a weaker custodian.

Then test it. Replace one signer on a test account before you do it for real, and confirm the remaining signers can find each other and execute. The procedure, not the threshold, is what you will rely on when a signer is lost.

What the contract does not decide

A multisig is a statement about who must agree, not whether they agree correctly. If two of three signers approve a transfer to an address supplied by a compromised interface, the contract executes it as designed. The catches are around the signing step: whether the wallet can decode the request, and whether the signers compare the destination rather than the prompt.

It is not a substitute for understanding custody. A multisig held by a provider that controls all the signers is a custodial arrangement with extra steps, and the distance from a self-custodied account is the one described in custodial versus non-custodial wallets. The threshold is a tool; the custody question is who holds the keys it counts.