Safe Wallet, formerly known as Gnosis Safe, has become one of the most widely deployed multisignature solutions in the Web3 ecosystem, securing billions in digital assets for DAOs, protocols, and institutional participants. Yet its ubiquity has also made it a target. Over the past several years, the platform and its users have experienced a series of security incidents—some stemming from misconfiguration, others from smart contract vulnerabilities, and still others from attacks that exploited the gap between the wallet’s technical capabilities and how organizations actually deployed it. Understanding these incidents is essential because Web3 security depends not only on the strength of cryptographic primitives but on how carefully those tools are implemented and maintained.
The critical lesson from each documented exploit is that a multisignature wallet’s security properties emerge only when specific operational practices are followed. A wallet can be mathematically sound while still failing to protect assets if signers are poorly distributed, threshold settings are incorrect, transactions are not independently verified, or updates are not applied promptly. This article examines the historical record of Safe Wallet vulnerabilities and the operational failures that made them dangerous, then distills practical lessons for organizations seeking to manage institutional crypto custody without repeating these errors.
Web3 security breaches tied to Safe Wallet configuration mistakes
The 2023 Curve Finance incident illustrates how Web3 security can fail at the governance layer rather than the protocol layer. Curve’s multisignature wallet, which controlled substantial protocol reserves, experienced an attack that resulted in significant fund loss. While the attack did not directly exploit Safe Wallet’s code, it exposed a configuration weakness: the signer set had been delegated to addresses that were themselves compromised or insufficiently protected. The fundamental security model of multisignature wallets—that no single compromise can move funds—requires that signers remain independent. When several signers are controlled by the same person, stored on the same infrastructure, or share recovery information, that assumption collapses.
A more direct example emerged with various instances of Safe Wallet misuse where organizations configured extremely low thresholds relative to signer count. A 1-of-5 multisignature arrangement is technically non-custodial, but it offers little practical protection beyond single-key custody. If one signer is compromised, funds can be moved unilaterally. Yet some organizations and DAOs have deployed Safe Wallets in this configuration, either through misunderstanding threshold mechanics or to prioritize operational speed over security. The security surface area of such a wallet is almost identical to a single-key system; the additional signers add complexity without adding protection.
Another category of incidents involved Safe Wallet deployments on newer or less-tested EVM chains where node operators, validators, or bridge systems had not been as thoroughly audited as the Ethereum mainnet. Organizations moved assets to these chains for cost or speed reasons, then discovered that the underlying blockchain infrastructure carried risks that Safe Wallet itself could not mitigate. The wallet’s security properties remain only as strong as the blockchain confirming its transactions; a compromised node or consensus failure could theoretically permit transaction reversal or censorship. This is not a Safe Wallet vulnerability per se, but it represents a critical gap between intended security model and actual deployment environment.
The operational lesson is that Web3 security requires explicit attention to configuration. Safe Wallet provides the tools—threshold requirements, signer role separation, transaction queuing, and on-chain transparency—but organizations must actively use them. A team that creates a Safe Wallet with the default settings and then adds five signers without establishing independent key management practices has not actually improved security. The technical capability exists, but it has not been operationalized.
Historical smart contract vulnerabilities and patch management
Safe Wallet has experienced a small number of direct smart contract vulnerabilities, each revealing important maintenance practices. In 2023, a vulnerability was discovered in the Safe wallet code that could have theoretically allowed unauthorized transaction execution under specific conditions. The vulnerability existed in a specific version and was mitigated through a contract upgrade. Organizations using outdated versions had to explicitly approve and execute a migration to the patched version. Some users and DAOs did not perform this migration promptly, remaining exposed to the vulnerability even after a fix was public.
This pattern—vulnerability discovered, patch released, but adoption delayed—appears repeatedly in blockchain wallet security history. Unlike traditional software where updates can be pushed to users, blockchain wallets are decentralized systems where each user (or organization) controls their own deployment. A patch means nothing if applied inconsistently. Safe Wallet addresses this through governance mechanisms; DAOs can propose and vote on upgrades, and the Ethereum community maintains documentation of recommended versions. However, the onus remains on each organization to monitor advisories, understand the implications, and execute the upgrade.
The multisignature requirement amplifies both the protection and the delay. An upgrade to a Safe Wallet’s proxy contract requires threshold-meeting signatures from the configured signers. This ensures that no single person can unilaterally modify the wallet, which is a security feature. Yet it also means that applying a critical patch requires coordinating among multiple stakeholders, potentially across time zones or amid organizational turbulence. Teams that have practiced their upgrade process—establishing who signs, in what order, and with what verification—can execute patches quickly. Teams that have not planned will face delays exactly when speed matters most.
The institutional crypto custody standard therefore requires not only selecting a secure wallet but also establishing a governance process around maintenance. This means documenting which signers are responsible for security updates, testing patches before deployment, maintaining communication channels among signers, and conducting periodic security audits of the configuration itself. A multisignature wallet does not automatically provide these practices; they must be deliberately instituted and regularly rehearsed.
Social engineering and signer compromise as persistent threats
While Safe Wallet has not experienced widespread direct technical exploitation, a significant number of incidents have involved compromise of individual signers through social engineering, malware, or credential theft. The wallet’s strength—requiring multiple signatures—can become a limitation if attackers can impersonate or compromise enough signers to reach threshold. In several documented cases, attackers used phishing emails, compromised email accounts, or fraudulent communications to convince signers to approve transactions that they did not intend to authorize.
The attack pattern is straightforward: an attacker identifies a Safe Wallet’s signers through public on-chain analysis or social research. They then impersonate a trusted team member, create a fake multisignature transaction that appears legitimate, or compromise a signer’s recovery phrase. If they can control threshold-meeting signers, the transaction executes. The Safe Wallet itself functioned correctly; the vulnerability existed in the operational security of the signer set. Organizations that have experienced this have often discovered that signers were reusing passwords across services, had not enabled hardware security keys, or did not have a formal process for verifying transaction details before signing.
Protection against this vector requires Web3 security practices that extend beyond the wallet interface. Signers should use hardware wallets for signing, reducing the attack surface to physical security rather than cloud credentials. Organizations should implement a formal transaction review process where signers independently verify the destination, amount, and purpose of a transaction before signing, ideally using out-of-band communication to confirm. Signers should be educated about common phishing tactics and aware that even emails from colleagues can be compromised. Some advanced organizations have established a “treasury committee” that meets regularly (weekly or monthly) to review pending transactions, reducing ad-hoc approval requests that can be easier to fake.
The multisignature model also creates a trust structure that signers must consciously maintain. If a signer becomes unavailable or compromised, the organization must be able to identify this quickly and either retrieve the signer’s capability (through key recovery procedures) or remove them from the signer set and add a replacement. This requires a pre-established process: how many signers can be added or removed, by whom, with what approval threshold, and in what timeframe. A Safe Wallet’s role-based access control enables these distinctions, but they must be configured intentionally and tested before they are needed in an emergency.
Dependency risks and integration vulnerabilities
Safe Wallet does not operate in isolation. Organizations typically integrate it with governance tools (Snapshot, Tally), transaction execution infrastructure (Tenderly, Defender), token management systems, and dApp interfaces. Each integration point introduces a potential vector for attack. In several incidents, the Safe Wallet itself remained secure, but a compromised dependency or misconfigured integration allowed attackers to forge transaction requests or intercept approvals.
For example, if an organization uses a governance interface to propose and queue Safe Wallet transactions, security depends not only on Safe Wallet’s code but also on the governance interface, the backend serving proposals, and the communication between them. A compromised governance front-end could present false transactions or modify pending proposals before they reach the multisignature wallet. Similarly, if an organization relies on automated transaction execution tools, misconfiguration could permit an attacker to trigger unintended transactions.
The institutional crypto custody standard requires understanding the complete transaction pipeline. Organizations should audit their governance setup, confirm that proposal systems are using secure communication (HTTPS, signed messages), verify that any automated execution tools have appropriate role restrictions, and maintain awareness of which systems hold signing authority. A review of a Safe Wallet’s transaction history should reveal not only the final approved transactions but also rejected or queued proposals; discrepancies may indicate compromise of an upstream system.
Web3 security also means treating integrations as security boundaries. Using a Safe Wallet through a reputable interface (Etherscan, the official Safe UI, or a verified governance dashboard) is more defensible than custom scripts or untrusted front-ends. If an organization does develop custom tooling, it should be subject to code review, tested in staging, and deployed with limited permissions (e.g., a governance action that can only queue transactions, not execute them directly).
Lessons from delegation and recovery phrase management
A counterintuitive challenge in multisignature wallet security emerges when organizations attempt to simplify operations through delegation. Some teams have created Safe Wallets where certain signers are designated as “operations” signers—lower-security keys that can approve routine transactions quickly—while others are “vault” signers kept offline and used only for high-value or administrative changes. This model has merit, but it requires meticulous execution.
When such delegation went wrong, it typically involved recovery phrase mismanagement. A signer created a key for the operations role, stored the recovery phrase in a seemingly secure location (cloud storage, password manager, corporate vault), and then experienced a compromise: the cloud service was breached, the password manager was accessed through malware, or the corporate vault lacked proper access controls. The attacker gained access to the operations signer and, in some cases, escalated to administrator signers by studying transaction patterns or social-engineering other team members into approving administrative transactions disguised as routine operations.
Recovery phrase storage for signers in a multisignature arrangement deserves special consideration. Each signer should treat their recovery phrase as equivalent to complete control of the Safe Wallet, because collectively, threshold-meeting signers do control it. This means each signer should store their recovery phrase with the same care as a personal emergency fund: encrypted, redundant across physically separate locations, and absolutely not in cloud services or shared corporate systems. Some organizations have issued hardware security keys to all signers and required that keys be kept in personal custody, with the organization maintaining only a registry of who holds each key and a process for removal or replacement.
An overlooked aspect of multisignature security is the recovery process when a signer is unavailable or compromised. If a key is lost, the Safe Wallet cannot simply generate a new one; the signer set must be modified on-chain. If a key is compromised, the same procedure applies. Organizations should have documented and tested a process for removing a signer and adding a replacement, including the minimum number of signings required and the time required for on-chain confirmation. Practicing this procedure during a security incident is far worse than rehearsing it during a regular security audit or governance review. You can learn more about maintaining Safe Wallet operational procedures through the official documentation and community resources.
Threshold decisions and the balance between security and operability
The most consistent thread in Safe Wallet incidents is the misalignment between security intention and threshold configuration. A DAO with ten multisig signers might deploy a 3-of-10 threshold believing that provides “distributed” protection, without considering that an attacker only needs to compromise three signers. Conversely, a team may set a 9-of-10 threshold intending to require consensus, then discover that when one signer becomes unavailable, the wallet is effectively frozen unless that signer is removed.
The mathematical relationship between signer count and threshold creates a security curve. At very low thresholds (1-of-n or 2-of-n), the multisignature arrangement approaches single-key security. At very high thresholds (n-of-n), the wallet becomes operationally fragile. The optimal threshold depends on the organization’s actual threat model and operational capacity. A DAO treasury managing public funds might choose 4-of-7 (requiring 57% of signers), accepting that a moderately determined attacker could potentially compromise the threshold but ensuring that single-individual compromise is insufficient. A corporate custody arrangement managing employee funds might choose 3-of-5 (60% threshold), balancing security against the need to execute transactions even if one signer is temporarily unavailable.
Web3 security also requires honest assessment of signer availability and reliability. If an organization plans to add ten signers but knows that two live in time zones where communication is difficult, and one has significant competing commitments, then the actual operational threshold is higher. A 3-of-10 configuration might function as 3-of-7 in practice. Some organizations mitigate this by establishing a primary signer group (5 highly available signers) and a secondary group (5 backup signers), with a threshold that requires at least two from each group. This ensures distributed control without creating excessive operational friction.
The institutional crypto custody standard suggests documenting threshold decisions explicitly: why each threshold was chosen, what assumption about signer compromise it is designed to tolerate, what operational challenges the threshold creates, and when the threshold should be reviewed. This documentation serves as both a governance record and a trigger for periodic reassessment. If circumstances change—an organization grows, loses a trusted signer, or faces elevated threat activity—the threshold should be evaluated and potentially adjusted.
Monitoring, transparency, and detection of unauthorized activity
Safe Wallet transactions are recorded on-chain, creating an immutable audit trail. Yet this transparency is only useful if someone is actively monitoring it. Several organizations have experienced losses that persisted longer than necessary because no one was regularly reviewing the transaction history. An attacker compromised a signer, executed a transaction, and it was only discovered days or weeks later during a routine reconciliation.
Effective monitoring requires establishing a process: who reviews transactions, how frequently, through which interface, and what triggers an investigation or halt. Some organizations use automated alerts (monitoring on-chain events, notifications when transactions are queued or executed), while others rely on manual periodic review. A effective approach likely combines both: automated alerts for certain high-risk actions (large transfers, signer modifications, upgrades) and regular manual review of all transaction history.
The transparency of blockchain transactions also creates a vulnerability: anyone can analyze Safe Wallet transaction patterns to understand signer composition, thresholds, and operational timing. Organizations should be aware that their wallet structure is publicly visible and should avoid creating patterns that reveal when signers are expected to be available or how they typically coordinate. Some security-conscious organizations have used time delays, varied transaction timing, and off-chain governance to reduce the predictability of their wallet behavior.
Building an operational security culture for multisignature arrangements
The majority of Safe Wallet incidents reflect not technical failures but institutional ones: organizations that did not maintain a cohesive operational security practice around their multisignature arrangement. The wallet was secure, but the ecosystem surrounding it was not. Addressing this requires treating multisignature wallet security as an organizational capability, not a technical checkbox.
This means establishing a governance charter that documents the wallet’s purpose, signer responsibilities, transaction approval criteria, emergency procedures, and review schedule. It means conducting regular security drills—practicing key recovery, signer addition or removal, emergency fund transfer to a backup wallet—to ensure that documented procedures actually work and that all signers understand their role. It means maintaining communication channels among signers, establishing norms around verification and deliberation before signing, and creating a culture where expressing uncertainty about a transaction is normal rather than a sign of obstruction.
Organizations should also conduct periodic security assessments. External auditors can review the signer set composition, threshold configuration, integration points, and operational practices, identifying gaps and recommending improvements. Such audits are common for institutional crypto custody but less standard for DAOs and mid-sized teams. The incidents described in this article suggest that structured assessment—even internal, conducted by a team member with blockchain security experience—substantially improves the durability of a Safe Wallet deployment.
Frequently asked questions
What Web3 security mistakes have organizations made with Safe Wallet multisignature deployments?
Common mistakes include setting thresholds too low (1-of-5, 2-of-n) relative to the asset value, deploying signers on the same infrastructure or from the same person, failing to apply security patches promptly, inadequately protecting recovery phrases, and insufficient monitoring of transaction history. Many incidents resulted not from Safe Wallet vulnerabilities but from misconfiguration or poor operational discipline among signers.
How can an organization protect against signer compromise in a multisignature wallet?
Use hardware wallets for signing to reduce malware risk, implement a formal transaction review process where signers independently verify details, require out-of-band confirmation before approving significant transfers, educate signers about phishing, and maintain an offline recovery process for compromised signers. Establish a treasury committee that regularly reviews pending transactions, reducing ad-hoc approval requests that attackers can impersonate.
What is the relationship between multisignature threshold and institutional crypto custody security?
The threshold determines how many signers an attacker must compromise to move funds. Very low thresholds (1-of-n or 2-of-n) provide little protection beyond single-key custody. Very high thresholds (n-of-n) make the wallet operationally fragile. The optimal threshold depends on organizational threat model and signer availability. A 3-of-5 or 4-of-7 arrangement typically balances security against operational reliability, but the choice should be documented and reviewed periodically.
