Safe is a smart contract wallet that holds assets in a programmable account controlled by a configurable set of signers, with on-chain rules for who can move funds and under what conditions. Originally launched as Gnosis Multisig in 2017, rewritten as Gnosis Safe in 2018, and rebranded to Safe in 2022, the protocol has become the default treasury wallet for DAOs, foundations, and onchain businesses. Safe contracts secure tens of billions of dollars in aggregate across more than a dozen EVM chains, with public TVL trackers on DeFiLlama placing the system among the largest non-custodial custody platforms in crypto.
​

This deep dive covers what Safe actually is at the contract level, how the Singleton plus Proxy pattern keeps deployments cheap, how threshold signatures and Modules and Guards compose into a programmable account, how Safe integrates with ERC-4337 through the Safe 4337 Module, what the Safe{Core} SDK exposes to builders, who uses Safe in production, and how it compares to alternatives like Squads on Solana. It is written for treasury operators, protocol engineers, and anyone evaluating a smart account for institutional or DAO use.
​

Safe is a smart contract wallet protocol that replaces externally owned account (EOA) custody with a deployed contract that holds assets and enforces signing rules onchain. Where a MetaMask EOA is a public-private key pair with one signer and no programmable logic, a Safe is a contract instance with a stored list of signers, a configurable signature threshold (the M in M-of-N), and optional extensions called Modules and Guards. The Safe team maintains the contracts as open-source code at github.com/safe-global/safe-smart-account, audited by firms including Ackee Blockchain, OpenZeppelin, G0 Group, and Runtime Verification across multiple releases since 2018.
​

The product surface has three layers. Safe Smart Account is the contract layer, deployed and verifiable on each supported chain. Safe{Core} SDK and Safe Transaction Service are the developer layer, used by wallets and apps to construct, propose, and execute Safe transactions. Safe{Wallet} at app.safe.global is the consumer layer, a hosted interface that DAO operators and treasurers use to manage signers, propose transactions, and confirm signatures. The contracts are free to deploy and use. Safe{Wallet} adds an optional fee for sponsored transactions and premium features through Safe Pass and the SAFE token governance system that launched in 2024.
​

Supported chains as of 2026 include Ethereum mainnet, Polygon, Arbitrum One, Optimism, Base, BNB Chain, Avalanche C-Chain, Gnosis Chain, zkSync Era, Linea, Scroll, Mantle, Celo, and several other production EVMs, with the full list published at docs.safe.global. The same Singleton bytecode is deployed at a deterministic address on each chain through Safe's deployment factory, so a Safe with the same configuration parameters lands at the same address across chains when deployed by the same deployer.
​

Safe's architecture rests on four design choices that together make smart account custody cheap and flexible enough for production use. The first is the Singleton plus Proxy pattern. A single Safe Singleton contract holds the actual implementation logic. Each Safe account a user deploys is a thin GnosisSafeProxy contract that delegatecalls into the Singleton for every operation. The Singleton at version 1.4.1 weighs about 22 KB of bytecode, but the Proxy is roughly 174 bytes. Deploying a new Safe costs a fraction of what deploying a fresh full-logic wallet would, because the Proxy stores only the Singleton address and an owners list, then borrows execution from the shared Singleton.
​

The second is threshold signatures. Each Safe stores an array of owner addresses and a uint256 threshold. To execute a transaction, the Safe verifies that signatures from at least threshold owners are present, valid, and ordered correctly. Signatures can be standard ECDSA from EOA owners, EIP-1271 contract signatures from other Safes or smart accounts, or pre-approved hashes stored onchain. This lets a 3-of-5 DAO multisig include another Safe as one of its signers, or include a contract that implements custom approval logic, without changing the core verification path.
​

The third is Modules. A Module is a separate contract that the Safe authorizes to call execTransactionFromModule and move funds without collecting threshold signatures. Modules are how Safe extends from a static multisig into a programmable account. Common modules in production include the Safe Allowance Module, which lets a designated address spend up to a configured amount per period; the Recovery Module from Safe and third-party providers like Sentinel, which lets a recovery guardian replace signers after a delay; and the Safe 4337 Module, which makes a Safe behave as an ERC-4337 account and accept UserOperations. Adding a Module requires a normal threshold-signed transaction, so the owners always retain the power to revoke any module that misbehaves.
​

The fourth is Guards and Fallback Handlers. A Guard is a contract the Safe calls before and after every execTransaction, with the ability to revert and block the transaction. Guards are how teams add policy enforcement: spending limits, transaction-source whitelists, time-of-day rules, or compliance hooks. The Fallback Handler is the contract the Safe delegatecalls when it receives a call to a function it does not natively implement. The default CompatibilityFallbackHandler implements EIP-1271 signature verification and ERC-165 introspection, which is what lets a Safe sign a message that other contracts can verify offchain.
​

A standard Safe transaction flow runs as follows. A proposer constructs a transaction payload, including target, value, data, operation type (CALL or DELEGATECALL), and gas parameters, then hashes it with EIP-712 to produce the SafeTxHash. Owners sign that hash offchain through Safe{Wallet} or programmatically through the Safe{Core} SDK. Signatures collect in the Safe Transaction Service, a hosted indexer Safe runs at safe-transaction-mainnet.safe.global and equivalents per chain. Once the threshold is met, any owner or relayer submits execTransaction with the concatenated signature bytes, the Safe verifies them, runs the Guard pre-check if configured, executes the call, then runs the Guard post-check. The whole flow is fully onchain at execution time, but the signature collection is offchain to avoid paying gas per signer.
​

Modules are the most-used extensibility point and the place where most production Safe deployments differ from a vanilla multisig.
​

The Allowance Module lets a Safe designate an address as a delegate with permission to spend up to a configured token amount per refill period. A 4-of-7 DAO multisig might use the Allowance Module to give an operations contributor a $5,000 USDC monthly allowance, executable as single-signer transactions, without weakening the threshold for treasury-level moves. The module is open source at github.com/safe-global/safe-modules and ships as a verified deployment on every Safe-supported chain.
​

The Recovery Module assigns a recovery address with delayed authority to add, remove, or replace owners. A typical setup: a sole signer assigns a hardware-wallet recovery key with a 7-day timelock, so a lost or compromised primary key can be replaced through the recovery key after the delay, but only the original signer can short-circuit the delay. Third-party providers including Sentinel and Lossless have shipped variants with social-recovery guardians and policy-driven recovery flows on top of the same module interface.
​

The Safe 4337 Module makes a Safe act as an ERC-4337 account. The module implements validateUserOp, the function the ERC-4337 EntryPoint calls to verify a UserOperation, and routes the validated UserOp into the Safe's normal execTransactionFromModule path. With the 4337 Module enabled, a Safe can accept gas-sponsored transactions from a Paymaster, batched transactions, and sessions signed by alternative key types like Passkeys. Pimlico, Alchemy, and ZeroDev all ship Safe-compatible bundlers and paymasters that work with the 4337 Module. See What Is ERC-4337? Account Abstraction Explained 2026 for the underlying standard and Best ERC-4337 Infrastructure 2026 for the provider landscape.
​

Beyond the official modules, teams build custom modules for spending caps, role-based access, and chain-specific compliance. Zodiac, a module suite from Gnosis Guild, ships Roles, Delay, Bridge, Connext, and Reality modules that compose with any Safe. The Delay Module is widely used to add a mandatory timelock between proposal and execution for high-value transactions, giving the community a window to react if a treasury vote is contested.
​

Guards run before and after every execTransaction, and they are the right primitive for policy enforcement that must apply to every signer-driven transaction, not just delegated module calls. A Guard can revert the transaction in checkTransaction, which runs pre-execution, or in checkAfterExecution, which runs post-execution. Production examples include Guards that block transactions to non-whitelisted addresses, Guards that enforce per-chain spending caps for cross-chain treasuries, and Guards that require co-signature from an external compliance contract.
​

Fallback Handlers handle calls to functions the Safe Singleton does not implement. The default handler implements EIP-1271 isValidSignature, which lets a Safe sign offchain messages that any onchain or offchain verifier can check. This is how Safes sign Permit2 approvals, sign in to apps that use Sign-In with Ethereum, and approve OpenSea listings. Custom Fallback Handlers can add support for new standards as they emerge, like ERC-6492 for predeploy signatures or ERC-7579 for modular account interfaces.
​

The Safe{Core} SDK is a TypeScript library at github.com/safe-global/safe-core-sdk that exposes the Safe protocol as five composable packages. Protocol Kit handles Safe deployment, transaction construction, signature gathering, and execution. API Kit talks to the Safe Transaction Service for indexed Safe data and signature relays. Auth Kit wraps Web3Auth and similar providers for social-login Safes. Relay Kit handles ERC-4337 UserOperation construction and gas sponsorship through providers like Gelato and Pimlico. Onramp Kit integrates fiat ramps so a freshly created Safe can receive its first deposit without a separate bridging step.
​

The SDK targets two audiences. Wallet integrators use it to embed Safe creation and management into a custodial or self-custodial product. Application builders use it to enable smart-contract-wallet flows in their dApps, like batched approval-plus-swap transactions or gas-sponsored onboarding for new users. Safe also maintains a Python SDK and a Go SDK for backend treasury automation, both linked from docs.safe.global.
​

Safe is the default treasury tool for the largest onchain organizations. DAO treasuries holding billions of dollars in aggregate, including those of Uniswap, Aave, MakerDAO, ENS, and Lido, are publicly documented as managing their core funds through Safe instances visible on app.safe.global. Protocols use Safes as multi-signer admin keys for upgradeable contracts, with timelocks added through the Zodiac Delay Module for sensitive operations. Foundations and DAO service providers like Karpatkey, Llama, and StableLab operate Safe-based treasury workflows for dozens of organizations.
​

Beyond DAOs, Safe is used by exchanges, market makers, and asset managers for hot and warm wallet segregation, where threshold signatures replace traditional MPC custody for chain-native operations. Several Bitcoin-bridging protocols use Safes as the canonical guardian set for their reserve contracts on EVM chains. DeFiLlama tracks Safe TVL across chains at defillama.com/protocol/safe, and the protocol routinely sits in the top tier of onchain custody platforms by assets secured.
​

Safe's closest competitors fall into three groups. Direct EVM multisig alternatives include Avocado from Instadapp, Ambire, and the newer Coinbase Smart Wallet for single-user accounts. Account-abstraction-first wallets include Argent on Starknet and Ethereum, ZeroDev's Kernel, Biconomy's Smart Account, and Alchemy's Modular Account, all of which support more aggressive ERC-4337 and ERC-7579 feature sets out of the box. Non-EVM equivalents include Squads on Solana, which provides the same treasury-multisig user experience for SPL tokens, with comparable governance and module patterns adapted to Solana's account model.
​

The trade-offs are roughly as follows. Safe has the longest production track record, the largest auditor coverage, and the most institutional integrations, including Fireblocks, Anchorage, and Coinbase Custody. Newer ERC-4337-native wallets ship features like passkey signers, session keys via ERC-7715, and one-click cross-chain UX faster than Safe, because they are not constrained by backward compatibility with the existing Safe Singleton ABI. Squads is the right choice for Solana-native treasuries and would not run on EVM chains. The practical answer for most multi-signer organizations holding EVM assets in 2026 remains Safe, with the Safe 4337 Module added when account abstraction features are needed. See Best Smart Wallets 2026 for a side-by-side comparison and Smart Wallet vs EOA 2026 for the case against staying on an EOA.
​

Safe supports two recovery patterns. The native pattern is signer rotation: as long as the threshold-required number of remaining owners can sign, they can call addOwnerWithThreshold, removeOwner, or swapOwner to replace a lost or compromised signer. This is the simplest path for DAO treasuries with five-plus active signers, where one going dark does not threaten the threshold.
​

For sole signers or small multisigs where losing one key can lock the Safe, recovery modules add a delayed third-party path. Sentinel, the recovery service launched by Safe in 2023, offers a hosted Recovery Module configuration plus a guardian network. The owner designates one or more recovery guardians and a timelock period. To trigger recovery, a guardian initiates an addOwner or swapOwner transaction through the module. After the timelock elapses, the transaction can be executed, replacing the lost signer. The original owner retains a veto: at any point during the timelock, they can cancel the recovery transaction with their original key. This avoids the trust-the-guardian failure mode of pure social recovery while keeping recovery possible for solo signers. See Smart Wallet Recovery 2026 for a side-by-side comparison of social, multisig, and passkey recovery options.
​

The Safe contract layer is free. There are no protocol fees on execTransaction beyond the standard gas cost paid to the chain. Safe{Wallet}, the hosted UI at app.safe.global, is also free for basic use, including signer management, transaction proposal, signature collection, and execution. Fees enter through optional services: Safe Relay charges a small markup on gas for sponsored transactions, Safe Pass layers premium features on top of the free tier following the SAFE token launch in 2024, and third-party services like Sentinel charge subscription fees for the recovery guardian network. ERC-4337 bundlers and paymasters that route transactions for Safe 4337 accounts have their own fee structures, typically a percentage markup on gas plus a per-UserOp fee. None of these affect the underlying contract: a self-hosted Safe operator can avoid every Safe-the-company fee by running their own transaction service and submitting transactions directly to chain.
​

Safe's contract audits are public at github.com/safe-global/safe-smart-account/tree/main/docs. The 1.0.0 release was audited by G0 Group in 2018. Versions 1.1.0 through 1.3.0 were audited by Runtime Verification, with formal verification of core invariants. The 1.4.0 release in late 2022 was audited by Ackee Blockchain and OpenZeppelin. The Safe 4337 Module was audited by Ackee Blockchain in 2023 and by Certora in 2024. The protocol has been operating without a contract-level compromise since the rewrite to Gnosis Safe in 2018, despite securing assets across hundreds of thousands of deployments and many billions of dollars in aggregate value. Notable incidents have come at the operational layer, not the contract layer: the 2024 phishing incidents that drained several institutional Safes traced to social engineering against signers, not to any Safe contract vulnerability. The Safe team has since published guidance on transaction simulation, hardware-wallet co-signing, and Guard-based domain whitelisting to harden Safes against signer-side attacks.
​

Stablecoin treasuries are the obvious fit for Safe. A business holding USDC, USDT, or DAI for operations, payroll, or supplier payments wants multi-signer custody, programmable spending limits, recovery paths, and the option to add account abstraction features as they mature. Safe provides all four out of the box. Eco Routes, the cross-chain stablecoin transport that powers fast USDC and USDT transfers across 15-plus chains, is callable from any Safe through a normal execTransaction or, with the 4337 Module enabled, through a sponsored UserOperation. Teams that use Safe as their treasury layer and Eco Routes as their transport layer can move stablecoins across chains in a single signed transaction without surrendering custody to a bridge contract or a centralized custodian. To start building, the Eco Routes documentation at docs.eco.com walks through SDK integration, and a Safe with the Safe 4337 Module is the recommended account configuration for production stablecoin workflows.
​