Requests coverage for a UserOperation. Returns paymasterAndData if approved, errors if not.
Network Support
| Chain | Mainnet | Testnet |
|---|---|---|
| Ethereum |  | |
| Polygon | | |
| Arbitrum | | |
| Optimism | | |
| Base | | |
| Frax | | |
| Zora | | |
NOTE
While you can use
alchemy_requestPaymasterAndDatato request a paymaster signature, it's important to note that this function requires gas fields to be part of theUserOperation. These gas fields are influenced by thepaymasterAndDatacontent (size and validation gas), creating a circular dependency.To simplify this process, we recommend using
alchemy_requestGasAndPaymasterAndData. This function not only provides a gas estimation, but also returns a signedpaymasterAndDatacontaining that gas estimation, therefore resolving the circular dependency.
Choosing an Entry Point Version
alchemy_requestPaymasterAndData 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_requestPaymasterAndData, 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.