Title: [Discussion] Decentralizing Safe’s Transaction Service & Creating a Sustainable Revenue Model for the SAFE Token
Authors: Dennison Bertram (dennisonbertram.eth / dennison@tally.xyz)
Others are welcome to co-author—please reply if you’d like to collaborate.
Created: 2025-06-03
Abstract
This proposal presents a path to long-term sustainability for SafeDAO by introducing a decentralized, privacy-focused transaction service that charges a small fee per transaction—unlocking revenue for the SAFE token. This initiative addresses a critical systemic risk in Safe’s current architecture while providing ordinary users access to institutional-grade security. Fees generated through this service would be used to reward SAFE token holders and service operators, creating a meaningful, mission-aligned use case for the token that scales with adoption.
Proposal Types
- Other SEPs (Protocol Economics / Infrastructure)
Proposal Details
Purpose and Background
The SAFE token today lacks a direct, scalable mechanism for capturing value. To maintain and grow its utility, Safe must evolve beyond governance alone and enable the token to participate in protocol economics in a way that aligns with its core values: security, sovereignty, and decentralization.
At the same time, Safe’s current transaction architecture introduces a critical centralization risk. Transactions initiated through the Safe frontend are routed through a centralized transaction service that:
- Holds pending transactions while collecting multisig signatures.
- Has privileged access to pre-confirmation transaction data.
- Presents a single point of failure and a vector for MEV exploitation.
This setup is not only a security risk—it’s also an underutilized surface for value creation.
Today, many technically advanced teams, institutional players, and large DAOs already recognize these risks and run private, isolated transaction infrastructure. This gives them superior privacy and protection from pre-trade MEV, while the average Safe user is left exposed.
We believe this creates a powerful opportunity:
Let’s democratize institutional-grade privacy and security, and let SAFE token holders power it.
This proposal aims to solve these two problems—centralization risk and the lack of protocol revenue—through a decentralized, fee-based transaction service that scales with Safe usage and rewards the community for operating and securing it.
Effects and Impact Analysis
What This Proposal Delivers
We propose that Safe introduces a decentralized, privacy-preserving transaction relay system that:
- Allows users to choose their transaction service provider (or use a default).
- Charges a small “Safety & Privacy Fee” per transaction for enhanced execution privacy.
- Sends this fee to SAFE stakers and relayer node operators as protocol revenue.
- Integrates natively into the Safe frontend in an elegant and user-friendly manner.
This proposal captures value in a way that:
- Is impossible to undercut (because it’s not just swaps or frontend routes).
- Aligns directly with Safe’s mission of enhancing user safety and sovereignty.
- Improves the protocol by eliminating a single point of failure.
- Gives SAFE token real economic power, tying value to usage at scale.
User Experience
Most users don’t know that their transaction data is vulnerable the moment they submit a Safe tx. Whether executing a large trade or deploying a governance upgrade, that information—held in pending state—is visible to anyone with access to the transaction service backend.
Attackers could exploit this to:
- Front-run major trades.
- Preempt DAO treasury upgrades.
- Target known vulnerabilities in protocols during upgrade execution.
By offering a privacy-first, decentralized relay, users can opt into a more secure mode—just like major VCs and protocols already do—but without needing custom infrastructure.
And in return, they pay a small fee—one that supports the entire Safe ecosystem.
Pros
- Mission-aligned: Reinforces Safe’s commitment to decentralization and security.
- Simplified-UX: Institutional security and SEV (Safe Extractable Value) protection without additional complexity of self-hosted options.
- Scalable: As Safe grows, so does the demand for secure relaying.
- Composability-friendly: Integrates easily into any Safe-based UX, including custom frontends.
- Token utility: Introduces staking, service provision, and revenue participation for SAFE holders.
- Opt-in adoption path: No disruption to current users; can be gradually introduced as default.
Cons / Risks
- New infrastructure required: Decentralized relayers must be built and maintained.
- Economic calibration needed: Fees must be balanced—high enough to support operators, low enough to not disincentivize use.
- Security challenges: The decentralized service must avoid introducing new attack vectors.
These risks are manageable—and are outweighed by the security improvements and token utility gains this model enables.
Alternative Solutions Considered
Other revenue-generating mechanisms, such as frontend swap integrations (e.g., CowSwap fee shares), have been explored. However, these are easily undercut by competitors and don’t offer a durable economic moat.
Safe Apps monetization is another path—but app usage is fragmented and depends on broader ecosystem growth.
By contrast, execution relaying is core infrastructure. It’s something every Safe user needs. And it’s something users are willing to pay for when it provides real, trusted security improvements.
Implementation
Does this require new code?
Yes. We will need to implement:
- A decentralized relayer network (or extend existing solutions like Flashbots Protect or Shutter).
- A frontend UI for selecting relayers and previewing fees.
- Fee routing contracts for SAFE staking and operator rewards.
Implementation path:
- Prototype a decentralized relay architecture that prioritizes anonymity and censorship resistance.
- Integrate into Safe frontend as an opt-in relay option.
- Establish staking and incentive mechanisms for SAFE token holders to operate relays.
- Deploy fee collection contracts, with governance control over pricing and distribution.
- Gradual adoption and community-driven improvement over time.
Support needed:
- Technical input from the Safe core team on safe-transaction-service internals.
- Community collaboration on staking design and economic modeling.
Open Questions
- What’s the optimal governance model for approving default relayer operators?
- Should relayer selection be permissionless, curated, or hybrid?
- How should slashing, reputation, or uptime guarantees be handled?
- Should this be rolled out under a new Safe module or via integration into the existing stack?
- Are there existing solutions (e.g., Shutter, Flashbots) we can partner with?
Copyright
Copyright and related rights waived via CC0 1.0 Universal