Reading a Flashbots Bundle Simulation Before You Send

In an eth_callBundle response, each transaction’s results entry tells you whether it reverted and how much gas it used, while coinbaseDiff and bundleGasPrice show what the block’s fee recipient earns. Read the transaction entries even if the RPC call itself returned successfully. These figures describe execution against the state you selected, which can differ from the state when the target block is built.

Read each transaction result before judging the bundle

Each entry in results reports an individual transaction’s outcome and gas use. Match entries to your submitted transactions using txHash; gasUsed shows how much gas that transaction consumed, and an error field or revert information signals a failure. A successful JSON-RPC response only means the simulation returned a result. It does not mean every transaction inside the bundle succeeded.

This distinction matters because bundles execute transactions in order. If an earlier transaction reverts, a later transaction may no longer have the state or balances it expects. Find the failing transaction, then inspect its inputs and assumptions—such as a nonce, balance, allowance, or price condition—before deciding whether to repair it or allow that specific transaction to revert. A revert you did not intend to allow can make the bundle unsuitable to send.

Use coinbaseDiff to measure the fee recipient’s gain

coinbaseDiff is the total amount the block’s fee recipient gains from the bundle. It includes transaction gas fees as well as direct payments. By comparison, ethSentToCoinbase counts only ETH transferred directly to that recipient. So if you want to know what the builder’s fee recipient receives overall, use coinbaseDiff; if you want to isolate your explicit transfer, use ethSentToCoinbase.

bundleGasPrice expresses that total gain per unit of bundle gas: divide coinbaseDiff by totalGasUsed. The result is in wei per gas. In the Flashbots Docs’ eth_callBundle example, the response reports 20,000,000,000,012,600 wei of coinbaseDiff and 42,000 gas used, giving a bundle gas price of about 476 billion wei per gas. This effective price helps builders compare the payment a bundle offers for the blockspace it uses.

Use the figures to decide whether to adjust payment, but don’t treat one simulation as a guarantee of inclusion. If the bundle executes as intended but its effective price is weak for the competition, consider raising the direct payment or transaction fees and simulating again. If the transaction results show a revert, fix the cause first; paying more does not repair failed execution.

StateBlockNumber tells you which state the result describes

stateBlockNumber is the block whose state the simulation used. The request’s blockNumber identifies the target block for inclusion; these two numbers answer different questions. If you simulated against latest, for example, the response identifies the specific state block that tag resolved to.

That state may change before the target block is built. Another transaction can alter a balance, nonce, pool price, or contract condition your bundle relies on, changing both whether it succeeds and how much gas or payment it produces. When you act on the response, confirm that the simulated state and target block still match your assumptions; after relevant state changes, simulate again.

With these fields separated, you can tell whether a bundle needs an execution fix, a payment adjustment, or a fresh simulation against updated state. In a MEV-Boost setup, which builders receive Flashbots bundles determines where your submission can be considered, while the simulation helps you judge what those builders would receive from it.

Practical simulation questions

Can I simulate a bundle without a Flashbots signing key?

You do not need a special key from Flashbots to authenticate the RPC request. The endpoint expects an X-Flashbots-Signature header, and its documentation says you can use any valid Ethereum key for that signature. This authentication key is distinct from the keys that signed the transactions in your bundle: the simulation still needs the signed transaction data you want to execute.

How do I simulate against a block that hasn’t been built yet?

Set the request’s blockNumber to the target block and choose a stateBlockNumber for the state on which to base the simulation, such as latest. The RPC simulates execution for that target using the selected state; it cannot know what transactions will change that state before the block is built. Treat the response as a test of your current assumptions and rerun it if the relevant chain state changes.