BUNDLER API

Bundler API Fee Logic

Fee logic for Bundler API ( eth_sendUserOperation )

Fee logic for Bundler API ( eth_sendUserOperation )

Fee Logic

To provide its services, Alchemy’s Rundler requires fees when using eth_sendUserOperation, and these fees differ based on the mainnet or testnet in use. Rundler’s requirements for priority fees are expressed via the rundler_maxPriorityFeePerGas endpoint.

Each Bundler API endpoint has an associated compute unit cost.

The following table provides a detailed breakdown of the fee logic and recommendations for each network type:

Network TypeNetwork NameExtra Fee Requirement
MainnetAll except Arb chainsPriority fee buffer: 25% Base fee buffer: 27% minimum, 50% recommended
MainnetArbitrum Nitro chainsPriority fee buffer: None Base fee buffer: 27%, 50% recommended
TestnetAll testnetsPriority fee buffer: None Base fee buffer: 27%, 50% recommended

Recommended Actions for Calculating maxFeePerGas:

  1. Fetch Current Base Fee: Use the method eth_getBlockByNumber with the 'latest' parameter to get the current baseFeePerGas.

  2. Apply Buffer on Base Fee: To account for potential fee changes, apply a buffer on the current base fee based on the requirements and recommendations in the table shown above. (27% is the minimum for bundler acceptance, but we recommend at least 50%)

  3. Fetch Current Priority Fee with Rundler: Use the rundler_maxPriorityFeePerGas method to query the current priority fee for the network.

  4. Apply Buffer on Priority Fee: Once you have the current priority fee using rundler_maxPriorityFeePerGas, increase it according to the fee requirement table shown above for any unexpected changes (No buffer for Arbitrum Mainnet and 25% buffer for all other mainnets).

  5. Determine maxFeePerGas: Add the buffered values from steps 2 and 4 together to obtain the maxFeePerGas for your user operation.

The Alchemy bundler requires the simulated gas limit efficiency of both a UO’s pre-operation gas and call gas to be greater than or equal to 15%. (Note: the 15% efficiency value is subject to change and we will update docs if it does.)

Gas limit efficiency = gas used / gas limit

Pre-operation gas = preVerificationGas + verificationGasLimit + paymasterVerificationGasLimit

Note: for EP v0.6 paymasterVerificationGasLimit == verificationGasLimit

This check is intended to prevent user operations from taking up gas limit space in a bundle, but then not using the gas on-chain. This could prevent other UO’s from being bundled that otherwise could have. It is recommended to use the results from the eth_estimateUserOperationGas endpoint, with slight buffers if desired while keeping above 15% efficiency.

It’s recommended to use our AA SDK to minimize the complexities of estimating user op gas fees.

FAQs

How many compute units will it cost to create a smart contract account?

You can deploy a smart contract account in two ways:

  • Contract deployment by a sending transaction: You can deploy the smart contract account which is essentially a contract by sending a transaction through eth_sendRawTransaction from an EOA. This is same as other contract deployments. In this case, it will cost you 250 CUs which is the cost of calling eth_sendRawTransaction.
  • Contract deployment by sending a user operation: You can deploy the smart contract account by sending a user operation through eth_sendUserOperation with a non-empty initCode. In this case it will cost you 1000 CUs which is the cost of calling eth_sendUserOperation.

How do we determine fee values to give your UO the best chance of landing on chain?

  • alchemy_requestGasAndPaymasterAndData is on opinionated endpoint that tries to set fee values that give your user operations a high chance of landing on-chain. Its likely that we’re over-estimating here a bit, but this is intentional in order to land your UOs faster!

  • We encourage you to try out different fee percentages and determine what works best for you as a balance between cost and chance/time to mine.

  • For alchemy_requestGasAndPaymasterAndData we offer the ability to override our fee estimates with the feeOverride parameters.

    • We default to increasing baseFee by 50% and priorityFee by 5%.
    • Note: The feeOverride parameters don’t include preVerificationGas (PVG) . The method will always increase the estimated PVG by 5% to give the UO a better chance to mine if the L1 /L2 fee ratio changes. If you would like to modify this value, its recommended you use alchemy_requestPaymasterAndData instead.