Ethereum Paymaster Gas: Who Pays?
Gas abstraction is a beautiful lie until you audit the payer ledger — and that is exactly where 90% of paymaster integrations bleed out. The Ethereum Paymaster Gas model flips the script: a third-party contract sponsors the gas, the user signs a UserOperation, and the bundler submits it to the EntryPoint. Sounds clean. In production, it is a financial knife fight over who eats the cost when the sponsorship logic misfires.
The Paymaster Deposit Is the Real Bottleneck
Every paymaster stakes ETH into the EntryPoint contract to cover sponsored transactions. That deposit is not decoration — it is collateral against execution risk. If your verification logic is sloppy, the EntryPoint will drain your deposit faster than a rigged slot machine drains a tourist. I have seen paymaster contracts get bricked in under 400 UserOperations because the team never modeled the postOp gas overhead. The Ethereum Paymaster Gas accounting includes the verification gas limit, call gas limit, and pre/postOp overhead — miss one and your sponsor balance evaporates.
Who Actually Foots the Bill
Three parties can end up paying, and the contract decides which one. First, the paymaster's deposit — the sponsor eats it. Second, the bundler — if the paymaster's validation reverts, the bundler can be penalized and passes that loss upstream. Third, the user — if the paymaster only partially sponsors, the smart account must hold a fallback balance or the op fails outright. The gas sponsorship flow is not charity; it is a credit system with liquidation risk baked into every op. 😤 Most teams discover this after their first mainnet revert storm.
Verifying Gas Limits Before You Sponsor
The EntryPoint enforces strict gas limit checks during simulation. If your paymaster's validatePaymasterUserOp under-reports the gas needed for postOp, the bundler rejects the op — or worse, it executes and the paymaster deposit gets slashed. Run a dry-run simulation against the exact EntryPoint version you deploy. Ethereum Paymaster Gas limits must be padded, not guessed. I pad verification by 15% and postOp by 25% on volatile chains; anything tighter is gambling with someone else's deposit. 🎯
Sponsorship Policy Is a Smart Contract, Not a Spreadsheet
Allowlists, rate limits, and per-user caps belong in the paymaster's validation logic, not in an off-chain cron job. If your sponsorship policy lives in a database, a race condition will double-sponsor the same account in the same block. Encode the cap on-chain, revert early, and emit an event for every sponsored op. That event log is your only forensic trail when the deposit goes missing. The Ethereum Paymaster Gas bill always comes due — the only question is whether your validation layer catches it at simulation or at settlement.