Secure Multisig Best Practices
Guidance for designing, operating, and auditing high-assurance multisigs. Use this as your single source for baseline rules, setup guidance, and daily operations.
Who This Is For
Advanced technical users, developers, Decentralized Autonomous Organizations (DAOs), and organizations responsible for managing protocol treasuries, smart contract ownership, or significant personal/collective assets.
Primary Goal
The primary objective is to eliminate single points of failure and establish robust, distributed control over high-value assets and critical smart contract functions.
Design Principles
Build in Slowness by Design
Actions that affect user funds or protocol security should be made deliberately slow through timelocks and review windows. Speed is a risk. Forced urgency is one of the primary tools attackers use in social engineering and key compromise scenarios. Legitimate operations can accommodate delays, and the slower the path, the more opportunities exist for detection and intervention.
Constrain Emergency Powers
If emergency bypass mechanisms exist (such as bypassing a timelock), they should be highly constrained to the minimum necessary action. For example, an emergency path should only be able to pause the protocol, not upgrade contracts or move funds. This way, even if emergency signatures are obtained maliciously, the damage is limited to a temporary pause rather than a full protocol takeover. The more powerful an action, the more restrictions and delays it should require.
Separate Responsibilities Across Multisigs
Protocols should not consolidate all admin privileges into a single multisig. Different functional areas (protocol upgrades, operational parameter changes, emergency response, treasury management) should be controlled by separate multisigs with potentially different signer sets and thresholds. This limits the blast radius of any single compromise and allows security measures to be tailored to each function's risk profile. See Separating Multisigs by Function for detailed guidance.
Core Concept: M-of-N Scheme
A multisignature (multisig) wallet is a smart contract that requires a predefined minimum number of approvals M from a
total set of authorized signers N to execute a transaction. This is known as an M-of-N scheme (e.g., 2-of-3,
3-of-5).
By distributing signing authority, a multisig ensures that the compromise of a single private key is insufficient to authorize the movement of funds or execute a privileged action.
General Rules
Thresholds & Configuration
- Minimum of 3 signers
- 50% signing threshold
- 7+ signers for multisigs holding 1M+ in assets (USD equivalent)
- Please see Classification Matrix in Planning & Classification for more information on threshold selection.
- All signers must use hardware wallets
- Multisigs managing assets on behalf of a DAO should set unlimited allowance with primary DAO agent
- All signing wallets should be monitored for any activity that is not directly related to multi-sig operations.
- No multisigs should use modules/guards except those mentioned in Setup & Configuration → Modules & Guards unless clear justification and security review is provided
- Threshold exceptions can be made for multisigs that are used in frequent operations but are highly constrained by smart contracts. For example, rate setting operations with tight bounds and a backup recovery mechanism to replace the multisig.
Threshold Selection
Avoid N-of-N schemes, as the loss of a single key would result in a permanent loss of access to all funds.
Dedicated Keys Per Multisig
Signers should use a dedicated address for each multisig they participate in:
- Wallet clarity: When a signer uses the same key across multiple multisigs, signing requests become ambiguous. A dedicated key per multisig makes it immediately obvious which multisig a transaction belongs to, reducing the chance of signing the wrong transaction.
- Blast radius containment: If an attacker compromises a signer's key that is shared across multiple multisigs, the attacker gains a valid signature on every multisig that key belongs to. With dedicated keys, compromising one key only affects one multisig.
In practice, use a different address index on your hardware wallet for each multisig — same derivation path, just switch between addresses and label each clearly in your wallet interface.
Strategic Signer Distribution
The security of a multisig depends entirely on the operational security (OpSec) of its individual signer keys. Storing multiple signer keys on the same device or in the same physical location negates the security benefits. Effective distribution strategies include:
- Using different hardware wallet models and manufacturers.
- Maintaining geographical separation for devices holding signer keys.
- Assigning signer keys to different trusted individuals within an organization.
- Using diverse client software to interact with the multisig to mitigate single-point-of-failure risks from a software vulnerability.
Signer Composition Requirements
- Role Diversity: Signers should be diverse individuals to reduce risk of multiple compromised accounts - a mix of executives, developers, and operational roles is recommended
- Technical Expertise: Include a high number of competent, well-vetted technical signers that will understand full transaction details and effects in your signing quorum
- External Parties: Multi-sigs managing high value wallets and contracts should have at least 1 additional required signer that is external to the organization (such as a security partner or trusted advisor)
Communication & Documentation
- In the event of loss of access to keys or potential compromise of keys or communication channels, the signer must immediately notify the other multisig participants and email your security contact - Incident Reporting
- Signers should use dedicated communication channels for multisig operations and maintain backup ways of reaching other signers
- All multisigs should be documented in the protocol documenting its purpose, general operating rules, multisig wallet address, and list of signer addresses
- Signers should verify their addresses by signing a message stating their affiliation and the multisig they intend to join (entity affiliation is ok)
Out-of-Band Verification for Admin Changes
Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message) to prevent social engineering attacks.
Signer rotation
- Signers can be rotated, but detailed documentation should be maintained
- Any changes to signer composition should be documented in the protocol documentation
- Any signer change should not reduce the number of signers or decrease the threshold unless clear justification is given and documented
Updating signer addresses
If the original key is accessible:
- The signer proves ownership of a new address by signing a message with their existing address.
- The signer must follow the steps in Signer Verification process
If the original key is lost:
- The signer must verify their identity to the other signers through alternative methods such as:
- Authentication via a verified social media account.
- A video call with other signers for confirmation.
- Other sufficient methods.
Training & Drills
- All signers should complete training as outlined in the Implementation Checklist
- For multisigs that perform emergency operations like pausing, teams should have processes to regularly conduct drills to ensure operational readiness and signer availability
Setup Best Practices
See General Rules above for thresholds and signer distribution guidance.
-
Practice on Testnet: Before deploying on mainnet, thoroughly practice wallet creation, transaction signing, and owner management on a test network.
-
Timelocks: Enforce a mandatory delay between the approval of a transaction and its execution. This provides a critical window for the community or team to detect and react to malicious proposals.
-
Veto Quorum: Establish a smaller veto group separate from the confirmation quorum to review and confirm transaction legitimacy. Organizations can establish veto quorums to bypass time-locks in case of emergency. The standard quorum plus two additional signers should be required to bypass.
-
Role-Based Access Control (RBAC): Implement modules that grant specific, limited permissions to certain addresses (e.g., a "pauser" or "executor" role) without making them full owners, adhering to the principle of least privilege.
-
Disaster Recovery Plan: Establish a clear, documented process for what to do when a signer is compromised, the multi-signature UI is down, or other emergencies arise. These should be done at regular intervals.
Operational Best Practices
-
Signer Key Revocation and Replacement: A feature of multisigs is the ability to add, remove, or replace signer keys. If a signer's key is compromised or lost, it can be revoked and replaced with a new, secure key through a transaction approved by the remaining owners, preserving the integrity of the wallet's assets without needing to migrate funds.
-
Secure Signing Environment: For maximum security, all signing activities should be performed on a dedicated, air-gapped, or hardened device running a secure OS. Using a primary work laptop significantly increases the risk of malware interference.
-
Independent Transaction Verification: Before signing, always verify the raw transaction data (target address, function call, parameters) to ensure it matches the intended operation.
-
Out-of-Band Verification for Admin Changes: Any critical administrative action, such as adding or replacing a signer, must be verified through multiple, independent communication channels (e.g., a video call and a signed message) to prevent social engineering attacks.
-
Active Monitoring: Implement monitoring and alerting systems to be immediately notified of any on-chain activity related to the multisig, including proposed transactions, new signatures, and owner changes (e.g., using tools like Safe Watcher ).
-
Documented Procedures: Maintain clear, secure, and accessible documentation for all multisig procedures, including transaction creation, signing, and emergency recovery plans.
-
General Signing Guidelines: Use hardware wallets, dedicated signing profiles, and re-verify before execution. Require a "how to check" guide and communicate status after signing (e.g., "checked, signed, X more required"). Last signer executes when applicable.
Address Book Discipline
The single most common cause of misdirected funds is using an incorrect address. Protocols must enforce strict address hygiene:
- Never copy addresses from block explorer transaction history, Etherscan address pages, or chat/email messages. These are all vectors for address poisoning attacks where attackers create transactions from addresses that resemble legitimate ones.
- Always copy addresses from a verified, maintained address book or directly from the multisig/custody platform interface.
- First-time recipients: Before sending any meaningful value to a new address, perform a bidirectional test transaction. Send a small amount, have the recipient confirm receipt and send a small amount back. This proves both parties control the addresses they claim.
- High-value transfers: For transfers above a protocol-defined threshold, verify the recipient address character-by-character on a video call with all approvers.
- Address changes: If a counterparty requests a change to a previously verified address, treat it as a full re-verification event. Do not simply update the address book based on a message.
Address Poisoning and Permissionless Safe Additions
Anyone can create a Safe and add your address as an owner without your consent. This Safe will appear in your Safe app dashboard alongside your legitimate Safes. Attackers exploit this by creating Safes with addresses that share the same first 4 and last 4 hex characters as your real Safes, making them visually similar in truncated address displays.
If you are not careful about which Safe you select in the UI, you may interact with or send funds to the attacker's Safe.
Mitigations:
- Always verify the full Safe address before interacting, not just the first and last few characters
- Bookmark your legitimate Safe addresses and navigate to them directly rather than selecting from a dashboard list
- If a new Safe appears in your dashboard that you did not create or expect, do not interact with it
- Use your verified address book to confirm any Safe address before transacting
Contract-Level Security
-
Invariant Enforcement: Design contracts to enforce invariants and expected state changes such as token balance changes, ownership and administration, and proxy implementation addresses. Ensure contracts automatically revert transactions if any invariant is violated.
-
Address Whitelisting: Approved smart contract and wallet addresses must be added to a whitelist that is enforced at the contract-level. Interactions with all other addresses should be denied and revert the transaction. Updating the whitelist should require an extra signer in addition to the standard transaction approval quorum.
For detailed configuration guidance, see Setup & Configuration → Contract-Level Controls.
Acknowledgements
Some ideas were borrowed from the EF's multisig SOP notes and Manifold Finance multisig best practices.