How paymasters sponsor gas fees and abstract gas from users in ERC-4337

05 September 2026

A paymaster is a smart contract that agrees to pay the gas fees for someone else’s UserOperation. It does this by staking a deposit on the EntryPoint contract. That deposit is what makes the paymaster’s promise credible.

The core idea is simple. The user never holds ETH for gas. The paymaster covers the cost. In return, the paymaster can enforce its own rules about who gets sponsored and under what conditions.

How a paymaster works in the two-phase flow

ERC-4337 splits execution into two phases: validation and post-operation. Paymasters participate in both.

During the validation phase, the EntryPoint calls the paymaster’s validatePaymasterUserOp function. This function checks whether the paymaster is willing to sponsor this specific operation. The paymaster can look at the user’s address, the call data, or any on-chain state it chooses. If the function reverts, the entire UserOperation fails and is rejected before any gas is spent on the main execution.

If validation succeeds, the EntryPoint sets aside the maximum gas cost from the paymaster’s deposit. This is an accounting lock, not an actual debit. The paymaster’s balance on the EntryPoint is reduced by this amount, preventing double-spending.

After the user’s main call executes, the postOp phase begins. The EntryPoint calls postOp on the paymaster. This is where the paymaster finalizes any settlement logic - for example, charging the user in a custom ERC-20 token, or simply recording the sponsored gas cost. The contract can refund unused gas to itself, or it can choose to absorb the full cost.

The paymaster must handle two postOp modes: success and revert. Even if the user’s operation fails, the paymaster still gets called and must clean up correctly. Failure to do so can break the deposit accounting.

The economic model: deposits and staking

To become a paymaster, a contract must first deposit ETH into the EntryPoint. The deposit is not a payment; it is collateral. The EntryPoint tracks each paymaster’s balance and deducts gas costs from it after each sponsored UserOperation.

The deposit also serves a second purpose: paymasters can optionally stake their deposit for a locked period. Staking raises the deposit’s security because it cannot be withdrawn immediately. This matters because the EntryPoint allows staked paymasters to sponsor operations with a higher gas limit. Unstaked paymasters are capped at a lower gas ceiling defined by the EntryPoint.

A paymaster can withdraw its deposit at any time, but if it is staked, a cooldown period applies. The EntryPoint enforces this via unstakeDelay. If a paymaster behaves maliciously - for example, by sponsoring operations that drain its balance in a single block - the delay gives other parties time to challenge or front-run.

The policy layer: deciding who gets sponsored

No paymaster sponsors every operation for free. Each paymaster encodes its own policy. Common approaches include:

• Whitelisting specific user addresses or contracts.
• Requiring the user to lock a token as collateral.
• Charging a fee in a stablecoin, deducted during the postOp phase.
• Limiting sponsorship to operations under a certain gas value.

The policy logic lives entirely inside the paymaster’s validatePaymasterUserOp function. That function can call external contracts, read storage, or perform computations. The only restriction is that it must not modify state during validation - ERC-4337 forbids state-changing writes in the validation phase except for writes to storage slots owned by the paymaster itself.

Error codes: what breaks when paymaster logic fails

ERC-4337 defines a namespace of error codes for validation failures. These are returned as AA3x values from the EntryPoint. When a paymaster’s validation reverts, the EntryPoint emits a specific error depending on the failure type.

• AA30 paymaster deposit too low - The paymaster’s balance on the EntryPoint is less than the maximum gas cost for this UserOperation.
• AA31 paymaster not deployed - The paymaster address is a contract that does not exist. This can happen if the paymaster was selfdestructed or not yet deployed.
• AA32 paymaker validation reverted (note the typo in the spec) - The validatePaymasterUserOp function reverted for any reason, including a failed policy check.
• AA33 paymaster postOp reverted - The postOp function reverted during the finalization phase. This is a serious failure because it means the paymaster’s accounting is broken. The EntryPoint still pays the gas, but the paymaster’s deposit is left in an inconsistent state.

These error codes let wallets and bundlers diagnose why a sponsorship failed. A user whose operation gets AA30 knows the paymaster is underfunded. A user who hits AA32 knows the paymaster’s policy rejected the operation. There is no ambiguity.

Practical implications for users and dApps

For a user, gas abstraction means they never need to acquire the chain’s native token just to transact. They can interact with any dApp using only the tokens they already hold. The paymaster does the accounting.

For a dApp, a paymaster can subsidize onboarding. A new user can create a wallet and perform their first transaction without any upfront ETH. The dApp covers the cost, and the postOp phase might convert the user’s first deposit into the gas refund.

The downside is trust. The user must trust the paymaster to execute its postOp correctly. The paymaster must trust the user not to abuse the sponsorship. The EntryPoint’s deposit system mitigates financial risk, but it does not eliminate it. A malicious paymaster could theoretically censor operations after validation by reverting in postOp, though the gas for validation is already spent.

ERC-4337’s paymaster design is not a gift economy. It is a programmable escrow with collateral, rules, and error messages. The abstraction works because the economics are explicit, not magical.

Back to smart wallets