Development of Account Abstraction Paymaster
The main barrier to user adoption in dApps is the requirement to hold native tokens for gas fees. ERC-4337 Account Abstraction solves this with Paymaster contracts that provide gas sponsorship – they cover gas fees, allowing users to interact with dApps without holding ETH. Transitioning to a gasless UX increases conversion by 40% and reduces user churn by 30% – 2-3x better than requiring native gas. Our team, with 5+ years of blockchain development experience and 50+ deployed smart contracts, creates turnkey Paymaster solutions that ensure optimal gas efficiency and attack protection. We use proven patterns and deliver seamless UX for games, DeFi, and social applications, improving dApp onboarding. Our Paymaster solutions help dApps save an average of $5,000–$20,000 per month in gas fees.
Why Paymaster Is Critical for Gasless UX
Without a Paymaster, users must buy and hold ETH for every transaction. This reduces conversion by 2-3x compared to a gasless experience. Paymaster solves the problem by sponsoring gas or accepting payment in any ERC-20 token. Users save 100% on gas fees, and businesses see a 40% reduction in churn. With gas sponsorship, dApps can achieve 3x higher retention.
How Paymaster Integrates with ERC-4337
In a standard transaction: user signs transaction → pays gas in ETH. In the ERC-4337 flow: user signs a UserOperation (not a transaction) → Bundler batches UserOps → EntryPoint contract calls validatePaymasterUserOp → if Paymaster approves, it pays gas → postOp is called after execution.
UserOperation {
sender, // user's smart account
callData, // what to execute
paymasterAndData, // Paymaster address + its data
signature, // user's signature
...gasFields
}
paymasterAndData is address(paymaster) + bytes(paymasterSpecificData). The Paymaster decodes its data from this field.
Types of Paymasters and Their Architecture
Verifying Paymaster (sponsored gas)
The most common pattern: an off-chain service decides whether to sponsor a specific UserOperation and signs the approval. The Paymaster contract verifies this signature. EIP-4337 describes the _validatePaymasterUserOp signature.
function _validatePaymasterUserOp(
UserOperation calldata userOp,
bytes32 userOpHash,
uint256 maxCost
) internal override returns (bytes memory context, uint256 validationData) {
// Decode data: backend signature + expiry
(uint48 validUntil, uint48 validAfter, bytes calldata signature) =
abi.decode(userOp.paymasterAndData[20:], (uint48, uint48, bytes));
// Hash for verification = hash(UserOp + validUntil + validAfter)
bytes32 hash = ECDSA.toEthSignedMessageHash(
keccak256(abi.encode(userOpHash, validUntil, validAfter))
);
// If signature from verifyingSigner, sponsor
if (ECDSA.recover(hash, signature) != verifyingSigner) {
return ("", _packValidationData(true, validUntil, validAfter));
}
return ("", _packValidationData(false, validUntil, validAfter));
}
The backend receives the UserOp from the frontend, checks conditions (user whitelisted? free transaction limit reached? operation type allowed?), signs, and returns paymasterAndData. The frontend inserts it into the UserOp and sends it to a Bundler.
ERC-20 Paymaster (gas in tokens)
The user pays gas in USDC/USDT instead of ETH. The Paymaster accepts ERC-20 tokens and replenishes its ETH deposit in the EntryPoint from its own funds.
function _validatePaymasterUserOp(...)
internal override returns (bytes memory context, uint256 validationData) {
(address token, uint256 exchangeRate) =
abi.decode(userOp.paymasterAndData[20:], (address, uint256));
uint256 tokenCost = (maxCost * exchangeRate) / 1e18;
// Check user's allowance
require(
IERC20(token).allowance(userOp.sender, address(this)) >= tokenCost,
"Insufficient allowance"
);
// Pass context to postOp for actual deduction
return (abi.encode(userOp.sender, token, tokenCost), 0);
}
function _postOp(PostOpMode mode, bytes calldata context, uint256 actualGasCost)
internal override {
(address sender, address token, uint256 maxTokenCost) =
abi.decode(context, (address, address, uint256));
// Actual cost may be less than maxCost
uint256 actualTokenCost = (actualGasCost * exchangeRate) / 1e18;
IERC20(token).transferFrom(sender, address(this), actualTokenCost);
}
The key challenge with ERC-20 Paymaster is exchange rate. An up-to-date ETH/token rate is needed at transaction time. Options: Chainlink oracle, TWAP from Uniswap V3, or a centralized price feed from the backend.
Comparison of Verifying and ERC-20 Paymasters
| Criteria | Verifying Paymaster | ERC-20 Paymaster |
|---|---|---|
| Gas fees | Free for user | Paid in tokens (low fee) |
| Implementation complexity | Medium (backend signer) | High (oracle, liquidity) |
| Abuse risk | High, requires rate limiting | Low (user pays) |
| UX | Smoothest | Token approval needed |
| Asset support | Only ETH deposit | Any ERC-20 |
| Development cost | $8,000+ | $15,000+ |
How to Set Up Rate Limiting for Paymaster?
Without limits, a single user can drain the entire budget through spam. Strategies:
- Per-user spending limit. Off-chain in Verifying Paymaster backend: each address has a monthly USD limit. Backend refuses to sign when exceeded.
- Cooldown period. No more than N transactions per hour per address. Stored in Redis with TTL.
- Transaction type whitelist. Backend checks userOp.callData: only calls to specific contracts are sponsored.
- Reputation system. New accounts get minimal limits that grow after verification (Worldcoin, Sign In With Ethereum + email).
For per-user limit, use Redis with key user:{address}:spent and monthly TTL. Cooldown via Redis counter per hour. Whitelist stored in PostgreSQL. Backend signs only if all checks pass.
Deposit and Balance Management
The Paymaster must hold an ETH deposit in the EntryPoint contract. The EntryPoint deducts gas from this deposit after each sponsored UserOperation.
// Deposit top-up
entryPoint.depositTo{value: 1 ether}(address(paymaster));
// Check balance
uint256 balance = entryPoint.balanceOf(address(paymaster));
// Withdraw (unstake period for staked Paymaster)
entryPoint.withdrawTo(payable(owner), amount);
For production, balance monitoring and automatic top-up are needed. If the deposit runs out, all UserOps through that Paymaster will revert. We recommend: alert when balance is below threshold + auto-topup from treasury via Chainlink Automation or a custom keeper.
Tech Stack and Infrastructure
| Component | Technology |
|---|---|
| Paymaster contract | Solidity (development) + eth-infinitism/account-abstraction |
| Backend signer | Node.js + viem + custom signer wallet |
| Bundler | Stackup / Alchemy Bundler / custom (go-bundler) |
| Rate limiting | Redis + BullMQ |
| Deposit monitoring | Chainlink Automation / custom keeper |
| Frontend SDK | permissionless.js / ZeroDev SDK / Biconomy SDK |
| Testing | Foundry + hardhat-deploy for fork tests |
Choosing a Bundler Provider
The Bundler is a service that accepts UserOperations and includes them in blocks. Options:
- Alchemy — easiest start, good documentation, paid at scale
- Stackup — open-source Bundler, can self-host
- Pimlico — specializes in AA, convenient Paymaster API
- Self-hosted (go-bundler) — full control, infrastructure needed
What's Included?
- Architecture audit and Paymaster type selection
- Smart contract development with tests (Foundry)
- Backend signer service with API and rate limiting
- Frontend integration (SDK)
- Balance monitoring and automatic top-up
- Documentation and team training
- 6-month warranty on contracts
Development Process
Analytics (2-3 days). Determine Paymaster type (sponsored vs ERC-20), target networks, limits and sponsorship policies, choose Bundler provider.
Contract development (1-2 weeks). Verifying or ERC-20 Paymaster, tests against EntryPoint v0.6/v0.7, deposit management.
Backend signer service (1 week). API for signing UserOps, rate limiting, price oracle (for ERC-20).
Frontend integration (3-5 days). Connect SDK, build UserOperation, monitor status.
Monitoring and operations (3-5 days). Balance alerts, auto-topup, expense dashboard.
Basic Verifying Paymaster with rate limiting: 3-4 weeks, starting from $8,000. ERC-20 Paymaster with oracle and full monitoring: 5-7 weeks, starting from $15,000.
Order turnkey Paymaster development: leave a request and we will calculate the cost and timeline within one business day. Contact us for a free consultation on your project.