EVM Threat Models

0x45-GASLIMIT

21 min read

Opcode Summary

PropertyValue
Opcode0x45
MnemonicGASLIMIT
Gas2
Stack Input(none)
Stack Outputblock.gaslimit (uint256)
BehaviorPushes the gas limit of the current block onto the stack. The gas limit defines the maximum total gas that all transactions in the block can consume. Validators adjust this value between blocks within a protocol-constrained range (±1/1024 of the parent block’s gas limit per block). On Ethereum mainnet, the gas limit is currently ~36M and trending toward 60M via coordinated validator signaling (EIP-7790). On L2s, the gas limit varies dramatically — Arbitrum’s effective execution limit is 32M, Base operates with ~140M across Flashblocks, and OP Stack chains have their own configurations.

Threat Surface

GASLIMIT exposes a block-level protocol parameter that is both mutable over time and partially validator-controlled. Unlike static opcodes, the value returned by GASLIMIT changes across blocks as validators collectively vote on the network’s throughput capacity. This creates a uniquely temporal attack surface: contracts that work today may break tomorrow if the gas limit shifts.

The threat surface centers on four properties:

  1. GASLIMIT changes over time by validator consensus. Each block’s gas limit can differ from its parent’s by up to 1/1024 (~0.1%). Over hundreds of blocks, validators can collectively push the gas limit significantly higher or lower. The gas limit has changed multiple times in Ethereum’s history — from 5,000 at genesis, to 8M during the Fomo3D era (2018), to 15M, to 30M post-EIP-1559, and currently trending toward 60M via EIP-7790 coordinated increases. Any contract that hardcodes a gas limit value or relies on it remaining within a specific range will eventually break.

  2. GASLIMIT is predictable but not constant. The gas limit for the next block is tightly bounded by the current block’s gas limit (±1/1024). This means the value is almost perfectly predictable for the next block, somewhat predictable over tens of blocks, and entirely unpredictable over months or years. Contracts using block.gaslimit for randomness get near-zero entropy. Contracts using it for capacity planning face long-term drift.

  3. GASLIMIT interacts with denial-of-service vectors. The gas limit defines the upper bound on computation per block. Contracts with loops, batch operations, or payout functions that scale with the number of participants can become permanently unexecutable if they require more gas than the block limit allows. If the gas limit drops (validators voting it down), previously-executable functions may become too expensive to call.

  4. GASLIMIT differs radically across L2s. Arbitrum reports an artificially large gas limit (~1.1 quadrillion) but caps effective execution at 32M. Base distributes ~140M gas across 10 Flashblocks. OP Stack chains have their own gas limit configurations controlled by the sequencer. Contracts that use block.gaslimit for on-chain logic will observe wildly different values across chains, breaking cross-chain assumptions.

Smart Contract Threats

T1: Using block.gaslimit for Randomness (High)

block.gaslimit is sometimes included in pseudo-random number generation alongside other block variables. This is fundamentally broken because the gas limit is highly predictable:

  • Near-constant between adjacent blocks. The gas limit can only change by ±1/1024 per block (~29K at a 30M gas limit). For practical purposes, any attacker who knows the current block’s gas limit knows the next block’s gas limit with near-certainty. Most validators leave the gas limit unchanged unless actively participating in a coordinated increase/decrease campaign.

  • Publicly observable. The gas limit of every block is part of the block header and visible to all participants. Any attacker can read the current gas limit and compute the exact randomness output for the next block before submitting their transaction.

  • Adds zero meaningful entropy. Even when combined with block.timestamp, block.coinbase, or block.prevrandao in a hash, adding block.gaslimit to the entropy mix contributes effectively zero additional bits of entropy because the value is so predictable. Developers may believe they’re strengthening randomness by including more block variables, but the gas limit is the weakest possible input.

  • Constant on L2s for long periods. On many L2 chains, the gas limit is a fixed configuration value that only changes during sequencer upgrades, making it a literal constant for randomness purposes.

Why it matters: Any lottery, NFT mint ordering, gambling contract, or random selection mechanism that includes block.gaslimit in its entropy computation provides a false sense of security. The attacker can predict the gas limit component with near-perfect accuracy.

T2: Gas Limit-Dependent Loop Bounds (Critical)

Contracts that use block.gaslimit to determine how many iterations a loop should perform, or that scale batch operations relative to the gas limit, are vulnerable to denial of service and unpredictable behavior:

  • Unbounded growth. If a loop iterates block.gaslimit / someConstant times, the number of iterations grows as validators increase the gas limit. A function designed when the gas limit was 8M might iterate 10x more at 80M, potentially exceeding storage or memory bounds in unexpected ways.

  • Sudden reduction. If validators vote the gas limit down (historically rare but possible), loop iterations decrease, potentially leaving work incomplete. Functions that assumed “enough iterations to process all pending items” may leave items unprocessed.

  • Cross-chain divergence. A contract deployed on Arbitrum sees an artificially large gas limit (~1.1 quadrillion), causing any loop bound based on block.gaslimit to attempt an astronomically large number of iterations, immediately running out of gas.

Why it matters: The gas limit is not a stable constant. Using it as a computation parameter creates functions whose behavior changes over time and across chains without any contract upgrade.

T3: Hardcoded Gas Limit Assumptions (High)

Contracts that embed specific gas limit values as constants or thresholds will eventually break as the gas limit evolves:

  • require(block.gaslimit >= X) guards. Contracts that check the gas limit meets a minimum threshold may fail on chains with lower gas limits or after a gas limit decrease. Conversely, require(block.gaslimit <= X) guards will fail after gas limit increases.

  • Gas estimation based on gas limit fractions. Contracts that compute gas budgets as fractions of block.gaslimit (e.g., “use 1/4 of the block gas limit for this sub-call”) produce different behavior as the gas limit changes. A sub-call budgeted at 7.5M gas (1/4 of 30M) behaves differently from one budgeted at 15M (1/4 of 60M).

  • Deployment-time assumptions. Contracts deployed when block.gaslimit was 8M that assumed “the gas limit will always be around 8M” broke when it increased to 30M. The same will happen to contracts assuming 30M when it reaches 60M.

Why it matters: Gas limit changes are governance-level events that happen without any on-chain signal to existing contracts. There is no callback or event when the gas limit changes — contracts simply start seeing a different value.

T4: Denial of Service When Gas Limit Drops (Medium)

If the block gas limit decreases, contracts with functions that require gas close to the current limit may become permanently unexecutable:

  • Payout functions that iterate over all participants. A function that loops over an array of addresses to distribute rewards may work at a 30M gas limit but become unexecutable if the gas limit drops and the array has grown large enough. The GovernMental Ponzi scheme demonstrated this class of vulnerability — its payout function required clearing a large array, which exceeded the block gas limit, permanently locking ~1,100 ETH.

  • Migration and cleanup functions. Contract upgrade patterns that involve migrating state in a single transaction may fail if they were designed around a higher gas limit than currently available.

  • Compounding failure. Once a function exceeds the gas limit, it cannot execute. If the function is the only way to reduce the state that makes it expensive (e.g., clearing an array), the contract enters a permanent deadlock where the fix requires the broken function to run.

Why it matters: A gas limit decrease is a protocol-level change that can permanently brick contracts without any bug in the contract code itself.

T5: Validator Gas Limit Manipulation (Low)

Validators collectively control the block gas limit through the 1/1024 adjustment rule. While no single validator can make drastic changes, coordinated groups can shift the gas limit over time:

  • 1/1024 per block adjustment. Each validator can raise or lower the gas limit by ~0.1% per block they propose. At ~7,200 blocks per day, a coordinated majority of validators could shift the gas limit by ~7x over a day (1.001^7200 ≈ 1330x theoretical maximum, though in practice consensus mechanisms and client defaults limit this).

  • Coordinated increases for capacity attacks. Validators who want to increase network throughput (to earn more fees) can vote the gas limit up. Historically, miners coordinated to raise the gas limit from 8M to 12.5M in 2020. Very high gas limits increase state growth and can strain node operators with limited hardware.

  • Coordinated decreases for denial of service. A colluding majority of validators could vote the gas limit down to very low values, reducing network throughput and causing transaction congestion. This would be economically irrational (validators earn less in fees) but could be used for extortion or competitive attacks.

  • Client default influence. Most validators use default gas limit targets set by their client software (e.g., Geth, Prysm). A single client update changing the default target can move the entire network’s gas limit if that client has majority market share.

Why it matters: The gas limit is a soft-governance parameter. Contracts cannot assume it will remain stable, and shifts — especially downward — can break contracts that depend on sufficient block capacity.

Protocol-Level Threats

P1: Validator Gas Limit Voting and Network Capacity (Medium)

The gas limit voting mechanism is Ethereum’s primary throughput control. Each block proposer sets the gas limit within ±1/1024 of the parent’s gas limit (defined by GasLimitBoundDivisor = 1024 in the protocol). This creates a slow-moving governance lever:

Security implications:

  • No hard floor or ceiling (pre-EIP-7790). The protocol does not enforce a minimum or maximum gas limit — only that each block’s limit is within 1/1024 of its parent. In theory, validators could push the gas limit arbitrarily low (down to the minimum of 5000) or arbitrarily high, given enough coordinated blocks.

  • EIP-7790 coordinated increases. The current coordinated gas limit increase (from 30M toward 60M at 6 gas per block starting from block 21,792,420) demonstrates that validator coordination on gas limits is an active governance process. Contracts should expect the gas limit to reach 60M and plan accordingly.

  • State growth amplification. Higher gas limits allow more computation per block, which increases the rate of state growth (new storage slots, new contracts, new accounts). This puts pressure on full node operators and may lead to future gas limit decreases to manage state bloat.

P2: Block Stuffing Attacks Exploiting Gas Limit Capacity (High)

The block gas limit defines the finite capacity of each block. Attackers can exploit this by filling blocks with their own transactions, preventing legitimate transactions from being included:

  • Fomo3D-style block stuffing (2018). The attacker submitted transactions consuming up to 4.2M gas per transaction (half the 8M gas limit at the time) with extremely high gas prices. Miners prioritized these high-paying transactions, filling blocks and preventing competitors’ transactions from being included for ~11 consecutive blocks.

  • Post-EIP-1559 block stuffing is more expensive but still possible. Under EIP-1559, blocks can expand to 2x the target gas limit. An attacker must pay the base fee (which increases exponentially with consecutive full blocks) plus priority fees. Block stuffing for 11 blocks at a 30M target costs significantly more than at 8M with legacy fee markets, but remains economically viable for sufficiently high-value targets.

  • Gas limit increases make block stuffing more expensive. A higher gas limit means more capacity per block, requiring the attacker to spend more gas (and ETH) to fill each block. The move from 30M to 60M roughly doubles the cost of block stuffing attacks.

Edge Cases

Edge CaseBehaviorSecurity Implication
Gas limit changes between consecutive blocksCan differ by up to ±1/1024 (~29K at 30M gas limit)Contracts reading block.gaslimit in consecutive blocks may see slightly different values; near-zero entropy for randomness
Very low gas limit (near protocol minimum of 5000)Only the simplest transactions can be included; most contract calls failMass denial of service for all contracts; practically impossible on mainnet due to validator economics
Very high gas limit (e.g., 60M+ after EIP-7790)More computation per block; larger transactions possiblePreviously gas-limit-bounded loops may iterate more; state growth accelerates; node hardware requirements increase
L2 gas limits (Arbitrum)Reports ~1.1 quadrillion but effective execution limit is 32MContracts using block.gaslimit for arithmetic will compute wildly wrong values; loop bounds based on gas limit will overflow or consume all gas
L2 gas limits (Base with Flashblocks)~140M total gas distributed across 10 FlashblocksIndividual Flashblock gas limits vary (14M to 140M cumulative); contracts see different gas limits than on L1
L2 gas limits (OP Stack)Sequencer-configured, differs from L1Static and controlled by sequencer; changes only on sequencer config updates
Gas limit in STATICCALLReturns the same block.gaslimit as any other contextNo variation across call types; gas limit is a block property
Gas limit during contract creationSame block.gaslimit as runtime executionConstructor logic using gas limit sees the same value as deployed code
Gas limit == gasleft()If only one transaction fills the block, gasleft() approaches block.gaslimit minus intrinsic gasNot a reliable equivalence; multiple transactions share the block gas limit
Post-EIP-1559 elastic blocksBlocks can use up to 2x the target gas (e.g., 60M at 30M target)block.gaslimit reflects the actual limit (not the target); during high demand, the limit may be at the elastic maximum

Real-World Exploits

Exploit 1: GovernMental Ponzi — 1,100 ETH Permanently Locked by Gas Limit DoS (2016)

Root cause: A payout function required clearing a dynamically-growing array of creditor addresses in a single transaction, eventually exceeding the block gas limit.

Details: GovernMental was an educational Ponzi scheme contract on Ethereum. Users invested ETH and were promised 10% returns from subsequent investors. The contract maintained arrays of creditor addresses and creditor amounts that grew with each new investment. When the Ponzi needed to pay out its jackpot, the payout function had to clear both arrays:

creditorAddresses = new address[](0);
creditorAmounts = new uint[](0);

As the number of creditors grew, the gas required to reset these arrays (zeroing storage slots) exceeded the block gas limit. The payout transaction could never complete, permanently locking approximately 1,100 ETH in the contract.

GASLIMIT’s role: The contract implicitly depended on block.gaslimit being large enough to process its entire creditor list in a single transaction. As the creditor list grew, the gas required surpassed the block gas limit (~4.7M at the time), making the function permanently unexecutable. The contract had no fallback mechanism, pagination, or batch processing alternative.

Impact: ~1,100 ETH permanently locked. Became the canonical example of gas limit denial of service in smart contract security education. The OWASP Smart Contract Top 10 (SC09) and virtually every smart contract security guide cite this pattern.

References:

Exploit 2: Fomo3D — Block Stuffing Attack Using Gas Limit Capacity ($3M, August 2018)

Root cause: The attacker exploited the finite block gas capacity to prevent competitors’ transactions from being included, running down a game timer to claim a jackpot.

Details: Fomo3D was a “last buyer wins” game where the last person to purchase a “key” before a countdown timer expired won the pot. Each key purchase reset the timer. The attacker (address 0xa169) deployed smart contracts that conditionally consumed massive amounts of gas via assert() failures. The contracts called getCurrentRoundInfo() to monitor the game state, and when the attacker was the last key buyer and the timer was nearly expired, the contracts activated.

Each attack transaction consumed up to 4.2M gas — roughly half the 8M block gas limit at the time — and offered extremely high gas prices to ensure miners prioritized them. For approximately 11 consecutive blocks (6191898-6191908), the attacker’s transactions filled the blocks, reducing the number of legitimate transactions per block from hundreds to single digits (3-92 transactions per block). This prevented any competitor from purchasing a key to reset the timer.

GASLIMIT’s role: The attack directly exploited the block gas limit as a finite resource. At 8M gas limit, two attack transactions at 4.2M gas each nearly filled an entire block. The attacker’s strategy was calibrated to the specific gas limit — consuming enough gas to crowd out competitors while leaving just enough room for miners to include the attack transactions themselves. If the gas limit had been significantly higher (as it is today at 30M+), the attack would have been proportionally more expensive.

Impact: 10,469.66 ETH (~$3M) stolen. Demonstrated that the block gas limit is an attackable resource that adversaries will exploit when sufficient value is at stake. Led to widespread awareness of block stuffing as an attack vector.

References:

Exploit 3: Sepolia Testnet Incident — Gas Limit vs. RPC Message Size Mismatch (February 2024)

Root cause: Inconsistent RPC message size limits between Ethereum clients allowed crafting blocks that fit within the gas limit but exceeded certain clients’ message size constraints, causing consensus divergence.

Details: On February 6-7, 2024, Ethereum Foundation researchers discovered a vulnerability that had existed since The Merge. Blocks could be constructed with many transactions that individually stayed below the 128KB transaction size limit and collectively stayed within the 30M gas block limit, but when assembled into a block, produced an RPC message exceeding certain clients’ HTTP message size limits (notably Geth’s lower threshold).

An attacker could craft blocks up to 2.7MB compressed by submitting multiple high-paying transactions with large calldata. These blocks were valid per the gas limit but would be rejected by clients with smaller RPC message limits. This caused a network split: some clients accepted the block while others rejected it, leading to repeated chain reorganizations and consensus failures.

GASLIMIT’s role: The gas limit defined the block’s computational validity. The vulnerability arose because the gas limit alone was insufficient to bound the block’s data size — a block could be gas-valid but size-invalid for certain clients. This exposed a gap between the gas limit’s role as a computation bound and the practical limits on block propagation. The incident led to EIP-7825 (Transaction Gas Limit Cap at 2^24 gas) to create a tighter coupling between gas limit and block size.

Impact: Discovered and patched before mainnet exploitation. The vulnerability could have caused sustained consensus failures and chain reorganizations on mainnet. Geth released a fix on February 9, 2024, and the Dencun hard fork fully resolved the issue.

References:

Attack Scenarios

Scenario A: Unbounded Loop Exceeds Gas Limit (DoS)

contract VulnerableAirdrop {
    address[] public recipients;
    mapping(address => uint256) public amounts;
 
    function addRecipient(address r, uint256 amount) external {
        recipients.push(r);
        amounts[r] = amount;
    }
 
    function distributeAll() external {
        // VULNERABLE: If recipients grows large enough, this loop
        // requires more gas than block.gaslimit, and the function
        // becomes permanently unexecutable.
        for (uint256 i = 0; i < recipients.length; i++) {
            payable(recipients[i]).transfer(amounts[recipients[i]]);
        }
        delete recipients;
    }
 
    // Attack: An attacker calls addRecipient() thousands of times
    // (with dust amounts or their own addresses). Eventually,
    // distributeAll() exceeds block.gaslimit and all funds are locked.
    // At ~9,000 gas per transfer + SLOAD, 30M gas limit allows
    // ~3,000 recipients. The 3,001st locks the contract.
}

Scenario B: Hardcoded Gas Limit Assumption Breaks Over Time

contract VulnerableBatchProcessor {
    uint256 constant EXPECTED_GAS_LIMIT = 30_000_000;
 
    function processBatch(uint256[] calldata items) external {
        // VULNERABLE: Assumes gas limit is always ~30M.
        // When gas limit increases to 60M, batchSize doubles,
        // potentially processing more items than intended or
        // exceeding memory bounds.
        uint256 batchSize = block.gaslimit / 10_000;
        uint256 end = items.length < batchSize ? items.length : batchSize;
 
        for (uint256 i = 0; i < end; i++) {
            _process(items[i]);
        }
    }
 
    function isNetworkHealthy() external view returns (bool) {
        // VULNERABLE: Will return false when gas limit exceeds 35M,
        // even though the network is perfectly healthy.
        return block.gaslimit >= 25_000_000 &&
               block.gaslimit <= 35_000_000;
    }
 
    function _process(uint256 item) internal { /* ... */ }
}

Scenario C: Gas Limit as Broken Randomness Source

contract VulnerableRaffle {
    address[] public entrants;
 
    function enter() external payable {
        require(msg.value == 0.01 ether);
        entrants.push(msg.sender);
    }
 
    function pickWinner() external {
        require(entrants.length >= 20);
 
        // VULNERABLE: block.gaslimit is nearly constant between blocks
        // (changes by at most ~29K out of 30M). An attacker can read
        // the current gas limit, predict the next block's value with
        // near-certainty, and compute the winner index before entering.
        uint256 seed = uint256(keccak256(abi.encodePacked(
            block.gaslimit,
            block.timestamp,
            block.number
        )));
        uint256 winnerIndex = seed % entrants.length;
 
        payable(entrants[winnerIndex]).transfer(address(this).balance);
        delete entrants;
    }
 
    // Attack: Attacker reads current block.gaslimit (nearly identical
    // to next block's). Predicts block.timestamp within ~12s window.
    // block.number is deterministic. Precomputes winner for every
    // possible timestamp and enters only when they win.
}

Scenario D: Cross-Chain Gas Limit Divergence on Arbitrum

contract VulnerableCrossChain {
    function estimateCapacity() external view returns (uint256) {
        // VULNERABLE: On Arbitrum, block.gaslimit returns
        // ~1,125,899,906,842,624 (artificially inflated).
        // This returns a capacity estimate ~37 million times too large.
        return block.gaslimit / 30;
    }
 
    function allocateResources() external {
        uint256 slots = block.gaslimit / 1_000_000;
        // On Ethereum mainnet (30M): slots = 30 (reasonable)
        // On Arbitrum (~1.1 quadrillion): slots = ~1.1 billion (DoS)
        // On Base (~140M): slots = 140 (unexpected but survivable)
 
        // Attempting to allocate 1.1 billion slots will consume
        // all available gas and revert on Arbitrum.
        uint256[] memory buffer = new uint256[](slots);
        _processSlots(buffer);
    }
 
    function _processSlots(uint256[] memory buffer) internal { /* ... */ }
}

Mitigations

ThreatMitigationImplementation
T1: Gas limit for randomnessUse verifiable randomness sourcesChainlink VRF v2+ for provably fair randomness; commit-reveal schemes for lower-stakes use cases. Never include block.gaslimit in entropy computations.
T2: Gas limit-dependent loop boundsUse explicit, hardcoded batch limitsuint256 constant MAX_BATCH = 500; — never derive loop bounds from block.gaslimit. Process large datasets across multiple transactions with pagination.
T3: Hardcoded gas limit assumptionsAvoid referencing block.gaslimit in contract logicRemove all conditional checks against specific gas limit values. If capacity estimation is needed, use off-chain computation and pass results as function parameters.
T4: DoS when gas limit dropsPull-over-push payment patternLet recipients withdraw individually (withdraw()) instead of pushing to all recipients in a single loop. Use OpenZeppelin’s PaymentSplitter or claim-based distribution.
T4: Unbounded array operationsPaginated processing with progress trackingTrack a processedIndex in storage; each call processes a fixed-size batch starting from the index. function processBatch(uint256 batchSize) external { ... }
T5: Validator gas limit manipulationDesign contracts to be gas-limit-agnosticNever assume a specific gas limit. Ensure all functions complete within a small fraction of any reasonable gas limit.
Cross-chain gas limit divergenceChain-aware gas limit handlingCheck block.chainid and use chain-specific constants instead of block.gaslimit for capacity estimation. Or avoid block.gaslimit entirely.
Block stuffing attacksTime-based expiry with grace periodsUse longer timeout windows (not “last action before expiry” patterns). Add grace periods that survive block stuffing. Require multiple blocks of inactivity before triggering time-sensitive actions.

Compiler/EIP-Based Protections

  • EIP-1559 (London, August 2021): Introduced elastic block sizes with a target gas limit and a max gas limit (2x target). Blocks can temporarily exceed the target, and the base fee adjusts to discourage sustained full blocks. This makes block stuffing exponentially more expensive over consecutive blocks.
  • EIP-7790 (Controlled Gas Limit Increase): Defines a coordinated schedule for increasing the gas limit from 30M to 60M at 6 gas per block. Provides predictability for the gas limit trajectory, but contracts should not hardcode the target.
  • EIP-7825 (Transaction Gas Limit Cap): Proposes capping individual transaction gas at 2^24 (16,777,216) gas, independent of the block gas limit. Prevents single transactions from consuming excessive block space and mitigates certain DoS vectors.
  • Solidity optimizer: The Solidity compiler does not optimize away block.gaslimit reads or provide warnings about its use in arithmetic or randomness. Developers must rely on static analysis tools (Slither, Mythril) to detect gas limit misuse.

Severity Summary

Threat IDCategorySeverityLikelihoodReal-World Precedent
T1Smart ContractHighMediumGambling DApps using block variables for randomness (2017-2019, OWASP SC08)
T2Smart ContractCriticalHighGovernMental (~1,100 ETH locked), OWASP SC09
T3Smart ContractHighMediumContracts breaking after gas limit changes from 8M → 30M (ongoing)
T4Smart ContractMediumLowGovernMental, theoretical gas limit decrease scenarios
T5Smart ContractLowLowCoordinated miner gas limit increases (2020), no malicious exploitation on record
P1ProtocolMediumMediumEIP-7790 coordinated increase; historical miner-driven gas limit changes
P2ProtocolHighMediumFomo3D block stuffing ($3M, 2018); block space as finite resource
OpcodeRelationship
GAS (0x5A)Returns the remaining gas available to the current execution context. While GASLIMIT is a block-level maximum, GAS reflects the per-execution remaining gas. Contracts sometimes confuse the two — gasleft() (GAS) tells you how much gas your transaction has left, while block.gaslimit tells you the block’s total capacity.
GASPRICE (0x3A)Returns the gas price of the current transaction. GASPRICE and GASLIMIT together define the economic parameters of block space — GASLIMIT is the quantity of gas available, GASPRICE is what each unit costs. Both are used in block stuffing attack economics.
BASEFEE (0x48)Returns the current block’s base fee (EIP-1559). BASEFEE is algorithmically determined from the parent block’s gas usage relative to the target (half of GASLIMIT). When blocks consistently use more gas than the target, BASEFEE increases exponentially, making block stuffing progressively more expensive.

Graph View

Latest updates

Backlinks