A protocol treasury holds millions in assets across Ethereum, Arbitrum, and Optimism. The Safe Wallet deployment looks standard on the surface: five signers, three-of-five threshold, hardware wallets listed in the UI. Yet when a security team performs a forensic review, they discover that one signer’s key is shared across three organizations, another was generated on a web-based tool and never rotated, and the fourth signer is the protocol’s multisig admin account—which itself requires only one signature to execute transactions. The configuration is live, transactions are flowing, and no breach has occurred. But the practical security guarantees have eroded to something much closer to single-signature control.

This scenario repeats across production treasuries. Safe Wallet itself—formerly Gnosis Safe—has become the de facto standard for DAOs, protocols, and organizations managing shared assets because it eliminates single points of failure through configurable multisig thresholds and role-based access control. The immutable smart contract rules that govern the wallet are sound. The problem is not the technology. It is that most teams never systematically audit the configuration they have deployed, the operational practices that surround it, or the assumptions embedded in their signer selection. An audit checklist that covers the full attack surface can reveal gaps that remain hidden in a routine status check.

Verify the actual signer composition and key custody model

The first forensic step is to confirm that each listed signer is genuine, unique, and under the control of the person or entity whose name appears next to it. This is less trivial than it sounds. A signer may be listed as “Protocol Lead” but the private key may actually be held by an operations team member, an external consultant, or a shared password vault. When auditors ask “who holds the key to signer X,” the answer should be one person or a documented group with clear custody procedures—not a shrug and “someone on the team has it.”

Hardware wallets as signers represent the baseline security expectation for treasury multisigs. A hardware wallet such as a Ledger, Trezor, or Lattice cannot be fully compromised by malware on a signing computer unless the attacker can physically intercept the device or persuade the holder to approve a transaction they do not intend. Yet teams often deploy hardware wallets incorrectly. A key generated on the device and then exported to a QR code to scan into Safe is no longer a hardware wallet signer; it is now a key stored in software. Similarly, a hardware wallet that remains plugged into one workstation acts as a remote signing service, not a true air-gapped device. The hardware wallet’s security benefit depends on the signing process: disconnection between key storage and the network, and a physical confirmation step for each transaction.

For each signer, document the custody model in writing. Is it a hardware wallet? A key held in a password manager by one individual? A threshold multisig of other parties? The custody model should be as strong as the threat model of the assets involved. A 100-million-dollar protocol treasury protected by a signer whose key is stored in a browser extension is not secure, no matter what the other signers contribute. Shared keys and shared custody create proportional risk: if the shared account is compromised, all signers using it are compromised. The audit should also verify that no signer’s key was generated on a web-based tool, a mobile app without hardware backing, or a centralized service that retains a copy. Any of those circumstances means an attacker may have access to a private key that was never supposed to exist outside the signer’s exclusive custody.

Check for distributed geography and institutional independence

A multisig with three-of-five signers located in the same city, working for the same organization, or using internet service providers on the same network backbone has significantly lower practical security than the same configuration with distributed signers. The reason is not abstract: a targeted attack on one physical location, organization, or network can potentially compromise multiple signers simultaneously. A natural disaster, regional outage, or coordinated law enforcement action affecting one jurisdiction could disable signers in that area.

The audit should map each signer to its custody location, responsible institution, and underlying infrastructure. Signers should be distributed across geographies—ideally different continents—and should belong to independent organizations with no shared management, board membership, funding, or operational dependency. If three of five signers work for companies in the same venture fund, they may feel independent in theory while actually being subject to pressure from the fund’s leadership. If the multisig governs a protocol’s treasury, the signers should not all be protocol team members; at least half should be external parties who have reputational but not financial stakes in the protocol’s success.

A corollary worth testing is whether signers could be simultaneously incapacitated through social engineering, coercion, or regulatory action. If four of five signers are residents of one country, that country’s government could theoretically compel all four to refuse to sign, effectively giving veto power to the minority signer. This is not a hypothetical concern; regulatory agencies in multiple jurisdictions have frozen accounts and compelled cooperation from individuals. Distributed geography and institutional independence are not merely operational preferences; they are structural defenses against systemic risk.

Audit the threshold and quorum dynamics

The multisig threshold—the number of signatures required to execute a transaction—is the core security parameter. A three-of-five threshold means that at least three signers must approve any transaction, and no fewer than three signers can be compromised or coerced without breaking the wallet’s protection. However, the effective threshold is not determined by the configuration alone. It is also determined by how many signers are unavailable, unresponsive, or no longer trusted in practice.

An audit should answer: How many signers have actually signed a transaction in the past twelve months? If one signer has been inactive for a year, the practical threshold has fallen. Similarly, if one signer is known to be untrustworthy but remains on the list pending formal removal, the threshold is effectively lowered. The audit should document each signer’s recent activity, their contact information, their response time to signing requests, and their stated availability. A signer who is traveling for two months and unreachable does not reduce the formal threshold, but it does reduce the number of available signers, which can make routine treasury operations impossible and create pressure to add a new signer or lower the threshold temporarily.

The relationship between threshold and total signer count also deserves scrutiny. A one-of-one threshold is no better than a standard hot wallet. A two-of-two threshold requires both signers to be available and cooperative for every transaction, which creates a single point of failure on either side. A three-of-five threshold is often treated as a safe default, but “safe” depends on context. A three-of-five threshold for a 10-million-dollar treasury managed by a small team is different from the same threshold for a 100-million-dollar treasury managed by geographically distributed organizations. The absolute value at risk and the time-to-compromise for common attack vectors should inform the threshold choice.

Examine transaction history and approval patterns for irregularities

The blockchain records every transaction that the Safe has executed. This history is forensic evidence. An audit should retrieve and analyze all transactions from the wallet’s deployment to the present, paying attention to patterns that may indicate misconfiguration, pressure, or compromise. Common red flags include: transactions approved by fewer signers than the documented threshold, transactions approved by the same subset of signers repeatedly, delays between the transaction being proposed and signed that are unusually long or short, transactions executed during unusual times for the responsible signer’s time zone, and transactions whose purpose cannot be documented.

For each transaction, verify that the threshold was actually met. Safe’s user interface shows the required confirmations, but the underlying blockchain transaction should be checked independently using a block explorer. A transaction that shows “3 of 5 required” in the UI should have exactly three valid signatures attached. If a team member casually mentions that “we approved this one quickly without waiting for all five to check,” that indicates the threshold is not being enforced in practice, even if the configuration is correct.

Examine which combinations of signers appear in the transaction history. If signers A, B, and C have signed the last ten transactions, while signers D and E have never signed anything, those inactive signers are not providing security. They are creating the appearance of security while the practical multisig is three-of-three, with zero fault tolerance. The audit should also look for any transactions that involve moving large sums to new addresses or wallets, interacting with unfamiliar smart contracts, or changing the wallet’s configuration. Those transactions should have clear documentation: who proposed them, why, when, and with which signers’ approval. Any transaction that lacks clear documentation is itself suspicious, regardless of the amount.

Verify that Safe Wallet features are configured for your threat model

Safe Wallet includes features designed to prevent common mistakes: transaction guard periods that introduce a delay before a queued transaction executes, spending limits that restrict the amount a single transaction can move, and role-based access control that differentiates between signers, proposers, and other participants. These are not decorative. Auditors should verify that each feature is turned on, configured appropriately, and actually in use. You can see below for more information on Safe Wallet’s core features and configuration options.

A guard period—typically 24 hours—creates a window during which any signer can cancel a queued transaction before it executes. This is valuable because it allows time for a signer to notice and object to a malicious or mistaken transaction before it is irreversible. However, guard periods are not a substitute for careful review before approving. A guard period also means that every legitimate transaction requires extra time to complete, which can be frustrating for time-sensitive operations. The audit should verify that the guard period is set, that signers understand it applies, and that the treasury’s operational timeline can accommodate it. If the protocol needs to respond to a liquidation or emergency within a few hours, a 24-hour guard period may be incompatible with the threat model.

Spending limits restrict how much value can leave the wallet in a single transaction without triggering additional approvals or manual overrides. A spending limit of 10 million dollars on a 100-million-dollar treasury provides some protection against mistakes or compromise of a lower-value transaction, but a determined attacker with three-of-five approval could bypass it entirely by proposing a transaction that explicitly removes the spending limit. Spending limits are a useful circuit breaker, not a hardened control. The audit should document what spending limits are in place, how often they have been changed, and whether they align with the wallet’s operational patterns. Large transfers that are routine should be above the limit; unusual transfers should trigger a warning.

Test the emergency and recovery procedures

No multisig is fully tested until it has been used in an actual emergency. However, teams can and should rehearse their procedures before an emergency arrives. An audit should include a tabletop exercise: a hypothetical scenario in which one signer is unavailable or compromised, and the team must execute a transaction with the remaining signers. Can the threshold still be met? Can the remaining signers contact each other within a reasonable time? Is there a procedure to revoke the compromised signer and add a replacement? How long would that take?

For each signer, document the recovery process: how would a replacement signer be identified, vetted, and added to the multisig? How many signatures are required to change the signer list? If changing signers requires the same three-of-five threshold, the procedure is clear and matches the governance model. If it requires a separate vote, token holder approval, or a different threshold, that procedure should be documented and tested. An audit should also verify that there is a written plan for what to do if the multisig itself becomes compromised—if an attacker gains control of enough signers to execute arbitrary transactions. What is the protocol’s fallback? Is there an upgrade path? Can the community intervene?

Recovery also applies to signer credentials. If a signer loses access to their hardware wallet or password manager, how would they re-establish access to their key? If the key cannot be recovered, how would they be removed from the multisig and replaced? A team that has never tested this scenario and then faces it in reality will discover that their backup procedures are incomplete. The audit should include a small test: one signer deliberately resets their signing device and re-imports the key from backup, ensuring that the backup procedure works as documented and that the signer can sign a test transaction. This is disruptive only to that one signer and provides concrete proof that recovery is possible.

Assess operational processes and monitoring infrastructure

The Safe Wallet configuration is only part of the security picture. The operational processes around it matter equally. An audit should examine how signing requests are communicated, approved, and verified. Are signers using email, Slack, Discord, or a dedicated signing platform? Email and Slack are less secure than dedicated tools because they are vulnerable to account compromise and message interception. A signer who receives an approval request via email should independently verify that it came from a trusted channel, ideally by checking the Safe UI directly rather than clicking a link in the message.

Documentation of decisions should be centralized and immutable. If signer approvals are discussed in a private Slack channel, that channel should be archived but never deleted, and signers should verify that the transaction they are approving matches what was discussed. For large transactions or configuration changes, a more formal approval process—such as a governance forum post, a snapshot vote, or a recorded meeting—provides better auditability and evidence of intent.

Monitoring infrastructure should track all transactions, configuration changes, and signer additions or removals. A dashboard that shows recent transactions, pending approvals, and configuration drift can alert the team to irregularities before they become problems. Automated alerts should notify signers if a transaction is proposed outside normal parameters: a large transfer, interaction with a new smart contract, configuration changes, or approvals from unusual signers or at unusual times. The alerts should route to a channel that signers monitor actively, not to an infrequently checked email inbox. The security benefit of a multisig depends on signers actually noticing and reviewing each transaction; passive configuration is not enough.

Document the threat model and acceptance criteria

The final step of an audit is to articulate the threat model that the multisig configuration is intended to defend against, and to measure whether the configuration actually provides that defense. The threat model should include: the total value at risk, the time horizon over which a breach could be tolerated, the types of attackers most likely to target the treasury, and the attack vectors most likely to succeed given the configuration and operational environment.

For example, a threat model might state: “The treasury holds 50 million dollars in assets. We are defending against a motivated attacker with sufficient budget to attempt legal attack vectors such as buying a signer’s cooperation, plus technical attack vectors such as compromising one signer’s hardware. We assume that a signer will not be deliberately malicious, but one signer may be coerced or their device compromised. We can tolerate up to 24 hours of delay for non-emergency transactions, and we have 2 hours to execute emergency transactions in response to a liquidation or exploit. Our threat model assumes that at least three signers remain trustworthy and available at any given time.”

With that threat model in place, the audit can assess whether the configuration meets it. A three-of-five threshold with geographically distributed signers and hardware wallet custody meets the stated threat model. A three-of-five threshold with four of five signers in the same organization, or with one signer’s key in software, does not. The audit should be explicit about which elements of the configuration are adequate and which create risk relative to the stated threat model. If risk exists but is accepted as a trade-off for operational simplicity, that acceptance should be documented with the understanding that it may need to be revisited as the treasury grows or the threat environment changes.