Tenderly shows 'Actual Gas Used' far above 'Total Gas' on Arbitrum because it includes L1 calldata posting gas

Symptom: for an Arbitrum (or other rollup) transaction, Tenderly's gas view reports something like Total Gas ≈ 205k but Actual Gas Used ≈ 8,000k. It looks impossible for "actual" usage to exceed the total.

Explanation: the two numbers measure different things. - "Total Gas" is L2 execution gas — the opcode-by-opcode cost, the same quantity you would see on Ethereum mainnet for equivalent execution. - "Actual Gas Used" is the gas actually deducted from the sender, which on Arbitrum also covers the cost of posting the transaction's calldata to L1. Arbitrum charges that L1 data cost by inflating the L2 gas units consumed, so in Arbitrum's own notation Gas Limit (G) = L2 gas (L2G) + buffer for L1 cost (B). "Actual Gas Used" corresponds to G, "Total Gas" to L2G.

That is why the gap is enormous for calldata-heavy transactions and small for compute-heavy ones, and why it swings with the L1 base fee rather than with your contract code.

How to verify: Arbiscan's transaction page breaks it out explicitly as "L1 Gas Used" and "L2 Gas Used"; those match the two Tenderly figures.

Practical implications: benchmark contract optimisations against L2 execution gas, but budget user cost against the total including the L1 component — which means shrinking calldata (fewer/smaller arguments, packed structs, avoiding long dynamic arrays) often saves far more on rollups than shaving opcodes. Also do not size gas limits from mainnet-style estimates; use the L2's own eth_estimateGas, which includes the L1 buffer. Same pattern applies to OP Stack chains, though they surface the L1 fee as a separate fee component rather than folding it into gas units.

Source: adapted from a Stack Exchange answer by 0xSanson (question by matorus), https://ethereum.stackexchange.com/questions/166281/tenderly-actual-gas-used-much-higher-than-total-gas — CC BY-SA 4.0