Ethereum Paymaster: Who Pays Gas?
Every transaction on Ethereum burns gas, and someone has to foot the bill. The Ethereum Paymaster flips the entire model on its head by letting a third party absorb that cost. No more forcing users to hold ETH just to move a token or claim a reward. The paymaster contract signs off on the gas, and the user walks away with a zero-balance wallet. That is the raw mechanic, and it changes everything about onboarding.
The Core Architecture: ERC-4337 and the EntryPoint
Paymasters do not exist in a vacuum. They operate inside the ERC-4337 account abstraction framework, where a central EntryPoint contract orchestrates the flow. A user submits a UserOperation, a bundler picks it up, and the EntryPoint calls the paymaster's validatePaymasterUserOp function before execution. If the paymaster approves, it deposits ETH into the EntryPoint to cover the gas. If it rejects, the operation dies on the spot. The gas sponsorship model is binary: either the paymaster stakes collateral or it does not. There is no middle ground, and any developer who thinks otherwise is begging for a reverted transaction.
Who Actually Signs the Check?
The paymaster is not a charity. Three models dominate the landscape. First, the dApp itself acts as the paymaster, subsidizing user gas to drive adoption. Second, a token paymaster accepts ERC-20 tokens as payment and swaps them for ETH behind the scenes, so the user never touches native gas. Third, a verifying paymaster uses off-chain signatures to authorize sponsorship, which is where things get spicy. The off-chain signer holds the keys, and if that signer gets compromised, the paymaster's deposit drains faster than a broken faucet. 🎯 The gasless transaction experience is only as secure as the signature verification logic, and most implementations cut corners on replay protection.
Stake, Deposit, and the Slashing Risk
Paymasters must deposit ETH into the EntryPoint to cover gas, and they must also stake ETH as collateral. That stake is not decorative. If a paymaster behaves maliciously or fails to validate properly, the EntryPoint can slash the stake. A bundler that includes a bad UserOperation also faces penalties, which creates a bizarre incentive layer where bundlers scrutinize paymaster behavior more aggressively than any auditor. The deposit covers execution; the stake covers trust. Confuse the two and your paymaster gets drained or slashed within the first hundred operations. 💸
The Token Paymaster Trap
Token paymasters sound elegant until you hit the oracle problem. The contract needs to price the ERC-20 against ETH in real time, and if the oracle lags or gets manipulated, the paymaster either overcharges users or bleeds value on every transaction. Most production token paymasters use a fixed exchange rate with a buffer, which is a bandage, not a fix. The real solution is a TWAP oracle with a circuit breaker, but that adds gas overhead to every single operation. Developers who skip the breaker are running a subsidized arbitrage machine for MEV bots. 🛡️
PostOp and the Unchecked Refund Path
The postOp function is where paymasters handle refunds and accounting after execution. This is the most under-tested surface in the entire ERC-4337 stack. A paymaster that miscalculates the actual gas used in postOp either overpays or under-refunds, and both outcomes compound across thousands of operations. The EntryPoint calls postOp with the actual gas cost, and if the paymaster's internal accounting drifts from the EntryPoint's calculation, the deposit depletes silently. No revert, no alarm, just a slow bleed until the paymaster can no longer sponsor anything. The only defense is a strict invariant check inside postOp that reverts on any deviation beyond a tight tolerance.
Who Pays When the Paymaster Fails?
The bundler eats the loss. If a paymaster's validatePaymasterUserOp returns success but the postOp reverts, the EntryPoint still charges the paymaster's deposit for the gas consumed up to that point. The bundler gets reimbursed from the deposit, and the user's operation may or may not execute depending on where the failure occurred. This asymmetry means paymasters carry the validation risk while bundlers carry the inclusion risk. Any team deploying a paymaster without a full simulation of the postOp revert path is gambling with their deposit, and the house always wins.