Cowrie Research

safe

5 min read

Safe

  • Name: Safe
  • URL: https://safe.global/
  • Category: Smart-account infrastructure / multisig wallet / account-abstraction stack
  • Tags: ethereum-ecosystem
  • Summary: Safe is the account-substrate note in this cluster: a widely used smart-account system whose owner, threshold, module, guard, fallback-handler, and execution-mode structure stays comparatively legible onchain even when the surrounding product stack does not. The durable analytical value is not just popular multisig wallet, but Safe as shared-account infrastructure that many protocols, DAOs, exchanges, and custody workflows build on or wrap. In the exploit corpus, that distinction matters because some high-profile losses involving Safe-branded workflows were really representation-layer or operator-surface failures above the substrate, while the substrate still defined which privileged primitives became dangerous once signatures were gathered.
  • What it does:
    • Provides smart-contract-based self-custody accounts used for multisig treasury management, organizational operations, and individual asset security
    • Exposes developer tooling through Safe{Core}, including SDKs, APIs, relay tooling, transaction-service infrastructure, and deployment materials for integrating Safe Smart Accounts into applications
    • Supports modular extensions such as guards, modules, spending controls, and ERC-4337 account-abstraction flows
    • Publishes documentation and examples for passkeys, relaying, supported-network installation, and AI-agent patterns with human approval and spending-limit controls
    • Maintains open-source contract, wallet, SDK, CLI, and transaction-service repositories that show Safe functioning as ecosystem infrastructure rather than only a wallet UI
  • Key claims:
    • The homepage describes Safe as “the most trusted smart wallet infrastructure,” emphasizing modular, programmable, battle-tested self-custody and treasury management
    • Safe’s docs llms.txt describes the project as an “open-source and modular account abstraction stack” with over $100B+ in assets secured and 200+ projects built on top since 2018
    • The Safe Infrastructure docs say the stack is intended for developers building next-generation account-abstraction wallets and solutions on a thoroughly audited and tested core
    • Safe’s AI overview explicitly recommends Safe Smart Accounts for AI agents because signers keep key control and can add spending limits, timelocks, whitelists, and human-approval workflows
    • The public GitHub organization and repositories show a broad operational footprint across wallet UI, SDKs, CLI, transaction service, deployment tooling, and smart-account contracts
  • Whitepaper: No classic Safe whitepaper or litepaper was found during this pass. The strongest primary materials were the homepage, Safe docs (llms.txt, infrastructure overview, AI overview), GitHub organization, and smart-account repository; see ../whitepapers/safe-primary-sources-2026-04-25.md.
  • Sources:

Internal linkages

Exploit-corpus cut

  • The important split is Safe account semantics versus Safe-branded signing workflow. Bybit belongs mainly to safe and the blind-sign / payload-substitution family because the decisive failure sat in the signer-facing representation layer, not in a break of the Safe smart-account primitive itself.
  • That said, the substrate still matters during those incidents because it defines the privileged objects the attacker ultimately wants to reach: owner sets, thresholded execution, module installs, guard changes, fallback handlers, delegatecall-style execution modes, and upgrade-like implementation pivots in adjacent wrappers.
  • Keeping the substrate note separate preserves a cleaner comparison discipline: use this note when the question is what authority graph does Safe expose onchain?, and use the company / incident notes when the question is what offchain interface or coordination layer convinced humans to authorize the wrong Safe action?.

Protocol / company / foundation boundary

  • Keep this project note on the substrate that remains legible onchain: owners, thresholds, module installs, guard wiring, fallback handlers, execution modes, and the smart-account permission graph other teams inherit or wrap.
  • Use safe for the operator-managed signing and coordination shell above that substrate: Safe{Wallet}, Client Gateway, Transaction Service, Event Service, simulation presentation, decoding, notifications, and the browser / mobile surfaces humans treat as transaction truth.
  • Keep the foundation and governance perimeter conceptually separate again. SafeDAO / Safe Ecosystem Foundation questions are about ecosystem stewardship, token governance, and constitutional direction, not about the exact account object or the exact operator-run review surface a signer relies on during a treasury action.
  • That split matters because what can this Safe account authorize?, what did the signer-facing Safe stack represent?, and who steers the broader Safe ecosystem? are related but not identical control-surface questions.

Substrate vs service layer

  • The account logic is the part worth reading: Safe accounts, owners, thresholds, modules, guards, fallback handlers, and erc-1271 validation stay comparatively legible onchain.
  • The surrounding product stack still matters: transaction-service indexing, relays, passkey packaging, notifications, signer coordination, and recovery flows can all pull practical influence back into middleware.
  • That is the clean comparison cut in this cluster. Safe keeps more authority visible onchain than hosted signer platforms, even though the polished user experience is never purely onchain.

Control surface

  • Practical leverage still accumulates around which modules and guards get normalized, how execution modes such as call versus delegatecall are surfaced to signers, how transaction-service and relay defaults shape execution, who coordinates signer recovery, and which wrappers users treat as canonical.

  • Safe is still the reference case where the account permission graph remains comparatively legible onchain without pretending the surrounding middleware disappears.

  • In exploit analysis, this note is the what did the account actually authorize? anchor that complements the operator-side what did the humans think they were signing? notes.

  • The taxonomy reason to keep this note separate is that the smart-account object remains analytically useful even when the company-run wallet, decode, and coordination stack changes around it.

  • Last reviewed: 2026-08-09 UTC

Graph View

Backlinks