Bundler API Fee Logic

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.

❗️

Gas limit efficiency requirement >= 15%

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.

📘

Simplify Gas Fee Estimation

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.
ReadMe