[Discussion] Decentralizing Safe’s Transaction Service & Creating a Sustainable Revenue Model for the SAFE Token

Proposals Phase 0: Discussion
1

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:

  1. Prototype a decentralized relay architecture that prioritizes anonymity and censorship resistance.
  2. Integrate into Safe frontend as an opt-in relay option.
  3. Establish staking and incentive mechanisms for SAFE token holders to operate relays.
  4. Deploy fee collection contracts, with governance control over pricing and distribution.
  5. 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

3 Likes
2

Hey @DennisonBertram completely agree with this idea but I think the solutions you proposed are better suited once other aspects of the network infrastructure and SDK have been addressed.

Not sure if you have read this but I actually proposed something similar here shortly when we lost access to relayer during the bybit hack.

We also had a call where many people also signalled support for this idea to move forward.
It really great to see Tally also pushing for this as will draw more attention to this issue.

I think the E2E relayer network is ambitious and the correct endgame, but we have a few steps and some low hanging fruit to solve to get there.

Happy to jump on a call and hash this out further or continue here for all to see!

2 Likes
3

Yeah happy to chat about this! I’d be curious to hear more about the other aspects of the network infra that are being worked on.

1 Like
4

I’m not sure a plan has been publicly shared yet.

That said, this is right up @gakonst’s alley, his experience with reth and related work seems like the ideal complement to bring something like this to life.

1 Like
5

Ah geez! In all transparency, I shared this plan with the team I think two years ago at this point. :slight_smile:

Would love to be in the loop. :slight_smile:

1 Like
6

Sharing a lite paper I’ve been working on: https://docs.fileverse.io/0xF9B7EbEF0C14339785c4b7BcC2B52517D37525ec/9#key=_nwyl3YlwGjn-clyfUc0ZOHo7TSSyYbvay7aD64TJK7TbFyl_OVmh7x4HIvpvPrp

2 Likes
7

This is the kind of forward-thinking proposal SafeDAO needs. Tackling both protocol centralization risk and token utility in one move is a power play. The idea of turning the transaction service into a decentralized, opt-in privacy layer is especially strong — it upgrades user security without friction, and actually gives the SAFE token economic purpose beyond governance.

:white_check_mark: Institutional-grade privacy for the average user? Yes, please.
:white_check_mark: Revenue flowing back to SAFE stakers? That’s real utility.
:white_check_mark: Eliminating single points of failure? Core to decentralization.

That said, I’d love to hear more on how relayer incentives will be tuned over time, especially in early phases before wide adoption kicks in. But overall, this is a solid step toward making SAFE more than just a governance token. Count me in on supporting and amplifying this and open to co-authoring too if there’s space!

1 Like
8

Few thoughts on this:

  1. Biggest UX challenge is what keys the users can utilize for e2ee.
  2. Use of Waku seems to add a big complicated dependency without much benefit. Couldn’t the nodes simply use http to talk to each other? They need to support http to accept requests from users anyway.

Generally when it comes to a revenue model for the Safe token, a transaction relay service doesn’t really seem high value enough to account for the valuation of the Safe token?

1 Like
9

Thanks for the post and bringing this topic up again!

Agree that the transaction service is a centralized point of failure. It serves 2 main purposes:

  1. Indexing historical onchain data - “indexer”
  2. Storing tx data and pre-confirmations before they are executed - “queue”

The indexer is much heavier and should ideally be run by large infrastructure providers such as Alchemy. Privacy is less of an issue since data is historical and onchain anyway. Of course the question of right incentives and economic soundness as part of a token model remains. This seems what TheGraph originally set out to do, right? Can we draw any learnings from them?

The queue is much more lightweight in terms of processing overheard. It is what the original post is mainly about, right? The number of actors being able to run it, is much bigger. Question of incentives remains, of course. Are users willing to pay for each pre-confirmation or prefer free but less available services. The queue is the component though where privacy is more relevant. While both are relevant I feel we should look at the 2 topics of privacy and decentralization separately.

Privacy:
To the point of encrypting via eg. HPKE, assuming the Safe has multiple owners, the tx data would just be encrypted for each owner, separately, correct?

(Side topic and not so relevant for this proposal: We will have to showcase ways to encrypt data with a Safe that also allows for changing owner structure. This would enable all kinds of use cases leveraging end2end encryption with Safes.)

Decentralization:
I don’t have much comments at this point on the proposed Waku/EigenLayer idea, however was thinking of the OG Gnosis MultisigWallet which just put all tx data + confirmations on chain. At Safe we have an internal, more lightweight prototype for this ready to be published soon which should help us explore how to decentralize the transaction queue.

4 Likes
10

Distributing the Safe transaction tx service is a potentially good initial use of Safenet to improve security and decentralization! :sparkle:

Value

  • Advanced individuals and organizations would want to enable this with an additional small fee for specific accounts and txs that are important
  • $SAFE token holders would be excited to support an important network service

Strategy

  • It seems like there’s multiple options for the messaging layer like XMTP, Waku, etc.
  • EigenLayer EL helping to decentralize Safe txs could be one of EL’s biggest use cases securing billions of dollars of tx volume
2 Likes
11

Love the direction and generally believe SafeDAO should aggressively invest SAFE from it’s treasury into high-potential use-cases and generate value now that we still have the chance.

Expanding on Earn with Vaults + the decentralizing the queue would be two use-cases I would support, getting the resources required.

@DennisonBertram based on @tschubotz’s input - do you believe there’s enough value in just focusing on the queue, or do you see the indexer as a core piece of the value prop?

4 Likes