Multisig Best Practices: The Institutional Signer Policy

By the Guardian team Updated November 2026 6 min read

Quick answer. Treat signers as the perimeter: split powers across Safes and size thresholds to each. Give signers dedicated keys and devices, verify calldata before signing, timelock upgrades, vet modules and guards, and alert on owner and threshold changes.

Watch: Multisig Best Practices: The Institutional Signer Policy 1:42

Video transcript

Three of the largest multisig losses did not break the multisig. Enough signers approved transactions they did not understand.

Bybit lost about 1.5 billion dollars to a routine looking transfer that was a wallet upgrade. WazirX reported over 230 million. Drift's pre-signed approvals ran with no timelock.

A threshold counts signatures, but cannot check what they approve. So treat signers as the perimeter.

The Security Alliance, or SEAL, says split powers. Upgrades, parameters, pause and treasury each get their own Safe, with thresholds sized to the blast radius.

SEAL's default minimum delay is three days. Yet Guardian's census found five of 25 large Ethereum protocols that can upgrade by multisig with no delay.

Give each signer a dedicated key per Safe, a hardware wallet and a dedicated signing device. High-value Safes add an outside signer.

Verify every signature, because the screen may not match the transaction. Simulate, recompute the hashes, match the full hash on the device and decode the calldata.

Then alert on every owner, threshold, module and guard change, and on the implementation address. Bybit's signers approved an implementation upgrade.

Guardian's Managed Security maps every path to your funds. Its security operations team reviews every multisig transaction before it is signed.

Read the full guide for the checklist and drills, or talk to Guardian about a signer policy for your Safes.

Three of the largest multisig losses did not break the multisig. At Bybit, WazirX and Drift, enough signers approved transactions they did not understand.

A threshold counts signatures. It cannot check what they approve.

This guide turns the Security Alliance (SEAL) multisig framework and Safe's docs into a signer policy.

Three Incidents, One Pattern

Incident	Setup	What signers approved	Reported loss
Bybit, Feb 21, 2025	Safe multisig cold wallet	A routine-looking transfer that was a wallet implementation upgrade	About $1.5B (FBI)
WazirX, Jul 18, 2024	Safe, 6 signers: 5 WazirX, 1 Liminal	A transaction WazirX says differed from Liminal's display	Over $230M (WazirX)
Drift, Apr 1, 2026	Squads, 2 of 5, zero timelock	Pre-signed durable nonce transactions handing over admin	About $285M (Chainalysis)

At Bybit, Sygnia found malicious JavaScript served from Safe{Wallet}'s AWS S3 bucket, aimed at Bybit's cold wallet.

WazirX said its signers used Ledger hardware wallets and a destination whitelist. Liminal said a Grant Thornton review of its web application found no evidence of compromise.

At Drift, two of five council signers had pre-signed transactions. With no timelock, they executed at once. See our Drift write-up.

Hong Kong's SFC described the same pattern in August 2025: altered interfaces, weak independent checks, and signers who "blindly approved forged transactions".

Thresholds, Timelocks and Roles

Start with SEAL's rule: "Do not put all admin privileges in one multisig." Give upgrades, parameters, pause and treasury their own Safe.

Function	SEAL threshold	SEAL timelock
Protocol upgrades	High, e.g. 7 of 9 or more	7 to 14+ days
Operational parameters	Moderate, e.g. 3 of 5	48 to 72 hours
Emergency pause	Lower, e.g. 2 of 4	None
Treasury	High, e.g. 4 of 7	Varies

SEAL's default minimum delay is three days. It adds: "A timelock without monitoring provides no protection."

Its baseline for every Safe:

At least 3 signers and a 50% threshold.
7 or more signers once a Safe holds $1M or more.
No N-of-N: one lost key would lock the funds for good.
At least one required signer from outside the organization on high-value Safes.

Emergency signers should only stop things. SEAL: "An emergency path should never be able to upgrade contracts or move funds."

In our Safe multisig statistics, upgrade Safes need a median of 4 signatures, and six can upgrade with no delay.

Our admin key census found five of 25 large Ethereum protocols that can upgrade by multisig with no delay.

Signers and Their Devices

Independence is what makes a threshold real. Count people and devices, not slots.

A dedicated address for each multisig, never one key across Safes.
Keys spread across hardware wallet makers, locations and people.
A hardware wallet for every signer, as SEAL requires.
A dedicated signing device, never a primary work laptop.
Signer identities kept need-to-know, as Drift plans after its exploit.

SEAL warns that a primary work laptop "significantly increases the risk of malware interference." The SFC expects approval devices to be dedicated and isolated from general purpose workstations.

Shared and nested signers lower the real bar. Our statistics found 239 distinct signers in 270 slots, and nine Safes with another Safe as a signer.

For where keys live and how they are backed up, see private key management.

Verify Before Every Signature

At Bybit, and by WazirX's account at WazirX, the screen did not match the transaction. So the policy cannot trust the screen.

SEAL's Safe verification guide sets the routine:

Record the Safe address, network and nonce.
Simulate, and check the expected events and transfers.
Recompute the hashes independently, with the safe_hashes.sh script or OpenZeppelin Safe Utils.
Match the entire message hash on the hardware wallet, not just its ends.
Decode the calldata: function, target and parameters.
Stop on any DELEGATECALL unless the target is a known, audited module.

SEAL: "Hash verification confirms you are signing the intended transaction, but it does not tell you what the transaction does."

It warns that simulations can be spoofed and calls can hide in MultiSend batches. Three more rules:

No pre-signed or durable nonce approvals for admin actions.
Addresses from a verified address book, never explorer history or chat.
A non-signer executes the fully signed transaction.

For the interface itself, see signing interface security.

Modules, Guards and Monitoring

A module can execute transactions without owner signatures. Safe's docs warn that "a malicious module can take over a Safe."

A guard checks every transaction and can block it. Safe adds that "a broken Guard can cause a denial of service for a Safe."

SEAL says to install neither "without explicit governance approval and security review". In our sample, one of 39 Safes had a module and one had a guard.

What to alert on

Alert on every configuration event, and more:

AddedOwner, RemovedOwner and ChangedThreshold.
EnabledModule, DisabledModule, ChangedGuard and ChangedFallbackHandler.
The singleton (implementation) address in storage slot 0: Bybit's signers approved an implementation upgrade.
Every proposed transaction, new signature and queued timelock operation.
Any signer address activity outside multisig operations.

SEAL asks for redundant alert channels that flag changes to their own configuration. For timelock queues, at least one channel should be run by an outside party.

Rotation and Compromise Drills

Rotation and offboarding

Add the new signer before removing the old, while the old key is reachable.
Verify the new address with a signed message, then sign a test transaction.
Keep 3 or more signers and a threshold of at least 50%.

SEAL says no signer change should lower the signer count or threshold "unless clear justification is given and documented".

Its example runbook offboards a signer within 48 to 72 hours for emergency Safes, 7 days for critical ones and 14 days otherwise.

When a signer is compromised

SEAL's first 30 minutes: halt all non-emergency transactions, alert the team on every channel and find which keys are exposed.

Then quarantine suspect devices, set up a fresh wallet and rotate the signer out.

If a chat account is taken over, treat recent messages as suspect and switch to backup channels.

Drills

SEAL's cadence: communication tests quarterly, paging tests twice a year, and a full emergency simulation with all signers yearly. Track the time to reach threshold.

Multisig Best Practices Checklist

One Safe per function: upgrades, parameters, pause, treasury.
Thresholds sized to blast radius; 3 or more signers; no N-of-N.
Upgrades behind a timelock of days, with the queue monitored.
Pause signers who can pause and nothing else.
A dedicated key per Safe on a hardware wallet, and a dedicated signing device.
An external signer on high-value Safes.
Hashes recomputed and calldata decoded before every signature.
No pre-signed, durable nonce or unexplained DELEGATECALL approvals.
Modules and guards only after review, with a recovery path.
Alerts on owner, threshold, module, guard and implementation changes.
A rotation runbook, offboarding deadlines and a yearly drill.

How Guardian Helps

Guardian's Managed Security maps every path to your funds: the contracts, the roles that can move them, and the keys, signers and multisigs behind each one.

Its security operations team reviews every multisig transaction before it is signed, and every deployment and configuration change as it lands.

Its multisig management covers signer changes, device hygiene, simulation before approval and tested recovery.

An OpSec audit tests what a signer actually sees before approving.

Frequently Asked Questions

What is a good multisig threshold?

SEAL suggests at least 3 signers and a 50% threshold, 7 or more signers for Safes holding $1M or more, and around 7 of 9 for upgrades. Among 39 admin Safes we read, 4-of-7 was most common.

Does a hardware wallet stop attacks like Bybit?

Not on its own: WazirX's signers used Ledger hardware wallets. Signers still need to recompute the hash, match it on the device and decode the calldata before approving.

Should a multisig use a timelock?

Yes, for anything beyond pausing. SEAL's default minimum is three days, and 7 to 14 days or more for upgrades. Drift's zero timelock let two pre-signed approvals execute at once.

Are Safe modules and guards safe to use?

Only after review. A module can execute transactions without owner signatures, and a broken guard can block every transaction. SEAL says to add neither without governance approval and security review.

Sources

Put a signer policy behind your Safes

Guardian reviews every multisig transaction before it is signed, and every configuration change as it lands.

Talk to Guardian Explore Managed Security