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:white-check-mark::white-check-mark:
Polygon:white-check-mark::white-check-mark:
Arbitrum:white-check-mark::white-check-mark:
Optimism:white-check-mark::white-check-mark:
Base:white-check-mark::white-check-mark:
Frax:white-check-mark::white-check-mark:
Zora:white-check-mark::white-check-mark:

📘

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.

:warning: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.

Language
URL
Click Try It! to start a request and see the response here!
ReadMe