A paymaster is a smart contract under the ERC-4337 account abstraction standard that pays gas on behalf of a user operation. Instead of the smart account holding ETH and signing a transaction that debits its own balance, the EntryPoint contract deducts gas from a paymaster's prefunded deposit. The result: a user can swap, mint, or sign in to a dapp without ever holding ETH, and an app can absorb that cost or accept payment in USDC, USDT, or any other ERC-20 the paymaster supports.
​

Paymasters are one of the three core pieces of the ERC-4337 stack alongside bundlers and smart accounts. They make gasless onboarding possible, unlock pay-in-stablecoin flows, and let apps run loyalty-style programs where the first N transactions for a new user are free. This guide walks through what a paymaster does, the three classic models, the validation flow inside EntryPoint, the major providers in 2026, and the cost and abuse vectors every app needs to plan for.
​

A paymaster sits between the user's smart account and the EntryPoint contract defined by ERC-4337. When a UserOperation includes a non-empty paymasterAndData field, the EntryPoint routes gas payment to the paymaster instead of the sender. The paymaster must have a deposit staked with the EntryPoint, and that deposit gets debited at the end of the operation for actualGasCost plus a small fee.
​

The paymaster contract implements two functions defined in the ERC-4337 specification: validatePaymasterUserOp and postOp. validatePaymasterUserOp runs during the validation phase, before the bundler commits the operation to the mempool. It checks whatever policy the paymaster enforces, returns a context blob, and tells EntryPoint whether to accept the op. postOp runs after the smart account executes, lets the paymaster do bookkeeping, and is also where ERC-20 paymasters pull the user's token payment.
​

The full EIP-4337 text at eips.ethereum.org defines the exact ABI and the validation rules a paymaster must follow to stay compatible with bundlers. Stake and deposit requirements live in the EntryPoint contract at the canonical address 0x0000000071727De22E5E9d8BAf0edAc6f37da032 on most EVM chains.
​

Almost every paymaster deployed in 2026 falls into one of three patterns. Apps often combine more than one in a single contract.
​

The sponsorship paymaster covers gas fully for users that match an allowlist or policy. The app funds the paymaster's EntryPoint deposit and writes off the gas as a customer-acquisition or activation cost. This is what makes a true gasless onboarding flow possible: a new user can mint an NFT, claim an airdrop, or complete their first swap without ever buying ETH.
​

Policies are typically enforced offchain. A verifying paymaster (described below) signs UserOperations that pass the app's rules, then the onchain contract verifies the signature in validatePaymasterUserOp. Pure onchain sponsorship is possible but inflexible because policy changes require a contract upgrade. Coinbase Smart Wallet pairs this pattern with passkeys to deliver a no-ETH first-run experience.
​

An ERC-20 paymaster lets the user pay gas in a token they already hold. The paymaster fronts ETH to the EntryPoint, executes the operation, and in postOp pulls the equivalent value in USDC, USDT, DAI, or another configured ERC-20 from the user's smart account.
​

The price quote comes from an onchain oracle (Chainlink price feeds are common) or a configured spread above the spot rate. Most production ERC-20 paymasters charge a markup of around 5 to 15 percent over the actual gas cost to cover oracle drift and the cost of converting collected stablecoins back to ETH. Pimlico, Biconomy, and Etherspot all ship an ERC-20 paymaster module out of the box.
​

A verifying paymaster delegates the sponsorship decision to an offchain signer controlled by the app or infra provider. The signer evaluates a UserOperation against arbitrary business logic (allowlist, daily quota, dapp-specific limits, KYC status), then signs a payload that gets passed in the paymasterAndData field. The onchain contract just checks that the signature is valid and the expiry has not passed.
​

This is the model behind nearly every production gas-sponsorship API. Alchemy Gas Manager, Pimlico, ZeroDev Ultra Relay, Biconomy Paymaster, and Coinbase Developer Platform Paymaster all expose verifying paymasters under the hood. The app calls a JSON-RPC method like pm_sponsorUserOperation, the provider applies its policy, and the response includes the signed paymasterAndData blob the bundler needs.
​

A UserOperation that uses a paymaster goes through a six-step lifecycle inside ERC-4337. Understanding the order matters because each phase has a strict gas budget and a fixed set of opcodes that paymaster code is allowed to touch.
​

Step one: the client builds a UserOperation with the paymaster address and any required data packed into paymasterAndData. For verifying paymasters this involves an RPC call to the provider's pm_sponsorUserOperation or pm_getPaymasterData endpoint, which returns the signed blob.
​

Step two: the bundler receives the UserOperation via eth_sendUserOperation. The bundler simulates the op against EntryPoint.simulateValidation, which calls validatePaymasterUserOp on the paymaster. The paymaster runs its checks, returns a context bytes value and a validationData field encoding any time bounds.
​

Step three: the bundler aggregates the op into a bundle (typically one to fifteen UserOperations per bundle, depending on chain and infra) and submits a single transaction to EntryPoint.handleOps.
​

Step four: onchain, EntryPoint loops through each op, calls validatePaymasterUserOp again to confirm nothing changed since simulation, then calls the smart account's executeUserOp or callData target.
​

Step five: after execution, EntryPoint calls postOp on the paymaster, passing the context returned during validation, the actualGasCost, and a mode flag indicating whether the user op succeeded, reverted, or postOp itself reverted on the first attempt. ERC-20 paymasters pull token payment here.
​

Step six: EntryPoint deducts the gas cost plus the bundler's fee from the paymaster's deposit and refunds any unused gas prepayment. If the paymaster reverted in postOp or the deposit was insufficient, the bundler eats the cost, which is why bundlers are conservative about which paymasters they accept.
​

The validation phase is restricted to a subset of EVM opcodes (no GAS, BLOCKHASH, BALANCE of external accounts beyond limited cases) and storage access is scoped per the ERC-7562 validation rules. Paymasters that violate the rules get throttled or banned by bundlers regardless of whether their deposit is funded.
​

Five providers handle the majority of paymaster traffic in 2026. The choice usually comes down to which bundler the app is already using, what chains it supports, and whether the app needs an ERC-20 mode in addition to sponsorship.
​

Pimlico runs both a bundler and a paymaster service with a single API surface. Its sponsorship paymaster supports a policy engine where apps configure rate limits, allowlists, and per-dapp spending caps in a dashboard. The ERC-20 paymaster supports USDC, USDT, DAI, and a handful of other stablecoins across Ethereum, Base, Arbitrum, Optimism, Polygon, BNB Chain, and several other EVM chains. Pimlico documents its endpoints at docs.pimlico.io.
​

Alchemy bundles its paymaster into its broader Account Kit SDK. Gas Manager is a sponsorship-only product with a policy dashboard, per-user spend limits, and integration with Alchemy's bundler. Coverage spans Ethereum, Base, Arbitrum, Optimism, Polygon, and Alchemy's other supported chains. Apps that already use Alchemy for RPC and indexing typically default to Gas Manager because it inherits the same API key and project setup.
​

Biconomy was one of the earliest paymaster providers and ships both sponsorship and ERC-20 modes. Its Modular Account stack (Biconomy Smart Account V2 + Nexus) integrates directly with the Biconomy Paymaster, with a SaaS dashboard for policy and gas-tank top-ups. Biconomy's paymaster also supports a "session" model where a user can prefund a session and spend gas from that allocation across multiple operations without re-signing.
​

ZeroDev pairs its Kernel smart account with the Ultra Relay paymaster and bundler combo. ZeroDev's distinguishing feature is tight session-key integration: a session key issued via ERC-7715 can be scoped to a sponsorship policy so the paymaster only pays gas while the session is valid and the user is acting within the policy's contract allowlist. See the related guide on ERC-7715 session keys for the permission model.
​

Coinbase Developer Platform offers a paymaster that integrates with Coinbase Smart Wallet and any ERC-4337 account on Base. CDP Paymaster is sponsorship-only, focused on Base, and ties into Coinbase's broader Onchain Kit so a dapp can drop in a "gasless on Base" button with a few lines of TypeScript. The pricing model is per-transaction with monthly free-tier credits.
​

The cost of sponsoring a user's gas depends on three variables: the chain, the type of operation, and the bundler markup on top of raw gas. The table below gives realistic 2026 ranges for a typical UserOperation that runs an ERC-20 transfer or a small contract call.
​

On L2s, where most consumer apps deploy in 2026, sponsoring a user's first ten operations typically costs the app under a dollar in total. That is competitive with the customer-acquisition cost of nearly any paid channel. On Ethereum mainnet, sponsorship is usually reserved for high-value flows like a one-time deposit into a yield vault, because covering an active user across dozens of swaps quickly exceeds the lifetime value of the relationship.
​

A realistic monthly budget calculation for a Base-native app with 10,000 monthly active users averaging twelve sponsored operations each lands around $1,200 to $9,600 per month, depending on operation complexity and bundler markup. That ratio is one of the reasons gas sponsorship adoption is concentrated on L2s and rarely seen on mainnet outside of high-ticket flows.
​

An open paymaster is a free vending machine for anyone who can craft a valid UserOperation. The same flexibility that makes sponsorship useful makes the contract a prime target. There are four common abuse patterns and a standard set of mitigations apps deploy.
​

A single attacker generates thousands of smart accounts and submits sponsored UserOperations from each. Without limits, this empties the paymaster's deposit in minutes. The standard mitigations: rate limit by source IP at the RPC layer, enforce per-account spending caps in the verifying paymaster's offchain signer, and require account creation to come from a passkey or social-login flow that introduces real-world friction.
​

An attacker submits an operation that succeeds in validation but reverts in postOp, forcing the paymaster to absorb gas without delivering any product value. Mitigations include verifying onchain that the operation's target call is on an app-controlled allowlist of contracts, so attackers cannot route the sponsored op into arbitrary calls that revert deliberately.
​

For ERC-20 paymasters, an attacker times operations against a price-oracle update so the postOp price quote favors the user by several percent. Mitigations: use Chainlink-grade oracles with short heartbeats, add a fixed markup (5 to 15 percent is typical) on top of the spot price, and cap the maximum operation gas the paymaster will sponsor in a single call so a single bad quote does not blow the budget.
​

If a paymaster's validatePaymasterUserOp reverts frequently during bundler simulation, ERC-7562 bundler reputation rules throttle the paymaster and eventually ban it from mempool propagation. The mitigation is operational: monitor revert rate in production, return validationData with a tight expiry so stale signatures fail clean, and make sure the offchain signer key is highly available so signatures get returned within the RPC deadline.
​

Most production paymasters layer all four mitigations and add a kill switch that lets the app pause sponsorship instantly if the dashboard detects an unusual spend curve.
​

Almost every app starts on a hosted verifying paymaster (Alchemy, Pimlico, Biconomy, ZeroDev, or CDP) because the operational overhead of running an offchain signer plus monitoring plus deposit management plus bundler-reputation tracking is substantial. Hosted paymasters take a small markup (typically 5 to 20 percent on top of gas) in exchange for handling all of that.
​

Reasons to deploy a custom paymaster contract include: enforcing onchain-only policy that the app does not want a third party to be able to override, supporting an ERC-20 the hosted providers do not list, or building a paymaster as a public good (a community-funded paymaster sponsoring a specific category of apps). Even custom paymasters usually run on top of a hosted bundler rather than self-hosted infrastructure, since bundler operations require their own deposit, monitoring, and mempool integration. The deeper picture of the full stack is covered in the account abstraction stack overview.
​

The most consequential paymaster use case in 2026 is not gaming or memecoin trading. It is stablecoin payments. A USDC sender on Base or Polygon paying a USDC recipient on Arbitrum should not need to hold ETH on either chain. With a paymaster, the sender's smart account pays a small USDC fee, the paymaster covers the ETH gas on both sides, and the user experience matches what they would expect from a fintech app rather than a DeFi protocol.
​

That flow is exactly what Eco Routes orchestrates underneath: a single-signature stablecoin transfer that abstracts gas, chain, and routing into one user action. Apps wiring up Eco Routes typically pair it with an ERC-20 paymaster so the user can pay all fees, including network gas, in the same stablecoin they are sending. The result is a payments experience that fits inside an app, not on top of a wallet, and that is what makes account abstraction worth shipping rather than just an ERC number.
​

ERC-4337 specification from eips.ethereum.org. EntryPoint canonical address from the eth-infinitism/account-abstraction GitHub repository. Validation rules from EIP-7562. Provider documentation from Pimlico, Alchemy Gas Manager, Biconomy, ZeroDev, and Coinbase Developer Platform. Gas cost ranges from public RPC gas trackers and L2 fee dashboards in mid-2026. Bundler reputation rules per the ERC-7562 published draft. Cost figures are illustrative ranges for typical UserOps and will move with chain conditions.
​