Introduction
When Humanity Protocol’s multisig was drained, it wasn’t because Gnosis Safe failed. It’s because the humans operating it did.
Gnosis Safe is the dominant programmable multisig wallet across Ethereum and EVM-compatible chains. DAOs, protocol treasuries, and team funds depend on it daily. But “multisig” is not a synonym for “secure.” The threshold number in your Safe UI is the floor of your security model, not the ceiling.
This guide covers what the Humanity Protocol hack reveals about multisig complacency, how Safe’s M-of-N threshold model actually works under adversarial conditions, and the concrete steps you can take right now: threshold selection, hardware key isolation, ProxyAdmin hygiene, owner rotation, and emerging tools like Safe Watch Agent. By the end, you’ll have a working security checklist you can apply to any Safe configuration.
What the Humanity Protocol Hack Reveals About Multisig Complacency
The Humanity Protocol incident is useful precisely because it’s not unusual. An attacker compromised enough signers, or exploited a misconfiguration, to push a malicious transaction through a setup that looked secure on paper. The Safe contract performed exactly as designed. The failure lived in the operational layer above it.
That distinction matters. A multisig threshold is only as strong as the operational security of each individual signer key. Compromise a majority of keys and the entire security model collapses, regardless of how many total owners appear on-chain.
The Ronin Bridge hack made this point at scale. An attacker gained control of five of nine validator keys, enough to meet the threshold and drain the bridge. The numeric configuration looked reasonable. The organizational reality was different: insufficient signer diversity meant those five keys were reachable through a single concentrated attack. According to OpenZeppelin’s security research, signer diversity and geographic separation are as important as the numeric threshold itself.
OpenZeppelin’s backdooring analysis of Gnosis Safe multisig wallets adds a second, less obvious warning. “A Gnosis Safe can be silently backdoored at deployment if the deployer inserts a malicious module or delegate call target before handing over ownership,” OpenZeppelin Security Research notes in their analysis at blog.openzeppelin.com. Teams that receive a Safe from a third-party deployer should verify its on-chain state immediately. Don’t trust the handoff.
These aren’t exotic attacks. They’re the predictable result of treating a multisig as a product you configure once rather than a process you maintain continuously.
How Gnosis Safe Actually Works: M-of-N Thresholds Explained
Gnosis Safe requires M signatures from N registered owner addresses before any transaction executes on-chain. Owners are standard Ethereum addresses: externally owned accounts (EOAs) controlled by hardware wallets, software wallets, or other smart contracts.
The on-chain implementation lives in the safe-contracts package. According to the package registry at app.unpkg.com, the actively maintained version as of mid-2026 is 1.3.0. CoinGecko’s Safe overview confirms it’s the market-leading programmable multisig across Ethereum and EVM-compatible chains, used by major DAOs and protocol treasuries.
Beyond the threshold, Safe supports three extension points that matter for security:
- Modules: Smart contracts that, when enabled, can execute transactions without going through the signature threshold. A malicious or misconfigured module bypasses your M-of-N requirement entirely.
- Guards: Contracts that inspect every transaction before execution. Guards can enforce custom rules, such as whitelisting recipient addresses or capping single-transaction transfer amounts.
- Delegate calls: A low-level EVM instruction that executes external code in the context of your Safe. A malicious delegate call target can rewrite your Safe’s storage.
Each of these expands the attack surface when misconfigured. Understanding them is a prerequisite for the hardening steps below.
Choosing the Right Threshold: What a 3-of-6 Setup Means Under Adversarial Conditions
The adversarial math is worth stating plainly. According to the Gnosis Safe documentation, a 3-of-6 configuration means an attacker only needs to compromise three keys, not all six, to fully control the Safe. The security guarantee is defined by the minority required, not the total owner count.
Industry practitioners generally recommend a threshold ratio above 50% of total owners. A 3-of-5 or 4-of-7 structure forces an attacker to compromise a genuine majority. Common configurations and their tradeoffs:
- 2-of-3: Convenient for small teams. Creates single-point-of-failure risk if two signers share infrastructure, a cloud provider, or a social engineering vector.
- 3-of-5: A reasonable baseline for most protocol teams. Above the 50% threshold. Survivable if one signer key is lost.
- 4-of-7 or 5-of-9: Appropriate for enterprise treasuries. No single team, office, or device ecosystem should hold a signing majority.
The Gnosis Pay best-practices documentation explicitly addresses owner management and threshold configuration as a core operational responsibility, not a setup detail. Threshold changes require a quorum transaction, so rehearse the amendment process on a testnet before a real emergency forces it under pressure.
One rule holds across all configurations: add a new signer without raising the threshold and you reduce the effective security ratio. Every owner-set change should trigger a threshold review.
Signer Device Hygiene: Hardware Wallets, Air-Gapped Keys, and What Not to Do
The device each signer key lives on is the physical boundary of your Safe’s security. Gnosis Pay’s official help documentation on Safe best practices covers device hygiene and owner key management as primary security responsibilities.
What to do:
- Each signer key should live on a dedicated hardware wallet (Ledger, Trezor, or equivalent) used exclusively for Safe signing.
- For high-value Safes, air-gapped signing setups provide the highest available isolation. These are offline devices that never connect to the internet, transferring transaction data via QR code.
- Verify transaction details on the hardware wallet screen itself, not just in the browser UI. UI-spoofing attacks present a legitimate-looking interface while routing signatures to a malicious transaction.
What not to do:
- Never store a signer key on a hot wallet, browser extension, or shared device.
- Never store seed phrases or private keys in cloud password managers, shared Notion documents, or any environment accessible to more than one person.
- Never reuse a signing device for general browsing, DeFi interaction, or any activity that exposes it to untrusted code.
KeeperHub’s integration documentation, which references Safe signing workflows, specifically flags validating transaction parameters at the hardware level as a required step before approving any transaction. Social engineering remains the most common attack vector for multisig compromise. A signer who trusts the browser over the hardware screen is the weakest link in an otherwise strong configuration.
[LINK: hardware wallet security guide]
ProxyAdmin and Upgrade Risk: The Hidden Attack Surface in Your Safe
Safe uses a proxy pattern. The proxy contract delegates calls to a singleton implementation contract, the “master copy.” If the upgrade path isn’t properly locked, an attacker who controls the ProxyAdmin can swap that implementation for a malicious contract and effectively replace your Safe with a different program.
OpenZeppelin’s backdooring analysis at blog.openzeppelin.com is the canonical reference for this risk class. Its core finding: ownership of the deployment process is a security surface, not an administrative detail. The analysis remains relevant even against updated Safe architecture.
A practical on-chain audit of your Safe state should confirm all of the following:
- No unexpected modules are enabled.
- The fallback handler is set to the canonical Safe address.
- No delegate call targets have been added without a governance vote.
- The owners list and threshold match your documented configuration.
For any protocol contracts governed by your Safe, the ProxyAdmin address should itself be a multisig or timelock. Never an EOA. A single private key standing between your protocol and a complete contract replacement isn’t an acceptable risk surface.
Routine on-chain audits of Safe state should appear in every team’s security runbook. Module lists and fallback handlers can be changed by an attacker who’s already crossed your threshold. Catching that change quickly limits the damage window.
[LINK: smart contract upgrade security]
Owner Rotation, Recovery, and Governance Without Downtime
Adding or removing an owner requires a threshold-passing transaction, the same as any other Safe operation. According to Gnosis Pay’s official documentation on the owner-addition flow at docs.gnosispay.com, the process is straightforward but must be rehearsed before an emergency makes it urgent.
The most common failure mode here is inaction. A signer who leaves an organization retains a valid key until an on-chain owner-removal transaction explicitly revokes it. If the departing signer is adversarial, the clock starts the moment they walk out the door.
A working rotation protocol covers four scenarios:
- Planned departure: Initiate the removal transaction before the signer’s last day. Confirm the threshold remains above 50% of the new owner set.
- Key compromise: Treat this as an immediate emergency. Rotate the compromised key out in a single coordinated quorum transaction. Don’t wait for confirmation of the attack.
- Unresponsive signer: If the team can’t reach quorum without a missing signer, the “break glass” procedure applies.
- New signer onboarding: Add the new signer before removing any departing one. Never let the owner set shrink below your minimum functional threshold.
Gnosis Pay’s help center article on understanding and changing Safe owners at help.gnosispay.com covers the rotation workflow in detail and is a reliable primary reference for the mechanics.
The “break glass” procedure is the recovery plan for when M signers are simultaneously unavailable due to travel, illness, or key loss. Every team should hold one emergency backup key in cold storage with a documented, tested access protocol. Write it down. Store it securely. Review it annually.
Advanced Defenses: Delay Modules, Timelocks, and the Safe Watch Agent
A well-configured threshold with disciplined signers is necessary. It’s not sufficient. Layered defenses extend the window between a compromise and a successful drain.
Delay Modules and Timelocks
Safe’s Delay Module introduces a mandatory waiting period between transaction proposal and execution. A 24 to 72 hour delay on large transfers gives security monitors and community members time to detect and cancel malicious transactions before they settle. For protocol treasuries, this waiting period isn’t bureaucratic friction. It’s a meaningful security control.
Timelocks serve a related purpose at the governance layer: they prevent even a legitimate majority of signers from executing an irreversible action without public notice. Both controls give your team a cancellation window that a direct threshold attack would otherwise eliminate.
Safe Watch Agent
On June 2, 2025, according to Gnosis’s official announcement at gnosis.io/blog, Gnosis introduced Safe Watch Agent: an on-chain co-signer that analyzes queued Safe transactions for fraud signals before execution.
In Gnosis’s own words from the official announcement: “Safe Watch Agent is an on-chain guardian co-signer that analyzes queued Safe transactions for fraud signals and can block or approve transactions. It operates as an on-chain signer that can reject or sign based on risk.”
The Watch Agent is open source and self-hostable. Teams can run their own instance rather than relying on Gnosis-hosted infrastructure, preserving the self-custodial model the Safe ecosystem is built on. A live demo is available at safewatch.ai.gnosisdev.com; the OpenAPI specification is at safeguard.ai.gnosisdev.com.
The Watch Agent flags pattern signatures common to most treasury drains: unexpected recipients, unusual token amounts, and interactions with newly deployed or unverified contracts. Combined with a Delay Module, the architecture creates two intervention points. The AI-assisted co-signer analyzes the queued transaction during the delay window. Human monitors have the same window to review and cancel independently.
Guards as On-Chain Policy
Guards let teams encode custom rules directly on-chain. Whitelisting recipient addresses and capping single-transaction transfer amounts are the two most commonly deployed controls. A guard that rejects any outbound transfer above a defined limit can’t be bypassed by a compromised signer set. Modifying the guard requires a separate governance action. That separation of concerns is the point.
[LINK: Safe modules and guards explainer]
The Checklist
Use this as a standing audit against your current Safe configuration.
Threshold:
- Threshold is above 50% of total owner count
- No single team, office, or device ecosystem controls a signing majority
- Threshold is re-evaluated after every owner-set change
Device hygiene:
- Every signer key lives on a dedicated hardware wallet
- No signer key is stored in a hot wallet, browser extension, or cloud environment
- Signers verify transaction details on-device, not in the browser UI
On-chain state:
- Owners list and threshold match documented configuration
- No unexpected modules enabled
- Fallback handler is set to the canonical Safe address
- No unauthorized delegate call targets
- ProxyAdmin for any governed contracts is a multisig or timelock, not an EOA
Rotation and recovery:
- Rotation procedure documented and tested on testnet
- Departing signers removed via on-chain transaction before leaving
- “Break glass” recovery procedure documented and stored securely
Layered defenses:
- Delay Module enabled for high-value Safes
- Safe Watch Agent evaluated or deployed
- Guards configured with recipient whitelists and transfer caps where appropriate
The Core Reframe
A multisig is not a security product. It’s a security process. The Humanity Protocol hack didn’t expose a flaw in Gnosis Safe’s code. It exposed the gap between what a multisig configuration promises and what the humans behind it actually practice.
The threshold number in your Safe UI is a starting point. Real protection comes from device isolation, signer diversity, rotation discipline, routine on-chain state audits, and layered controls like Delay Modules and Safe Watch Agent. The tools exist. The documentation exists. The checklist above exists.
The only open question is whether your team follows it before an attacker tests it for you. Schedule the audit. Run the testnet rotation. Enable the delay module. Then do it again in six months.
The protocols that survive treat security as a maintenance schedule, not a launch-day checkbox.
