Paymaster

What Is a Paymaster?

A paymaster is a smart contract that sponsors transaction fees for users within the ERC-4337 account abstraction system. In standard Ethereum transactions, every user must hold ETH to pay gas fees before they can do anything on-chain. This creates a chicken-and-egg onboarding problem: a new user receives tokens but cannot move them without first acquiring ETH from somewhere else.

Paymasters eliminate this friction. They act as intermediaries between the user and the network's gas market, covering the cost of transaction execution on the user's behalf. The paymaster deposits ETH into the EntryPoint contract in advance, and that deposit is drawn down each time it sponsors a UserOperation. From the user's perspective, the transaction is free. Behind the scenes, the paymaster or the application operator absorbs the cost.

The concept extends beyond simple sponsorship. Paymasters can accept alternative payment methods: USDC, ERC-20 governance tokens, or even off-chain payment commitments. This flexibility transforms gas from a user-facing concern into an infrastructure cost managed by application developers, similar to how web applications absorb server costs rather than billing users per API call.

How It Works

Paymasters operate within the ERC-4337 transaction flow. When a user submits a UserOperation (the account abstraction equivalent of a transaction), the EntryPoint contract checks whether a paymaster is specified. If one is, the EntryPoint calls the paymaster's validation function before executing the operation and its post-execution hook afterward.

The Paymaster Interface

Every ERC-4337 paymaster implements two core functions defined in the IPaymaster interface:

interface IPaymaster {
    // Called during validation to approve sponsorship
    function validatePaymasterUserOp(
        PackedUserOperation calldata userOp,
        bytes32 userOpHash,
        uint256 maxCost
    ) external returns (
        bytes memory context,
        uint256 validationData
    );

    // Called after execution for cleanup, refunds, or token collection
    function postOp(
        PostOpMode mode,
        bytes calldata context,
        uint256 actualGasCost,
        uint256 actualUserOpFeePerGas
    ) external;
}

The validatePaymasterUserOp function runs during the verification phase. It receives the UserOperation, its hash, and the maximum gas cost. The paymaster decides whether to sponsor this operation and returns context data that gets passed to postOp later. The validationData return value encodes the sponsorship decision along with optional time-range validity (valid-after and valid-until timestamps).

The postOp function runs after the UserOperation executes. It receives the actual gas cost (which may be less than the maximum estimated during validation) and the context from validation. This is where token paymasters collect ERC-20 payment, refund unused gas deposits, or update internal accounting.

Transaction Flow with a Paymaster

The full lifecycle of a paymaster-sponsored transaction:

1. The user's smart wallet constructs a UserOperation and includes the paymaster's address in the paymasterAndData field, along with any paymaster-specific data (signatures, token approval, subscription proof)
2. A bundler collects the UserOperation and submits it to the EntryPoint contract
3. The EntryPoint calls validatePaymasterUserOp on the paymaster contract, passing the maximum gas cost
4. If the paymaster approves, the EntryPoint locks the estimated gas cost from the paymaster's deposit (not the user's balance)
5. The EntryPoint executes the UserOperation against the user's smart account
6. The EntryPoint calls postOp on the paymaster with the actual gas consumed
7. The paymaster's deposit is debited for the actual cost, and any excess is returned

Paymaster Deposits

Paymasters must maintain a stake in the EntryPoint contract to cover gas costs. This deposit functions as a prepaid gas pool: the EntryPoint debits it for each sponsored operation. If the deposit runs dry, the paymaster cannot sponsor further operations and validation will fail.

Application operators monitor their paymaster's deposit balance and top it up as needed. Infrastructure providers like Pimlico and Alchemy offer managed paymaster services that handle deposit management automatically, charging operators on a usage basis.

Types of Paymasters

Verifying Paymaster

A verifying paymaster sponsors gas for operations that carry a valid off-chain signature from an authorized signer. The application's backend signs a message approving the sponsorship, and the paymaster verifies this signature on-chain during validation.

This is the most common paymaster pattern. The flow works as follows:

1. The user's wallet sends the unsigned UserOperation to the application's backend
2. The backend checks sponsorship rules (user is eligible, within rate limits, operation is whitelisted)
3. If approved, the backend signs the UserOperation hash with the paymaster's authorized signer key
4. The signature is appended to paymasterAndData in the UserOperation
5. On-chain, the paymaster recovers the signer and verifies it matches the authorized address

Verifying paymasters give applications fine-grained control over which operations to sponsor. An application can limit sponsorship to specific contract calls, cap per-user daily gas budgets, or restrict sponsorship to users who have completed KYC.

Token Paymaster

A token paymaster accepts ERC-20 tokens instead of ETH as gas payment. Users pay for gas in USDC, USDT, or another token, and the paymaster handles the conversion.

During validation, the paymaster calculates how many tokens are needed based on the estimated gas cost and current token-to-ETH exchange rate. It transfers (or pre-approves) that amount from the user's account. In postOp, the paymaster adjusts for the actual gas used and refunds any excess tokens.

Token paymasters require a price oracle to determine exchange rates. This introduces oracle dependency and manipulation risk: if the oracle returns a stale or manipulated price, the paymaster may charge too little (losing money) or too much (overcharging users).

Sponsored Paymaster

A sponsored paymaster draws from a prepaid gas pool funded by an application developer, protocol treasury, or third party. There is no off-chain signature step and no token exchange: any UserOperation that meets the paymaster's on-chain criteria gets sponsored automatically.

These are common in promotional contexts: a DeFi protocol sponsoring gas for the first 1,000 users, or a gaming platform covering all in-game transaction fees. The simplicity comes at the cost of less granular control, making rate-limiting and abuse prevention more important.

Business Models

Paymasters enable several approaches to gas fee monetization and subsidization:

• App-sponsored gas: applications absorb gas as a customer acquisition cost, similar to how fintech apps offer free transactions. This is the dominant model today, used by wallets like Coinbase Smart Wallet and protocols onboarding new users
• Subscription-based: users pay a monthly fee (in fiat or crypto) for unlimited gasless transactions within the application. The paymaster verifies subscription status before approving sponsorship
• Token payment: users pay gas in stablecoins or application tokens. The paymaster converts tokens to ETH in the background. This removes the native token requirement while still passing costs to users
• Cross-subsidized: transaction fees from high-value operations (large swaps, NFT mints) subsidize gas for low-value operations (approvals, small transfers), creating a progressive fee structure

Paymasters vs. Meta-Transactions

Before ERC-4337, the primary approach to gasless transactions was meta-transactions defined by ERC-2771. In this older pattern, users sign a message (not a transaction) describing their intent. A relayer submits the actual on-chain transaction and pays the gas. The target contract uses a trusted forwarder to extract the original sender's address from the call data.

ERC-4337 paymasters are the standardized replacement for meta-transactions. They work with any smart contract (the smart account makes the call, not a forwarder), have built-in replay protection, and support token-based gas payment natively. Meta-transactions remain in use for legacy contracts that already support ERC-2771, but new applications overwhelmingly adopt the paymaster model.

Infrastructure Providers

Several infrastructure providers offer managed paymaster services, abstracting away deposit management, gas estimation, and policy enforcement:

• Pimlico: offers a verifying paymaster with policy engine and an ERC-20 paymaster supporting stablecoin gas payments across multiple chains
• Alchemy: provides Gas Manager as part of Account Kit, with dashboard controls for sponsorship policies and spending limits
• Biconomy: runs a paymaster service integrated with their smart account SDK, supporting both sponsorship and token payment modes
• ZeroDev: offers paymaster APIs within their modular smart account platform, with support for ERC-7677 standardized paymaster endpoints

ERC-7677, the Paymaster Web Service standard, defines a standardized JSON-RPC interface for paymaster APIs. It specifies methods like pm_getPaymasterStubData and pm_getPaymasterData that wallets use to request sponsorship from any compliant paymaster service. This standardization lets wallets switch between paymaster providers without code changes and enables interoperability across the ecosystem.

Why It Matters

The requirement to hold native gas tokens is one of the most significant barriers to crypto adoption. A user who receives USDC for freelance work cannot spend it without first acquiring ETH. A gamer who earns in-game tokens cannot trade them without gas. A merchant who accepts stablecoin payments cannot process refunds without maintaining an ETH balance.

Paymasters solve this at the infrastructure level. By shifting gas costs from users to applications, they align crypto UX with user expectations from traditional fintech. This is particularly relevant for embedded wallets and smart wallets targeting mainstream audiences who should never need to know what gas is.

Self-custodial wallets like Spark take a different approach to eliminating fee friction. On Bitcoin's Layer 2, Spark enables instant, low-cost transfers without the EVM gas model entirely. Rather than abstracting gas fees away with a paymaster, Spark's architecture avoids per-transaction on-chain fees for most operations, achieving a similar user experience through protocol design rather than smart contract intermediation. For a deeper comparison of Bitcoin Layer 2 approaches, see the Bitcoin Layer 2 comparison research article.

Use Cases

• Onboarding new users: applications sponsor a new user's first transactions so they can start using the product immediately without acquiring native tokens
• Stablecoin payments: users paying for goods and services in stablecoins can pay gas in the same stablecoin, eliminating the need for a separate ETH balance
• Gaming and social: session-based paymasters cover all gas for in-game actions or social interactions, keeping the experience seamless
• Enterprise operations: corporate treasury wallets use paymasters to centralize gas spending under a single billing account rather than distributing ETH across every employee wallet
• DeFi protocol incentives: protocols sponsor gas for specific actions (providing liquidity, staking, governance voting) to encourage participation
• NFT minting: creators cover minting gas fees so collectors only pay the mint price without worrying about fluctuating gas costs

Risks and Considerations

Deposit Depletion

If a paymaster's EntryPoint deposit runs out, all sponsored transactions fail. Applications relying on gas sponsorship must monitor deposit balances and implement automatic top-up mechanisms. A depleted paymaster during a traffic spike can break the entire user experience.

Gas Griefing

Without proper rate limiting, attackers can drain a paymaster's deposit by submitting many sponsored UserOperations. Each operation consumes gas from the paymaster's deposit even if the user has no stake. Verifying paymasters mitigate this through off-chain signature checks, but sponsored paymasters with open policies are vulnerable.

Oracle Risk for Token Paymasters

Token paymasters depend on price oracles to convert between tokens and ETH. A stale or manipulated oracle price can lead to underpayment (draining the paymaster) or overpayment (overcharging users). Robust oracle integration with staleness checks and price deviation bounds is essential.

Centralization Concerns

Most paymaster services today are operated by centralized infrastructure providers. If a paymaster service goes offline or decides to stop sponsoring an application, users lose gasless functionality. Applications should consider running their own paymaster contracts or maintaining fallback providers to reduce single-point-of-failure risk.

Smart Contract Risk

Paymasters are smart contracts that handle value (the gas deposit). Bugs in paymaster code can lead to deposit drainage or stuck funds. Paymasters with token-handling logic face additional attack surface from reentrancy and approval manipulation. Audits and battle-tested implementations reduce but do not eliminate this risk.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.