Cowrie Research

safe

12 min read

Safe

  • Name: Safe
  • URL: https://safe.global/
  • Category: wallet-and-signing-workflow operator / account-infrastructure company / transaction-coordination middleware company
  • Tags: ethereum-ecosystem
  • Summary: Safe matters here as more than the smart-account substrate captured in safe. The operator-managed Safe{Wallet} stack at safe.global runs the web and mobile signing surfaces, the Safe Client Gateway, the Config Service, the Transaction Service that coordinates offchain multisig proposals and confirmations, the Event Service that pushes indexed updates toward clients, and the decoding layer that turns raw calldata into human-readable transaction summaries. That makes Safe a useful separate company note in this exploit cluster: incidents like Bybit were not only about a Safe smart account onchain, but about the operator-managed interface and coordination layer that signers treated as custody truth.
  • What it does:
    • Operates Safe{Wallet} as the canonical web and mobile interface for proposing, reviewing, simulating, and signing Safe smart-account transactions
    • Runs the Safe Infrastructure stack behind that interface, including the Client Gateway, Config Service, Transaction Service, and Event Service used to aggregate chain state and proposal state for end users
    • Uses the Client Gateway as the facade and intended single front-end communication point above the backend services, while the Config Service maps supported networks and chain-specific variables and routes requests toward the right Transaction Service instance
    • Exposes the Transaction Service as both Safe’s own backend and a developer-facing coordination layer for tracking transactions, proposing multisig transactions, collecting offchain confirmations, collecting EIP-1271 message signatures, and indexing executed Safe activity
    • Provides transaction decoding and ABI-sourcing infrastructure so wallet users see interpreted calls rather than only raw calldata
    • Packages mobile notifications, human-readable transaction rendering, hardware-wallet support, and transaction simulation as part of the user-facing signing workflow
  • Key claims:
    • Safe’s homepage describes Safe{Wallet} as “the most trusted smart wallet infrastructure” and positions it as the leading smart-account system for secure self-custody, treasury management, and organizational transactions.
    • Safe’s mobile page says Safe Mobile lets users track assets, sign on the go, import signers, receive notifications, view human-readable transactions, and preview transaction outcomes before confirming.
    • Safe’s current infrastructure docs still describe the Safe Client Gateway as the facade between end customers and backend services, the Config Service as the supported-network registry, multiple Transaction Service instances as the chain-specific coordination layer, and the Event Service as the notifier that feeds new indexed events back toward the gateway.
    • The same API overview says the Client Gateway transforms, aggregates, and caches data from the Config and Transaction Services and is intended to be the single front-end communication point for Safe’s web and mobile clients.
    • The current Transaction Service overview still says the service tracks Safe transactions, supports sending transactions, collects offchain signatures, and informs owners about pending transactions awaiting execution.
    • The lower-level Transaction Service docs additionally say the service collects offchain multisig confirmations and EIP-1271 message signatures while sourcing ABIs and verified contract metadata from services such as Sourcify, Etherscan, and Blockscout to decode contract interactions.
    • NCC Group’s Bybit analysis makes the Client Gateway path more concrete for this note: it describes the gateway as the component that orchestrates proposed multisig messages above Safe wallets and notes that Safe later added stricter matching-hash / matching-signature checks before proposal data is passed deeper into the Transaction Service flow.
    • NCC also says the current safe-client.safe.global deployment no longer accepts a tampered proposal without a matching hash and signature, which is a useful post-incident reminder that proposal-object integrity was part of the real custody boundary rather than convenience middleware.
    • The Safe Ecosystem Foundation presents itself separately as an “anon-profit” accelerating permissionless self-custody infrastructure and SAFE-token governance, which is a useful governance-layer boundary: this company note is mainly about the operator-managed wallet and coordination stack at safe.global, not about SafeDAO governance in the abstract.
    • Public Bybit postmortems from Sygnia, CertiK, and NCC Group preserve the key distinction for this note: the exploit path ran through a compromised Safe{Wallet} representation layer and signing flow, not through an onchain break of the Safe smart-account primitive itself.
  • Whitepaper: No separate company whitepaper is the important artifact here. The useful primary materials are the Safe{Wallet} site, current infrastructure and Transaction Service docs, and the Bybit-incident statements that show the operating stack above the Safe contract becoming part of custody authenticity.

Why this company note belongs in the exploit corpus

  • Analysts often say Safe was used when the sharper question is which Safe layer mattered: the onchain account primitive, the Safe-operated representation and coordination stack, or the surrounding signer workstation environment.
  • Bybit is the preserved reason to keep those layers separate. The Safe contracts behaved according to the signatures they received, but the signer-facing Safe{Wallet} delivery path, proposal object, and coordination flow had already become the authenticity boundary that failed.
  • That makes Safe a recurring operator-boundary note, not only a product note. The useful question is not just what can a Safe account do? but which Safe-operated surfaces do humans treat as truth when deciding what a Safe account is about to do?

Triage questions this note should trigger

  • Was the incident primarily an onchain Safe-permission failure, a Safe-operated representation / coordination failure, or a compromise of the signer endpoint that happened to pass through Safe?
  • Which object was treated as canonical by the humans involved: browser-rendered transaction, Client Gateway proposal, Transaction Service record, device prompt, or executed calldata?
  • Could queued Safe proposals, partially collected confirmations, or other stored Safe-side approval objects have remained live after the signer-facing environment became suspect?
  • Which trust claim actually mattered in context: Safe contract threshold, Safe-operated interface integrity, or operator discipline around the signer workstation and browser bundle?

Sources

Internal linkages

Protocol / company / foundation boundary

  • safe is the substrate note: owners, thresholds, modules, guards, fallback handlers, and other permission objects that stay comparatively legible onchain.
  • This company note is the operator-surface note: the safe.global web and mobile clients, Client Gateway, Config Service, Transaction Service, Event Service, simulations, notifications, and decoding stack that many signers use as the practical truth surface for Safe activity.
  • The Safe Ecosystem Foundation is a separate governance-and-ecosystem layer that frames itself as the steward of SAFE-token governance and broader self-custody ecosystem acceleration. That matters because not every important Safe trust boundary is the same kind of thing: some are onchain account permissions, some are operator-managed representation and coordination services, and some sit in governance and ecosystem stewardship.
  • For exploit analysis, Bybit lands mainly in this note because the decisive failure sat in the operator-managed representation layer. A governance note would answer a different question.

Operator stack worth keeping mentally separate

  • Onchain Safe account layer — owners, threshold, modules, guards, fallback handler, and the current implementation / masterCopy semantics. This is the layer preserved in safe.
  • Safe-operated representation layer — web bundle, mobile clients, transaction rendering, simulation presentation, and notification surfaces that tell humans what they are signing.
  • Safe-operated coordination layer — Client Gateway, Config Service, Transaction Service, and Event Service that aggregate pending transactions, confirmations, indexed execution state, and network context for clients. Bybit made this layer much less abstract: proposal-object integrity, matching-hash checks, and the exact handoff from gateway proposal to stored multisig record were themselves part of the signing truth surface.
  • External metadata / decode layer — ABI sourcing, verified-contract lookups, and human-readable decoding that can change whether a signer experiences a call as routine transfer or as strange privileged action.
  • Governance / ecosystem layer — SAFE-token governance and foundation stewardship, which matter for ecosystem direction but are analytically distinct from the operator-run signing surfaces that mattered in Bybit.
  • The operational lesson is that Safe is not one trust object. Review has to ask which of these layers a user is actually trusting when they say it looked right in Safe.

Control surface

  • The point of this note is not Safe company has one hidden admin key over every Safe. The important leverage is softer and more operational: which interface users treat as canonical, how proposals are rendered and coordinated, which backend surfaces aggregate and cache transaction state, how notifications and simulations shape signer trust, and where ABI decoding and transaction interpretation come from.
  • Safe’s own docs make the layering explicit. The Safe smart account remains the onchain permission object, but the company-run Safe{Wallet} stack is the default path many users take to understand what they are signing. Once that path becomes canonical, the browser bundle, mobile client, Client Gateway, Transaction Service, Event Service, notification rail, and decoding layer become part of the real authenticity boundary.
  • The Client Gateway / Config Service / Transaction Service split is especially worth preserving because it shows how what transaction is pending, what network context applies, what events just happened, and what this calldata supposedly means are all mediated by services above the contract layer.
  • NCC’s post-Bybit observation that Safe tightened matching-hash / matching-signature validation in the gateway path is useful evidence that this coordination layer was not just passive transport. It was one of the places where displayed proposal, stored proposal, and signed payload either stayed identical or drifted apart.
  • That is why Bybit belongs partly in a company note rather than only a wallet-contract note. The preserved lesson is that even when the Safe contract itself behaves correctly, the operator-managed representation and coordination stack above it can still decide whether multisig signers approve the transaction they think they are approving.

Failure-prevention checklist

  • Treat the Safe{Wallet} review surface, Client Gateway, Config Service, Transaction Service, Event Service, decoding stack, and notification rails as custody-adjacent production infrastructure, not convenience middleware. Release control, integrity monitoring, rollback discipline, and incident triage have to be designed accordingly.
  • Bind the browser-rendered proposal, simulation input, stored multisig transaction, collected confirmations, and final execution payload to one exact transaction envelope. Humans should not have to trust that these layers stayed aligned by convention.
  • Fail closed on privileged shape inside routine treasury flows. If a signer opens what is supposed to be an ordinary transfer and the proposal contains delegatecall, module enablement, owner rotation, implementation rewrite, guard change, or another control-plane mutation, the workflow should stop automatically.
  • Make proposal-object integrity explicit at the coordination layer: matching hash, matching signature, matching target, matching operation, matching calldata, and matching nonce should be first-class invariants rather than best-effort checks.
  • Keep high-blast-radius actions on a visibly different ceremony than day-to-day transfers. Safe-based treasury movement should not quietly share the same review and approval lane as masterCopy swaps, module installs, or root ownership changes.
  • Require a second verification channel for actions the signing device cannot render clearly. If the device cannot distinguish benign transfer semantics from privileged contract mutation, the browser alone is not an acceptable authenticity source.
  • Age out or revoke pending privileged proposals aggressively after signer anomalies, browser-bundle integrity scares, proposal-service incidents, or unexplained retry storms. A suspiciously gathered approval object should not remain live by default.
  • Preserve proposal ids, signed hashes, decoder outputs, gateway records, client-bundle versions, and device-visible prompts by default so representation-layer incidents can be reconstructed quickly.

Audit prompts

  • Which Safe layer are operators actually trusting in this workflow: onchain threshold, browser-rendered proposal, Client Gateway object, Transaction Service record, device prompt, simulation output, or notification-driven review path?
  • What proves that the transaction object rendered in Safe{Wallet} is still the exact object whose confirmations are being collected and whose calldata will execute onchain?
  • Can the Client Gateway, Config Service, Transaction Service, decoder pipeline, or signer endpoint still change meaning after human review but before signature collection or execution?
  • Which privileged semantics remain too opaque on the signing device: delegatecall, module installs, guard changes, owner changes, batched subcalls, or implementation-slot mutations?
  • Can a Safe workflow that is socially treated as routine treasury transfer still authorize a root-control action if the interface, metadata, or decoding layer is compromised?
  • What happens to partially collected confirmations and queued proposals after a suspicious signing session, bundle rollback, or transaction-service integrity incident?
  • Which external metadata sources or verified-contract lookups are shaping human-readable transaction meaning, and what happens if those decode assumptions drift or fail?

Lessons that should already be standard

  • It looked right in Safe is not a complete security claim. The important question is whether the represented proposal, the signed envelope, and the executed payload were still the same object.

  • The Safe contract threshold and the Safe-operated interface stack are different trust surfaces. Strong onchain threshold semantics do not rescue a compromised representation layer.

  • Proposal coordination, transaction decoding, notification delivery, and simulation are part of custody truth once signers rely on them to decide what to approve.

  • Routine transfer lanes should not quietly inherit root-control semantics. If one review path can both move funds and rewrite future wallet authority, a representation-layer compromise becomes catastrophic.

  • Blind-signing should reduce the class of Safe actions that can be authorized. If the device cannot clearly express the privileged shape, the workflow needs a stronger second channel or a narrower action set.

  • Queued proposals and partially collected confirmations are stored authority, not harmless workflow residue. Once signer-intent integrity is in doubt, those objects need expiry, revocation, and inventory discipline.

  • Post-incident hardening at the gateway or proposal-validation layer is evidence about the real control surface. If tighter matching checks materially reduce risk, that layer was already inside the authenticity boundary.

  • Last reviewed: 2026-08-04 UTC

Graph View

Backlinks