Multisig Treasury Operations Guide for Protocols and Companies: Thresholds, Signer Hygiene and Transaction Verification in Practice

A multisig only protects a treasury if the people, devices and interfaces behind each signature are as carefully designed as the threshold itself. The largest multisig losses of recent years did not break the cryptography: attackers changed what signers saw, collected genuine signatures and moved the funds legitimately. This guide covers how to classify and size multisigs, separate them by function, choose and protect signers, verify every transaction independently of the signing interface, and run the day-to-day and emergency processes that keep a treasury safe. It is written for treasury, security and engineering leads at protocols, DAOs, exchanges and companies that hold digital assets in Safe, Squads or custodial MPC accounts. For the wider web3 threat model, see the Web3 and Crypto Security Guide.

Key takeaways

• Classify before you configure. Size each multisig by financial exposure, protocol impact and response urgency, then set threshold, signer count and timelock from that classification rather than from habit.
• One multisig should never hold every power. Separate upgrades, parameters, emergency pause and treasury into different multisigs with different signers, so one compromised quorum cannot upgrade, pause and drain in a single move.
• The signing interface is untrusted. Each signer verifies the safeTxHash, decoded calldata and operation type on an independent tool and on the hardware wallet screen, because a compromised front-end can show one transaction and request another.
• Signer devices and accounts are part of the quorum. Dedicated signing devices, a dedicated key per multisig, verified Signal safety numbers and phishing-resistant MFA matter as much as the M-of-N number.
• Slowness is a control. Timelocks, test transactions, address book discipline and a monitored review window turn a single bad signature into an event that can be caught before funds leave.

Classifying multisigs and custody accounts

Start with an access control inventory of every privileged role before deciding how many multisigs you need. The Security Alliance (SEAL) Multisig for Protocols framework asks for each role: the role name (for example UPGRADER_ROLE, owner, pauser), which address holds it, which contracts it controls, what it can do, what constrains it (timelocks, parameter bounds, governance) and its blast radius if compromised. Without that inventory you cannot tell whether a "treasury" Safe can also upgrade a contract.

Then classify each multisig on two axes: impact if it is compromised or unavailable, and how quickly it must act. SEAL publishes indicative bands for protocol multisigs and, separately, percentage bands for custodial treasury accounts.

The operational axis matters as much. SEAL's treasury classification distinguishes a cold vault (fewer than 5 transactions a month, 48 to 72 hour response window), warm storage (5 to 50 a month, 4 to 24 hours), active operations (more than 50 a month, under 4 hours) and time-critical accounts such as collateral management (unpredictable, under 2 hours). A critical cold vault can afford a high threshold and a long delay; a time-critical collateral account cannot, so it needs tight on-chain constraints and spending caps instead. Single-approver configurations belong only on very small operational accounts with strict limits and daily reconciliation.

Separating multisigs by function and sizing thresholds

Consolidating all admin rights into one "god-mode" Safe is the most common design defect. SEAL recommends separate multisigs per function, mapped to separate on-chain roles (for example with OpenZeppelin AccessControl), and that no multisig holds both pause and upgrade rights unless the upgrade path is behind a timelock.

General sizing rules from SEAL's secure multisig best practices: at least 3 signers, a threshold of at least 50%, 7 or more signers for multisigs holding $1M or more, every signer on a hardware wallet, and never N-of-N, because losing one key would lock the funds permanently. Signer changes should not reduce the signer count or threshold without documented justification.

Choosing between multisig, MPC and a custodian

• On-chain multisig (Safe, Squads): transparent, the policy is enforced by the contract, signer changes are visible on-chain. The trade-off is that every signer needs good verification habits and the front-end is a target.
• MPC with a policy engine: one address on-chain, key shares distributed, and rules evaluated before signing (allow, block or escalate). SEAL suggests considering MPC for accounts holding more than 10% of assets or over $10M, with at least 3 distinct approvers across Treasury, Security and Finance, and a requester who can never approve their own transfer. See the MPC Wallet and Threshold Signing Security Guide.
• Qualified custodian: moves key operations to a third party; your controls become approver MFA, whitelists, device security and the custodian's own policy rules. Due diligence replaces key ceremonies, but you still own the approval workflow.
• Small organisations: a 3 of 5 Safe with hardware wallets, one external signer and a self-hosted or bookmarked interface is achievable with a handful of people. Large organisations should add separate multisigs per function, an independent monitor and formal key ceremonies (see the Cryptographic Key Ceremony Template).

Choosing and protecting signers

The security of a multisig depends on the operational security of each signer key. Three signers who share an office, a laptop image and a chat account are closer to one signer than to three.

• Diversity: mix executives, developers and operations staff; use different hardware wallet models and manufacturers; keep devices in different locations; use more than one client to interact with the multisig.
• External signer: for high-value wallets and contracts, SEAL recommends at least one required signer from outside the organisation, such as a security partner or trusted adviser. It adds a party an internal phishing campaign does not reach.
• Dedicated key per multisig: each signer uses a fresh hardware wallet address (a different address index) for each multisig, labelled clearly, so a signing request can only belong to one multisig and a compromised key cannot be reused across them. Addresses on the same seed still share seed risk.
• Proof of ownership: a new signer signs a message such as "[handle] is joining [Multisig] with address 0x..." with the signing key, and the admin verifies and stores it with the registration record before the address is added.
• Dedicated signing device: a clean laptop or tablet used only for signing and verification tools, with default-deny network rules, full disk encryption, current updates and no email, chat or general browsing. At minimum use a separate browser profile for signing.
• Accounts and communications: FIDO2 security keys rather than SMS or app codes, phone numbers removed from recovery, a private "cold" recovery email, and Signal with safety numbers verified over a second channel. A primary channel plus a backup on a different platform, and 24/7 paging for emergency multisigs, tested quarterly.

Signer keys, proposer addresses, custody API keys and the CI identity that deploys the front-end are non-human identities in their own right. Give each an owner, record it in the inventory and remove it on every role change. See the Crypto Wallet Security Guide for hardware wallet and seed phrase handling.

Transaction verification: what every signer checks

Verification exists because the UI can lie. In Safe, three values matter: the domain hash (the EIP-712 domain separator for that Safe and chain), the message hash (the hash of the transaction parameters) and the safeTxHash that combines them. A signer who confirms that the hash on the hardware wallet matches a hash computed independently, and that the decoded calldata does what was agreed, is protected even if the hosted interface is compromised.

1. Propose through a delegated proposer. A non-signing proposer address submits the transaction to the Safe Transaction Service first, so every signer, including the first, can verify it. Record Safe address, network and nonce.
2. Check the basics. Correct Safe (full address, navigated from a bookmark), correct chain, expected nonce, recipient matches the verified address book, token and amount correct.
3. Compute hashes independently. Use a separate tool such as the open-source safe_hashes.sh script or OpenZeppelin Safe Utils, with checksummed addresses. If the tool reads from the Safe API, also check the calldata it decodes; interactive mode removes the API dependency.
4. Read the operation type. Operation 0 is a CALL; operation 1 is DELEGATECALL, which runs the target's code with full control of the Safe's storage. A DELEGATECALL to anything other than a known, expected library (such as the official MultiSend) is a stop signal.
5. Simulate and reconcile. Simulate the transaction and confirm the events and balance changes match the intent. Simulations can be spoofed, so reconcile simulated effects against decoded calldata, not one or the other.
6. Confirm on the device. Compare the hash on the hardware wallet screen with the independent tool before approving. Never blind-sign a privileged transaction.
7. Sign, report, execute separately. Post "verified and signed, N more needed" in the signer channel. The final signer avoids the combined "sign and execute" action, which verification tools do not hash; a non-signer executes the fully signed transaction, and whoever executes re-verifies it as if signing.

Any unexpected error that prompts a re-sign is itself a reason to stop. In the Radiant Capital incident of October 2024, the company's post-mortem describes malware on three contributors' devices that showed legitimate data in the Safe interface while relaying a different transaction to the hardware wallets; after an error, signers were prompted to sign again, which is common enough that it raised no suspicion. Radiant's remediation included halting signing whenever a signer sees an error and decoding raw transaction data on an independent device.

Address book discipline and large transfers

Misdirected funds most often start with a wrong address. The rules are simple and must be enforced, not suggested:

• Source of addresses: copy only from a maintained, verified address book or from the custody platform itself, never from block explorer history, chat or email, which are the vectors for address poisoning.
• Full address checks: attackers can create Safes that list you as an owner without consent, with addresses matching the first and last four characters of your real Safe. Verify the full address and navigate to your Safe from a bookmark, not from the dashboard list.
• New recipients: run a bidirectional test (a small amount out, a small amount back) 24 to 48 hours before a large transfer. SEAL's enhanced treasury controls suggest test transactions of no more than $100 and verifying new addresses against three independent sources.
• Change requests: a request to change a counterparty's address is a full re-verification event over a separate channel, never an address book edit based on a message. This is the crypto equivalent of supplier bank detail fraud; see the Invoice Redirection and Supplier Bank Detail Fraud Guide.
• High-value ceremonies: above an internal threshold, two or three people verify the address character by character on a video call, check the EIP-55 checksum, and for transfers over $1M sign a record confirming they did so.

On-chain guardrails: timelocks, modules and guards

Contract-level controls limit what even a full quorum can do in a hurry.

SEAL advises installing no other modules or guards without governance approval and a security review, testing on a testnet first, and remembering that a misconfigured guard can lock funds permanently. For treasury tiers, it recommends at least three equally funded cold wallets managed by different multisigs, longer time-locks on seldom-used wallets, and alerts to the whole team on any activity there.

Day-to-day operations, rotation and offboarding

• Runbooks per operation: keep a short runbook for token transfers, signer rotation, threshold change and emergency pause, each with prerequisites, a signer verification checklist and the expected hash workflow.
• Signer rotation: a new address is proved with a message signed by the existing key; if the key is lost, identity is confirmed by video call and pre-arranged methods. After every change, verify owners and threshold on-chain and update the registration record.
• Offboarding deadlines: set them in policy. SEAL's examples are 48 to 72 hours for emergency-class multisigs, 7 days for critical-class and 14 days for others, plus leaving signer channels and deleting local multisig data.
• Self-hosted and backup interfaces: SEAL recommends self-hosting the multisig UI, IP restricted to signer machines, and practising with alternatives such as Eternal Safe or the Squads public client, two or three RPC providers and a backup explorer, before they are needed.
• Drills: for emergency multisigs, test paging twice a year and run a full simulation with all signers once a year.

Emergency procedures

Agree the steps for compromise before you need them. SEAL's multisig emergency procedures set a 30-minute window for the first actions on a suspected key compromise: stop non-emergency transactions, notify the team over every channel using a prepared template, assess which keys are exposed, escalate to the security lead and start a timeline. Recovery then isolates affected devices, sets up a fresh hardware wallet with a new seed and replaces the signer through the rotation runbook. If a signer's Telegram, Signal or Discord account is taken over, treat recent messages from it as suspect, cancel pending transactions it initiated and require extra verification until it is secured. For contract exploits, pausing and war rooms, use the Web3 Incident Response Playbook.

Detection and measurement

Monitor every multisig for proposed transactions, new signatures, owner and threshold changes, module and guard changes, DELEGATECALL operations and any activity on signer addresses unrelated to multisig work (open-source tools such as Safe Watcher do this). For timelocked multisigs, SEAL recommends an external monitor that simulates pending transactions and reports at least 48 business hours before the timelock lapses. Track:

• Verification coverage: share of signatures with a recorded independent hash check (target 100% for privileged multisigs).
• Function separation: number of multisigs holding more than one of upgrade, pause and treasury powers (target zero).
• Signer hygiene: share of signers on dedicated devices with hardware keys and a dedicated address; median days to remove a departed signer against the policy deadline.
• Hot exposure: hot wallet balance as a share of its ceiling, reviewed daily.
• Emergency readiness: time from page to threshold signatures in the last drill.
• Address changes: number of address book changes made without a recorded out-of-band verification (target zero).

Common failure patterns

• Trusting what the front-end shows. In the Bybit hack, malicious JavaScript placed in Safe{Wallet} front-end resources fired only for Bybit's cold wallet, so signers approved what looked like a routine transfer and more than 400,000 ETH and stETH (about $1.5 billion) left. The FBI attributed the theft to North Korea (TraderTraitor). Independent hash and calldata checks on the hardware wallet are the control.
• Treating a re-sign prompt as routine. Radiant's signers re-signed after an error, giving the attacker the third valid signature it needed on a 3 of 11 admin multisig.
• Too few, too similar keys. Low thresholds on very large signer sets, or signers who share devices and channels, mean a single phishing campaign reaches the quorum. Concentration in one key is worse still, as the BitMart hot wallet hack showed.
• God-mode multisig. One Safe that can upgrade, pause and move the treasury turns any compromise into a total one.
• Signers who never leave. Departed staff remain owners for months because nobody owns offboarding.
• Timelocks nobody watches. A delay without an alerting monitor only postpones the loss.

Framework mapping

Relevant ATT&CK techniques include T1195.002 Compromise Software Supply Chain (front-end and library tampering), T1204.002 Malicious File (lures run on developer or signer machines), T1528 Steal Application Access Token and T1657 Financial Theft.

Practitioner checklist

• Build and maintain an inventory of every privileged role, its holder, capabilities and blast radius.
• Classify each multisig and custody account by impact and urgency, and record the resulting threshold and timelock.
• Split upgrade, parameter, pause and treasury powers into separate multisigs with separate signers.
• Require at least 3 signers, a threshold of at least 50%, hardware wallets, a dedicated address per multisig and one external signer for high-value multisigs.
• Provide dedicated signing devices or at least a dedicated browser profile, FIDO2 keys and verified Signal channels with a backup platform.
• Mandate independent safeTxHash and calldata verification, an operation type check and no blind signing, with a delegated proposer and a non-signer executor.
• Copy addresses only from the verified address book, test new recipients both ways and re-verify every address change out of band.
• Put timelocks on upgrades and parameter changes, with a monitor that alerts on queued transactions.
• Set offboarding deadlines and rehearse signer rotation, backup interfaces and the 30-minute compromise steps.
• Report verification coverage, signer hygiene, hot exposure and drill times monthly.

Standards and references

• Security Alliance (SEAL): Multisig for Protocols framework
• Security Alliance (SEAL): Secure Multisig Best Practices
• Security Alliance (SEAL): Safe Multisig Step-by-Step Verification
• Security Alliance (SEAL): Treasury Operations framework
• Safe: Safe Guards documentation
• FBI IC3: North Korea Responsible for $1.5 Billion Bybit Hack
• Radiant Capital: Radiant Post-Mortem

Related NHI Mgmt Group resources: Web3 and Crypto Security Guide · MPC Wallet and Threshold Signing Security Guide · Web3 Developer Operational Security Guide · Crypto Exchange Identity and Key Security Guide · Cryptographic Key Ceremony Template