Safe: Decentralized Custody Protocol

Authors Gnosis Safe Team; Richard Meissner; Stefan George; et al.
Year 2018
Project Safe (formerly Gnosis Safe)
License LGPL-3.0
Official Source https://docs.safe.global/

This page is an educational summary and analysis of an official whitepaper or technical paper, written for reference purposes. It is not a verbatim reproduction. CryptoGloss does not claim authorship of the original work. All intellectual property rights remain with the original author(s). The official document is linked above.

Safe (formerly Gnosis Safe) is a modular M-of-N threshold multisig smart contract wallet ecosystem, with documentation and formal specifications available since 2018. Safe is the dominant institutional custody protocol in DeFi — it secures over $100 billion in assets across more than 7 million deployed Safe instances on Ethereum and other EVM chains.

Unlike hardware wallets (single-key) or EOA accounts (single private key), a Safe requires M-of-N designated signers to authorize any transaction. Compromise of a single key cannot drain the Safe — an attacker must compromise M keys simultaneously.

> Documentation: docs.safe.global

> Source code: github.com/safe-global/safe-contracts


Publication and Context

Gnosis Safe was developed by Gnosis GmbH (Stefan George, Richard Meissner, and team) starting in 2018. Gnosis itself was originally a prediction market protocol (launched 2017); the Safe multisig was developed as internal tooling for Gnosis DAO treasury management and later became its own product.

History milestones:

  • 2018: Safe v0.0.1 deployed to mainnet (originally called Gnosis Multisig, then Gnosis Safe)
  • 2019: Safe v1.0.0 — modular architecture with Guards and Modules
  • 2021: Safe v1.3.0 — widely deployed; audited by multiple security firms
  • 2022: SafeDAO formed; SAFE token governance token launched; project spun out from Gnosis GmbH
  • 2023: Safe rebranded from “Gnosis Safe” to “Safe”; ERC-4337 integration for account abstraction
  • 2024: Safe became leading platform for on-chain organizations (DAOs, protocol treasuries, institutional holders)

Core: M-of-N Threshold Multisig

A Safe is configured at deployment with:

  • N owners: A set of Ethereum addresses (EOAs, other Safes, hardware wallets, Smart contracts)
  • M threshold: The minimum number of owners who must sign a transaction to execute it

Example: A 3-of-5 Safe has 5 authorized signers; any 3 must co-sign for a transaction to execute.

Transaction Flow

  1. Any of the N owners proposes a transaction (off-chain, via Safe’s transaction builder)
  2. Other owners review and sign (via MetaMask, hardware wallet, etc.) — signing is off-chain, gas-free
  3. When M signatures are collected, any party (gas sponsor) submits the transaction on-chain
  4. The Safe contract verifies all M signatures and executes the transaction

Signatures are ECDSA; the Safe contract verifies them on-chain using ecrecover.


Modular Architecture

Safe’s power comes from its modular extension system:

Guards

Guards are smart contracts that can add pre-execution checks to every Safe transaction:

  • A Guard’s checkTransaction() is called before execution
  • A Guard’s checkAfterExecution() is called after execution
  • If a Guard reverts, the transaction fails

Use cases:

  • Spending limits: Reject transactions exceeding a daily disbursement limit
  • Allowlist addresses: Reject transactions to non-whitelisted addresses
  • Time locks: Reject transactions during restricted hours
  • DeFi constraints: Reject transactions interacting with non-approved protocols

Modules

Modules are contract extensions that can bypass the M-of-N requirement for specific purposes:

  • Modules are enabled by M-of-N vote (secure addition)
  • Once enabled, a Module can directly execute transactions without collecting M signatures
  • Designed for automation: recurring payments, DAO execution bots, recovery mechanisms

Examples: Zodiac Reality Module (Snapshot-to-on-chain execution), Allowance Module (pre-approved recurring payments), Delay Module (time-lock between proposal and execution).

Fallback Handler

The Fallback Handler is called when the Safe receives a function call for a function it doesn’t natively support:

  • Enables ERC-1271 signature validation (Safe as ERC-1271 signer for other protocols)
  • Enables ERC-777 token callbacks
  • Enables custom interface support without modifying the core contract

Security Model

Safe has been audited by:

  • G0 Group, Ackee Blockchain, Certik, OpenZeppelin, Runtime Verification, Consensys Diligence

Security properties:

  • No admin key: No Gnosis/Safe team key can override the Safe; only the designated owners control funds
  • Formal verification: The Safe contracts have been formally verified for specific properties
  • Immutable core: The core Safe singleton contract is not upgradeable (preventing supply chain attacks via upgrade)

The Safe singleton pattern: All Safes are proxies pointing to a single deployed implementation contract. This reduces deployment gas costs and ensures all Safes share the same audited implementation.


Safe Ecosystem

SafeDAO and SAFE Token

SAFE token is the governance token for SafeDAO:

  • Governs protocol decisions, fee structures, grant funding
  • Distributed via an airdrop to historical Safe users in September 2022
  • Initially non-transferable; transferability enabled by governance vote in 2023

Safe{Wallet}

The official frontend (app.safe.global) provides:

  • Transaction Builder (compose contract calls with a GUI)
  • Batch transactions (multiple calls in one Safe transaction)
  • Mobile app (iOS/Android) for signing on-the-go
  • WalletConnect integration (connect Safe to any dApp)

Reality Check

Safe is the most successful and battle-tested institutional crypto custody solution:

  • $100B+ secured across 7M+ Safes
  • Used by: Ethereum Foundation, Uniswap DAO, Optimism, Arbitrum, nearly every major DeFi protocol treasury
  • Zero critical hacks of the core Safe contract in 6+ years of deployment

Known risks:

  • Social engineering of signers: Safe’s security depends on safe key management by all signers. If 3 of 5 signers are social-engineered or their keys compromised, the Safe can be drained.
  • Module risk: Poorly written Modules can introduce vulnerabilities. Users must carefully audit any Module before enabling it.
  • Frontend risk: Users who interact via a compromised frontend could be tricked into signing malicious transactions. Hardware wallet confirmation is essential.
  • Owner key loss without recovery: If M or more private keys are lost simultaneously and no recovery module is set up, the Safe becomes permanently inaccessible.

Legacy

Safe established the standard for on-chain multisig custody and has become the de facto institutional wallet for DeFi. Its modular extension architecture (Guards, Modules) is the most flexible production smart wallet system available. Safe’s accumulated security track record (100B+ secured, zero core contract hacks) is unmatched in smart contract wallet history.


Related Terms


Research

  • Meissner, R., George, S., et al. (2018). Gnosis Safe Smart Contract System Specification. github.com/safe-global.

— Primary technical specification; covers the singleton proxy pattern, Guards/Modules/Fallback architecture, signature verification, and the module enabling flow.

  • Luu, L., Chu, D.-H., Olickel, H., Saxena, P., & Hobor, A. (2016). Making Smart Contracts Smarter. ACM CCS 2016.

— Seminal smart contract security paper; provides context for the vulnerabilities that Safe’s multisig-and-Guard design prevents.

  • Buterin, V., Weiss, Y., et al. (2021). ERC-4337: Account Abstraction Using Alt Mempool. EIPs.ethereum.org.

— Safe integrates ERC-4337 for Bundler-compatible UserOps; the two systems are complementary: Safe provides the M-of-N policy, ERC-4337 provides the gas abstraction infrastructure.