Gasless Transactions With ERC-4337 Paymasters: What They Cost and How They Get Drained

An ERC-4337 paymaster is a smart contract that pays the network fee for your users, so they can use your Web3 app without buying ETH first. That's gas sponsorship. Wahib Rizwan on our team has built a verifying paymaster with its own signing backend for gasless transactions, and the contract is the easy bit. The hard parts are cost and abuse.

Sponsorship matters because of one screen: "you need ETH to pay for gas". Many new users leave right there. They came to use your product, not to buy a cryptocurrency on an exchange first.

This guide covers how sponsorship works, what it really costs, how paymasters get drained and the rules we'd put in place before switching one on. Our wallet and Web3 integration service adds gasless transactions to products that already exist, without a rebuild.

How an ERC-4337 paymaster sponsors a transaction

ERC-4337 adds account abstraction to Ethereum without changing the core protocol. Instead of a normal transaction, the user's smart account produces a UserOperation: a description of what it wants to do.

1. Your app builds the UserOperation and, for a sponsored one, asks your paymaster to agree to pay.
2. A bundler collects UserOperations and submits them in one transaction to the EntryPoint, a shared contract that runs them.
3. The EntryPoint asks your paymaster contract to confirm (validatePaymasterUserOp), runs the user's action, then lets the paymaster settle up afterwards (postOp).
4. The gas is paid from your paymaster's deposit, held in the EntryPoint.

That deposit is real money you top up, and every sponsored action draws it down.

Two common kinds of paymaster

• Verifying paymaster. Your backend signs each UserOperation it's willing to pay for, and the contract checks the signature. You decide off-chain who gets sponsored. This is the most common choice for onboarding.
• ERC-20 paymaster. The user pays the fee in a token, such as a stablecoin, and the paymaster pays the network in ETH. The user still pays, just not in ETH.

Where EIP-7702 fits

Since Ethereum's Pectra upgrade on 7 May 2025, EIP-7702 lets an ordinary wallet address (an EOA) delegate to smart account code without moving to a new address. The two standards work together: a 7702-upgraded wallet can still use ERC-4337 bundlers and paymasters, and EntryPoint v0.8 added native support for it.

So sponsorship isn't only for users who create a brand-new smart account in your app. Existing wallets can use it too.

What gas sponsorship really costs

There's no single price. Gas prices change by the minute and differ hugely between Ethereum mainnet and Layer 2 networks. But the parts are predictable:

1. The user's action itself, at the network's gas price.
2. The overhead of account abstraction. A basic ERC-4337 operation uses roughly 42,000 gas, against 21,000 for a plain transfer, according to Vitalik Buterin's account abstraction roadmap notes. Smart account verification, the paymaster's checks and the bundler's costs are all extra work.
3. On Layer 2 networks, the data fee for posting the transaction to Ethereum.
4. A service margin, if you use a hosted bundler or paymaster service instead of running your own.

Estimate cost per action on your target network from real test transactions, not a calculator. Multiply by your expected number of sponsored actions per user, then put a hard cap on both.

On mainnet, sponsoring every action can get expensive quickly. On most Layer 2 networks it's cheap enough to sponsor onboarding and the first few actions, which is where it matters.

How paymasters get drained

A paymaster is a pot of money with a public address, and people will try to empty it.

1. Free-gas farming

If your backend signs anything for anyone, bots will create thousands of accounts and spend your deposit on their own transactions. This is the most common and least technical attack.

2. The unused-gas penalty

The ERC-4337 specification charges a 10% penalty on unused gas above a threshold, to stop operations reserving gas they don't use. A December 2025 analysis by the security firm OtterSec showed how this can hurt paymasters: an attacker sets an inflated gas limit, the penalty is charged to the paymaster's deposit and paid to the bundler. If the paymaster's cost calculation ignores the penalty, it loses money on every such operation.

3. `postOp` griefing

Paymasters that charge users after execution, for example by collecting ERC-20 tokens in postOp, can be tricked. The same analysis describes an operation that passes simulation with a token approval in place, then has the approval revoked before execution. The charge fails, but the EntryPoint still pays the bundler from the paymaster's deposit.

4. Upgrades that change the rules

EntryPoint versions behave differently. OtterSec notes that a post-execution charging pattern that worked in v0.6 can lose funds in v0.7, so any EntryPoint upgrade needs a fresh review of the paymaster's assumptions.

Rules to put in place before you sponsor anything

For a verifying paymaster, most of the protection lives in the backend that decides what to sign:

1. Only sponsor your own contracts. Check the target contract and function in the UserOperation before signing. Never sponsor arbitrary calls.
2. Cap everything. Per-user limits per day, a total daily budget, and a maximum gas per operation.
3. Tie sponsorship to a real user. A signed-in account (for example with passkey authentication), a verified email or another signal that costs a bot something.
4. Use short expiry times. Set validUntil on every signature so approvals can't be saved and replayed later.
5. Include the penalty in your cost maths, and keep gas limits realistic rather than generous.
6. For ERC-20 paymasters, charge before execution, with a refund afterwards, rather than collecting in postOp.
7. Monitor the deposit. Alert when it drops faster than expected, and keep only a few days' budget in it.
8. Review on every EntryPoint upgrade.

If your paymaster reads its own storage, reads other contracts' storage that isn't tied to the user's account, or returns a context so it can run postOp, the related ERC-7562 rules require it to stake in the EntryPoint so bundlers will accept its operations. The stake isn't spent, but it's locked, so plan for it.

Build your own paymaster or use a service?

Hosted paymaster services handle the bundler, deposits and much of the policy work, and they're the fastest way to test whether sponsorship helps your product. Building your own verifying paymaster gives you full control of the rules and avoids a service margin, but you own the smart contract, its security review and the monitoring.

Start with a service, measure how much sponsorship actually improves sign-ups, and build your own only when volume justifies it. If you're planning the wider product, our guide to scoping a software project helps you decide what belongs in the first version.

Frequently asked questions

The bottom line

Gas sponsorship takes the "buy ETH first" step out of Web3 onboarding. Treat the paymaster like a bank account with a public address: sponsor only what you mean to, cap every limit and watch the balance. The contract is the easy part. The policy around it is what keeps it solvent.

Adding gasless onboarding to your product? Book a free consultation and we'll help you estimate the costs and set the limits before you switch it on.

Sources

• ERC-4337: Account Abstraction Using Alt Mempool: https://eips.ethereum.org/EIPS/eip-4337
• ERC-7562: Account Abstraction Validation Scope Rules: https://eips.ethereum.org/EIPS/eip-7562
• EIP-7702: Set Code for EOAs: https://eips.ethereum.org/EIPS/eip-7702
• ERC-4337 team, EntryPoint v0.8 released: https://erc4337.substack.com/p/entrypoint-v08-released
• Vitalik Buterin, The road to account abstraction: https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap
• OtterSec, ERC-4337 paymasters: better UX, hidden risks (December 2025): https://osec.io/blog/2025-12-02-paymasters-evm