8 posts tagged with "gas"

There are 842,000 transactions sitting in the Ethereum mempool right now that have been there for more than 24 hours. Most people assume they're stuck because gas fees went up. That's wrong.

69% of them — 582,000 transactions — are mathematically impossible to include. Not "too expensive to bother with," but literally incapable of being mined at any point in the future at their current pricing.

And inside that group, there's a quieter disaster: 9,436 wallets are in a nonce death lock, where one underpriced transaction from days ago has frozen every subsequent transaction the address ever tried to send.

Ethereum's gas fees are close to zero. Everyone knows that. What's less obvious is what the collapse did to where the fees go — and what it means for EIP-1559's core promise.

In January 2025, for every ETH a user paid in gas, roughly 82% was burned and 18% went to validators as tips. Today it's the opposite: roughly 89% goes to validators and 11% is burned. The ratio didn't shift gradually. It inverted in a single month.

There's a simulation running on every mainnet block that almost nobody talks about. EthPandaOps built it. It watches every EVM opcode across every transaction and asks a question the current gas price deliberately ignores: what kind of resource is this gas actually paying for?

The answer changes everything about how you think about gas pricing.

Ethereum's base fee is so low right now — bouncing between 0.025 and 0.97 gwei — that something unexpected has emerged in the mempool: a class of transactions that aren't too cheap to ever be included. They're just cheap enough to wait.

At 0.027 gwei, the median time to inclusion is 2.6 hours. At 0.030 gwei, it's 57 seconds. Three thousandths of a gwei separate an hour of waiting from near-instant inclusion — and whether you wait depends almost entirely on what time UTC it is when you submitted.

Ethereum block execution isn't a fixed-cost operation. For small blocks the state LRU cache handles nearly everything. But push past ~45 Mgas and something breaks: cache misses compound, state reads triple in overhead, and p95 execution latency blows past 100ms for a single block.

Nobody talks about this because mgas/s benchmarks measure throughput — not the hidden cost of cold cache reads. The gas limit doubling from 30M to 60M made this matter.

When people talk about the Ethereum Virtual Machine, they reach for the "world computer" metaphor — a globally shared processor executing smart contract code. That framing implies computation: arithmetic, cryptography, logic. In practice, the EVM spends more than half its gas budget on something far more mundane: reading and writing persistent state.

Every week, roughly 1,440 gigagas of EVM execution passes through the mainnet. More than half — 56.7% — goes to exactly two opcodes.

I started this looking for evidence that high-MEV blocks are harder for execution clients to process. The intuition is obvious: MEV blocks are full of complex DeFi interactions, sandwich attacks, arbitrage — all the state-thrashing stuff. Surely they're heavier to execute.

They're not. The correlation between MEV block value and newPayload execution time is r = −0.004. Essentially random noise.

What actually predicts execution latency is simpler and more boring: how much gas the block used.

The "Ethereum Virtual Machine" sounds like a computation engine. In practice, looking at 101 blocks of opcode execution data, it spends most of its time doing something much more mundane: reading and writing state.

SSTORE and SLOAD together account for 60.7% of all gas consumed on mainnet. Every other opcode — arithmetic, hashing, control flow, cross-contract calls — splits the remaining 39.3%.