What is a paymaster and how gas sponsorship works (ERC-4337 and EIP-7702)
What a paymaster is, how ERC-4337 and EIP-7702 solve gas differently, and why the second one spares your users from switching wallets.
What is a paymaster
A paymaster is the component that pays the network fee on behalf of whoever signs a transaction. The term comes from Ethereum's account abstraction work, but it addresses a problem every Web3 product knows: to do anything on-chain, a user must hold the network's native coin — ETH on Ethereum, BNB on BNB Chain, POL on Polygon. Newcomers do not have it, and often do not understand why they would need it.
A paymaster inverts that. The user signs the intent; someone else covers the cost. Be precise about what this means: the gas does not disappear. The network still charges it and someone still pays — the sponsor. What changes is who pays, and when.
The problem, in the right order
Two things get conflated here.
The first is cost. On a network like BNB Chain or Polygon, a token transfer costs cents. For most products, the cost of gas was never the real obstacle.
The second is acquisition. To pay those cents, the user has to buy the native coin somewhere, pass identity verification, withdraw to a wallet and pick the right network. That is five steps before step one. Conversion dies there — not at the price, but at the path.
A paymaster solves the second problem, not the first. The sponsor absorbs a cost that was already small and removes a path that was expensive in abandonment.
ERC-4337: the original design
ERC-4337 introduced account abstraction without changing Ethereum's protocol. Instead of ordinary transactions, the user emits a UserOperation, a structure describing what they want to do and who pays for it.
Four roles are involved:
- Smart Account — the user's account stops being a key and becomes a contract that can define its own validation rules.
- Bundler — batches UserOperations and submits them as a normal transaction.
- EntryPoint — the singleton contract that validates and executes each operation in the batch.
- Paymaster — the contract that commits to paying. It implements `validatePaymasterUserOp`, where it decides whether to fund that operation, and `postOp`, called after execution to settle up.
To operate, a paymaster must keep a deposit and a stake in the EntryPoint — the economic guarantee that it will not accept operations and leave the bundler holding the bill. The reference implementation lives in eth-infinitism's account-abstraction repository.
The design is powerful and enables things a plain account cannot do: social recovery, spending limits, multiple signers, sessions. It carries one unavoidable requirement, though: the user needs a smart account. Someone who already has a wallet must create another account, at another address, and move funds there. For a product trying to reduce friction, that migration is new friction.
EIP-7702: the plain account gets superpowers
EIP-7702 addresses exactly that. It defines a new transaction type carrying an authorization list: with it, a plain account (EOA) points at a contract and starts behaving like it, keeping the same address and the same key.
In practice the account's code becomes a small delegation indicator pointing to the chosen contract. Every call to that account runs the delegated contract's logic. The authorization is signed by the account owner, and can be revoked.
The product consequence is direct: the user does not switch wallets. The address they already shared keeps working, their history stays where it is, the wallet they already use keeps working — and they still gain the ability to transact without holding the native coin.
Comparing the two
| ERC-4337 | EIP-7702 | |
|---|---|---|
| User account | a new smart account | the same EOA they already have |
| Address | changes | preserved |
| Migration | required | none |
| Infrastructure | bundler + EntryPoint + paymaster | delegated contract + sponsor |
| Strength | very rich account rules | frictionless adoption |
They are not mutually exclusive: an account delegated via 7702 can take part in a 4337 flow. The choice is product engineering, and it depends on where your friction is. If the core value is social recovery and signing policy, 4337 gives you more. If the core value is asking nothing of the user, 7702 gives you more.
That is why VKX Gas uses the EIP-7702 model: the service exists to remove the gas step, and it would be contradictory to remove it while charging a wallet migration in exchange.
How sponsorship works in practice
The model is prepaid. You keep a native-currency deposit, and a single deposit covers the EVM networks served — today BSC, Polygon, Base, Arbitrum and Ethereum. When your user is about to act, your backend requests the sponsorship, VKX returns the signed data, the user signs their own operation and the transaction goes through. You are charged from your balance for the real gas consumed, and part comes back as cashback credit applied to later transactions.
npm install @vkx/gasThe integration lives on your server, because that is where your key belongs. The gas dashboard shows balance, per-network consumption and history.
Advantages and limitations
What gas sponsorship delivers:
- It removes the native-coin prerequisite, the single largest cause of abandonment in on-chain flows for non-technical audiences.
- It preserves self-custody: the user still signs. Sponsoring gas is not custodying funds.
- It makes cost predictable for you — gas becomes an acquisition cost line, not a product obstacle.
What it does not deliver, and this deserves to be said plainly:
- It is not free. The cost exists and it is yours. On low-cost networks that is trivial; on Ethereum during congestion it is not — measure before sponsoring everything.
- It does not prevent abuse by itself. If anyone can trigger sponsored operations, someone will. Limits per user, per operation and per time window are part of the design, not optional extras.
- It does not replace the native coin in every case. Operations that depend on native value (sending ETH, for instance) still require a balance.
When it makes sense
It makes sense when "you need gas" is the sentence that makes your user quit. That shows up in NFT mints and in-game items, in loyalty reward redemption, in stablecoin payments, and in any onboarding whose first user action is on-chain.
It does not make sense when your audience already operates on-chain comfortably and already keeps a native balance. There, sponsorship solves a problem they do not have.
FAQ
Is a paymaster the same as a custodial wallet? No. Custody means someone else holds the user's key. In gas sponsorship the key stays exclusively with the user — the sponsor pays the fee, it does not sign on their behalf.
Does the user notice the sponsorship? They notice the transaction went through without asking for a native balance. Nothing else changes.
Do I need one deposit per network? No. A single native-currency deposit covers the EVM networks served.
Does EIP-7702 work on any network? It works on networks that adopted the specification. The current list of served networks is on the product page.
How is it priced? You pay the real gas consumed, with no markup, and part returns as credit. On networks like BNB Chain that means cents per transaction.
Next step
If gas is what stands between your user and their first action, see how to implement sponsorship or talk to engineering through the VKX Gas page.
Disclaimer: this content is informational and educational and does not constitute investment advice.