Gas Sponsorship and Paymasters, Explained
Every transaction on Ethereum costs gas, and on a traditional account the person sending the transaction is the person who pays for it, in the chain's native coin. That single rule is the reason a new user who holds a stablecoin but no ETH can find themselves unable to move their own funds. Account abstraction breaks that link, and the piece of machinery that does the breaking is the paymaster. This article explains what a paymaster is in ERC-4337, where it sits in the flow, and — most importantly — what gas sponsorship actually means for someone who custodies their own keys.
This is the fourth article in our account abstraction series. If the terms below feel unfamiliar, start with Account Abstraction from First Principles; for the underlying fee model that gas sponsorship sits on top of, read Gas Fees on Ethereum Explained for Self-Custody Users.
What a paymaster actually is
A paymaster is a smart contract. Its single job is to agree to cover the gas for someone else's operation. Under ERC-4337, when a smart account expresses what it wants to do as a UserOperation, that operation can name a paymaster. If the paymaster agrees, it — not the account — settles the gas cost with the network.
There are two flavors of this, and they answer two different user problems:
- Sponsoring the gas outright. The paymaster pays the fee on the user's behalf, and the user pays nothing for gas. This is what people mean by "gasless."
- Accepting payment in an ERC-20 token. The paymaster pays the native-coin gas to the network, then charges the user in an ERC-20 token instead — a stablecoin, say. The user never has to hold ETH; they settle up in the token they already own.
In both cases the protocol still gets paid in the native coin. Gas does not become free; the question is only who funds it and in what denomination the user experiences the cost.
Where the paymaster sits in the flow
To see why a paymaster can be trusted to pay, it helps to recall how an ERC-4337 operation travels. A smart account does not send a normal transaction. It emits a UserOperation into a separate mempool. A bundler collects these, packs them together, and submits them on-chain through the audited EntryPoint contract, which calls into each account to run its validation logic before executing.
The paymaster enters during the validation step. When the EntryPoint processes a UserOperation that names a paymaster, it calls the paymaster's own validation function. The paymaster inspects the operation and decides, then and there, whether it is willing to cover the gas. If it agrees, it effectively guarantees payment to the EntryPoint, and the operation proceeds. If it declines, the operation is not sponsored — it either falls back to the account paying, or it does not go through on those terms.
The important mental model is this: sponsorship is a decision made at validation time, by a contract, about a specific operation. It is not a blanket promise. A paymaster looks at this operation and says yes or no.
What gas sponsorship is good for
Decoupling the fee payer from the sender unlocks a handful of concrete patterns:
- Sponsored onboarding. A new user can complete their first action — a swap, a mint, a claim — without first acquiring the native gas token from an exchange. Removing that "you must buy ETH before you can do anything" step is one of the biggest friction reductions account abstraction offers.
- dApp-sponsored fees. An application can choose to pay gas for its users as a product decision, the way a web app absorbs server costs. The user clicks; the app's paymaster covers the operation.
- Paying fees in a stablecoin. Rather than keeping a separate ETH balance just for gas, a user can pay the fee in the token they are already transacting in. The paymaster takes the token and fronts the native coin to the network.
Each of these is an instance of the same primitive — a contract willing to pay gas on conditions it sets — applied to a different problem.
"Sponsored" is not "free"
It is worth being blunt about the economics, because the word "gasless" invites a misunderstanding. The network always charges gas in the native coin. When a transaction is "sponsored," that cost has not disappeared; someone else has agreed to absorb it. A paymaster has to be funded, and whoever funds it — an application, a protocol, a service — is paying real money for the privilege of removing friction.
That has two consequences a self-custody user should keep in mind:
- A paymaster can decline. Because sponsorship is a per-operation decision, there is no guarantee any given operation will be covered. Sponsorship programs can have eligibility rules, spending caps, or simply run out of funds. "Gasless" is a feature of a particular flow, not a property of the chain.
- You should know which paymaster is involved. A paymaster is a contract that participates in your transaction. As with any contract you interact with, it is worth understanding whose paymaster it is and what it is doing — sponsoring a fee is benign, but trust still matters. When you pay fees in a token, you are also accepting whatever exchange rate the paymaster applies between that token and the native coin.
None of this is a reason to avoid paymasters. It is a reason to understand them: a sponsored transaction is a service someone is providing, not a free lunch the protocol hands out.
What it means for self-custody
Here is the part that matters most for someone holding their own keys, and it is easy to get backwards. Gas sponsorship changes who pays the fee. It does not change who controls the funds.
When a paymaster covers your gas, you still sign the operation with your own keys. The paymaster cannot move your assets, redirect your transaction, or authorize anything on your behalf — it can only agree to pay the fee for the operation you authorized. Custody is untouched. You are still the only party who can approve a transfer of your funds; the paymaster has merely volunteered to pay the toll for a trip you decided to take.
For SSP specifically, this fits naturally with the security model. SSP is a self-custodial wallet built around 2-of-2 multisig: one key in the SSP Wallet browser extension, the second in the SSP Key mobile app, both required to approve every transaction. On EVM chains SSP is an ERC-4337 smart account that verifies a Schnorr-aggregated 2-of-2 signature, audited by Halborn in 2025. Because it is an ERC-4337 account, the standard's gas mechanics — including the ability for a UserOperation to be paid by a paymaster — apply to it the same way they apply to any ERC-4337 account. The full design is covered in the SSP account abstraction architecture.
To be precise about what that does and does not promise: ERC-4337 enables gas sponsorship and pay-in-token flows, and SSP's accounts live within that standard. Whether any particular transaction you make is sponsored, or payable in a token, depends on the application or wallet flow you are using and whether a paymaster is in the picture for that operation. The two-key custody guarantee, by contrast, is always in force regardless of who pays the gas.
The takeaway
A paymaster is a contract that can pay a UserOperation's gas on the user's behalf, or let that gas be paid in an ERC-20 token instead of the native coin. It agrees to this during validation, per operation, and it can decline. It enables gasless onboarding, dApp-sponsored fees, and stablecoin gas — real conveniences that lower the barrier to transacting. But "sponsored" means "funded by someone," not "free," and the paymaster never gains any control over your assets. For a self-custody user, that is the clean summary: paymasters can change who pays for the trip, but you still hold the keys to the car.
The rest of this series
- Account Abstraction from First Principles — why EOAs are limiting and what account abstraction means.
- EOA vs Smart Account: The Differences That Matter — a direct comparison of the two account models.
- SSP Account Abstraction Architecture — how SSP wires ERC-4337 into a 2-of-2 wallet.
- Gas Sponsorship and Paymasters, Explained — this article: how paymasters decouple who pays from who sends.
- Account Abstraction on Non-Ethereum Chains — how the same idea travels beyond Ethereum.
For the standard itself, the authoritative reference is EIP-4337, and Ethereum's account abstraction roadmap tracks where the broader effort is heading. If you want the standard in isolation first, read What Is Account Abstraction (ERC-4337)?.
