What is a paymaster?

A paymaster is a smart contract that pays the gas for someone else's user operation. ERC-4337 introduced it so an app can sponsor fees in the chain's native token, or let a user pay those fees with an ERC-20 token such as USDC, while the bundler that submitted the operation still gets repaid in the native token.

That is the whole job. A new user holds USDC and no ETH. The swap, the mint, or the first account deployment never starts, because the network will not accept a transaction the sender cannot pay for. The paymaster is the contract that covers that fee under rules the app sets.

It is not the wallet, and it is not the bundler. The sender is usually a smart account. The bundler is the offchain service that packs user operations into one transaction. The EntryPoint is the onchain contract that checks everyone, runs the call, and repays the bundler. The paymaster is the party that agrees to fund that repayment.

What is a paymaster?

A paymaster is an ERC-4337 contract with a deposit of native gas token on the EntryPoint. When a user operation names that paymaster, the EntryPoint pulls the fee from the paymaster's deposit instead of from the sender.

The user operation carries the paymaster address in paymasterAndData (older EntryPoint versions) or in the separate paymaster and paymasterData fields (EntryPoint v0.7 and later). The data is how the paymaster recognizes a sponsorship it already approved. On Alchemy's paymaster, that data is a 32-byte packed time range followed by a 65-byte signature.

Without a paymaster, the smart account has to hold ETH, or whatever the chain uses as gas, before it can do anything. With one, the app can pay, or the user can pay in a token they already hold.

When should you use a paymaster?

Use a paymaster when the person taking the action should not have to hold the chain's gas token.

There are two durable reasons.

Sponsorship. The app pays. New users finish onboarding, a campaign covers the first actions, or a product hides gas the way a fintech hides card-network fees. The paymaster's deposit on the EntryPoint settles the fee.

ERC-20 payment. The user pays in a token, often a stablecoin, and the paymaster still settles the bundler in the native token. The token does not become the chain's gas token. The paymaster quotes a price, takes the tokens, and uses its own native-token deposit to pay the network.

Both can run at once: sponsor some users, and let others pay in USDC. The policy decides which.

How does a paymaster work?

A paymaster never submits the transaction itself. The bundler does. The EntryPoint is the contract that calls the paymaster, then pays the bundler back.

For a sponsored user operation, the sequence is:

1. The sender signs a user operation that names a paymaster.
2. The bundler submits a bundle to EntryPoint.handleOps.
3. The EntryPoint checks that the paymaster's deposit covers the worst-case cost of the operation. If the deposit is too low, the operation fails with AA31 paymaster deposit too low.
4. The EntryPoint calls validateUserOp on the sender. Because a paymaster is paying, the account is not asked to deposit funds for this operation.
5. The EntryPoint calls validatePaymasterUserOp on the paymaster. If the paymaster rejects the operation, it does not run.
6. The EntryPoint executes the sender's call.
7. If validation returned a non-empty context, the EntryPoint calls postOp so the paymaster can settle, for example by pulling an ERC-20 token.
8. The EntryPoint pays the bundler from the paymaster's deposit. If the operation had no paymaster, the sender's own deposit pays the bundler.

What functions must a paymaster implement?

The paymaster interface has two functions.

validatePaymasterUserOp runs during validation. It receives the user operation, its hash, and the maximum cost. It returns a context byte array and a validation result. A non-empty context is the signal that postOp should run after execution. An empty context means there is nothing left to settle.

postOp runs after the call, and only if that context was non-empty. This is where an ERC-20 paymaster transfers tokens from the sender. It also runs if the call reverted, so the paymaster can react to failure. The mode argument tells it which case this is.

Both functions must reject any caller that is not the EntryPoint. A paymaster that accepts calls from anywhere can be tricked into sponsoring operations it never approved.

What kinds of paymasters are there?

ERC-4337 does not define two official products. It defines one interface. Teams sort paymasters by who decides to pay, and by what the user is charged.

Verifying paymasters

A verifying paymaster asks an offchain service to approve the operation, then checks that approval onchain. The usual check is a signature over the user operation, often bound to a time window so the approval cannot be replayed later.

This is the pattern for an onchain paymaster that sponsors gas for the app. The app's backend, or a gas policy service, decides that this sender, this call, and this cost are allowed. The signature is what the contract trusts. Alchemy's Onchain Paymaster policy works this way. The policy approves the user operation, and alchemy_requestGasAndPaymasterAndData returns the paymaster address, the signed data, and gas estimates. The recommended Gas Sponsorship policy does not. It sponsors at the bundler and returns no paymaster fields.

A verifying paymaster can also sit behind a card or fiat charge. The offchain service confirms payment first. The onchain contract only sees a signature that says the fee is covered.

ERC-20 paymasters

An ERC-20 paymaster, sometimes called a token or deposit paymaster, charges the user in an ERC-20 token. The EntryPoint still pays the bundler in the native token, from the paymaster's deposit. postOp, or in some designs the validation step, collects tokens so the deposit can be refilled.

The exchange rate has to be fixed before the user signs. Alchemy locks the quote from the Token Prices By Address API at the moment the sponsorship is signed, not when the operation is mined. A price that moves between signature and inclusion would change the fee the user already agreed to.

There are two ways to move the tokens:

• After execution, which is the mode to start with. The user operation can include the token approval, so there is no separate approval transaction. If the token transfer fails, the whole operation reverts, but the sponsor is still liable for the gas that was used. Simulate first. Simulation is not a guarantee.
• Before execution. The transfer happens inside validatePaymasterUserOp. The paymaster must already have allowance, from an earlier approve or a permit signature. If the allowance is missing, the operation is rejected. This costs more gas and adds a step the user can see.

The paymaster's native-token deposit is what the bundler is paid from in both modes. Taking USDC from the user does not remove the need for that deposit.

How do wallets request paymaster data?

Wallets should not each invent a private API for sponsorship. ERC-7677 is the paymaster web service standard. An app passes a paymaster service URL. The wallet calls two JSON-RPC methods on that URL:

• pm_getPaymasterStubData returns dummy paymaster fields so the wallet can estimate gas before the user signs.
• pm_getPaymasterData returns the final fields for the signed user operation that will be submitted to a bundler.

The service has to detect the EntryPoint version. v0.6 expects paymasterAndData. v0.7 and later expect paymaster and paymasterData.

Alchemy implements those pm_ methods for an Onchain Paymaster policy. alchemy_requestGasAndPaymasterAndData returns the paymaster fields and gas estimates together. alchemy_requestPaymasterAndData is the older method and is being deprecated. Bundler Sponsored Operations do not use these methods, and they do not return paymaster fields.

Did EIP-7702 replace paymasters?

No. EIP-7702 lets an externally owned account delegate to smart contract code for a transaction, or until the account changes that delegation. The account can batch calls and use smart-account features without deploying a separate contract wallet first. Someone still has to pay gas.

When that flow uses an onchain paymaster, the payer is still that paymaster, and the submitter is still a bundler. EntryPoint v0.8, deployed at 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108, adds native EIP-7702 checks: the user operation hash includes the delegation address, and the EntryPoint checks that the delegation matches. The published Gas Manager request example targets EntryPoint v0.7 at 0x0000000071727De22E5E9d8BAf0edAc6f37da032. Pass the EntryPoint your account is built for. The bundler and the EntryPoint still have to understand the authorization.

EIP-7702 made sponsorship available to existing EOAs. It did not remove the paymaster from ERC-4337. Alchemy's recommended Gas Sponsorship policy can still cover a delegated EOA, and that path leaves the paymaster off the user operation. That is a bundler policy, not a change to the EntryPoint.

How do you limit sponsored gas?

A sponsorship policy without limits will cover whatever it is asked to cover. The policy is the allow and deny list in front of the bundler, or in front of the paymaster contract.

On Gas Manager, a sponsorship policy can set:

• A global max spend, in USD
• A max spend per sender, and a max spend per user operation
• A max number of sponsored operations, globally and per sender
• A sender allowlist and a sender blocklist
• A start time and an end time
• A sponsorship expiry, in milliseconds, which is how long a signed approval stays valid

Those last two are different on an onchain paymaster. The start and end times bound the policy. The expiry bounds one paymaster signature. Bundler Sponsored Operations require the max spend per user operation, and the bundler retries up to that amount. On that path the expiry starts when the bundler accepts the user operation, because there is no paymaster signature.

For rules that are not a spend cap, attach a webhook. Gas Manager calls your URL and uses the response to allow or deny the operation. approveOnFailure chooses what happens if that call errors or times out: approve, if you would rather stay up, or deny, if you would rather stay strict. The default is deny.

Create the policy in the dashboard, or with the Gas Manager Admin API. The same shape exists for ERC-20 rules, including which tokens are accepted and whether collection happens after execution.

How does Alchemy sponsor gas?

Gas Manager holds the policy. It is not always an onchain paymaster.

The recommended policy type is Gas Sponsorship, powered by Bundler Sponsored Operations. BSO checks that policy when the bundler receives the signed user operation through eth_sendUserOperation. The user operation does not carry paymaster fields, and there is no paymaster contract to call. The Bundler covers the gas and retries submission up to the policy's max spend per user operation. Rundler is the open-source bundler we run.

An Onchain Paymaster policy is the other EVM choice. That one is a verifying paymaster. You request paymaster fields before the user signs, the user operation carries the paymaster signature, and the EntryPoint repays the bundler from the paymaster deposit.

Wallet APIs sit above both for apps that should not assemble a user operation by hand. Pass the BSO policy ID on the smart wallet client, or on a single call. The SDK sponsors that call under the policy. In the EIP-7702 flow, wallet_prepareCalls returns an authorization for the user to sign, not a user operation, so the zeroed gas fields below do not apply there. The sender is the smart account, or an EOA delegated to smart-account code. wallet_prepareCalls and wallet_sendCalls still attach batching and EIP-7702 delegation.

How do you send a Bundler Sponsored Operation?

Create a Gas Manager policy with type Bundler Sponsored Operations and set Max Spend Per UO. That cap is required. The bundler retries up to it.

A low-level integration sends the signed user operation with eth_sendUserOperation. Put the policy ID in the x-alchemy-policy-id header, and set maxFeePerGas, maxPriorityFeePerGas, and preVerificationGas to zero. The bundler treats those zeros as the signal to fill in gas and sponsor the operation. Do not call alchemy_requestGasAndPaymasterAndData for this policy. A BSO user operation has no paymaster address and no paymaster signature.

Eligibility is decided when the bundler receives the operation. If the policy limit is already reached, the send fails. After the bundler accepts it, the operation still has to land in a bundle before the sponsorship expiry. If it does not, the bundler drops it.

When do you use an onchain paymaster?

Use an Onchain Paymaster policy when the user operation has to name a paymaster contract. That includes ERC-20 gas payments, where the user pays in a token and the paymaster still settles the bundler in the native token. Request the fields with alchemy_requestGasAndPaymasterAndData or the ERC-7677 pm_ methods, then submit through the Bundler. The policy is checked before the user signs. The paymaster signature expires, so the operation has to be sent inside that window.

What does sponsored gas cost?

Published Gas Manager fees, from the Gas Manager FAQ:

• Testnet sponsorship is free on every plan.
• The free plan does not include mainnet sponsorship.
• Pay as you go adds 8% on top of the mainnet gas covered. There is no standing mainnet allowance until you buy gas credits or arrange a limit.
• Enterprise fees and limits are custom.

Gas you cover is added to the monthly bill. Gas credits are a one-time USD purchase that applies to that bill and rolls over until it is used. Usage alerts go to billing admins at 50%, 75%, 90%, and 100% of the sponsorship limit. Because sponsorship is approved in batches, a busy policy can briefly spend slightly past a cap.

ERC-20 gas payments count toward the same limit. On an onchain paymaster, the native-token deposit is still what settles onchain. Bundler Sponsored Operations do not use that deposit. The docs price BSO gas as the onchain settlement cost plus a service fee for the bundler's retries and faster inclusion.

Which networks support gas sponsorship?

The network list changes as chains are added. Gas Manager and Bundler support follows the feature support table. Bundler Sponsored Operations run on every chain where Alchemy offers gas sponsorship, except MegaETH. ERC-20 gas tokens are enabled per policy. The dashboard list is not the ceiling: a custom token can be added through the Admin API when the Token Prices By Address API has a price for it, or when you set a reference token with the same number of decimals.

Deployment addresses move with EntryPoint versions and new networks. Use the addresses in the Gas Manager docs for the network you are on, rather than a copied list.

Is there a paymaster on Solana?

Not an ERC-4337 one. Solana has no EntryPoint and no user operations. Gas Manager still sponsors Solana fees, through alchemy_requestFeePayer, which returns a fee-payer signature on the transaction plus fee and rent estimates. The product job is the same, the app pays the network fee, and the mechanism is not a paymaster. Do not point a Solana transaction at validatePaymasterUserOp.

How do bundlers limit a malicious paymaster?

A paymaster's storage is shared by every operation in a bundle that uses it. One hostile validatePaymasterUserOp can make later operations in that bundle fail. That is a denial-of-service against the bundler, not against a single user.

ERC-4337 answers with reputation scoring and throttling, and with a stake. The stake is not slashed, and it can be withdrawn. It exists so an attacker cannot cheaply deploy a new paymaster for every attempt. Bundlers can also ban a paymaster that keeps invalidating other operations. The rules are in the reputation section of ERC-4337.

Frequently asked questions

What is a paymaster in ERC-4337?

A paymaster is a smart contract that pays gas for a user operation. It deposits the chain's native token with the EntryPoint, approves operations in validatePaymasterUserOp, and repays the bundler from that deposit. It can sponsor the fee outright, or collect an ERC-20 token from the user and still settle the bundler in the native token.

What is the difference between a paymaster and a bundler?

The bundler submits user operations and pays the chain up front. An onchain paymaster decides whether to cover that cost and refunds the bundler through the EntryPoint. A Bundler Sponsored Operation skips the paymaster contract. The bundler checks the Gas Manager policy when it receives the signed operation and covers the gas itself. An app needs the policy and a bundler that will accept the operation. It needs a paymaster contract only on the onchain path, including ERC-20 gas payments.

Can users pay gas in USDC?

Yes. An ERC-20 paymaster quotes a token price, takes USDC (or another enabled token) from the smart account, and pays the bundler in the native gas token. Prefer collection after execution so the approval can be batched into the same user operation. If that transfer fails, the operation reverts and the sponsor still owes the gas.

Did EIP-7702 replace paymasters?

No. EIP-7702 lets an EOA delegate to contract code. An onchain paymaster still funds the bundler when the user operation names one, and EntryPoint v0.8 checks the delegation. Alchemy's recommended Gas Sponsorship policy can cover that delegated EOA without a paymaster on the user operation.

How much does Alchemy charge to sponsor gas?

Testnets are free. Mainnet sponsorship is not on the free plan. Pay as you go is 8% of mainnet gas covered, once you add credits or a limit. Enterprise pricing is custom. Confirm the current table in the Gas Manager FAQ before you budget a launch.

How do I start sponsoring gas?

For app-sponsored gas, create a Gas Sponsorship policy. That uses Bundler Sponsored Operations. A low-level caller sends the policy ID in the x-alchemy-policy-id header and sets maxFeePerGas, maxPriorityFeePerGas, and preVerificationGas to zero. Wallet APIs callers pass the same policy ID and do not build paymaster fields. Use an Onchain Paymaster policy, and alchemy_requestGasAndPaymasterAndData or the ERC-7677 pm_ methods, only when the user operation must name a paymaster, including ERC-20 gas. Open the BSO guide, the policy types, and the policy rules first.