alchemy_requestGasAndPaymasterAndData

Requests gas and coverage for a UserOperation. Returns paymasterAndData and gas parameters if approved, errors if not. Optionally accepts fee parameter overrides to be used in the UserOperation.

Network Support

ChainMainnetTestnet
Ethereum
Polygon
Arbitrum
Optimism
Base
Frax
Zora

📘

Overriding gas and fee

You can override our gas and fee estimates using the overrides parameters. Use this parameter to optionally override available fields: maxFeePerGas, maxPriorityFeePerGas, callGasLimit, verificationGasLimit, orpreVerificationGas. This will apply either

  1. absolutes overrides (using a hex string) simply overriding estimated values entirely OR
  2. multiplier overrides relative to our estimates (in the format of { "multiplier": number } with max precision of 4 decimal places). For example, if the override value is { multiplier: 1.1 } for the maxPriorityFeePerGas field, then a 1.1 multiplier, or a 10% increase, is applied to the estimated maxPriorityFeePerGas of the user operation.

These overrides will be applied for every user op sent with this provider. A higher buffer may give UOs a better chance to mine if the L1/L2 gas and fees change.

"overrides": {
  "maxFeePerGas": "hex string" | { "multiplier": number },
  "maxPriorityFeePerGas": "hex string" | { "multiplier": number },
  "callGasLimit": "hex string" | { "multiplier": number },
  "verificationGasLimit": "hex string" | { "multiplier": number },
  "preVerificationGas": "hex string" | { "multiplier": number },
}

For backward compatibility, we will process at feeOverrideif overrides is not provided, however we suggest using overrides.

⚠️Deprecated: previous override using "percentage" has been deprecated in favor of "multiplier" values

📘

NOTE

This endpoint does not require a valid signature field. It just requires a dummy signature for gas estimation. You can use the dummy signature mentioned below when the sender account is LightAccount or SimpleAccount:

0xfffffffffffffffffffffffffffffff0000000000000000000000000000000007aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1c

Choosing an Entry Point Version

alchemy_requestGasAndPaymasterAndData supports versions v0.6 and v0.7 of ERC-4337. These two versions define different formats for user operations, and their entry point contracts are deployed at different addresses. Thus, when calling alchemy_requestGasAndPaymasterAndData, you must choose whether you want to use the v0.6 or v0.7 version of this endpoint and ensure that you are using the correct user operation format and entry point address for that version.

Which version you want is determined by the smart contract account for which you are trying to send a user operation. A given smart contract account will typically be written to be compatible with either v0.6 or v0.7 and you should use that version in your request. If you're not sure which version is compatible with a smart contract account, you can look at its source code and check the first parameter to validateUserOp. If it has type UserOperation, then the account uses v0.6, while if it has type PackedUserOperation then the account uses v0.7.

For more information about the differences in versions, see the specifications for ERC-4337 v0.6.0 and ERC-4337 v0.7.0, particularly the description of the user operation fields.

Parameters

  • Object: This object contains all necessary fields to estimate gas and coverage:

    • policyId (string): The gas policy ID.

    • entryPoint (string): The address where the request should be sent through. This must be one of the entry points returned by the supportedEntryPoints RPC call and should match the version of the user operation.

    • dummySignature (string): A dummy signature for the operation. This helps estimate gas costs.

    • userOperation (object): An object containing optional gas parameters, paymasterAndData, and signature fields. It can be either a v0.6 or v0.7 user operation but must match the version of the entry point at the specified entryPoint.

    • overrides (object): Optional fields that override default gas and fee behavior. This can apply multiplier overrides relative to default estimates or absolute overrides.

    • stateOverrideSet (Object): Allows changes to the state of a contract before executing the call. For example, you can modify variable values (like balances or approvals) for that call without changing the contract itself on the blockchain.

      In more technical terms, the state override set is an optional parameter that allows executing the call against a modified chain state. It is an address-to-state mapping, where each entry specifies some state to be overridden prior to executing the call. Each address maps to an object containing:

      FIELDTYPEBYTESDESCRIPTION
      balanceQuantity<32Fake balance to set for the account before executing the call.
      nonceQuantity<8Fake nonce to set for the account before executing the call.
      codeBinaryanyFake EVM bytecode to inject into the account before executing the call.
      stateObjectanyFake key-value mapping to override all slots in the account storage before executing the call.
      stateDiffObjectanyFake key-value mapping to override individual slots in the account storage before executing the call.
Language
URL
Click Try It! to start a request and see the response here!