# How gas is estimated and why a fee can spike mid-day
A plain-language breakdown of how Ethereum gas is estimated, why fees can jump sharply during business hours, and what that means for professionals routing high-value payments onchain.
---
There is a moment that every professional who has ever sent or received a high-value onchain payment will recognise. You look at the gas estimate on your screen — say, the equivalent of $3 (roughly AUD 4.70) for what is about to be a six-figure settlement transaction — and you feel reassured. Thirty seconds later, the confirmation arrives with a fee closer to $18 (AUD 28.20). Nothing went wrong with the transaction itself. The money arrived. But the fee was not what the estimate said it would be, and no one told you why.
This article explains exactly why that happens. It starts at the lowest level — how Ethereum actually computes the gas a transaction needs — works up through the fee market mechanics introduced by EIP-1559, and then maps the real-world triggers that turn a calm Thursday morning into a congested, high-fee environment by early afternoon. For settlement agents, closing attorneys, escrow officers, OTC desks, and title companies, understanding this architecture is not academic. It is the foundation of operating with confidence when the payment is the deal.
12.5%the most the base fee can rise or fall from one block to the next
14:00–18:00 UTCthe Tuesday-to-Thursday window when Ethereum gas fees consistently peak
10×the fee spike a major event can still cause, despite lower baseline fees
Figures from the EIP-1559 adjustment rule, the weekly demand cycle and the failure modes detailed below.
## What gas actually measures
Before anything else, it helps to be precise about what gas is. In order to prevent network abuse, all transactions on Ethereum are subject to a fee paid in "gas." Gas is the fundamental unit used to measure the cost of computation and execution of a transaction on Ethereum.
The important point is that gas measures *work*, not money. Moving ETH from one address to another costs 21,000 gas units — always, deterministically, regardless of the price of ETH. Calling a smart contract that splits funds and routes them simultaneously to four receiving addresses costs more gas units because the Ethereum Virtual Machine must execute more operations: read state, perform arithmetic, write new balances, emit events. The gas unit count for a given operation is fixed at the protocol level. What changes, continuously and sometimes violently, is the *price* of each gas unit.
That distinction matters enormously in practice. When a professional receives a gas estimate, they are receiving a two-part number: units × price. The units component is mostly predictable. The price component is a live market.
## How eth_estimateGas works — and what it misses
When a wallet or application needs to quote a gas cost before a transaction is signed, it calls a protocol method called `eth_estimateGas`. This method generates and returns an estimate of how much gas is necessary to allow the transaction to complete on Ethereum.
Under the hood, the node performs a simulation: it replays the transaction against the current chain state — the current balances, the current contract storage values — and counts how many gas units the execution path consumes. The result is not a guarantee. It is the gas cost *if the transaction landed right now, against the state that exists right now.*
That conditional matters. Between the moment the estimate is generated and the moment the transaction is actually included in a block, other transactions may have landed ahead of it, modifying the same state. eth_estimateGas still simulates against state that can change before your transaction lands. For a simple ETH transfer, this is rarely a problem — the execution path does not depend on contract state. For a smart contract payment that reads balances, checks conditions, or routes to multiple recipients, the gap between simulation state and landing state is a real source of variance.
Beyond the gas *quantity* estimate, wallets and applications also need to pick a gas *price* — and that is where `eth_feeHistory` comes in. Modern implementations query this method to retrieve a statistical distribution of recent gas prices across recent blocks, then select from a range of percentiles to set the user's maximum fee bid. The difference between a good gas estimation implementation and a bad one comes down to using `eth_feeHistory` with appropriate percentiles instead of relying on a single `eth_gasPrice` value, and adding buffers to `eth_estimateGas` results.
The oldest and least sophisticated approach — hardcoding a maximum fee — is a cautionary tale. A contract that hardcoded a `maxFeePerGas` value worked fine for six months. Then an NFT drop happened, and the base fee spiked to 3,000+ gwei. Every transaction reverted with "transaction underpriced." The `maxFeePerGas` was set to 500 gwei. The lesson has not changed: treating any gas price as static in a dynamic fee market is a structural mistake.
## The EIP-1559 fee structure: base fee, priority fee, and the burn
Understanding gas spikes requires understanding the fee architecture that has governed Ethereum since August 2021. EIP-1559 fundamentally rewrote how transaction fees work on Ethereum. Before it, you submitted a gas price and miners took all of it as profit — the market was chaotic. After EIP-1559, the fee market split into two separate components: a base fee that burns and a priority fee — a tip to the validator.
The base fee is set by the protocol itself. Nobody negotiates it; the network calculates it from the previous block's fullness and publishes it for the next block. The core mechanism splits each transaction's gas fee into two parts, under a maximum the transaction specifies:
| Component | Set by | Where it goes |
| --- | --- | --- |
| Base fee | The protocol, per block, from the previous block's fullness | Burned rather than paid to validators |
| Priority fee | The user, as an optional payment | To the block proposer, for inclusion priority |
| Max fee (`maxFeePerGas`) | The user: the maximum fee per gas they will pay in total | Covers the base fee and the priority fee; any unused portion is refunded |
Users only pay the base fee plus the priority fee. This protects users from unexpected fee spikes between the time they submit and the time their transaction is included.
The base fee adjustment rule is the engine of the whole system. When a block is more than 50% full, the base fee increases by up to 12.5% for the next block. When utilisation drops below 50%, it decreases by up to 12.5%. This creates a predictable, self-adjusting price signal.
A 12.5% compounding increase sounds modest. In practice, if demand is sustained and consecutive blocks keep arriving above the 50% target, the base fee climbs exponentially.
Base fee after consecutive full blocksGwei, starting at 10 gwei, up 12.5% per block
Each consecutive full block multiplies the base fee by 1.125. Values after five, ten and twenty blocks are rounded.
The math is unforgiving when demand is sustained, which is precisely what happens during peak trading windows.
## Why the fee can spike mid-day: the human and algorithmic demand cycle
The timing of gas spikes is not random. Because Ethereum's base fee dynamically adjusts based on network demand, transaction costs can vary widely throughout the day.
The most consistent pattern in Ethereum's fee history is geographic and commercial. Ethereum gas fees consistently peak Tuesday through Thursday, between 14:00 and 18:00 UTC, due to overlapping US and European trading hours and automated bot activity. Weekends, especially early mornings UTC between 2 AM and 6 AM, offer the lowest fees of the week, often dropping to roughly half of weekday rates.
The magnitude of this intraday swing is significant. Weekday peak periods can run three to five times higher than the quietest overnight weekend windows. For a professional routing a high-value transaction and treating the morning gas estimate as representative of afternoon cost, that gap is consequential.
The reasons for the peak-hour spike involve layered demand. The first layer is straightforward: more people transact during business hours. The second layer is less visible but arguably more impactful.
Ethereum's gas market is also shaped heavily by automated systems — arbitrage bots, MEV searchers, and liquidation bots — that operate continuously, but whose profitability is tied to how much human trading activity is happening at any given moment. When markets are quiet, there is simply less price divergence for arbitrage bots to exploit, fewer large trades for MEV searchers to front-run or sandwich, and fewer positions sitting near liquidation thresholds.
When human trading volume surges during the Tuesday-to-Thursday window, all of that automated activity surges right alongside it, compounding the fee pressure rather than replacing it. This is part of why the peak windows tend to be so consistently sharp rather than gradual.
The automated layer deserves more attention than it typically receives in gas fee discussions.
## MEV bots and the hidden demand multiplier
Maximal Extractable Value — MEV — refers to the profit that can be captured by controlling the order of transactions within a block. In proof-of-stake Ethereum, block production involves three main roles: searchers, who find profitable opportunities and create transaction bundles; builders, who collect these bundles and construct candidate blocks; and validators, also called proposers, who choose which block to include on the chain. This division of roles is known as proposer-builder separation.
The competition between searchers to capture MEV opportunities is what transforms peak-hour volume into exponential fee pressure. When several bots compete to capture the same opportunity, they send many overlapping transactions with high gas bids. Most of those transactions never succeed, but still consume block space. One Flashbots analysis described an arbitrage bot that, on average, consumed gas equal to almost four full Ethereum blocks for each successful arbitrage because hundreds of failed attempts were included. This kind of behaviour can push gas fees higher for everyone.
In practice, this means that transaction costs become less predictable. You might see normal network conditions one minute, then a sharp spike the next as bots swarm a profitable opportunity.
To put the scale in context: the average sandwich attack only nets about $3 (AUD 4.70) in profit, but there are over 4,400 attacks per day on Ethereum — more than one per block. Each of those attacks involves multiple transactions bidding aggressively for block priority, adding demand to every block they touch.
Arbitrage bots typically pay 50–60% of their profits as tips to validators. That is not charity — it is the cost of being included before a competitor. And every elevated tip bid creates upward pressure on the priority fee environment that every other transactor is navigating simultaneously.
## What a mid-day spike actually looks like in practice
Consider a concrete scenario. A title company is coordinating an onchain commercial property settlement at 11:00 AM Eastern Time — 15:00 UTC, squarely in the peak window. The parties have agreed to use an onchain payment router to distribute the proceeds simultaneously: seller, lender payoff, brokerage commission, and legal fees, all from a single incoming transfer.
At 10:45 AM, the settlement agent checks gas. The base fee is sitting at 8 gwei. The all-in estimate for the routing transaction — which involves slightly more computation than a simple transfer, because it is executing multi-party logic — comes to approximately $6.20 (AUD 9.71). The agent notes it and moves forward with final document preparation.
At 11:03 AM, a large DeFi protocol executes a governance vote that triggers a wave of liquidity repositioning. Automated systems detect arbitrage gaps across three decentralised exchanges simultaneously. Hundreds of bot transactions flood the mempool, each bidding competitively for the next block. When demand for transaction inclusion exceeds supply, the base fee rises. When demand drops, it falls. The 12.5% adjustment cap per block means the base fee cannot spike instantly — it takes several consecutive full blocks to drive a significant increase.
By 11:07 AM, after six consecutive blocks above target capacity, the base fee has climbed from 8 gwei to roughly 16 gwei. During congestion, large NFT mints, liquidations, and airdrop claims can push priority fees to 50+ gwei. In a hot MEV environment, priority fee pressure stacks on top of the base fee increase, and the total gas cost for that routing transaction is now closer to $19 (AUD 29.77).
Nothing about the transaction itself changed. The payment is still going to the same parties, in the same proportions, from the same sender. The network simply became more competitive between the estimate and the landing.
## The gap between estimate and reality: five failure modes
Professionals routing high-value payments onchain encounter predictable categories of estimation error. Understanding each one prevents operational surprises.
**Stale estimates.** Opening the estimator earlier and never refreshing before sending is a common source of divergence. In a quiet market, a twenty-minute-old estimate may still be accurate. During peak hours, a four-minute-old estimate can be materially wrong.
**Flat priority fee assumptions.** Many wallet interfaces surface a simplified "slow / standard / fast" selector. These are simplified bundles of fee assumptions. They are calibrated to recent history, not to what the mempool looks like in the seconds before signing. When bot activity surges, the "fast" preset may still underbid.
**Contract complexity underestimation.** A transaction that routes to multiple recipients is not equivalent to a simple token transfer. Complex transactions like swaps or smart contract interactions also cost more gas than simple ETH transfers. Gas estimates must be run against the actual call — the specific contract function, with the actual recipients and amounts — not a generic transfer approximation.
**Ignoring mempool competition signals.** Pending transactions tell the estimator whether lots of users are already bidding for inclusion. A professional routing tool or wallet that does not surface mempool depth is leaving a critical data point off the dashboard.
**Over-reliance on historical averages.** Major events still cause up to 10× fee spikes despite overall lower baseline fees. The fact that average fees have fallen dramatically since 2021 does not mean spikes cannot occur. It means the baseline is lower, but the shape of the spike — driven by block-by-block feedback — is the same.
## The structural improvement: lower baselines, same mechanics
It would be misleading to discuss gas volatility without noting how much the cost landscape has shifted. Average gas prices fell from approximately 72 gwei in early 2024 to approximately 2.7 gwei by March 2025 — a roughly 96% drop. Current average transaction fees sit around $0.34 (AUD 0.53) per transaction as of late 2025.
Several protocol upgrades drove that improvement. The most significant recent upgrades are Dencun in March 2024, Pectra in May 2025, and Fusaka in December 2025. The community raised the L1 gas limit from 30 million to 60 million during 2025, and Fusaka standardised 60 million as the new default. More block capacity means less competition per transaction in a given block, which keeps the base fee lower on average.
But lower averages do not flatten the volatility curve. Lower average fees do not remove competition — they make timing even more tradable, because more users are willing to transact when costs feel manageable. When fees are at historic lows, more participants enter the market, and the incremental demand of a single significant event — a large liquidation cascade, a high-profile token launch, a governance vote with time pressure — is enough to trigger the compounding base fee mechanism.
EIP-1559 improved fee predictability but did not reduce fees: total costs still depend on network congestion. The protocol gives professionals better tools to anticipate and budget for gas. It does not eliminate the underlying supply-and-demand reality of block space.
## Practical implications for settlement professionals
What does all of this mean for the people actually orchestrating high-value onchain payments?
**Budget gas as a range, not a point.** When preparing for a significant onchain settlement, the appropriate question is not "what is the gas fee?" but "what is the 90th-percentile gas fee during the window when this transaction will land?" The difference between median-hour and peak-hour costs for a smart contract transaction can easily be a factor of three to five. That range should be communicated to all parties before the transaction is initiated.
**Understand the timing window.** During peak usage hours, typically aligned with U.S. business hours from around 2 PM to 6 PM UTC, gas fees tend to spike as traders, developers, and institutions all compete for block space. For a settlement agent in New York, that is the 10 AM to 2 PM Eastern window — exactly when most deal closings are scheduled. For an agent in Sydney, the equivalent risk window is overnight. Scheduling flexibility, where it exists, has real dollar value.
**Refresh estimates immediately before signing.** Refresh the estimator right before signing, and check recent on-chain activity in a block explorer to see whether current blocks support the quote. The estimate is a live market quote, not a locked price.
**Favour tools that execute in a single transaction.** Every additional transaction in a settlement flow is an additional gas exposure event. An architecture that requires one transaction to fund escrow, a second to release it, and a third to distribute fees compounds the timing risk threefold. A routing structure that moves funds from sender to all receiving parties in a single execution has exactly one gas event to manage.
**Build confirmation into the workflow.** Onchain transactions, once included in a block, are final. There is no reversal, no charge-back process, no clearing window. That finality is the value proposition for settlement — a payment confirmed on Ethereum is settled, fully, at the block timestamp. But it also means the gas cost, whatever it turns out to be, is a sunk cost at confirmation. Build a buffer into gas estimates and treat any refund from an overestimated `maxFeePerGas` as a pleasant outcome rather than an expectation.
## How routing architecture interacts with gas exposure
For professionals evaluating onchain payment infrastructure, the architectural choice between single-transaction routing and multi-step workflows is not just an operational preference — it is a gas risk decision.
A multi-step workflow — fund a holding address, then distribute, then confirm with each recipient — means three separate transactions, each subject to the gas market at the moment it lands. If a spike occurs between step one and step two, the total gas cost for the settlement is materially higher than any single estimate suggested.
A single-transaction router executes the split and distribution atomically. All parties receive their allocation in the same block, from the same call. There is one gas event, one price exposure, and one confirmation. The gas estimate applies to that one event. The complexity is absorbed by the smart contract; the gas cost is a function of how many output addresses the split touches and the computational overhead of the routing logic — not of sequencing multiple transactions across multiple blocks.
This is precisely the architecture that shaka.deal is built around. The platform receives an incoming payment and distributes it simultaneously to every party at preset shares, in a single transaction, with finality. One gas event. Preset distribution logic. No sequencing risk between steps. For a settlement agent or escrow officer managing a closing with four or five parties receiving different allocations, that means one estimate to budget, one confirmation to watch for, and one gas cost to account for — rather than a chain of exposures that compounds with each step.
## Reading the signals: what to watch before a high-value transaction
For professionals who want to actively manage gas exposure rather than simply absorb it, the signals are readable in advance.
Gas tracker dashboards — Etherscan's gas tracker, Blocknative's gas estimator, and similar tools — surface the current base fee and project the next block's base fee based on the current block's fullness. A base fee that has risen more than 20% in the past ten minutes is a yellow flag. A base fee rising more than 40% in that window, combined with elevated pending transaction counts, is a signal to pause and decide whether the timing is avoidable.
Scrutinising all public pending transactions on Ethereum enables the accurate prediction of the minimum gas price required for the next-block confirmation. Advanced mempool tooling makes this visible in real time for professionals who need it.
Geographic user demand cycles from Asia and the US create predictable fee volatility patterns. These patterns mean that a closing scheduled for 11 AM Eastern on a Wednesday is, by definition, being executed at the highest-risk point in the weekly gas cycle. A closing at the same time on a Sunday morning is at the lowest-risk point. Neither is always possible to control — deals close when the documents are ready — but awareness of the pattern is the first step toward managing it.
## The final word on certainty
Gas estimation is an inherently probabilistic activity. The estimate a wallet surfaces is the best projection available at the moment it is computed, using the current chain state and the current mempool. It is not a contract. The fee that lands on the blockchain is determined by the competitive market for block space at the exact moment the transaction is included — a moment that may be seconds or minutes after the estimate was generated.
With or without EIP-1559, transaction fees will be high whenever the demand for EVM computation far exceeds its supply. The point of EIP-1559 is to make transaction fees *more predictable*, making the fee estimation problem — choosing the optimal gas price for a transaction — as straightforward as possible.
More predictable is not the same as perfectly predictable. The protocol gives professionals better tools. Peak-hour demand, MEV competition, and sudden market events still create spikes. The professionals who operate most effectively on Ethereum are those who understand this dynamic, build appropriate buffers, and choose infrastructure that minimises the number of gas exposures in any given settlement workflow.
The mechanics described in this article are not going away. Block space is a finite resource. When demand for transaction inclusion exceeds supply, the base fee rises. That is not a flaw. It is the pricing mechanism of a decentralised network operating under honest rules. Working with it — rather than being surprised by it — is the professional standard.