Paymaster Types
Explore different Paymaster patterns in ERC-4337, from whitelists to token gas payments.
Paymasters in ERC-4337 can be implemented in various ways depending on how gas is sponsored and what validation logic is required. Below are the most common patterns.
✅ Whitelist Paymaster
Simplest model. The Paymaster maintains a list of allowed users or operations.
Use case: Free gas for early users, partners, or test campaigns.
How it works:
Checks the sender address or calldata
Accepts or reverts in
validatePaymasterUserOpOptionally restricts frequency or nonce range
🔐 Verifying Paymaster (Off-Chain Signed)
Requires an off-chain component to approve each transaction.
Use case: Controlled sponsorship via API, rate limits, user-specific logic
How it works:
User gets a signed message from a backend
paymasterAndDataincludes the signature and metadataContract verifies the signature before approving sponsorship
This model is extensible and secure — popular in production wallets.
💰 ERC-20 Paymaster (Token-Paying)
Lets users pay for gas in an ERC-20 token, which the Paymaster converts to ETH.
Use case: Gasless UX for apps where users hold tokens but no ETH
How it works:
Contract checks token balance or transfer approval
Performs a token-to-ETH swap off-chain or via internal pool
Uses ETH deposit in EntryPoint to cover the gas
Caution: swaps can be complex and require slippage/timing protection.
🧩 Hybrid and Custom Patterns
Quota-based Paymasters: Allow N txs per user/day
Multi-condition checks: Combine whitelist + signatures
Action-specific Paymasters: Only subsidize known
callData
The Paymaster model is extremely flexible. The key constraint is ensuring validatePaymasterUserOp() remains safe, bounded, and deterministic.
✅ Summary
Paymasters enable powerful UX flows, from gasless onboarding to pay-in-token systems. Choose a pattern based on your app’s risk tolerance, business model, and infrastructure capabilities.
Last updated