Safe Multisig for Institutional Treasuries: How DAOs and Funds Manage Billions On-Chain

When a DAO holds hundreds of millions of dollars in its treasury, the question of how those funds are secured becomes existential. A single compromised key can drain everything. A rogue insider can redirect grants to themselves. The answer for most on-chain organizations has been the same since 2018: Safe (formerly Gnosis Safe), a smart contract wallet that requires multiple signers to approve every transaction.

As of 2026, Safe has over 63 million deployed accounts across 25+ networks, securing tens of billions of dollars in assets. The platform processed more than $600 billion in transaction volume during 2025 alone. From protocol treasuries to venture fund operations, Safe has become the default infrastructure for institutional on-chain asset management: not because it is the only option, but because its architecture, auditability, and module ecosystem are unmatched in the EVM world.

How Safe Works: Smart Contract Multisig Architecture

A Safe is a smart contract wallet deployed on an EVM-compatible chain. Unlike a standard externally owned account (EOA) controlled by a single private key, a Safe enforces an m-of-n signature threshold at the contract level. For example, a 3-of-5 Safe requires any three of five designated signers to approve a transaction before it executes.

Core components

• Owners: the set of addresses authorized to sign transactions. Each owner typically controls a hardware wallet, an MPC key share, or another Safe.
• Threshold: the minimum number of owner signatures required for execution. Adjustable through a threshold-signed governance transaction.
• Modules: extension contracts that can execute transactions on behalf of the Safe without going through the normal signature flow. Used for spending limits, automated payments, and account abstraction integration.
• Guards: hook contracts invoked before and after every transaction execution. A guard can enforce policies such as "no transfers above $1M without a 48-hour delay" by reverting the transaction if conditions are not met.
• Fallback handler: a contract that handles calls the Safe does not natively support, enabling compatibility with new standards like EIP-7702.

On-chain enforcement: Unlike MPC or custodial solutions, every Safe approval is recorded on-chain. Anyone can verify who signed what, when. This transparency is what makes Safe attractive for DAOs where treasury decisions must be publicly auditable.

Proxy pattern and upgradeability

Each Safe is deployed as a lightweight proxy pointing to a shared singleton implementation contract. This design keeps deployment costs low: creating a new Safe costs roughly the same gas as a token transfer. The proxy can be pointed to a new implementation through a threshold-signed transaction, allowing Safe accounts to adopt new features without migrating funds. This upgradeability is powerful but introduces risk: the February 2025 Bybit incident demonstrated how an attacker can exploit this mechanism if signers are deceived.

The Module Ecosystem

Modules are what transform Safe from a simple multisig wallet into a programmable treasury platform. A module is a separate smart contract that, once enabled by the Safe owners, can execute transactions without requiring the full signature threshold. This sounds dangerous, and it can be: the security of a Safe is only as strong as the modules installed on it. But well-designed modules enforce their own access controls, creating a layered permission system.

Key modules in production

The Zodiac standard popularized by Gnosis Guild provides a composable framework for building these modules. Because Zodiac modules follow a consistent interface, DAOs can stack them: a Roles Module controlling which protocols a treasury manager can access, combined with a Delay Module enforcing a 24-hour cooldown on large transactions, layered with a Guard that blocks transfers to sanctioned addresses.

Allowance module in practice

Consider a DAO treasury that needs to pay 50 contributors monthly. Without the Allowance Module, each payment requires collecting signatures from 3 of 5 multisig owners: a process that can take days for organizations spread across time zones. With the module, the treasury designates a payments coordinator as a delegate with a $250,000 USDC monthly allowance. The delegate can execute transfers within that budget as single-signer transactions. If the delegate exceeds the limit or acts maliciously, the multisig owners can revoke the module in a single threshold-signed transaction.

Who Uses Safe for Treasury Management

Safe dominates institutional EVM treasury management. Most major DAOs, venture funds with on-chain operations, and protocol foundations rely on Safe wallets for their primary treasury.

DAO treasuries

Protocol DAOs typically hold treasury assets in one or more Safe wallets controlled by elected multisig signers or on-chain governance modules. Uniswap, Aave, Lido, Arbitrum, ENS, and GnosisDAO all use Safe for their primary treasury operations. The SafeDAO itself managed its joint treasury with GnosisDAO through a 2-of-2 multisig between the two organizations, with professional treasury manager karpatkey previously overseeing active management of the pooled assets.

Professional DAO treasury managers like karpatkey, Steakhouse Financial, and Llama use the Roles Module to interact with approved DeFi protocols within defined risk parameters. This architecture separates strategic decisions (governed by the multisig owners) from tactical execution (delegated to treasury managers with scoped permissions).

Venture funds and corporate treasuries

Crypto-native venture funds use Safe wallets for fund operations: receiving capital calls in stablecoins, deploying capital to token purchases, and distributing returns to LPs. Corporate entities holding Bitcoin or stablecoins on their balance sheets use Safe when they want transparent, auditable custody without relying on a centralized custodian.

The accounting layer matters. Tools like Cryptio, Bitwave, and Tres Finance integrate directly with Safe transaction data to generate institutional-grade reporting for tax and audit purposes. This integration ecosystem is a major reason why treasuries that start on Safe tend to stay.

Safe vs Alternatives: Smart Contract, MPC, and Native Multisig

Safe is not the only approach to institutional custody. The choice depends on which chains you operate on, how much transparency you need, and whether you can tolerate vendor lock-in.

Squads on Solana

Squads is the Safe equivalent for Solana. Its v4 program has been immutable since November 2024 and has been audited by OtterSec, Neodyme, and Trail of Bits. Squads reports securing over $10 billion in value and offers features like time locks, spending limits, roles, and sub-accounts. However, it is Solana-only: teams managing assets across both EVM and Solana ecosystems need both Safe and Squads, creating operational complexity.

Fireblocks and MPC custody

MPC wallets like Fireblocks take a fundamentally different approach. Instead of coordinating signatures through a smart contract, MPC splits a single private key into cryptographic shares distributed across multiple parties. The signing process happens off-chain, producing one standard-looking signature. This means lower on-chain costs and broader chain coverage, but it sacrifices transparency: there is no on-chain record of who approved what.

For institutions that need regulatory compliance and a licensed custodian, Fireblocks offers chartered custody services. For DAOs that need public accountability, MPC's opacity is a disqualifier. Many institutions use a hybrid: Safe for governance-visible treasury decisions, with individual signers using MPC-secured keys (or hardware wallets) to sign their Safe approvals.

The Bybit Incident: What $1.5 Billion Taught the Industry

On February 21, 2025, attackers compromised the development machine of a Safe{Wallet} developer and injected malicious JavaScript into the Safe UI hosted on AWS. When Bybit's multisig signers initiated a routine transaction, the UI displayed a legitimate transaction while sending different data to their hardware wallets. Three of six signers approved what they believed was a standard transfer. The signed transaction instead swapped the Safe's implementation contract for a malicious one, draining approximately $1.5 billion.

The contract was not exploited: The Bybit attack did not exploit a vulnerability in Safe's smart contracts. The contracts worked exactly as designed: they executed a transaction that had valid signatures from a quorum of owners. The attack targeted the human layer, specifically the gap between what signers saw on screen and what they actually signed on their hardware devices.

The incident, attributed to North Korea's Lazarus Group, triggered a complete overhaul of Safe's infrastructure and systems. It also highlighted a structural risk in smart contract wallets: the proxy upgradeability pattern that enables Safe accounts to adopt new features also enables an attacker with enough signatures to replace the entire implementation contract.

Lessons for institutional users

• Enable Guards: a transaction guard can block implementation contract changes entirely, or require a time delay for such operations.
• Verify on device: signers should compare transaction details on their hardware wallet screen against an independent data source, not the same UI that constructed the transaction.
• Separate signing infrastructure: avoid having all signers use the same front end. Using multiple interfaces (Safe UI, CLI, frame.sh) reduces the blast radius of a single compromised front end.
• Simulation services: tools like Tenderly and Blocknative can decode and simulate pending transactions before signers approve them.

Security Model and Risks

Safe's smart contract codebase is among the most reviewed in the industry. Core contracts have been audited by Ackee Blockchain, Certora (including formal verification), and others across every major version from 0.0.1 through 1.5.0. Critical modules including the Allowance Module, 4337 Module, Passkey Module, and Social Recovery Module each carry their own independent audit reports.

Risk taxonomy

• Signer compromise: if an attacker obtains enough keys to meet the threshold, they control the Safe. Hardware wallets mitigate this but do not eliminate social engineering risk.
• Module risk: a poorly configured or malicious module can drain funds. Adding a module requires a threshold-signed transaction, but once enabled, the module operates with delegated authority.
• Front-end attacks: the Bybit incident demonstrated that the UI layer is a critical attack surface. Transaction data manipulation between the UI and signing device can deceive even careful signers.
• Proxy upgradeability: the implementation contract can be swapped if signers approve the change (or are tricked into approving it). This is a feature for upgrades but a risk vector for attacks.
• Key person risk: in practice, many DAO multisigs have signers who are slow to respond or who have lost access to their keys. This can create operational bottlenecks or, worse, reduce the effective security of the threshold.

ERC-4337 and the Evolution of Safe Accounts

Safe has integrated with the ERC-4337 account abstraction standard through a dedicated module. This integration enables Safe accounts to participate in the bundler/paymaster infrastructure: gas can be sponsored by a third party, transactions can be batched, and session keys can authorize specific operations without requiring full multisig approval for each action.

For institutional users, ERC-4337 integration means that routine operations (like claiming staking rewards or rebalancing a liquidity position) can be automated through session keys with constrained permissions. The multisig retains full control: it can revoke sessions, change the threshold, or remove the 4337 module entirely at any time.

The combination of Safe's established security model with ERC-4337's flexibility is particularly attractive for the emerging agentic payments use case. AI agents managing treasury operations need constrained, revocable permissions: exactly what Safe's module and guard system provides.

Bitcoin Multisig: A Different Paradigm

Safe's approach to multisig is contract-based: the rules live in a smart contract on an EVM chain. Bitcoin takes a fundamentally different path. Traditional Bitcoin multisig uses Script opcodes like OP_CHECKMULTISIG to encode m-of-n requirements directly into the spending conditions of a UTXO. This is simpler and does not require a separate runtime, but it lacks the extensibility of Safe's module system.

More critically, traditional Bitcoin multisig reveals the number of signers and the threshold on-chain, increasing transaction size and fees proportionally. A 3-of-5 multisig transaction is visibly larger and more expensive than a single-signature transaction, creating both privacy and cost concerns for institutional users.

FROST threshold signatures on Spark

FROST threshold signatures, as used in Spark, offer a different paradigm for Bitcoin-native multisig. FROST enables m-of-n signing where the resulting signature is indistinguishable from a single Schnorr signature on chain. The multisig structure is completely invisible: no one observing the blockchain can tell whether the transaction was authorized by one party or twenty.

This has concrete implications for institutional Bitcoin treasury management. A DAO using Bitcoin multisig governance through FROST pays the same fees as a single-signer transaction. The privacy improvement is significant: observers cannot map the organization's signing topology. And because FROST operates at the cryptographic layer rather than the smart contract layer, there is no proxy contract to upgrade and no module to misconfigure.

The tradeoff is flexibility. Safe's module ecosystem enables programmable treasury policies that Bitcoin's UTXO model cannot replicate natively. For organizations that need spending limits, role-based access, or automated DeFi interactions, Safe's smart contract approach remains necessary. For organizations that prioritize minimal trust assumptions, lower fees, and privacy, FROST on Bitcoin offers a leaner architecture.

Different tools for different treasuries: Safe excels when a treasury needs programmable policies and on-chain auditability across EVM ecosystems. FROST-based threshold signatures on Bitcoin excel when a treasury needs minimal on-chain footprint and fee-efficient signing. Many institutions will use both.

Operational Best Practices for Institutional Safe Deployments

Deploying a Safe is straightforward. Operating one securely at institutional scale requires discipline around signer management, threshold configuration, and operational procedures.

Threshold configuration

A common mistake is setting the threshold too low for convenience. A 2-of-5 Safe is operationally easy but means any two compromised signers can drain the treasury. Industry practice for large treasuries is a minimum of 3-of-5, with many protocols using 4-of-7 or higher. The threshold should be high enough that compromising sufficient signers is implausible, but low enough that routine operations are not blocked by signer unavailability.

Signer diversity

• Geographic distribution: signers across different jurisdictions reduce the risk of coordinated physical coercion or legal seizure.
• Device diversity: mix hardware wallet vendors (Ledger, Trezor, GridPlus) so a single vendor vulnerability does not compromise all signers.
• Interface diversity: signers should not all use the same front end to construct and verify transactions.
• Organizational independence: avoid having all signers be employees of the same entity.

Operational security

Regular signer rotation ensures that departed team members no longer hold signing authority. Transaction simulation before signing catches front-end manipulation attacks. Timelocked execution for high-value transactions gives the community time to flag suspicious activity. And periodic audits of installed modules prevent accumulated permission drift.

The Future of On-Chain Treasury Management

Safe's evolution from a simple multisig to a modular smart account platform reflects the growing sophistication of on-chain treasury management. The integration of account abstraction, the emergence of AI-driven treasury agents, and the expansion to new chains all point toward a future where on-chain treasuries operate with the same programmatic rigor as traditional corporate finance.

But the Bybit incident also revealed the limits of smart contract security when the human layer is compromised. As treasuries grow larger, the incentive for sophisticated attacks grows with them. The next generation of treasury infrastructure will need to address not just who can sign, but how signers verify what they are signing.

For teams exploring how different custody models compare, the choice between Safe, MPC, and native multisig ultimately depends on the specific treasury's requirements: which chains, what governance structure, how much transparency, and what regulatory posture. For developers building treasury tooling on Bitcoin, the Spark SDK documentation provides integration guides for FROST-based threshold signing. And for a deeper comparison of institutional custody approaches, see our custody comparison tool.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.