Ethereum Paymaster: Who Pays Gas?
The gas tank isn't empty — it's just been hijacked by a third party with a spreadsheet and a profit motive. When your transaction settles onchain but your ETH balance never moved, that's not a glitch. That's a paymaster eating the cost, and you need to understand exactly who's holding the bag before you trust a single casino deposit rail built on this stack.
The Core Mechanism: Gas Abstraction Without Hand-Waving
A paymaster is a smart contract that agrees to cover gas fees on behalf of a user, either by sponsoring the transaction outright or accepting an ERC-20 token as payment. Under ERC-4337, the EntryPoint contract validates a UserOperation, then calls the paymaster's validatePaymasterUserOp function. If that returns a valid signature and sufficient deposit in the EntryPoint's stake, the paymaster's balance gets debited after execution. Simple on paper. Brutal in practice when you're auditing live betting rails moving real money.
The paymaster must pre-fund its deposit with the EntryPoint. That deposit is the collateral. No deposit, no sponsorship, no transaction. This is where Ethereum Paymaster economics become a blood sport — every sponsored op is a liability the operator must price correctly or bleed out within hours.
Sponsoring Versus Token-Based: Two Very Different Risk Profiles
Sponsoring paymasters eat the full gas cost. They do this for onboarding, airdrop eligibility farming, or to keep high-roller casino flows frictionless. The operator pays, the user feels nothing. Token paymasters let users pay gas in USDC, USDT, or a native token, converting at an oracle-driven rate. The user still pays, just not in ETH.
Here's the gut punch: token paymasters carry oracle risk, slippage risk, and front-running exposure. If the oracle hiccups during a volatility spike, the paymaster can end up subsidizing gas it never agreed to cover. I've watched operators lose six figures in a single weekend because their oracle feed lagged by 90 seconds on a Sunday pump.
Who Actually Bears the Cost End-To-End
Trace the money. The user signs a UserOperation. The bundler picks it up, simulates it, and submits it. The EntryPoint debits the paymaster's deposit. The bundler gets reimbursed from that deposit plus a priority fee. The user either paid nothing (sponsored) or paid in an ERC-20 (token model). The paymaster eats the spread between what it charged and what gas actually cost.
That spread is where gas sponsorship models live or die. If your paymaster charges a flat 0.15 USDC per op and gas spikes to 0.40 USDC equivalent, you're underwater on every single transaction. Multiply that across 50,000 daily bets on a live dealer platform and you've got a hole no treasury can fill.
Bundler Economics And The Hidden Markup
Bundlers aren't charities. They simulate, bundle, and submit. They charge a markup on the effective gas price — typically 10% to 30% depending on mempool conditions and chain congestion. That markup flows back through the EntryPoint accounting and lands on the paymaster's deposit. If your paymaster contract doesn't account for bundler markup dynamically, you're pricing your sponsorship on stale numbers.
The nastiest edge case: a bundler submits a bundle where one op fails validation post-inclusion. The paymaster still gets debited for the gas consumed during the failed execution. You pay for failure. That's not a bug — that's the protocol design, and any operator running ERC-4337 paymaster infrastructure needs to model failed-op rates into their gas budget or face silent, relentless drain.
Stake Requirements And Withdrawal Locks
Paymasters must stake ETH with the EntryPoint. That stake is subject to a withdrawal delay — currently measured in blocks, not seconds. If a paymaster wants to exit, it signals intent, waits out the cooldown, then withdraws. During that window, it can still be slashed for misbehavior. For gambling operators, this means liquidity planning isn't optional. You can't yank your deposit mid-session when a whale decides to run 400 hands in an hour.
The deposit and the stake are separate. Deposit covers gas. Stake covers reputation. Blow through your deposit and your ops start failing. Get slashed on stake and you're locked out of the mempool entirely. Both balances need real-time monitoring with alerting thresholds that trigger before you hit zero.
Real-World Attack Surface For Casino Rails
Paymaster drain attacks are real. A malicious actor crafts UserOperations that pass validation but consume maximum gas during execution — griefing the paymaster into insolvency. Simulation helps, but simulation isn't execution. State can change between the two. The gap between simulated gas and actual gas is where attackers operate.
Rate limiting per sender, per session, and per IP is mandatory. So is a maximum gas cap per op. If your paymaster doesn't enforce a hard ceiling on gas per UserOperation, you're handing attackers a blank check drawn on your deposit. I've audited setups where a single crafted op consumed 2.3 million gas because nobody set a cap. That's not a vulnerability — that's negligence with a smart contract wrapper.
Dynamic fee adjustment is the other non-negotiable. Static pricing in a variable gas environment is suicide. Your paymaster needs to read base fee, priority fee, and bundler markup in real time, then adjust what it charges the user or absorbs as sponsorship cost. Anything less and you're running a charity, not a business.