Paymaster

A paymaster is an ERC-4337 contract that pays gas on a user's behalf — the mechanism behind gasless transactions, fees paid in any token, and dApps that sponsor their users' onboarding. You sign the intent; the paymaster settles the bill under programmable rules; the wallet never needs "ETH for gas first." How it works Inside the ERC-4337 flow, a user operation references a paymaster alongside the wallet's validator: Validation: the EntryPoint calls the paymaster's validatePaymasterUserOp, which checks the sponsorship policy — is this wallet allowed? spending cap? token accepted? — and returns an acceptable price in context. Payment: the paymaster fronts the ETH for the user operation from funds deposited into the EntryPoint; it can then pull payment back in ERC-20s, apply per-user limits, or subsidize fully. Post-op: postOp runs after the operation, letting the paymaster reconcile refunds, off-chain settlement marks, or per-use allowances. Fee capture: a verifying or sponsor paymaster can charge a small surcharge baked into the operation — that is how "free UX" gets funded without breaking the trustless settlement. Bundlers include the sponsored operation like any other; the paymaster's deposit covers it, and the EntryPoint enforces the payment, so a paymaster cannot silently skip paying. Why it matters for decentralization Paymasters remove crypto's cruelest UX tax — "buy ETH before you can use anything" — without reintroducing custodians. Policy is code, and code is verifiable on-chain: the sponsorship contract, its allowlist, and its limits are queryable by anyone, which is strictly better than a corporate backend deciding who gets helped. The watch-point is dependence. If one paymaster subsidizes an entire ecosystem, that entity's policy choices (and outages) become choke points equivalent to a gatekeeper. This is the classic pillar test from the four-pillar model: the software that decides who transacts is part of the infrastructure layer, and it decentralizes only when many independent paymasters compete for the same user flow. Example: sponsor-gas onboarding on a real chain Pick a consumer on-ramp on Base or Polygon: a new user opens the app, connects a fresh smart wallet, performs a swap — and sees no gas prompt at all. Behind the scenes the dApp's paymaster fronted the ETH, capped per-wallet, and the app billed itself in the token it prefers. This is the pattern behind Coinbase's Smart Wallet early access and the widespread "free first transactions" offerings from wallet infra providers. The cost model is transparent in the contract: deposit + collateral + postOp, all auditable. Risks & limitations Sponsorship abuse: subsidy-bot drains and policy loopholes require careful cap design; an unbounded "sponsor everything" policy is a money printer for attackers. Paymaster centralization: if one provider wins every app's sponsorship contract, its policy engine silently becomes the network's gatekeeper. Policy bugs: a mistake in validation can lock users out or let an operation through the paymaster's restrictions — on-chain code being "verifiable" is exactly why it must be audited. Obscured true cost: "free" gas is rarely free; fees hide inside token prices or allowances, and users who believe otherwise are making decisions on bad information. The EntryPoint's accounting discipline is what keeps paymaster-funded flows honest. Every user operation that references a paymaster has the paymaster's deposit debited before execution, and the gas refund from a successful operation is routed so the paymaster is never left holding others' debt. Practically, there are three paymaster flavors worth distinguishing: Verifying paymaster — only approves; the wallet still pays gateway fees and the paymaster just verifies policy and signs off. Sponsor paymaster — fronts the ETH entirely; the classic "gasless onboarding" pattern, with deposit accounting in the EntryPoint and the sponsor pulling fees back in the token of its choice. ERC-20-wrapped paymaster — accepts fee payment in an arbitrary token, converting at a quoted or oracle-designated rate; the pattern behind "pay fees in USDC" experiences. The middle layer between wallets and paymasters is also standardizing. ERC-7677 describes a paymaster RPC so wallets can discover and bind to a sponsored flow transparently, and infrastructure providers (Stackup, Pimlico, Alchemy, Biconomy) ship paymaster APIs with per-app key policies. For an auditor, the three things to check are: the valuation feed (is the token price oracle gameable?), the refund ordering in postOp (can a batch trick the paymaster into over-refunding?), and the allowlist's breadth (does the policy provide what the UX promised?). How a sponsored onboarding is wired up end-to-end For a dApp builder, standing up gasless UX today is a standard sequence: Deploy a sponsor paymaster contract with an allowlist (which wallets/signers are sponsored) and a spend cap per wallet. Deposit ETH into the EntryPoint's paymaster bucket so there is always prefund cover. Configure the wallet SDK with the paymaster's address; the SDK references it during user-operation construction. Point each app flow at the right policy (onboarding = one sponsored swap; recurring = session-limited sponsorship). Watch the deposit bucket: when balances run low, sponsored transactions stop being included — a paymaster outage, not a chain outage, is what users will notice. The ever-present trap is fee estimation for ERC-20-based paymasters: the conversion happens at submission, so an oracle lag between quote and execution can expose the paymaster to arbitrage. Audited provider policies (Pimlico, Stackup, Alchemy) now price in submission-time freshness, but self-hosted paymasters routinely skip this — it is the first thing an independent security review should probe. Frequently asked questions Is "gasless" really free? No — someone always pays: the app, a sponsor, or you in another token. "Gasless" means invisible to the user, not absent from the ledger. Read the paymaster's policy to see who foots which bill. Do I trust the paymaster with my funds? With your transaction flow, partially — it can refuse service or decline your operation, but in standard designs it cannot steal your assets. Verify its policy code like any contract you interact with. Paymaster vs relayer — same thing? Same idea, new standard: paymasters are the ERC-4337-native, permissionless version of the old meta-transaction relayers. Anyone can write and operate one without a license. Sources & methodology ERC-4337 spec — paymaster interface and EntryPoint rules. erc4337.io — ecosystem dashboard on live paymasters and bundlers. W3D methodology + academy dataset. Related terms ERC-4337 · Account abstraction · Bundler · Session keys · Gas Chain audits: Base · Ethereum · tool: Address checker