Problem Statement: Predicting On-Chain Execution Cost
Problem Statement: Predicting On-Chain Execution Cost — gas estimator interview depth
Problem Statement: Predicting On-Chain Execution Cost
A gas estimator answers the question every wallet and dApp must answer before sending a transaction: how much will this cost, and what fee gets it mined in time? On EIP-1559 chains a transaction pays baseFee (burned, set by the protocol per block) + a priorityFee/tip (to the validator), capped by maxFeePerGas — so the estimator must predict both the gas the transaction will consume and the fee market over the next few blocks. This is the engine behind Etherscan's Gas Tracker, Blocknative's gas platform, MetaMask's fee picker, and Alchemy.
Two predictions, two failure modes. (1) Gas amount — run eth_estimateGas/eth_call to simulate the transaction and learn how much gas it burns; the trap is an RPC that returns optimistic gas on a call that would actually revert, so the user signs a tx that fails and burns the gas anyway. (2) Fee market — project the base fee forward and sample priority-fee percentiles; the trap is the base fee jumping between quote and broadcast, where a stale quote underpays and the tx sticks in the mempool.
The two personas pull opposite ways. A wallet optimizes latency — the user taps Send and wants a max-fee number in < 200ms. A trading bot / liquidator optimizes correctness — it will pay a fat tip but demands the quote actually lands within N blocks (during a liquidation cascade or an NFT-mint gas war, underpricing means a missed, money-losing opportunity). Design for both explicitly; don't average them into a number that serves neither.
Scale to anchor on: ~1.2M EVM txs/day on Ethereum mainnet, ~5–15M `eth_estimateGas`/`eth_call` simulations/day across providers, sub-200ms p95 for a wallet quote, and a fee refresh every block (~12s). The hard parts aren't QPS — they're keeping quotes fresh (stale fee data is wrong fee data) and honest (a quote that reverts on-chain is worse than no quote).
Close the loop with observability: quote_latency_ms, simulation_revert_rate, tier_inclusion_success, rpc_head_lag_blocks — and when fast-tier inclusion drops during a base-fee spike (a Base/L2 surge, a mint war), auto-raise the fee margin and page the model owner. A gas estimator that doesn't measure whether its quotes actually got mined is just guessing with confidence.
Key Highlights
- •Wallets and dApps need fee quotes before users sign—wrong gas causes stuck or overpaid transactions
- •Gas is multidimensional: intrinsic gas, calldata, storage SSTORE/SLOAD warmth, contract execution depth.
- •EIP-1559 splits base fee (burned) and priority fee (tip to validators/builders)
- •Products like Etherscan Gas Tracker, Blocknative, and Alchemy Gas API monetize accurate forecasts
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "For Problem Statement: Predicting On-Chain Execution Cost, I'll separate gas limit simulation from priority fee market signals."
- "Let me state quote expiry per block and inclusion SLO before picking cloud SKUs."