Verifying Paymaster

A verifying paymaster is a specialized smart contract within the ERC-4337 account abstraction standard that authorizes and pays for a user's transaction fees, acting as a financial sponsor. Unlike a traditional paymaster that simply pays gas, its core function is to perform custom verification logic—such as checking a user's signature, validating a session key, or confirming off-chain authorization—before agreeing to sponsor the transaction. This decouples fee payment from the transaction sender, enabling gasless transactions and novel user experiences where dApps or services can cover costs for their users.

The verification process is defined by the validatePaymasterUserOp function in the paymaster's code. When a UserOperation (a bundled user intent) is submitted to the EntryPoint contract, the paymaster is called to verify specific conditions. This could involve checking a cryptographic signature against a whitelist, validating the transaction's calldata, or ensuring a prepaid balance is sufficient. Only after this on-chain verification succeeds does the paymaster commit to paying the network fees, often by depositing ETH or its own tokens into the EntryPoint contract to cover the gas costs.

Common implementations include sponsorship paymasters used by dApps to onboard users, token paymasters that allow fees to be paid in ERC-20 tokens like USDC, and signature-based verifying paymasters that use off-chain signed messages for authorization. This architecture is fundamental to improving UX, as it removes the need for users to hold the network's native token (e.g., ETH) for gas, and allows for complex transaction sponsorship policies. Key related concepts are the EntryPoint, Bundler, and Smart Contract Wallet which together form the complete ERC-4337 stack.

A verifying paymaster is a smart contract within the ERC-4337 account abstraction framework that authorizes and pays for a user's transaction gas fees after programmatically verifying that the transaction meets predefined rules. Unlike a simple paymaster that pays unconditionally, its core function is the validatePaymasterUserOp method, which executes custom logic—such as checking a signature, validating a subscription, or verifying an off-chain attestation—before committing to sponsor the gas. This decouples transaction sponsorship from simple balance checks, enabling sophisticated gas sponsorship models like gasless transactions, subscription services, and sponsored sessions where the user never needs to hold the native blockchain token (e.g., ETH).

The operational flow begins when a User Operation (a packaged user intent) is sent to a Bundler. The bundler simulates the call to the verifying paymaster's validatePaymasterUserOp function, which must return a paymasterAndData value, often containing a signature or proof, if validation passes. This simulation ensures the paymaster will accept the cost later. Crucially, the paymaster must maintain a deposit of ETH in the EntryPoint contract to cover actual gas costs. After validation, the bundler includes the UserOp in a bundle, submits it on-chain, and the EntryPoint contract finally calls the paymaster's postOp function, which can execute cleanup logic or revoke a session.

A common implementation is the signature-based verifying paymaster. Here, the validation logic checks a cryptographic signature provided in the paymasterAndData field against a known signer address. This allows a backend server to sign specific UserOps it agrees to pay for, enabling use cases like fee sponsorship for whitelisted dApp actions or employees. The paymaster contract itself holds no business logic about who can be sponsored; that authority is delegated to the off-chain signer, making the system flexible and upgradeable without modifying the on-chain contract.

For the system's security, the validatePaymasterUserOp function is statically called during simulation and execution, meaning it cannot call external contracts or change state beyond its own storage. This prevents a malicious user from manipulating the validation. Furthermore, paymasters must carefully manage their EntryPoint deposit and implement rate-limiting or fraud detection in their off-chain components to prevent resource exhaustion attacks, where an attacker could drain the deposit by submitting many valid but costly operations.

The verifying paymaster is foundational for improving user experience in Web3. It enables applications to abstract away gas complexities entirely, allowing users to interact with blockchains using stablecoins or credit systems. By separating the validation logic from payment, it creates a market for gas fee services, where companies can offer gas sponsorship as a product, paying fees in exchange for tokens, subscription fees, or as a marketing acquisition cost.

The verification flow begins when a User Operation is submitted to a Bundler, which calls the validatePaymasterUserOp function on the designated Paymaster contract. This function is the core of the Paymaster's logic, where it must verify the transaction's validity and decide whether to sponsor it. The contract checks parameters like the user's signature, the transaction's callData, and any specific rules encoded in its state (e.g., whitelists, token balances). Crucially, it must return a context (a bytes value) and a validation deadline, which will be passed back to it later during the post-operation execution phase.

If validation succeeds, the Paymaster must prefund the EntryPoint contract to cover the transaction's maximum possible gas costs. This is done by the Paymaster (or a designated sponsor) depositing native chain currency (e.g., ETH) via the EntryPoint's depositTo function, creating a stake that the bundler can trust. The bundler then proceeds to include the User Operation in a bundle and submit it on-chain. The actual gas used is deducted from this deposit after execution. This prefunding mechanism is essential for preventing Paymaster griefing, where a malicious actor could cause a Paymaster to waste gas on invalid operations.

After the user's smart contract account logic executes, the EntryPoint calls the Paymaster's postOp function. This is the second half of the Paymaster's interface, receiving the context returned during validation. Here, the Paymaster performs any final settlement, such as charging the user in a different ERC-20 token, updating usage counters, or revoking a session key. The postOp call is guaranteed to execute if the initial validation passed, allowing the Paymaster to enforce payment even if the user's transaction reverts, protecting its economic model. This two-phase pattern (validate/postOp) is fundamental to secure and flexible sponsorship.