Choose a paymaster model
Selecting the right ERC-4337 paymaster architecture depends on balancing user convenience, security overhead, and your specific business model. The paymaster contract covers gas costs, but the logic it uses to validate and fund those transactions varies significantly.
Three primary models dominate the ecosystem: Sponsorship, ERC-20, and Verifying. Each serves a different UX goal, from removing friction entirely to charging users in their preferred token.
Compare paymaster models
The table below outlines the core differences between the three standard paymaster implementations.
| Model | Gas Paid In | Security Risk | Best Use Case |
|---|---|---|---|
| Sponsorship | ETH (Platform) | Low | Onboarding new users |
| ERC-20 | User Token | Medium | Token-specific dApps |
| Verifying | ETH (User) | High | Complex conditional logic |
Sponsorship model
The Sponsorship model is the simplest way to offer gasless transactions. The platform pre-funds the paymaster with ETH and covers all user operation costs. This removes the need for the user to hold native gas tokens, which is critical for onboarding.
Security is relatively low because the paymaster does not need to validate complex user data. It simply pays for execution. However, this model requires the platform to manage gas budgets and monitor for abuse.
ERC-20 model
In the ERC-20 model, users pay gas fees using a specific ERC-20 token, such as USDC or the dApp's native token. The paymaster swaps this token for ETH to pay the bundler. This aligns incentives by allowing users to spend their existing holdings rather than acquiring ETH first.
Security risks are medium. The paymaster must verify that the user has approved the necessary token spend and that the swap rate is fair. This requires careful integration with decentralized exchanges.
Verifying model
The Verifying model allows the paymaster to attach custom validation logic to the user operation. The paymaster only pays for gas if the user meets specific criteria, such as holding a certain NFT or completing a KYC step. This is the most flexible but also the most complex to implement.
Security is high because the paymaster can reject malicious or invalid operations before they are executed. However, this adds computational overhead and requires rigorous testing to avoid vulnerabilities.
As an Amazon Associate, we may earn from qualifying purchases.
Estimate sponsorship costs
Before launching a gasless experience, you need to know the burn rate. A paymaster under ERC-4337 covers gas costs from your prefunded deposit in the EntryPoint contract 1. If you underestimate this, your users will face failed transactions when the balance runs dry; if you overestimate, you waste capital that could fund user acquisition.
The total monthly cost is a function of three variables: active users, transaction frequency, and the prevailing gas price on your target chain. Since gas prices fluctuate, it is wise to model your budget using a conservative average rather than a peak estimate.
Use the calculator below to project your monthly sponsorship budget. Adjust the inputs to match your expected user base and transaction volume.
Cost structure breakdown
Understanding where the money goes helps you optimize your paymaster logic. The cost is not just the base gas; it includes the complexity of the user operation and any priority fees paid to bundlers.
Implement the Smart Account Flow
Integrating a paymaster requires connecting your smart account to the EntryPoint contract. This flow handles two distinct phases: validation, where the paymaster checks if it will pay for the transaction, and execution, where the contract actually performs the user's requested action. If validation fails, the EntryPoint reverts the entire operation, protecting users from invalid or malicious calls.
Prefund the Paymaster
Before processing any transactions, the paymaster contract must hold a sufficient deposit of native gas tokens (like ETH) in the EntryPoint contract. The EntryPoint locks these funds and deducts gas costs from this balance as operations are executed. If the balance drops below a safety threshold, the EntryPoint rejects new operations until you refuel the contract.
Handle Validation
When a user submits a user operation (UserOp), the EntryPoint calls the validateUserOp function in your paymaster. This is the critical security checkpoint. Your paymaster must verify:
- Signature Validity: Ensure the user's signature matches their smart account address.
- Payment Ability: Confirm the user can pay the paymaster's fee (e.g., via an ERC-20 allowance check for USDC).
- Stake Requirements: Ensure the paymaster meets the minimum stake and unstake delay requirements set by the EntryPoint to prevent spam.
If all checks pass, the paymaster returns the required stake and deposit data. If any check fails, it must revert with a specific error code so the EntryPoint can reject the operation cleanly.
Execute the Transaction
Once validation succeeds, the EntryPoint calls the postOp function (or executes the target call directly depending on the implementation) to perform the actual state changes requested by the user. The EntryPoint then deducts the gas cost from the paymaster's prefunded deposit and credits the bundler's fee.
Monitor for Reverts
Always implement monitoring for validation failures. Common issues include insufficient ERC-20 allowances or expired signatures. Logging these failures helps you adjust user experience flows, such as prompting users to approve token allowances before initiating a gasless transaction.
| Phase | Actor | Responsibility |
|---|---|---|
| Validation | Paymaster | Verifies signature and payment method |
| Execution | EntryPoint | Executes user call and deducts gas |
| Settlement | Bundler | Packages ops and submits to EntryPoint |
Secure Against Replay Attacks
Replay attacks are the single most critical vulnerability in paymaster implementations. Without strict safeguards, an attacker can capture a valid user operation and broadcast it repeatedly. Each replay consumes the paymaster’s prefunded deposit, draining funds and potentially crashing the service. This is not a theoretical edge case; it is a fundamental requirement for any production-ready gasless UX.
The primary defense is nonce validation. Every user operation must include a unique nonce that the paymaster verifies against its internal state or the EntryPoint contract. If a nonce has already been processed, the paymaster must reject the operation immediately. This ensures that even if an attacker intercepts the signed transaction, they cannot reuse it to claim gas sponsorship twice.
Beyond nonces, paymasters should implement signature verification checks. Since paymasters often sign off on user operations, an attacker might try to reuse a valid signature with different parameters. The paymaster must verify that the signature matches the exact operation data being submitted. This includes checking the chain ID, target contract, and calldata to prevent signature substitution attacks.
For developers building a Paymaster Kit 2026, integrating these checks is non-negotiable. The cost of a single successful replay attack can far exceed the development time required to implement proper security. Always test your paymaster against replay scenarios in a sandbox environment before deploying to mainnet.
| Feature | Secure Implementation | Vulnerable Implementation |
|---|---|---|
| Nonce Usage | Unique, monotonically increasing | Missing or reused |
| Signature Verification | Validates full operation data | Only checks signature presence |
| Chain ID Check | Enforces correct network context | Ignored or optional |
These measures create a layered defense. Nonces prevent duplicate submissions, while signature verification ensures the operation itself hasn’t been tampered with. Together, they form the baseline security model for ERC-4337 paymasters. Ignoring either layer leaves the system open to exploitation.
Verify gasless implementation
Before launching, ensure your paymaster contract handles user operations correctly across target chains and wallet providers. A broken verification step leaves users stuck with failed transactions, which erodes trust instantly.
Start by checking signature validation. Your paymaster must verify the user’s signature against the smart account’s public key before sponsoring the gas. If the signature check fails, the EntryPoint contract reverts the entire operation. Test this with both valid and invalid signatures to confirm the contract rejects bad data without freezing the user interface.
Next, verify chain compatibility. ERC-4337 paymasters behave differently on Ethereum L2s versus L1s due to gas pricing models. Ensure your paymaster can handle varying gas limits and price oracles. Test with MetaMask Smart Accounts, as they are the most common entry point for gasless UX. Their documentation provides specific examples for ERC-20 paymaster integration that you should mirror in your test suite.
Finally, audit your security controls. Paymasters are high-value targets for replay attacks. Implement strict nonces and chain IDs in your verification logic. Use a calculator to estimate the cost of a replay attack versus the cost of your verification checks to justify your security spending.
Verification Checklist
-
Signature verification rejects invalid signatures immediately.
-
Paymaster handles gas refunds correctly on EntryPoint.
-
Nonce management prevents replay attacks across chains.
-
MetaMask Smart Account integration works end-to-end.
-
Gas price oracles update correctly during market volatility.
| Test Type | Focus |
|---|---|
| Unit Tests | Verify signature logic and nonce checks in isolation. |
| Integration Tests | Test full user operation flow with EntryPoint contract. |
| Chain Tests | Deploy on testnets (Sepolia, Base) to check gas behavior. |
Common paymaster: what to check next
Addressing the specific mechanics and security concerns of ERC-4337 paymasters helps clarify how gasless UX actually works on-chain.
Is the paymaster legit?
Yes, the paymaster is a core component of the ERC-4337 standard. It is a smart contract that pays gas for a user operation, enabling account abstraction. Legitimacy depends on the contract code audited by your wallet or dapp.
What is the paymaster policy?
The policy defines how gas is paid. Instead of the user spending ETH, the EntryPoint contract deducts gas from the paymaster's prefunded deposit. This allows dapps to sponsor transactions or let users pay gas in ERC-20 tokens instead of the native chain currency.
How are paymasters compensated?
Paymasters recover costs by charging a fee directly from the transaction commission or by absorbing the cost as a marketing expense. They do not charge the user an upfront fee for gas sponsorship.
No comments yet. Be the first to share your thoughts!