Safe Wallet Fee Abstraction and Relayers: Why Your DAO Shouldn’t Make Signers Pay Gas and How to Automate It

A decentralized autonomous organization with twelve treasury signers faces an operational friction that most wallet users never consider. When a transaction proposal reaches the multisig threshold for execution, one signer must submit the final approval and pay the network gas fee—often $100 to $500 on Ethereum during congestion. That cost falls entirely on one individual, creating an unequal burden for what should be a shared responsibility. Over time, signers begin to avoid being last, proposals languish unsigned, or a centralized administrator ends up bearing the cost to keep treasury operations moving.

Safe Wallet, formerly Gnosis Safe, addresses this structural problem through fee abstraction: the ability to separate transaction approval from the cost of settlement. Rather than requiring a signer to hold ETH and pay gas directly, a relayer network can cover the cost, a smart contract can sponsor it from treasury reserves, or the approval itself can be structured as a meta-transaction whose fee is paid separately. The result is that signers need only cryptographic material to approve—not liquidity—and DAOs can decide whether to absorb costs collectively, reimburse signers, or use specialized infrastructure to make the entire process frictionless.

The structural problem: Why signers shouldn’t pay for governance

A traditional multisig wallet requires at least one signer to hold native cryptocurrency to pay transaction fees. This creates an immediate inequality. Signers with deeper liquidity positions may volunteer to pay repeatedly, incurring substantial costs. Signers without ETH reserves must either maintain a funded address—a security liability—or ask others to reimburse them afterward. In a DAO with dozens of signers voting on treasury operations, the transaction that a multi-signature wallet requires can easily exceed $1,000 on mainnet during peak periods, and that cost has historically fallen on whoever happened to submit the approval transaction last.

This financial burden is not merely inconvenient. It creates perverse incentives. A signer with limited funds may hesitate to participate in time-sensitive approvals. A signer who has already paid for several prior transactions may deprioritize their involvement. The organization then loses the benefit of distributed decision-making because signers are selectively absent based on their ability to cover gas. For treasury-heavy DAOs managing millions of dollars, having the final approval decision influenced by who can afford the fee is a governance flaw, not a technical limitation.

The alternative is a centralized administrator or fund manager who maintains a signer account with sufficient ETH to always be able to pay. This eliminates the per-signer burden but reintroduces the single point of failure that multisig was designed to prevent. The administrator becomes a gatekeeper on transaction settlement. If their account is compromised, drained, or lost, even fully approved transactions cannot execute.

Fee abstraction solves this by making the cost of approval independent of any individual signer’s holdings. The approval remains cryptographically required and immutable; only the payment mechanism is abstracted. A signer can issue a signature approving a transaction even if they hold zero ETH, because a separate entity—a relayer, a sponsor, or the Safe contract itself—will cover the cost of settlement.

How relayers execute Safe transactions without requiring signer gas

A relayer is a service or infrastructure component that accepts a fully signed Safe transaction and submits it to the blockchain on behalf of signers. From the blockchain’s perspective, the relayer is the account paying gas and sending the transaction. From the governance perspective, the transaction is valid only because it contains the required cryptographic signatures from the designated signers. The relayer never has custody or signing authority; it is purely a network-layer intermediary.

The workflow is straightforward. A signer generates an approval signature using their private key and submits it to the Safe transaction proposal system. Once enough signatures accumulate to meet the multisig threshold (for example, three of five signers), the transaction is “ready to execute.” A relayer service monitoring the Safe observes this readiness and constructs a transaction that bundles all the signatures and submits it on-chain. The relayer pays the gas, the blockchain validates the signatures, and the Safe contract executes the action—transfer funds, update permissions, or whatever the approved transaction specified.

The relayer can be a single trusted service, a decentralized network of competing relayers, or an in-house infrastructure component operated by the DAO itself. The important distinction is that the relayer never touches the private keys or has discretion over transaction content. It is a carrier, not a decision-maker. If a relayer attempts to modify the transaction, change the recipient, or drop a required signature, the blockchain will reject it because the signature no longer matches the transaction data. This means the cost of using a relayer is borne separately from the approval authority, and the two cannot interfere with each other.

Safe’s integration with relayer networks such as Gelato or the Safe Relay API makes this transparent. A DAO can configure a Safe to use a preferred relayer, and signers can simply approve as usual. The relayer handles the on-chain submission, and the transaction settles. Some relayers charge a flat fee per transaction, others take a percentage of the value moved, and some operate as a public service. The DAO then decides whether to cover the relayer cost from treasury reserves, pass it through to users, or distribute it among signers as a reimbursement.

Meta-transactions and sponsored execution

A meta-transaction is a pattern where the signer does not directly submit their transaction to the blockchain but instead signs a message or contract call that a third party will execute. Unlike a relayer, which always uses the same transaction structure, a meta-transaction can be crafted to include built-in fee sponsorship or delegated execution. The signer’s role is to authorize what should happen; the executor’s role is to pay for it.

In Safe’s architecture, this is implemented through ERC-4337 account abstraction standards and custom paymaster contracts. A signer approves a Safe transaction and includes metadata specifying that gas should be paid by a sponsor—often the Safe contract’s own treasury account, a protocol sponsor, or a third-party fee provider. When the transaction is submitted, the blockchain first validates that the sponsor’s signature or contract rules permit the expenditure, then executes the transaction, and finally deducts the gas from the sponsor’s balance.

The key advantage of meta-transaction sponsorship is flexibility. A DAO can implement custom rules: for example, all treasury spending below $10,000 is automatically sponsored from reserves, while larger transactions require explicit sponsor approval. Or a protocol can sponsor gas for signers participating in governance, recovering the cost from protocol revenue. Or a grants program can cover gas for approved recipients interacting with its Smart contracts. The sponsor never controls transaction content—the signer’s signature ensures that—but it does decide whether the cost of execution is acceptable.

This pattern becomes especially valuable in dApp integration scenarios. When signers interact with decentralized applications through a Safe, they are often executing complex transactions involving token swaps, liquidity provision, or contract interaction. The dApp itself can integrate with a paymaster to sponsor the gas cost, effectively offering gasless transactions to Safe users. This reduces friction and makes it practical for signers with no ETH holdings to participate in governance and treasury management.

Role-based access control and fee delegation

Safe’s role-based access control allows different signers to have different authorities over transaction types. A DAO might designate some signers as “frequent approvers” who handle routine operations and others as “emergency guardians” who can veto or override approvals. Fee abstraction naturally extends this model. A DAO can configure different fee policies for different roles: frequent approvers might have automatic gas sponsorship, while emergency actions require explicit sponsor approval or reimbursement.

This creates a cleaner governance structure. Instead of asking whether to burden signers with gas costs, the DAO asks: who benefits from this transaction, and where should the cost logically fall? If the beneficiary is the DAO treasury (approving an asset purchase), the cost should come from treasury reserves. If the beneficiary is an external user (approving a grant payout), the user or grant program might cover it. If the beneficiary is the protocol itself (governance voting), the protocol might sponsor it.

A Safe can also implement permission tiers using custom contracts. For example, a “sweeper” role can approve transactions up to a gas budget of 1 million wei without triggering sponsor approval, while a “treasurer” role can approve larger expenditures that invoke a formal sponsor decision. The blockchain enforces these rules through the Safe’s smart contract logic, ensuring that no individual can circumvent fee policies and that audit trails show who approved what and who paid for it.

When combined with hardware wallets as signers—a best practice for high-value treasuries—role-based fee delegation also improves security. A treasury manager using a hardware device can sign approvals without needing to hold ETH on a hot wallet. The relayer or sponsor infrastructure handles settlement, and the hardware device never touches the gas-paying account. This separation of concerns reduces the number of accounts that must be secured and funded.

Real-world implementation: DAOs and protocol treasuries

A multi-signature wallet has become the standard custody structure for DAO treasuries, often holding billions in assets across Ethereum and layer 2 solutions. The scale makes fee abstraction not just convenient but essential. A DAO with 50 signers cannot reasonably expect each to maintain a funded ETH address. Yet a centralized administrator paying all settlement costs reintroduces custody risk.

The practical implementation typically follows one of three patterns. The first is “always-on relayer,” where a relayer service (often the dApp or protocol operating the Safe) automatically submits ready-to-execute transactions. The relayer absorbs the cost or passes it through as a flat fee, which the DAO pays from treasury reserves. This is simple and reliable; the main risk is relying on a single relayer service. If the relayer is unavailable or misbehaves, transactions cannot settle even if fully approved.

The second pattern is “distributed relayer network,” where multiple independent relayers compete to submit transactions. A decentralized network of relayers creates redundancy: if one relayer is down or attempting to extract excessive fees, another will submit the transaction. This is the model used by services like Gelato or Flashbots Relay. The DAO pays the market price for relaying, which is typically much cheaper than the gas cost itself. in this guide, you will find technical details on integrating such networks into a Safe instance.

The third pattern is “self-operated relayer,” where the DAO runs its own relayer infrastructure. This requires technical operations capability but provides full control. The DAO can set fee policies, adjust sponsorship logic, and monitor which transactions are executing and when. Many larger protocols and DAOs opt for this approach, using it to combine relayer operations with their existing infrastructure.

Layer 2 solutions such as Arbitrum, Optimism, and Polygon dramatically reduce the absolute cost of transactions, but the pattern remains relevant. Even on Arbitrum, gas costs can accumulate for frequent approvals. Fee abstraction makes multisig operations consistent across chains and ensures that signer burden does not become a reason to choose a less-secure custody structure.

Security considerations: Trusting the relayer and the sponsor

Fee abstraction does not eliminate trust; it redistributes it. A signer no longer trusts themselves to hold ETH safely, but the system now depends on a relayer or sponsor not to misbehave. The critical distinction is that the relayer cannot approve transactions, only submit them. If a relayer is compromised, the worst it can do is fail to submit ready-to-execute transactions or attempt to submit transactions with invalid signatures (which the blockchain will reject).

A sponsor, by contrast, must have balance to cover fees and approval to spend that balance. If a sponsor account is compromised, an attacker could potentially drain it by submitting spurious transactions and paying high gas to themselves. However, the attacker still cannot approve transactions that signers have not signed. The sponsor’s role is purely to pay, not to decide.

The practical security model is therefore: (1) relayers should be operated by entities with strong uptime and audit history; (2) sponsors should be accounts or contracts with explicit spend limits and monitoring; and (3) signers should maintain the highest security standards, using hardware wallets and geographic distribution. If a relayer goes down, transactions may settle more slowly, but the DAO retains the ability to submit transactions directly. If a sponsor is compromised, the loss is limited to that account’s balance. If a signer is compromised, the entire Safe can be drained up to the signature threshold.

Monitoring is essential. A DAO should log all relayer submissions, audit sponsor balance changes, and set up alerts for unusual transaction patterns. Most Safe instances integrate with block explorers and transaction monitoring services that can flag suspicious activity. The combination of multi-signature control, fee abstraction, and active monitoring creates a robust system where no single failure point—not even a compromised relayer—can undermine the governance structure.

Configuring Safe for gasless operations

A Safe can be configured for gasless operations through a few key settings. First, designate a relayer in the Safe’s configuration. Most Safe interfaces provide a dropdown or integration form for popular relayers. Second, set up a fee sponsor account or contract that will cover gas costs. This can be the Safe’s own funds (allowing the contract to spend from its own balance) or a separate sponsor account that monitors a multi-signature wallet’s approvals and funds them accordingly.

Third, implement transaction approval policies that align with the fee structure. If all transactions are sponsored, signers can approve without considering gas cost. If only transactions above a certain threshold are sponsored, specify that rule in the Safe’s configuration or supporting documentation. Fourth, test the flow with a small transaction before relying on gasless execution for large operations.

The technical implementation varies depending on whether the Safe is using Safe contracts, a governance framework like Snapshot, or a custom dApp integration. The pattern is consistent: signatures are gathered off-chain or in a staging phase, then bundled and submitted by a relayer once the multisig threshold is reached. The signer’s experience is simply approving a transaction; the relayer and sponsor handle the rest.

Maintenance is ongoing. A relayer service can be retired and replaced with another; sponsors need monitoring to ensure they maintain sufficient balance. A DAO should document its fee abstraction setup and educate signers about how it works. Many governance disputes arise from signers misunderstanding how transactions are submitted or who is paying for them. Clear communication—”this DAO sponsors all settlement gas from treasury reserves” or “signers are reimbursed via separate proposal”—prevents friction and ensures participation remains voluntary and well-informed.

The long-term trajectory: Account abstraction standards

Fee abstraction in Safe is currently implemented through custom relayer networks, sponsor contracts, and integration with specific dApps. The longer-term trajectory is toward standardized account abstraction, particularly ERC-4337, which defines a universal interface for separating transaction logic from gas payment. As ERC-4337 adoption broadens, Safe will be able to use standard paymasters and bundlers rather than custom relayer implementations.

This standardization will reduce complexity and increase interoperability. A Safe using ERC-4337 can work with any paymaster on the network, competing for best pricing and service quality. Currently, each Safe setup often requires custom integration with its chosen relayer. ERC-4337 makes the choice modular: the Safe defines what transaction to execute, a paymaster sponsor decides whether to cover gas, and a bundler submits the combined operation to the blockchain.

The evolution will also make fee abstraction more accessible to smaller DAOs and teams. Currently, setting up a relayer or sponsor requires technical infrastructure. As standards and tooling mature, a DAO can enable gasless signings with a few configuration choices rather than custom development. This democratizes the ability to operate without burdening signers with gas costs, bringing multisig adoption—and the security benefits it enables—to organizations that previously could not afford it.