Account Abstraction Paymaster Development Services

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.

How to Set Up Rate Limiting for Paymaster?

Without limits, a single user can drain the entire budget through spam. Strategies:

1. Per-user spending limit. Off-chain in Verifying Paymaster backend: each address has a monthly USD limit. Backend refuses to sign when exceeded.
2. Cooldown period. No more than N transactions per hour per address. Stored in Redis with TTL.
3. Transaction type whitelist. Backend checks userOp.callData: only calls to specific contracts are sponsored.
4. 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

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.