A crypto multisig threshold requires a minimum number of authorized signers to approve an action through its ordinary signing path. Its protection depends on independent custody and transaction review, plus any alternate authority. In a simple 3-of-5 model, two unavailable signers leave a working quorum, but three addresses derived from one seed let one compromised secret satisfy the threshold. Check the custody roots, modules and recovery paths behind the displayed ratio.
What a threshold actually counts
In an m-of-n arrangement, n is the number of authorized signers and m is the number needed for the relevant action. Those signers are identities recognized by the wallet's verification rules. The number does not establish how many people, devices or organizations independently control them.
Safe provides a concrete smart-contract implementation: its account stores owners and a threshold, and its ordinary transaction path checks the required owner signatures. Owners can change the threshold through the account's authorization rules. These are Safe-specific mechanics; verify another wallet's rules separately. Safe owner and threshold concepts.
Two questions must stay separate. How much signing authority must an attacker obtain? How much signing capacity can disappear before legitimate users cannot act? Raising the threshold can change those answers in opposite directions.
| Hypothetical configuration | Compromised signers needed to meet the threshold | Unavailable signers tolerated while a quorum remains |
|---|---|---|
| 2-of-3 | 2 | 1 |
| 3-of-5 | 3 | 2 |
| 4-of-5 | 4 | 1 |
This table assumes distinct, independently controlled keys, honest remaining signers who refuse unauthorized transactions, and no other execution route. It isolates threshold arithmetic rather than recommending one setup. A willing quorum also needs working transaction submission and execution; enough signatures alone do not prove availability.
Enumerate the failure before choosing the ratio
Consider a hypothetical wallet with five signer addresses: A, B, C, D and E. Its threshold is three. For this example, all five are ordinary key-controlled accounts. Ignore contract defects, modules, guard restrictions and network failures until the later sections.
First, model theft. If compromised signers can approve an attacker-selected transaction and honest signers refuse, any three compromised keys can meet the threshold. The ten smallest sufficient combinations are ABC, ABD, ABE, ACD, ACE, ADE, BCD, BCE, BDE and CDE. There are five ways to choose the first omitted signer and four for the second, divided by two because omission order does not matter: 5 × 4 ÷ 2 = 10.
Next, run a separate availability experiment. Losing A and B leaves C, D and E: three working signers, so the normal quorum remains possible. Losing A, B and C leaves two, so that path cannot proceed. The smallest blocking sets are the same ten triples in this particular 3-of-5 model.
That symmetry is specific to this ratio. In 4-of-5, four compromised signers can authorize an attacker transaction, while just two unavailable signers leave only three and block normal signing. Theft resistance and recovery resilience are different design requirements.
The combination count is not a probability. It assigns no frequency to device theft, seed exposure, coercion, mistakes or outages. Ten possible failure sets do not mean a 10% chance of loss, and the model gives no basis for estimating one.
Replace addresses with custody roots
Now change one assumption. A and B are different addresses derived from the same seed. Call that common secret S. C, D and E retain separate custody roots. A compromise of S yields two signers at once; combine it with C and the attacker has A, B and C.
The wallet still displays 3-of-5. The smallest number of compromised custody roots needed in this construction has fallen from three to two.
| Custody arrangement in the hypothetical wallet | Minimal sufficient sets of compromised roots | Fewest root compromises needed |
|---|---|---|
| A, B, C, D and E have separate roots | The ten three-signer combinations above | 3 |
| S controls A and B; C, D and E are separate | S+C, S+D, S+E, or C+D+E | 2 |
| S controls A, B and C; D and E are separate | S alone | 1 |
These sets are minimal: removing any root from a listed set makes it insufficient. Minimal sets can have different sizes; C+D+E needs three roots, while S+C needs two. They can also describe permanent-loss scenarios if loss of a root makes all its affected signers unavailable. In the middle row, loss of S alone leaves C, D and E available; losing S and C blocks the ordinary path.
Security Alliance explicitly notes that addresses sharing a seed remain exposed to the same seed compromise. Its guidance also treats devices, physical locations, signer people and client software as relevant distribution decisions. Security Alliance multisig practices.
A custody map should therefore include more than seed generation. Separate keys might share one cloud backup administrator, one unlocked workstation, one physical storage site or one service able to recover them. Each relationship needs its own scenario. A shared email account is not automatically proof that every hardware key can be extracted; document what that account can actually reset or unlock.
Different people can also approve the same misleading request without any key being stolen. If all signers trust one transaction preparer or read one compromised interface, cryptographic separation does not establish independent judgment. Agree on the intended recipient, action, amounts and configuration changes, then verify the actual request before signing. Security Alliance's methodology calls for checking raw transaction details and rehearsing operations; the specific verification tools depend on the wallet and action. Multisig verification guidance.
Inspect every route that can act for the wallet
The threshold describes one authorization path. Safe documents a separate module transaction path that can bypass ordinary owner-signature verification. A 3-of-5 owner policy can therefore coexist with another route that uses different authority. Safe permits a module to be any Ethereum address; if an enabled address is key-controlled, map its custody root directly. Safe module transaction mechanics.
For each enabled module, record its address, whether it contains contract code, its permissions and its controller. For a contract module, identify its implementation and authorization rules. Ask whether it can move assets, change owners, initiate recovery or authorize other calls. If its logic is upgradeable, include the authority that can change it in the review. Safe warns that a malicious module can take over an account; a friendly module name is not evidence of restricted permissions. Safe module security considerations.
A guard creates another dependency. Safe guards can check transactions before and after execution, and a broken guard can prevent execution. Review the actual account version and each execution route before assuming that a restriction covers them all. Safe guard documentation.
Owner accounts can themselves be smart contracts in Safe. If one owner is another multisig, expand its authorization tree: who controls that owner, and do those controllers overlap with the other owners? Counting the outer addresses alone conceals those relationships. Safe account architecture.
The same analysis matters when a multisig holds administrative authority over another contract. Record exactly what that role can change and whether additional actors have comparable powers. The upgradeable-contract administrator guide examines that next layer of authority. A strong wallet quorum cannot establish the safety of every contract it controls.
Treat recovery as an authorization policy
“We have a backup” leaves several questions unanswered. A backup of A restores A's authority; it does not create an additional independent signer. Three envelopes containing the same seed are three copies of one secret, with a shared compromise consequence.
For ordinary owner replacement, first establish whether the surviving owners can still satisfy the current rules. If three keys are permanently lost in the simple 3-of-5 example, the remaining two cannot approve their own threshold reduction through the normal path. A procedure that assumes otherwise fails exactly when needed.
Some smart accounts add recovery modules with separate rules. Safe's documentation includes social recovery as a module use case, but no generic multisig ratio specifies its guardians, delay or powers. Read the deployed recovery component and configuration. Recovery through Safe modules.
Record who can start recovery, which replacements are permitted, whether a delay applies, who can cancel, and what happens if the ordinary signers are unavailable. If monitoring must detect a malicious recovery during a delay, identify who receives it and which surviving authority can intervene. A countdown is useful only with a viable response path.
Rehearse recovery in a supported test environment before depending on it. The backup and restore drill develops the related operating principle: successful file retrieval is one milestone; restored authority and current state require separate checks. Wallet recovery needs its own acceptance criteria.
A worksheet for the next configuration review
Use a protected record without seed phrases, private keys or recovery codes. Public owner addresses can still reveal sensitive organizational relationships when annotated with custody details.
| Review field | Evidence to record | Failure to examine |
|---|---|---|
| Account identity | Network, full address, implementation and observation time | Reviewing a similar address or another chain |
| Ordinary approval rule | Current owners and threshold from account state | A stale setup document |
| Custody roots | Person, device, seed, backup and recovery dependencies for each signer | One event affects a quorum |
| Transaction review | How each signer checks the intended action against the actual request | All signers approve one misleading presentation |
| Alternate authority | Enabled modules, guards, recovery actors and their exact powers | Another route bypasses the assumed boundary or blocks execution |
| Continuity | Surviving signers, contact method and tested recovery route for each scenario | A viable policy cannot be operated |
Choose one scenario from the worksheet and enumerate its affected signers. Start with a lost device, an exposed backup or an unavailable custodian. Count the remaining reachable signers and the authority available to an attacker separately. Then repeat for a shared dependency rather than assuming each address fails alone.
An account boundary can also sit outside the wallet. Exchange subaccounts have their own parent-account and permission relationships, as explained in the subaccount isolation worksheet. Keep those relationships in the operational map when funds move between custody systems.
After an approved owner or module change, verify the resulting onchain configuration under the chain's settlement policy. A collected signature is not an executed change, and inclusion is a different observation from finality. Use the confirmations and finality guide to define the required evidence.
Finish the review with a statement that names the boundary: which independent custody roots are required, which failures leave a working quorum, and which alternate actors can act. If that statement is weaker than the displayed threshold suggests, fix the underlying dependencies before treating the ratio as a security conclusion.