Paymasters are smart contracts that enable flexible gas policies like allowing decentralized applications to sponsor operations for their users (i.e.pay gas fees in the blockchain’s native currency), or accept gas fee payments in an ERC-20 token (e.g. USDC) in place of the blockchain’s native currency.

The paymaster smart contract was introduced in Ethereum Improvement Proposal (EIP) 4337 and integrates with other Account Abstraction infrastructure like bundlers and the entry point smart contract to compensate them for fronting the gas needed to execute user operations.

When should paymasters be used?

There are two main reasons to use a paymaster: to sponsor the gas fees for another account’s transaction, or to pay for gas fees in an ERC-20 token instead of the blockchain network’s native currency. This ERC-20 paymaster can be an application’s token, or a stablecoin such as USDC.

1. Paymasters for Sponsoring Transactions

Reasons why web3 application and wallet developers may choose to use a sponsoring paymaster include making it easier for new users to participate in web3, incentivize platform-specific user behaviors, mint an NFT without paying gas, deploy a wallet without spending gas, and many other use cases.

To sponsor transactions with a paymaster, web3 developers create policies by defining the rules which user operations can be sponsored, the paymaster contract they’re using will have some amount of cryptocurrency deposited with the entry point contract from which gas fees from subsidized transactions will be deducted, and then they activate the policy.

What are the rules that define paymaster sponsorship policies?

To control who can access sponsored transactions with a paymaster, developers can define rules to manage the spend and number of user operations per application and per sender (e.g. user requesting a sponsored user op), admit and deny access to sponsored user ops, and set controls for when policies begin, finish, and expire.

• Max spend - the max amount of money (in USD) that the policy can spend
• Max spend per sender - the max amount of money (in USD) that the policy can spend
• Max spend per user operation - the max amount of money (in USD) that each user operation can spend
• Max count of transactions - the global maximum number of transactions the policy can sponsor
• Max count of transactions per sender - the individual maximum number of transactions per sender
• Sender allowlists - rules to define the accounts that have access to the paymaster
• Sender blocklists - rules to define the accounts that do not have access to the paymaster
• Policy start time - the time the policy begins
• Policy end time - the time the policy finishes
• Policy expiration - the max amount of money (in USD) that the policy can spend

Note: These are the gas policy rules that can be set using Alchemy’s Gas Manager Coverage API. Other ERC-4337 compliant paymasters may support more or less rules.

Using paymaster access keys, developers can create, activate, and manage flexible gas sponsorship policies programmatically. To manage policies manually, developers can create them in the Gas Manager dashboard.

How does Alchemy’s Gas Manager Coverage API manage deposits for sponsoring user ops?

Alchemy’s Gas Manager Coverage API contract has already deposited native currency with the global entrypoint contract on each supported blockchain. When devs make gas policies through our Gas Manager, we track how much native currency they used to cover gas fees. 

At the end of the month, teams building on Alchemy receive an invoice with their total amount of gas fees their policy covered plus 8% of the total gas fee covered. This fee is then paid by through the payment method in their Alchemy account.

What are the fees associated with Alchemy's Gas Manager Coverage API?

The fees to cover gas for sponsored transactions are custom for Enterprise customers, 8% for Growth Tier customers, and free for free users since sponsored transactions are only available on testnets.

What networks are Alchemy’s sponsoring paymaster contracts deployed?

Alchemy has sponsoring paymaster contracts deployed on Ethereum, Arbitrum, Optimism, Polygon. Here are the mainnet deployment addresses and their links to Etherscan:

• Ethereum - 0x4Fd9098af9ddcB41DA48A1d78F91F1398965addc
• Polygon - 0x4Fd9098af9ddcB41DA48A1d78F91F1398965addc
• Arbitrum - 0x4Fd9098af9ddcB41DA48A1d78F91F1398965addc
• Optimism - 0x4Fd9098af9ddcB41DA48A1d78F91F1398965addc

What testnets are Alchemy’s sponsoring paymaster contracts deployed?

Alchemy has sponsoring paymaster contracts deployed on Sepolia, Goerli, Mumbai, Arbitrum-Goerli, Optimism-Goerli.  Here are the testnet deployment addresses and their contract addresses on a block explorer:

• ETH Sepolia - 0xC03Aac639Bb21233e0139381970328dB8bcEeB67
• ETH Goerli - 0xC03Aac639Bb21233e0139381970328dB8bcEeB67        
• Polygon Mumbai  - 0xC03Aac639Bb21233e0139381970328dB8bcEeB67       
• Arbitrum Goerli - 0xC03Aac639Bb21233e0139381970328dB8bcEeB67
• Optimism Goerli - 0xC03Aac639Bb21233e0139381970328dB8bcEeB67

2. Paymasters for Paying for Gas with ERC-20 Tokens

Reasons why dapp and wallet devs may elect to use an ERC-20 paymaster include adding utility to their application’s ERC-20 token, offering more flexibility to users who own a variety of digital assets within a blockchain network’s ecosystem, pay in a stablecoin whose value does not change, unlike native currencies like ETH, MATIC, OP, and ARB, and many other application-specific use cases.

What are the types of Paymasters based on the IPaymaster interface?

Paymasters serve multiple purposes like sponsoring transactions and enabling users to pay for gas with ERC-20 tokens, and paymasters that serve these two functions are described as verifying paymasters and token (deposit) paymasters based on the IPaymaster interface.

1. Verifying Paymasters

The verifying paymaster type is used when an off-chain service decides whether the transaction fee should be sponsored. For example, if a user wants to pay with fiat currency and a credit card, the sender of the user operation will first send their payment to the external signer, and if this step is successful, the paymaster will validate the operation, and confirm that it will cover the transaction fee.

2. ERC-20 Paymasters

The deposit paymaster type is used when gas fees are to be paid with an ERC-20 token. The developer specifies the ERC-20 token and the addresses of the smart contract wallets that are eligible for sponsored user operations. An example is when a web3 dapp wants to use it's own ERC-20 token to pay for the transactions of the first 1000 users.

Although a deposit paymaster allows fee sponsorship with ERC-20 tokens, the actual cost of the transaction is paid in ETH and is deducted from the paymaster’s deposited reserve amount in the entry point contract. The postOp() function contains logic that takes ERC-20 tokens from the sender based on the price quoted from an oracle to match the ETH required to cover the fees.

How do Paymasters work?

Paymasters work by interacting with the entry point contract to cover sponsored user operation fees and reimburse bundlers who execute user operations on behalf of senders.

For each user operation:

1. Call validateOp on the sender's wallet
2. If the user op has a paymaster address, call validatePaymasterOp
3. Discard user ops that fail the validatePaymasterOp call
4. For each user op, call executeOp on the sender’s wallet
5. Track how much gas was used to execute the user op on behalf of the sender
6. Transfer ETH to the bundler to pay for the gas the bundler used to execute the user op on behalf of the sender
7. If the user op has a paymaster field, the paymaster uses ETH deposited in their contract to pay the bundler
8. If the user op does not have a paymaster field, the ETH is reimbursed by the sender's wallet

Here's a diagram illustrating how paymasters work:

What functions are included in the IPaymaster interface?

The IPaymaster interface is the blueprint that each paymaster contract should follow to conform to the proposal’s specifications. It introduces two functions: validatePaymasterOp() and postOp().

1. validatePaymasterUserOp()

The validatePaymasterUserOp() is a function that is used by the mempool nodes, bundlers, and the entry point contract to make sure that the paymaster contract agrees to sponsor the transaction's fees. The validatePaymasterUserOp() is mentioned in the paymasterAndData field of a user operation.

The validatePaymasterUserOp() function accepts the bytes representation of the user operation to be verified, together with its ID, and maximum cost. It returns a bytes32 variable called ’context’ which is then passed to the postOp() function.

2. postOp()

The postOp() function defines what should be done if the user op is successfully validated. For example, if the sender of the user op wants to pay with an ERC-20 token, the entry point will call postOp() after the operation is done and communicate how much gas was used.

The postOp() function is callable only if the ‘context’ generated by validatePaymasterUserOp() is not null.

How do bundlers prevent malicious paymasters from DoS attacks?

The ERC-4337 specification describes a paymaster reputation scoring and throttling system that allows ERC-4337 bundlers to avoid executing user operations from malicious paymasters. 

Because a paymaster’s storage is shared across all the operations in a bundle that use that paymaster, the actions of one validatePaymasterOp could potentially cause validation to fail for numerous other user ops in the bundle that use that same paymaster in a Denial-of-Service attack (Dos).

To avoid malicious paymasters creating multiple instances of itself (i.e. Sybil attack), paymasters are required to stake ETH. Paymaster stakes are never slashed and can be withdrawn at any time; stakes exist to require a potential attacker to lock up a non-trivial amount of capital to deter malicious behavior.

What are the developer benefits of using a paymaster?

The benefits of paymasters include increasing the flexibility of gas policies, simplifying the web3 onboarding experience for new users, and adding greater programmability to transactions.

1. Attract New Users

One benefit to developers who leverage paymasters is to make it easier for new users to participate in web3. The current process of creating an Externally Owned Account (EOA) wallet, funding it with a blockchain’s native token, and minting an NFT is a complicated process with many opportunities for users to abandon the process. 

Paymasters help reduce the friction of funding a wallet with native currency to complete onchain transactions such as minting an NFT, claiming a username, or signing up for an event using their wallet.

2. Improve User Experience

Developers building web3 products can improve the user experience of their application with paymasters by adding features that support paying for gas in the platform’s native currency.

3. Incentivize User Behavior

Web3 startups trying to grow their company can benefit from paymasters by covering platform fees for power users, incentivizing users to test new products, and get buy-in to participate in marketing promotions.

Like the advantages of smart contact wallets, paymasters can benefit web3 developers in many different ways. Today’s most innovative web3 companies are finding new ways to implement paymasters to improve products and web3 UX.

How to Start Using a Paymaster API

Alchemy’s paymaster is live on Ethereum, Polygon, Optimism, and Arbitrum mainnets. To start sponsoring transactions and building flexible gas policies with an ERC-4337 compliant paymaster, explore our Gas Manager API and our quickstart guide for creating a paymaster policy.