ERC-4337 and Paymasters: Paying Transaction Fees on Behalf of Users
A customer has received 100 tokens, yet sending 10 of them requires obtaining ETH first. The customer already has the asset needed to use the service, but needs another asset to pay the network fee. If the service operator covers that cost, the customer can focus on transferring tokens.
Who submits the transaction on the customer's behalf, and which balance pays for it? To understand ERC-4337 and Paymasters, we need to separate authority to move assets, responsibility for submitting the on-chain transaction, and responsibility for its ultimate cost. Let us follow a small transfer from an account with no ETH.
Separate the address holding the tokens from the signing key
Suppose smart account A is already deployed on Ethereum. A smart account uses contract code to decide who may execute which requests. A holds 100 units of token T and no ETH. Recipient address B holds no T. The goal is to send 10 T from A to B.
For this example, T has zero decimal places. There are no token transfer fees, minting, burning, or other concurrent transactions. The initial cost of deploying the account is also excluded. These are illustrative assumptions, not measured on-chain results.
Suppose the person controlling A has an externally owned account, or EOA, called C, controlled by a private key. A's code is configured to accept a signature corresponding to C as valid authorization. The tokens belong to address A, while the request is signed with C's private key. The 100 tokens are not held at C's address. Once A checks the request's signature and calls the token contract, 10 tokens move out of A's balance.
We use an account that checks a signature from a single key. A real smart account can use other authentication rules, such as multiple signatures. ERC-4337 leaves that decision to the account's code. The role of a smart account is to manage both the address holding the assets and the rules for authorizing their use.
The user signs a request for execution
In an ordinary EOA transfer, the user signs an on-chain transaction and that EOA pays its gas fee.
With ERC-4337, the app first creates an execution request called a UserOperation.
It describes an action to perform through the user's account, but is not itself an ordinary transaction that goes directly into a block.
The ERC-4337 specification defines a separate submission path for these requests.
Our request identifies A as the executing account and includes the call to send 10 T to B, a nonce to distinguish repeated requests,
gas limits, and fee parameters. If a Paymaster is used, it also carries information needed to check approval for sponsorship.
The user signs the request prepared by the app with C's key.
A uses this signature to check its authorization rules. C's signature does not mean that tokens leave C's address or that C directly submits a transaction for which it pays gas. Creating the signature is not itself an on-chain transaction. C therefore does not need an ETH top-up to authorize the transfer in this example.
Beyond showing the recipient and amount, the app must ensure that the account and action being authorized match the intended operation. Sponsorship is useful only when the request the user approved is tied to the call that will actually execute.
Account authorization and Paymaster approval are separate
A Paymaster is a contract that decides whether to cover a user's gas fees. A service operator might adopt a policy such as, “We sponsor transfers of our token, up to a specified cost per request.” The users, calls, and validity periods it supports depend on the Paymaster's design and operating policy. The Paymaster guide describes this conditional sponsorship as a central part of its role.
A asks, “Does this request have authority to move A's assets?” The Paymaster asks, “Will we pay for this request from our budget?” A valid user signature does not guarantee sponsorship if the request falls outside the policy. Conversely, the operator's approval to pay does not allow A's signature check to be skipped.
One possible design has an operator's server check the policy and issue approval data that the Paymaster verifies. Paymasters do not all use the same server or signature format, however. The Paymaster types guide describes approaches including allowlists and separate approval signatures. For our example, we choose a policy in which the operator covers the entire cost without charging the user additional tokens.
The common entry point for checking both approvals is EntryPoint, a contract that coordinates validation, execution, and fee settlement.
It calls the account's validateUserOp and the Paymaster's validatePaymasterUserOp separately.
Account validation therefore remains part of the flow even when a Paymaster pays.
The Bundler submits the actual on-chain transaction
Once the user's signature is ready, the app sends the request to a Bundler. The Bundler receives execution requests,
validates them in advance, and groups one or more into an on-chain transaction calling EntryPoint's handleOps.
The Bundler also pays the gas for that outer transaction up front.
The Bundler's role extends beyond forwarding requests to taking on the cost of submission.
The execution path in our example can be summarized as follows.
User signs with C's key
↓
Bundler checks and submits
↓
EntryPoint checks both
approvals
↓
Smart account A runs the call
↓
Token T: 10 from A to B
Once validation passes, EntryPoint calls A, and A's code calls T's transfer function. From the token contract's perspective, A is the sender. The Bundler's submission of the outer transaction does not mean that the Bundler's tokens are being sent. The Paymaster's approval to cover the cost does not make it the owner of A's tokens either.
Advance validation helps the Bundler filter out requests whose costs it may not recover. Before execution, it checks matters such as the account's signature and nonce, the Paymaster's approval, and a sufficient deposit. Validation and execution take place again through EntryPoint on-chain.
Fees are settled from the deposit in EntryPoint
Simply holding ETH at the Paymaster's address does not complete the preparations for this flow. There must be a deposit in EntryPoint credited to that Paymaster for fee settlement. Validation checks whether it can cover the request's maximum required cost. After processing, the cost of that request is settled. Any prefunded amount not charged as a cost remains in, or is returned to, the deposit. EntryPoint's fee handling uses this balance.
Suppose the opening deposit is 0.010 ETH, and the cost F settled for the successful request is 0.001 ETH. F is an illustrative number, not a measured cost per transfer or a fixed price. It represents the settled cost of processing this request, including account validation and execution.
| Balance | Before | After success |
|---|---|---|
| A's T | 100 | 90 |
| B's T | 0 | 10 |
| A's ETH | 0 | 0 |
| Paymaster deposit | 0.010 ETH | 0.009 ETH |
The total amount of T is still 100. The deposit decreases by F, the cost borne by the operator, and EntryPoint collects the fees
and pays them to the beneficiary address specified by the Bundler. In this example, that is the Bundler's own receiving address.
The Bundler provides the ETH needed to submit the outer transaction and is reimbursed through this path.
When several requests are bundled together, the gas fee for the entire outer transaction and the amount settled for each request must be read separately.
A Paymaster's stake is different from this deposit. It consists of funds locked as a form of security to constrain abuse of the validation infrastructure, with conditions such as a delay before withdrawal. The deposit is the balance charged for gas each time. Staking requirements depend on factors such as the storage used during validation. A large stake does not make up for an insufficient deposit. The distinction is explicit in the specification's Paymaster extension.
A failed transfer can still incur a cost
Consider a request that passes both approval checks and begins executing on-chain, but whose token transfer reverts. For example, A's call could fail if the T contract is paused when the transfer executes. If the state changes for this transfer are reverted, A keeps 100 T and B keeps 0 T. The gas spent on validation and the execution attempt, however, does not come back.
The Paymaster still bears the cost when execution of a request it approved reverts. The cost of failure is settled from the actual processing outcome, so we do not assume it equals F from the successful example. The specification's Paymaster post-execution handling distinguishes success from execution failure while retaining responsibility for gas costs when execution fails. A sponsorship budget based only on successful transfers would miss the cost of processing failed ones.
A request rejected during the Bundler's off-chain prevalidation and never submitted to the chain is a different case. No on-chain gas fee is settled for that request. Recording prevalidation rejection, validation problems after submission, and execution failure after successful validation as a single “transfer failure” makes it difficult to determine who paid for what. If the outer transaction itself reverts on-chain, the Bundler incurs a gas cost, and the intended settlement from the Paymaster can also be reverted.
Operating a service when users do not see gas fees
A sent 10 T without receiving any ETH. That outcome came from connecting the user's execution authorization with the service's approval to pay, then settling costs with a separate submitter, rather than sending ETH to the user in advance. A service therefore needs to manage its sponsorship budget, supported calls, per-request cost limits, and the cost of failures alongside token balances.
If the deposit runs low or the sponsorship policy changes, support for the same request may stop even when A has enough tokens. The app should distinguish insufficient assets from a refusal to sponsor the cost. “Zero gas fees for the user” does not mean that the cost disappears. It means the service provides a payment path so that the user does not need to obtain ETH separately.
This article followed A as a separate smart contract account. ERC-4337 and EIP-7702 are not simply substitutes for each other: the current ERC-4337 specification also defines a path that incorporates 7702 authorizations. The next article uses a separate EOA example to explain how EIP-7702 connects execution code to an existing address.