Network
Launch Date
Consensus
Note
Sepolia
Oct 2021
PoW
Like-for-like representation of Ethereum
Görli
Jan 2019
PoA
Proof-of-Authority
Kiln
Mar 2022
PoS
Post-Merge (for ETH2), shadow fork of the mainnet
Kintsugi
Dec 2021
PoS
DEPRECATED, use Kiln; post-Merge (for ETH2)
Ropsten
Nov 2016
PoW
DEPRECATED, use Sepolia; the Merge to happen on Jun 8, 2022
Rinkeby
Apr 2017
PoA
DEPRECATED, use Görli and Görli Faucet
Kovan
Mar 2017
PoA
DEPRECATED, use Sepolia or Görli
List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup 
ZK-rollup 
Proof
Uses fraud proofs to prove transaction validity. 
Uses validity (zero-knowledge) proofs to prove transaction validity. 
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds. 
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions. 
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs. 
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state. 
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts. 
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared. 
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances. 
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs. 
Trust assumptions
Doesn't require a trusted setup. 
Requires a trusted setup to work. 
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud. 
Users don't need someone to watch the L2 chain to detect fraud. 
Security properties 
Relies on cryptoeconomic incentives to assure users of rollup security. 
Relies on cryptographic guarantees for security. 
Start building
on Alchemy.
Sign up for free
Start building on Optimism.
Sign up for free
Start building on Arbitrum.
Sign up for free
Start building on Ethereum.
Sign up for free
Start building on Polygon.
Sign up for free
Start building on Starknet.
Sign up for free
Start building on Flow.
Sign up for free
kiln faucet
Get free Kiln ETH.
Start building today
Goerli faucet
Get free Goerli ETH.
Start building today
SEPOLIA FAUCET
Get free Sepolia ETH.
Start Building Today
mumbai faucet
Get free Mumbai Matic.
Start building today
rinkeby faucet
Get free Rinkeby
ETH.
Start building today
Start building on Ethereum.
Get started for free
Start building on Ethereum.
Get started for free
Start building on Flow.
Get started for free
Start building on Polygon.
Get started for free
Start building on Starknet.
Get started for free
Start building on Optimism.
Get started for free
Start building on Solana.
Get started for free
Start building on Solana.
Sign up for beta access
Start building on Solana.
Join the waitlist
Arbitrum logo
Start building on Arbitrum.
Get started for free
Build with Alchemy's
Gas Manager & Bundler APIs
Learn
Solidity at
Alchemy
University
Get started today
Build with Alchemy's
Gas Manager & Bundler APIs
curl 
https://release.solana.com/v1.10.32/solana-install-init-x86_64-pc-windows-msvc.exe 
--output 
C:\solana-install-tmp\solana-install-init.exe 
--create-dirs
Account Abstraction
ERC-4337 PAYMASTER OVERVIEW

What are paymasters?

Learn the Function of Paymaster Smart Contracts in ERC-4337
Last Updated:
June 26, 2023
Table of Contents
Table of Contents
Table of Contents

{{aa-cta}}

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:

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:

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:

Diagram of how the entry point contract validates user ops via the paymaster contract, and refunds the bundler with funds from the paymaster.

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.

ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer
Account Abstraction
ERC-4337 PAYMASTER OVERVIEW

Intro to Account Abstraction: What are paymasters?

Learn the Function of Paymaster Smart Contracts in ERC-4337
Last Updated:
June 26, 2023
Last Updated:
June 1, 2023
Don't miss an update
Sign up for our newsletter to get alpha, key insights, and killer resources.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Table of Contents

Talk to an Expert

Learn how Alchemy's blockchain developer tools can help your business succeed in web3!
Valid number
Thank you! An Alchemy expert will be in touch with you shortly!
Oops! Something went wrong while submitting the form.

{{aa-cta}}

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:

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:

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:

Diagram of how the entry point contract validates user ops via the paymaster contract, and refunds the bundler with funds from the paymaster.

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.

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:

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:

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:

Diagram of how the entry point contract validates user ops via the paymaster contract, and refunds the bundler with funds from the paymaster.

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.

{{aa-cta}}

Contact Us

Talk to an expert at Alchemy to answer all of your product questions.
Valid number
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Build blockchain magic with Alchemy

Alchemy combines the most powerful web3 developer products and tools with resources, community and legendary support.

Get started for free