Ethereum Paymaster: Who Pays Gas?
The paymaster contract holds the ETH, and the user's transaction never touches their own balance — that is the entire mechanical truth of account abstraction in one sentence. If you are still signing transactions that drain your own wallet for gas, you are running a stone-age setup while everyone else routes value through a paymaster that eats the fee on your behalf. Let me break down exactly who bleeds the cost and why it matters for anyone moving serious volume.
Who Actually Foots the Bill
In an ERC-4337 flow, the smart account sends a UserOperation to a bundler. That bundler simulates the op, checks the paymaster's deposit in the EntryPoint contract, and if the deposit covers the max fee, the paymaster signs off. When the op lands on-chain, the EntryPoint deducts gas from the paymaster's staked balance — not the user's. The end user pays zero ETH. The sponsor pays in ETH or in the project's own token, and the accounting happens inside the EntryPoint's deposit ledger.
So the real answer to "who pays gas" is: whoever funded that paymaster's deposit. That could be a dApp subsidizing onboarding, a game studio covering in-game mints, or a relayer network charging a markup off-chain. The chain only sees the EntryPoint and the staked balance. Everything else is a side deal.
The Three Paymaster Models That Matter
Deposit-based paymasters pre-fund the EntryPoint and let users transact until the balance runs dry. This is the cleanest model for high-frequency gaming actions where you cannot afford a signature prompt every five seconds. The risk: a single deposit drain event wipes your entire user base's ability to transact. I have watched projects get rugged by their own paymaster balance hitting zero mid-session.
Token paymasters accept ERC-20 tokens as payment and swap them to ETH inside the validation phase. The user pays in USDC or your project token, the paymaster handles the conversion, and the EntryPoint still gets its ETH. The catch is oracle latency — if the token price moves between simulation and execution, the paymaster eats the spread or the op reverts. Verifying paymasters are the third breed: they gate sponsorship behind off-chain signatures, so only whitelisted users or NFT holders get free gas. That signature check is where most bugs hide, and it is where I have seen the most exploits drain paymaster deposits in a single block.
Where the Gas Money Actually Leaks
Bundlers front the ETH to get the op included, then get reimbursed from the paymaster deposit. If the paymaster's validation function is sloppy, a malicious user can craft an op that passes simulation but reverts on-chain — the bundler still gets paid, the paymaster still gets charged, and the user walks away clean. That is a direct drain on whoever funded the deposit. Precision in the validatePaymasterUserOp function is not optional; it is the difference between a working subsidy and an open faucet for attackers.
The staked deposit also has a cooldown. If your paymaster is unstaked and the deposit hits zero, every pending UserOperation fails at the bundler level and your users are stuck. There is no graceful degradation — the EntryPoint simply rejects the op and the bundler drops it. Projects that treat paymaster funding as a set-and-forget line item are one traffic spike away from a total outage.
Sponsorship Is a Business Decision, Not a Technical One
The contract mechanics tell you how gas gets paid, but the strategic question is who you choose to subsidize and for how long. A paymaster that sponsors every op is a paymaster that goes broke. The sharp operators set per-user caps, time windows, and token-gated access so the deposit serves acquisition and retention instead of random freeloaders. The EntryPoint does not enforce your business logic — you do, inside the validation function, and that is where the real engineering discipline lives. 💰