Gasless Transactions on Ethereum: How Paymasters Sponsor User Fees via ERC-4337
How ERC-4337 paymaster contracts enable gasless transactions where apps sponsor user fees, and the business models that make it sustainable.
Every Ethereum transaction requires gas, paid in ETH. For new users, this creates an immediate barrier: before doing anything on-chain, they must acquire ETH, understand gas fees, and approve a cost they cannot predict. Paymasters solve this by letting a smart contract pay gas on behalf of users, enabling what the industry calls gasless transactions. The user signs an intent; someone else covers the bill.
This mechanism is defined in ERC-4337, the account abstraction standard that introduced a new transaction pipeline for Ethereum. Paymasters are one of its most impactful components: they decouple who initiates a transaction from who pays for it. This article covers how paymasters work, what business models sustain them, which providers offer them, and the security risks they introduce.
What Is a Paymaster?
A paymaster is a smart contract that agrees to cover the gas costs for a user's operation. In ERC-4337, every transaction is represented as a UserOperation: a data structure containing the sender, calldata, gas limits, and an optional paymasterAndData field. When this field is populated, the EntryPoint contract charges gas to the paymaster's prefunded deposit rather than the user's account.
The EntryPoint is the singleton contract that processes all UserOperations. It is deployed at the same address across every EVM chain. The current production version is EntryPoint v0.7, live on Ethereum, Base, Arbitrum, Optimism, Polygon, and dozens more networks. Every paymaster must hold a deposit with this EntryPoint. When a sponsored operation executes, the EntryPoint debits the paymaster's deposit for the actual gas consumed plus a small overhead.
The Gasless Transaction Flow
A sponsored transaction moves through five stages, splitting responsibility between off-chain and on-chain components.
Step 1: UserOperation Construction
The user's smart wallet constructs a UserOperation containing the intended action (a token transfer, a swap, a contract call). The wallet sets the paymasterAndData field, which encodes the paymaster's address and any additional data it requires: typically a signature from the paymaster's backend authorizing the sponsorship, plus an expiry timestamp.
Step 2: Bundler Simulation
The signed UserOperation is sent to a bundler: an off-chain actor that collects, validates, and batches UserOperations. The bundler simulates the operation locally through the EntryPoint to confirm that both the smart account's validation and the paymaster's validation will pass. If simulation fails (the paymaster rejects, gas limits are insufficient, the signature is invalid), the bundler drops the operation before it reaches the chain.
Step 3: On-Chain Validation
The bundler submits a batch of UserOperations to the EntryPoint via handleOps. For each operation, the EntryPoint runs validation in two phases. First, it calls the smart account's validateUserOp function to check the signature and nonce. Then, if a paymaster is specified, it calls the paymaster's validatePaymasterUserOp function. The paymaster can accept (optionally returning context data for its post-execution hook) or reject by reverting. Validation runs under strict gas limits and restricted storage access to prevent one operation from interfering with others in the same bundle.
Step 4: Execution
Once validation passes, the EntryPoint calls the smart account to execute the intended action. Each operation is isolated: if one fails, the rest of the batch continues unaffected. This isolation is critical for bundlers, who need assurance that a single bad operation cannot grief an entire batch.
Step 5: Payment and Post-Op
After execution, the EntryPoint calls the paymaster's postOp function (if the paymaster provided context data during validation). The EntryPoint then debits the paymaster's deposit for the actual gas consumed and reimburses the bundler. The v0.7 EntryPoint also applies a 10% penalty charge on unused execution gas to discourage inflated gas limits.
Key point: The user never holds or spends ETH. From their perspective, the transaction is free. The paymaster absorbs the cost, and the bundler is made whole from the paymaster's deposit. This is what makes the experience “gasless.”
Types of Paymasters
Not all paymasters work the same way. The ERC-4337 standard defines the interface, but the logic inside validatePaymasterUserOp and postOp is entirely up to the implementer. Four patterns dominate production deployments.
| Type | How It Works | Use Case |
|---|---|---|
| Verifying | Checks an off-chain signature from the sponsor's backend authorizing the specific operation | Most common in production: apps request a sponsorship signature from their paymaster API before submitting |
| Token (ERC-20) | Accepts payment in an ERC-20 token (USDC, DAI) instead of ETH, converting at a posted exchange rate | Users still pay, but in a token they already hold: eliminates the need to acquire ETH |
| Deposit | Users pre-fund a balance with the paymaster, which draws from it for each operation | Enterprises and power users who want predictable billing |
| Sponsoring | Unconditionally covers gas for operations matching its policy rules | Onboarding flows, promotional campaigns, and dApps where the app absorbs all costs |
Most production gas sponsorship APIs use the verifying model. The on-chain contract is simple: it checks that the authorization signature is valid and the expiry has not passed. All policy logic (rate limits, allowlists, spending caps) lives off-chain in the provider's backend.
Paymaster Provider Comparison
Several infrastructure providers offer managed paymaster services, so teams do not need to deploy and fund their own contracts. The major providers as of 2026 are compared below.
| Provider | Sponsorship Model | ERC-20 Support | Chain Coverage | Notable Feature |
|---|---|---|---|---|
| Pimlico | Verifying paymaster with policy engine | Yes: major stablecoins | 90+ chains | Unified bundler and paymaster API with per-dApp spending caps |
| Alchemy | Gas Manager (sponsorship only) | No | Major EVM chains | Policy dashboard with per-user spend limits; integrated with Alchemy's bundler and RPC |
| Biconomy | Full-stack: accounts, bundler, and paymaster | Yes | Major EVM chains | Turnkey SDK that bundles smart account deployment with paymaster sponsorship |
| Circle | Gas Station: reimbursement billing | USDC-focused | Major EVM chains | Bills sponsor for gas plus a 5% processing fee; deeply integrated with USDC infrastructure |
| Coinbase CDP | $15/app/month free tier, then per-op billing | No | Base-focused | Tight integration with Base; $0.0001 per sponsored operation above the free tier |
The right choice depends on chain coverage, existing infrastructure, and whether you need ERC-20 gas payment. Teams already using Alchemy for RPC often default to its Gas Manager. Teams building across many chains lean toward Pimlico. Teams wanting an all-in-one SDK with minimal configuration choose Biconomy.
What Does Gas Sponsorship Actually Cost?
The cost a sponsor pays has two components: the underlying chain gas and the provider's markup.
Chain Gas: L1 vs L2
On Ethereum L1, a UserOperation costs roughly 10 to 20% more gas than an equivalent EOA transaction due to the overhead of the EntryPoint validation loop. A simple ERC-20 transfer via EOA uses approximately 65,000 gas. The same transfer through a smart account with paymaster sponsorship uses approximately 80,000 to 100,000 gas. At typical 2026 mainnet gas prices, that puts a sponsored transfer in the range of a few dollars during normal congestion and significantly more during gas wars.
On L2s like Base, Arbitrum, and Optimism, the economics shift dramatically. A simple USDC transfer costs roughly $0.01 to $0.05 in gas. A swap runs $0.10 to $0.50. A one-time smart account deployment costs $0.30 to $1.00. At these prices, sponsoring thousands of operations per day becomes a manageable line item for any growth-stage application.
L2 is where sponsorship makes economic sense: Most production paymaster deployments target L2 chains where the per-operation cost is low enough to absorb as a customer acquisition expense. L1 sponsorship is typically reserved for high-value operations where the transaction justifies the cost.
Provider Markup
On top of chain gas, providers charge a markup that varies by tier and vendor. Alchemy charges an 8% fee on Growth tier. Circle adds a 5% processing fee. Pimlico offers a free tier of up to 250,000 sponsored UserOperations per month, with paid plans starting at $99/month for higher volume. For ERC-20 paymasters that accept token payment, the typical markup over actual gas cost runs 5 to 15%.
Paymaster Business Models
Who pays, and why? Four sustainable models have emerged for applications that sponsor gas.
Sponsorship as Acquisition Cost
The most common model: the application treats gas sponsorship as a customer acquisition expense, similar to free trials or referral credits. The app sponsors the first N transactions for each new user, then either introduces fees or expects that engaged users generate revenue through other channels (trading fees, subscription upgrades, in-app purchases). This is standard practice for consumer crypto apps, gaming, and gasless onboarding flows.
Token Payment as Cost Recovery
ERC-20 paymasters let users pay gas in stablecoins or utility tokens. The user does not need ETH, but they do pay: the paymaster quotes a conversion rate, collects the token during postOp, and uses the proceeds to refill its ETH deposit. The markup covers exchange risk and operational costs. From the user's perspective, they pay a predictable fee in a token they understand rather than dealing with fluctuating gwei prices.
Selective Sponsorship
Rather than sponsoring all transactions, apps sponsor only specific high-value actions: the first swap, a bridge transaction, or a purchase. By matching gas spend to revenue events, the app ensures positive unit economics. The paymaster's off-chain policy engine controls which operations qualify based on contract address, function selector, or user tier.
Cross-Subsidy
Some protocols cross-subsidize gas costs from protocol revenue. A DEX might use a fraction of its trading fees to fund a paymaster that sponsors all user swaps. A stablecoin issuer might sponsor transfers of its own token as a competitive advantage. The fee abstraction appears free to the user but is funded by the protocol's existing revenue stream.
Security Risks and Mitigations
Paymasters introduce a new class of security concerns. Because a third party is paying for execution, attackers have incentives to exploit the gap between who initiates and who pays.
Paymaster Drain via Cheap Sponsorship
If a paymaster sponsors operations without sufficient constraints, an attacker can craft operations that consume maximum gas while accomplishing nothing useful: repeated back-and-forth token transfers, no-op contract calls, or operations that revert during execution (the paymaster still pays for gas consumed during successful validation). The mitigation is strict policy enforcement: per-user rate limits, per-period spending caps, operation allowlists, and graceful degradation as the deposit runs low.
Validation-Phase Griefing
A malicious actor can frontrun a bundle transaction, changing on-chain state so that multiple accounts' validation fails after the bundler has already submitted and paid for gas. The ERC-4337 specification mitigates this through a reputation system that tracks accounts, paymasters, and factory addresses. Entities that cause repeated validation failures are throttled or banned from the mempool.
initCode Front-Running
When a UserOperation includes initCode to deploy a new smart account, an attacker can front-run the deployment to a different address, causing the original operation to fail. This “denial of wallet” attack does not steal funds but wastes gas and blocks user onboarding. The standard mitigation is using CREATE2 with a salt derived from the user's signing key, so the deployment address is deterministic regardless of who deploys the contract.
Gas Estimation Manipulation
Paymasters rely on accurate gas estimation to size their deposits and set spending limits. Operations that consume different amounts of gas during simulation versus execution can cause paymasters to underestimate costs. The v0.7 EntryPoint's 10% penalty on unused execution gas helps here: it discourages overstated gas limits and makes estimation more predictable. Bundlers expose eth_estimateUserOperationGas as a dedicated RPC method for this purpose.
Audits are essential: Multiple security firms, including Trail of Bits and Osec, have published analyses of common paymaster vulnerabilities. Any team deploying a custom paymaster should treat it with the same rigor as a DeFi protocol: formal audits, bug bounties, and conservative deposit management.
EIP-7702 and the Future of Paymasters
The Pectra upgrade, which went live on Ethereum mainnet on May 7, 2025, introduced EIP-7702: a protocol-level change that lets EOAs temporarily delegate to smart contract code. This means existing Ethereum addresses can adopt smart account features (batching, gas sponsorship, session keys) without migrating funds to a new contract address.
EIP-7702 does not replace paymasters. A 7702-upgraded EOA still needs someone to pay for gas, and paymasters remain the standard mechanism for that. The two standards are complementary: EIP-7702 lowers the barrier to smart account adoption, and ERC-4337 paymasters provide the economic infrastructure for account abstraction to work in practice.
For a deeper look at how Pectra changes wallet design, see our full analysis. And for how session keys reduce the need for repeated paymaster interactions, see the session key payments guide.
Why Paymasters Exist: The Root UX Problem
The entire paymaster infrastructure exists to solve one problem: Ethereum requires users to hold ETH before they can do anything. This is a fundamental consequence of the account model and the gas fee mechanism. New users who receive a stablecoin transfer cannot spend it until they separately acquire ETH to pay gas. Users bridging from another chain arrive with tokens but no gas. Mobile users on a smart wallet should not need to understand gas mechanics at all.
Paymasters paper over this problem with infrastructure. They work, and they enable payment abstraction that is genuinely transformative for user experience. But they add a layer of smart contracts, off-chain services, deposit management, and security surface area that would not be necessary if fees were handled differently at the protocol level.
A Different Approach: Fees Without Gas Tokens
Not every Layer 2 requires this machinery. Spark, a Bitcoin Layer 2 built on statechains, takes a fundamentally different approach: there is no separate gas token. Fees are included directly in the payment itself, denominated in the asset being transferred. When a user sends Bitcoin or USDB on Spark, the fee is deducted from the transfer amount, similar to how traditional payment rails work.
This eliminates the UX problem that paymasters were built to solve. Users do not need to acquire a separate token to pay fees. There is no paymaster contract to audit, no deposit to manage, no bundler to coordinate with. The fee model is native to the protocol, not bolted on through additional infrastructure.
For developers exploring how to build on a system where fee abstraction is built in rather than retrofitted, the Spark SDK documentation covers integration patterns. And for users who want to experience gasless transfers today, General Bread is a Spark-powered wallet where sending Bitcoin and stablecoins never requires a separate gas token.
This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.