Dynamic Fee Markets at Sub-Second Timescales: Adapting EIP-1559 for High-Throughput Blockchains

Abstract

Dynamic fee market mechanisms, exemplified by EIP-1559, have been extensively studied for Ethereum’s 12 s block environment but remain uncharacterized at sub-second timescales. We present an agent-based simulation study of an EIP-1559 adaptation for Injective, a Layer 1 blockchain combining native EVM compatibility with CometBFT consensus, operating at 600 ms block times. Across twelve simulation runs (four parameter configurations × three demand scenarios), our analysis yields three findings: (1) temporal smoothing mechanisms (MA-25, 25-block trailing average) produce mixed effects in sub-second environments with up to 47% basefee overshoot during spam attacks and slight smoothing elsewhere, making per-block mechanisms preferable for consistent performance; (2) transitioning from 150M (66.66% target) to 300M (50% target) configuration reduces peak fees by 31% during variable demand; during spam attacks, the 300M configuration peaks 32% higher but recovers faster with block capacity as the primary driver for spam throughput; and (3) per-block mechanisms establish initial spam barriers within 17–32 s versus Ethereum’s 4–6 min, economically justifying lower minimum fees. We provide the first systematic sub-second EIP-1559 analysis and a parameter optimization framework for high-throughput chains. With proper tuning, dynamic fee mechanisms are compatible with high-throughput architectures.

1. Introduction

Transaction fee markets determine how constrained blockchain resources are allocated among competing users. Ethereum’s original first-price auction model, where miners selected the highest-paying transactions fitting within block gas limits, suffers from fundamental inefficiencies: users face significant uncertainty when selecting gas prices, leading to either overpayment or transaction exclusion, and the mechanism lacks incentive compatibility [1,2]. EIP-1559, deployed in August 2021, addressed these limitations by replacing pure auctions with a dynamically adjusted base fee that all users pay and which the protocol burns [1]. When block utilization exceeds a target threshold, the base fee increases; when utilization falls below target, fees decrease. This algorithmic approach provides better fee predictability and implements marginal cost pricing where users internalize the congestion externality they impose on others [2,3].

However, a critical research gap remains: how does EIP-1559 perform when adapted to blockchain architectures operating at fundamentally different timescales? High-throughput blockchains using Byzantine Fault Tolerant (BFT) consensus, such as Injective, achieve block times around 600 milliseconds, enabling 25 times faster block production than Ethereum’s 12–14 s. This architectural difference raises essential questions about fee market dynamics. Faster blocks compound basefee adjustments more rapidly in absolute time, potentially enabling quicker convergence to equilibrium prices but also introducing risks of higher volatility if parameters are not carefully tuned. Additionally, the relationship between block gas limits and fee dynamics in sub-second block environments has not been systematically studied. Injective, a Layer 1 blockchain with its own Tendermint-based Proof-of-Stake consensus and native EVM compatibility, bridging the Ethereum and Cosmos ecosystems, is optimized for decentralized finance with order book exchanges requiring low latency and high throughput, and it currently implements fixed gas pricing at a 150M gas block limit [4]. Studying EIP-1559 on Injective therefore speaks to a broader design question: whether an Ethereum-standard fee mechanism can operate effectively in a sub-second BFT consensus environment, contributing evidence toward the compatibility of EVM standards and Cosmos-based infrastructure.

Directly transplanting Ethereum’s EIP-1559 parameters to sub-second block times introduces three specific failure modes. First, temporal smoothing mechanisms (e.g., moving average basefee adjustment) that span minutes on Ethereum compress to seconds, causing memory lag that produces counterproductive fee overshoot after brief demand spikes. Second, the 25× faster compounding of per-block adjustments amplifies both convergence speed and volatility, requiring a recalibration of change rate parameters. Third, the basefee “ratchet effect,” where fees remain elevated after congestion subsides, persists longer relative to the block production rate because sub-second blocks sustain near-target utilization more consistently than Ethereum’s longer blocks. These degradations motivate the systematic parameter analysis presented in this paper.

This paper employs agent-based simulation (ABM) to analyze EIP-1559 adaptation for Injective’s sub-second block environment. We examine four parameter configurations (150M versus 300M gas limits, per-block versus moving average basefee mechanisms) across three realistic demand scenarios (smooth variable demand, sharp spikes, sustained spam attacks), yielding twelve simulation runs. Our analysis addresses interconnected questions: How does a 600 ms block time affect basefee stability and convergence properties? What are the effects of block gas limit scaling on fee market behavior? Does a moving average mechanism, where the basefee adjusts based on trailing average gas usage rather than single-block observations, reduce volatility in sub-second block environments? How do these parameters interact to determine equilibrium fees?

We present, to the best of our knowledge, the first systematic simulation-based analysis of EIP-1559 in sub-second block time environments, extending prior work focused on Ethereum [2,3].

Our key contributions are outlined below:

1.

First sub-second EIP-1559 analysis: simulation-based study of EIP-1559 adaptation to 600 ms block times, partially validated through controlled mainnet experiments, addressing previously unstudied parameter interactions at sub-second timescales.

2.

Block limit scaling characterization: empirical evidence that transitioning from 150M/66.66% to 300M/50% configuration reduces peak fees by 31% during variable demand; during spam attacks, the 300M configuration peaks 32% higher due to greater per-block spam capacity but recovers to the minimum fee floor faster (block 302 vs. 364); sensitivity analysis confirms block capacity as the primary driver for spam throughput, while the target utilization ratio dominates variable demand behavior.

3.

MA-25 mechanism evaluation: first systematic comparison of 25-block trailing average smoothing (15 s at 600 ms block time) for blockchain fee markets, demonstrating mixed effects: up to 47% overshoot (spam attack, 300M) in some configurations, with slight smoothing in others, making per-block mechanisms preferable for consistent performance at 600 ms block times.

4.

Optimal change rate identification: first systematic identification of $r_{max}=0.05$ as Pareto-optimal for sub-second EIP-1559 fee markets, reducing ratchet severity by $19\times$ relative to the initial testnet configuration while maintaining spam resilience adequate for 100-block attacks. This provides simulation-based parameter guidance applicable to high-throughput chains with similar BFT consensus and multiplicative fee adjustment formulas.

5.

Parameter selection framework: Quantitative framework for high-throughput chains specifying trade-offs between (1) the baseline efficiency versus burst capacity, (2) responsiveness versus volatility, and (3) minimum fees versus spam response time.

Throughout this analysis, we emphasize that our contribution is characterizing mathematical properties through simulation to quantify trade-offs, not prescribing specific implementation choices, as real-world deployment requires additional considerations of the validator capacity, governance processes, and operational constraints beyond simulation scope.

2. Background and Related Work

2.1. EIP-1559 Fundamentals

2.1.1. Legacy Fee Market

In Ethereum’s original fee market, users competed through a first-price auction where miners selected the highest-paying transactions within the block gas limit [1]. This mechanism lacks incentive compatibility: users have no dominant strategy to bid their true valuation, leading to strategic underbidding, frequent bid adjustments, and significant fee volatility during congestion [2]. Second-price auctions, while theoretically incentive-compatible, are vulnerable to self-dealing in decentralized settings where block producers can insert fake bids [5,6,7].

2.1.2. EIP-1559 Mechanism

EIP-1559 addresses these limitations by replacing pure auctions with a dynamically adjusted base fee: an algorithmically determined minimum price per unit of gas that all users must pay and which is subsequently burned, removing it from circulation [1,8,9]. The mechanism introduces four key components:

• Base fee: algorithmically determined, burned by protocol;
• Priority fee (tip): paid to block producer for transaction prioritization;
• Fee cap: maximum total fee user is willing to pay;
• Target gas: desired block utilization level.

The basefee adjusts dynamically based on the difference between the target gas usage and actual gas usage in blocks. For Ethereum, the update formula is

$${\mathrm{BaseFee}}_{t+1}={\mathrm{BaseFee}}_t+{\displaystyle \frac{{\mathrm{BaseFee}}_t\times ({\mathrm{GasUsed}}_t-\mathrm{TargetGas})}{\mathrm{TargetGas}\times \mathrm{Denominator}}}$$

(1)

where $\mathrm{Denominator}=8$ (equivalent to 12.5% maximum change rate). EIP-1559 also introduces elastic block sizes, doubling the block gas limit to allow temporary bursts above the target while the basefee mechanism drives utilization back to the target over time.

2.1.3. Economic Rationale

EIP-1559’s design aligns with established economic principles. Algorithmic pricing based on observed network utilization provides better fee predictability than auction-based mechanisms, reducing user uncertainty and enabling efficient resource allocation [2,10]. Alternative approaches include uniform-price auction mechanisms that reduce fee variance [11] and Bayesian mechanism designs that relax dominant-strategy requirements [12]. The basefee adjustment implements marginal cost pricing: users internalize the congestion externality they impose on others during high demand, which is similar to Pigouvian taxes. Burning the basefee separates transaction ordering incentives from fee revenue, as block producers cannot manipulate the basefee they do not receive, while retaining priority fees as compensation to maintain inclusion incentives [2]. However, recent work shows non-myopic validators can still manipulate the basefee through strategic block filling [13]. Fundamental impossibility results demonstrate that no non-trivial fee mechanism achieves full incentive compatibility for both users and block producers when an MEV is present [14].

2.2. CometBFT Architecture and Fast Finality

2.2.1. Deterministic Finality

CometBFT (formerly Tendermint) implements BFT consensus, enabling deterministic finality within a single block [15]. Unlike Ethereum’s probabilistic finality under Proof-of-Stake, CometBFT provides finality immediately upon block commitment, enabling significantly faster block times (600 ms for Injective versus 12–14 s for Ethereum).

2.2.2. Modular Architecture

Injective employs a modular blockchain architecture where functionality is implemented through composable modules. The fee module handles EIP-1559-style fee market implementation, managing basefee calculation, transaction validation, and fee burning. Pre-execution validation via the antehandler performs cryptographic signature verification, nonce sequencing, and fee sufficiency checks, rejecting invalid transactions before they consume block space.

This architecture differs fundamentally from Ethereum’s PoS security model. Ethereum relies on slashing conditions and fork-choice rules to disincentivize malicious behavior at the consensus layer. CometBFT chains implement security primarily through the BFT properties of the consensus mechanism itself, tolerating up to one third Byzantine validators while maintaining safety guarantees. This architectural distinction affects how fee markets and spam resistance mechanisms must be designed.

2.2.3. Implications for Fee Markets

Sub-second block times create distinct fee market dynamics compared to Ethereum. Basefee adjustments accumulate 25 times faster in absolute time, potentially enabling faster equilibrium convergence while risking increased volatility if parameters are not appropriately calibrated for the temporal scale. The modular architecture facilitates parameter customization and experimentation, allowing chains to tune EIP-1559 parameters to their specific use cases without requiring modifications to core consensus logic.

2.3. Injective Overview

Injective is a Layer 1 blockchain with its own consensus mechanism (Tendermint-based Proof-of-Stake, implemented via CometBFT) purpose built for decentralized finance. Unlike Ethereum Layer 2 rollups that inherit security from a parent chain, or application-specific chains that sacrifice ecosystem access for performance, Injective operates as a sovereign chain with deterministic BFT finality, approximately 600 ms block times, and over 25,000 native TPS. The protocol is optimized for high-speed trading, derivatives markets, and sophisticated financial primitives, implementing a fully onchain central limit order book (CLOB) that requires low latency and high transaction throughput to remain competitive with centralized alternatives.

Injective implements a native MultiVM architecture in which EVM and CosmWasm virtual machines coexist on the same chain, sharing liquidity, state, and modules. The EVM component is not a bridge or wrapper: it runs on an updated Geth runtime with full Ethereum-compatible reversion behavior, enabling existing Solidity contracts and Ethereum tooling (MetaMask, Hardhat, ERC-20/ERC-721 standards) to deploy without code modification. Benchmarks show Injective EVM achieving 320–800 EVM-equivalent TPS, an improvement of at least $8\times$ over comparable EVM environments on competing networks, while maintaining transaction fees below USD 0.0001.

This architecture addresses a fundamental trade-off in the blockchain design space. Pure EVM chains (including Ethereum MainNet and its rollup ecosystem) provide broad developer ecosystem access but either sacrifice throughput at Layer 1 or introduce probabilistic or optimistic finality assumptions with associated withdrawal delays at Layer 2. Pure Cosmos/BFT chains provide high throughput and deterministic finality but historically lacked EVM compatibility and the associated developer ecosystem. Injective’s design avoids both limitations: Cosmos SDK’s modular infrastructure and CometBFT consensus provide the performance and finality layer, while the native EVM provides full Ethereum ecosystem compatibility. This positioning, summarized officially as “the blockchain built for both Ethereum and Cosmos,” is directly relevant to this paper: it makes Injective an ideal platform to evaluate whether EVM-standard fee mechanisms such as EIP-1559 can operate effectively in a sub-second BFT environment.

These DeFi-specific requirements create distinct demands on the fee market mechanism compared to general-purpose blockchains. Algorithmic trading strategies require predictable transaction costs for profitability calculations. Liquidation mechanisms must execute quickly and reliably, even during market stress. High-frequency operations benefit from low baseline fees but require rapid response to spam attacks to maintain network quality.

Technical Characteristics. Injective operates with approximately 600 ms block times on MainNet, enabling near-instant transaction confirmation and execution finality. Unlike Ethereum’s 21k gas simple transfers, Injective transactions typically require 150k+ gas for DeFi operations and cross-chain transfers. A 150M gas block contains approximately 1000 transactions, not 7000.

Current Fee Market Status. As of 2025, Injective implements a fixed gas price model without dynamic basefee adjustment. The block gas limit is set at 150M as a hard capacity constraint, but there is no target utilization concept or algorithmic fee pricing mechanism. The gas price remains constant regardless of block utilization: a block consuming 30M gas and a block consuming 130M gas pay identical price per gas unit [4]. This research evaluates EIP-1559 adoption as a potential upgrade path for Injective’s fee market, providing an ideal environment for analyzing EIP-1559 adaptation to sub-second blocks.

2.4. EIP-1559 Implementation for Injective

2.4.1. Implementation and Formula

An open-source implementation of EIP-1559-style fee logic provides a reference implementation for high-throughput blockchains. Injective’s proposed adoption would leverage a similar implementation with parameters tuned for its specific 600 ms block time and DeFi-focused use case. The analysis in this paper evaluates Injective’s potential EIP-1559 deployment using this implementation.

While Ethereum and high-throughput chains both implement EIP-1559’s core mechanism, the formulas use different notation. Ethereum’s implementation (London hard fork) is shown below:

$$\delta =\mathrm{gasUsed}-\mathrm{targetGas}$$

(2)

$${\mathrm{baseFee}}^{\prime }=\mathrm{baseFee}+{\displaystyle \frac{\mathrm{baseFee}\times \delta }{\mathrm{targetGas}\times 8}}$$

(3)

where the denominator value of 8 corresponds to a maximum 12.5% change rate per block.

Injective’s implementation formula is shown below:

$$\mathrm{multiplier}=1+{\displaystyle \frac{\mathrm{gasUsed}-\mathrm{targetGas}}{\mathrm{targetGas}}}\times r_{max}$$

(4)

$${\mathrm{baseFee}}^{\prime }=\mathrm{baseFee}\times \mathrm{multiplier}$$

(5)

where $r_{max}=0.1$ represents a 10% maximum change rate.

These formulas are mathematically equivalent: one uses a denominator-based approach while the other explicitly specifies the rate. The key difference lies in the maximum change rate (10% vs. 12.5%).

2.4.2. Key Design Choices

Injective’s implementation makes several parameter choices that differ from Ethereum, each reflecting different operational priorities and environmental constraints.

Variable Target Utilization: The target utilization can be configured to balance baseline efficiency against burst capacity with lower target percentages providing more headroom for demand spikes at the cost of reduced baseline throughput.

7-Hour Reset Interval: Every 42,000 blocks (approximately 7 h at 600 ms block time), the basefee resets to $MIN\_BASE\_FEE$. This periodic reset prevents indefinite upward drift during sustained high demand. The mechanism creates predictable fee cycles, ensuring regular access to low-fee periods. However, it trades some market responsiveness for stability, as the basefee may reset during ongoing congestion.

10% Maximum Change Rate: The initial testnet configuration adopts $r_{max}=0.10$, providing a simple round value close to Ethereum’s 12.5% denominator-based rate. With 600 ms block times, per-block changes compound 25 times faster than Ethereum in absolute time, meaning each percentage point of change rate carries amplified cumulative effects over short wall-clock periods. Whether this rate is optimal for sub-second block environments is an open question addressed in Section 4.1, which sweeps the full sensitivity range to identify the sweet spot for MainNet deployment.

0.16 Gwei Minimum Base Fee: The minimum fee floor is significantly lower than Ethereum’s approximately 1 Gwei baseline. This low floor is feasible due to fast responsiveness: spam attacks can be detected and mitigated within seconds through rapid basefee escalation. The low minimum encourages network usage during quiet periods while the fast adjustment mechanism provides security through economic barriers that scale with demand.

2.5. Positioning Relative to Existing Work

Existing EIP-1559 analyses focus on Ethereum’s 12 s block environment. Roughgarden’s economic analysis [2] establishes incentive compatibility and welfare properties that are block-time invariant and carry over to any EIP-1559 implementation. Leonardos et al.’s dynamical analysis [3] characterizes convergence properties that depend on the number of blocks rather than wall-clock time. Moore and Sidhu [16] derive stochastic properties of basefee dynamics, including conditions for stationarity under random demand. Recent extensions include multidimensional fee markets for heterogeneous resources [17] and empirical analysis of EIP-4844’s blob gas fee mechanism [18]. However, several phenomena are unique to, or qualitatively different in, the 600 ms regime:

• Temporal smoothing failure: Moving average windows that span minutes on Ethereum compress to seconds, fundamentally altering their smoothing properties and introducing overshoot (Section 4.1).
• Absolute-time convergence: Per-block mechanisms establish initial spam barriers within 17–32 s (28–54 blocks) versus Ethereum’s 4–6 min, enabling lower minimum fees with equivalent spam resistance (Section 4.5).
• Ratchet effect persistence: Sub-second blocks sustain near-target utilization more consistently, reducing the natural variance that helps Ethereum’s basefee decay after congestion (Section 4.3).
• Block capacity interactions: The relationship between block gas limits and basefee dynamics at high block production rates has not been previously characterized (Section 4.2).

This paper contributes the first systematic analysis of these sub-second-specific dynamics, complementing rather than duplicating existing Ethereum-focused work.

3. Methodology

This section describes our simulation-based approach to analyzing EIP-1559 adaptation for Injective’s sub-second block environment. We employ agent-based modeling to evaluate fee market dynamics across four parameter configurations and three realistic demand scenarios, yielding twelve experimental simulation runs.

Table 1. Summary of key notation and parameters.

Symbol	Value	Description
${\mathtt{basefee}}_t$	variable	Base fee at block t (Gwei)
$\mathtt{gas}\_{\mathtt{used}}_t$	variable	Gas consumed in block t
$\mathtt{TARGET}\_\mathtt{GAS}$	100M or 150M	Target gas utilization per block
$\mathtt{BLOCK}\_\mathtt{MAX}\_\mathtt{GAS}$	150M or 300M	Maximum block gas limit
$r_{max}$	0.05 (5%)	Maximum per-block basefee change rate (testnet: 0.10)
$\mathtt{MIN}\_\mathtt{BASE}\_\mathtt{FEE}$	0.16 Gwei	Minimum basefee floor
$MA$	25 blocks	Moving average window size (15s)
$\mathtt{RESET}\_\mathtt{INTERVAL}$	42,000 blocks	Basefee reset interval (7 h)
$\mathtt{gas}\_\mathtt{premium}$	variable	Priority fee (tip) to block producer
$\mathtt{fee}\_\mathtt{cap}$	variable	Maximum total fee per gas unit

summarizes the key notations used throughout this paper.

3.1. Simulation Framework

3.1.1. Agent-Based Modeling Approach

Our simulation framework adapts the ethereum/abm1559 package [3,19] for high-throughput chains operating at 600 ms block times. The model comprises three agent types: users generating transactions with heterogeneous valuations (gas premium and fee cap), block producers selecting transactions to maximize tip revenue subject to gas limits [2], and the protocol layer updating basefee algorithmically based on gas utilization [1].

3.1.2. Transaction Model

Each transaction has three attributes: $\mathtt{gas}\_\mathtt{premium}$ (tip to block producer), $\mathtt{fee}\_\mathtt{cap}$ (maximum total fee), and $\mathtt{gas}\_\mathtt{used}$ (computational units consumed). A transaction is valid if $\mathtt{fee}\_\mathtt{cap}\ge \mathtt{basefee}$ [1]. Valid transactions are sorted by $\mathtt{gas}\_\mathtt{premium}$ descending and included until the block gas limit is reached.

Arrival Process. Transactions are generated fresh each block from the scenario-specific user population (no mempool carry-over between blocks). The number of users per block is fixed within each scenario phase: 5000 for variable demand, variable for demand spikes (scaled to target gas demand), and 700 regular (normal/recovery phases) plus 15,000 spam during attack phases. This per-block regeneration models a steady-state arrival rate rather than queuing dynamics.

Transaction Size Distribution. Gas consumption per transaction is drawn from $\mathtt{gas}\_\mathtt{used}\sim U(50\mathrm{k},150\mathrm{k})$ for regular users and $U(21\mathrm{k},50\mathrm{k})$ for spam users in the spam attack scenario (reflecting complex DeFi operations for regular users and simple transfers for spam), and it is computed as $\mathtt{gas}\_\mathtt{demand}/\mathtt{num}\_\mathtt{txs}$ for demand-controlled scenarios (variable demand, spikes), yielding approximately 30,000–50,000 gas per transaction.

Willingness-to-Pay Distribution. Gas premiums and fee caps are drawn independently from uniform distributions. Gas premiums range 0.5–15 Gwei for regular users and 0.1–1 Gwei for spam users. Fee caps are computed as $\mathtt{fee}\_\mathtt{cap}=\mathtt{gas}\_\mathtt{premium}+U(a,b)$ where $(a,b)$ varies by scenario: (5, 20) Gwei for variable demand, (5, 15) Gwei for spikes, (10, 20) Gwei for regular users during spam, and (0.5, 2) Gwei for spam transactions. All distributions use a fixed random seed (42) for reproducibility.

3.1.3. Block Producer Behavior

Block producers select the highest-paying valid transactions by $\mathtt{gas}\_\mathtt{premium}$ subject to block gas limits (150M or 300M). Revenue consists solely of gas premiums, as the basefee is burned, separating consensus incentives from fee dynamics [2,7].

3.1.4. Agent Behavior Assumptions

User Strategy. Users submit transactions with fixed fee caps and gas premiums drawn at block creation time. Users do not adapt bids in response to observed basefee levels (no strategic bidding), do not replace pending transactions with higher-fee versions (no fee bumping), and do not withdraw transactions that fail inclusion (no dropping). These simplifications model non-strategic, price-taking users rather than sophisticated agents.

Block Producer Strategy. Block producers follow a greedy, non-strategic inclusion rule: include the highest-tipping valid transactions until the gas limit is reached. Producers do not engage in MEV extraction, transaction reordering for profit, or strategic block space withholding.

Impact of Alternative Strategies. Strategic behavior (adaptive bidding, fee bumping, MEV extraction) would likely accelerate basefee convergence and reduce ratchet severity; modeling these dynamics with heterogeneous agent populations is a direction for future work.

3.1.5. Basefee Update Mechanism

The protocol updates the basefee after each block according to the following formula:

$${\mathtt{basefee}}_{t+1}=max\left(\mathtt{MIN}\_\mathtt{BASE}\_\mathtt{FEE},{\mathtt{basefee}}_t\times \left(1+{\displaystyle \frac{\mathtt{gas}\_{\mathtt{used}}_t-\mathtt{TARGET}\_\mathtt{GAS}}{\mathtt{TARGET}\_\mathtt{GAS}}}\times r_{max}\right)\right)$$

(6)

where $\mathtt{gas}\_{\mathtt{used}}_t$ is the gas consumed in block t, $\mathtt{TARGET}\_\mathtt{GAS}$ is the target utilization, $r_{max}$ is the maximum per-block change rate, and $\mathtt{MIN}\_\mathtt{BASE}\_\mathtt{FEE}=0.16$ Gwei enforces a floor. Injective’s initial testnet configuration uses $r_{max}=0.10$; our sensitivity analysis (Section 4.1) identifies $r_{max}=0.05$ as Pareto-optimal, which we adopt for all simulations. This implements the per-block basefee adjustment mechanism [2]. As a security measure, every 42,000 blocks (7 h), the basefee resets to $\mathtt{MIN}\_\mathtt{BASE}\_\mathtt{FEE}$ to prevent drift.

3.2. Parameter Configurations

This paper evaluates configurations across two dimensions: the block gas limit (150M vs. 300M) and basefee update mechanism (per-block vs. moving average).

Table 2. Experimental configurations tested across all demand scenarios. Config 1 represents the proposed baseline implementation at Injective’s current 150M block limit. Config 3 evaluates a potential upgrade to 300M limit with Ethereum-like 50% target utilization. Configs 2 and 4 test an experimental moving average mechanism with 25-block window (15 s at 600 ms block time).

Config	Block Limit	Target Gas	Target %	Mechanism	Purpose
1	150M	100M	66.66%	Per-block	Baseline (current limit)
2	150M	100M	66.66%	MA-25	Evaluate MA at 150M
3	300M	150M	50%	Per-block	Potential upgrade (2× limit)
4	300M	150M	50%	MA-25	Combined: higher limit + MA

summarizes the four experimental configurations.

Config 1 (150M, 66.66% target) represents the proposed baseline; Config 3 (300M, 50% target) evaluates a capacity upgrade. The different target utilization ratios compare two operational philosophies: efficiency-prioritized (66.66%) versus headroom-prioritized (50%). Preliminary tests with matched ratios confirmed that observed differences reflect the combined effect of capacity and utilization strategy. This yields 4 configurations × 3 demand scenarios = 12 simulation runs, isolating mechanism effects (Configs 1 vs. 2, 3 vs. 4) and capacity-utilization strategies (Configs 1 vs. 3, 2 vs. 4). Subsequent analysis focuses on per-block configurations (1 and 3); MA results are reported in Section 4.2.

Moving Average Implementation (Experimental)

The per-block mechanism (baseline) computes adjustment as

$$(\mathtt{gas}\_{\mathtt{used}}_t-\mathtt{TARGET}\_\mathtt{GAS})/\mathtt{TARGET}\_\mathtt{GAS}.$$

The Moving Average variant uses

$$(\overline{\mathtt{gas}\_{\mathtt{used}}_{25}}-\mathtt{TARGET}\_\mathtt{GAS})/\mathtt{TARGET}\_\mathtt{GAS},$$

where $\overline{\mathtt{gas}\_{\mathtt{used}}_{25}}$ is mean gas consumption over the trailing 25 blocks.

The 25-block window ($MA=25$) was selected to approximate the temporal smoothing duration of Ethereum’s effective basefee memory. On Ethereum, each block’s basefee depends primarily on the previous block, but the practical fee trajectory smooths over approximately 20–30 blocks (4–6 min) due to gradual demand transitions. At 600 ms block time, $MA=25$ spans 15 s, providing a comparable absolute-time smoothing window. This choice tests whether temporal-equivalent smoothing preserves its benefits at higher block production rates. The results (Section 4.1) demonstrate that it does not: the 25-block memory lag causes overshoot during brief spikes because demand transitions that span multiple minutes on Ethereum resolve within seconds at sub-second block times. Alternative smoothing approaches (shorter windows, exponential decay) were not evaluated and may exhibit different behavior.

3.3. Demand Scenarios

All scenarios execute for 300 blocks uniformly to ensure clean cross-configuration comparison without temporal bias. We test three scenarios representing realistic demand patterns: variable demand (sine wave), sharp spikes (mixed duration), and spam attacks.

3.3.1. Scenario 1: Variable Demand (Sine Wave Pattern)

This scenario evaluates basefee behavior under smooth demand oscillations. We simulate 5000 users per block with gas premiums from 0.5 to 15 Gwei and fee caps at basefee plus 5 to 20 Gwei. Demand follows a sinusoidal pattern with 60-block period (five cycles over 300 blocks). For Configs 1-2 (150M limit), demand oscillates between 50M and 150M gas centered on 100M target. For Configs 3-4 (300M limit), demand oscillates between 75M and 175M gas centered at 125M.

3.3.2. Scenario 2: Demand Spikes (Mixed Duration)

This scenario analyzes responsiveness to sudden demand changes. Baseline demand remains at 50M gas with sharp spikes reaching block limits (150M for Configs 1-2, 300M for Configs 3-4). We implement 15 spikes with mixed durations: six 5-block spikes, four 10-block spikes, three 20-block spikes, and two 60-block spikes.

3.3.3. Scenario 3: Spam Attack

This scenario evaluates spam mitigation through three phases. Phase 1 (blocks 0–100): 700 regular users generate 70M gas demand, maintaining the basefee at the minimum floor. Phase 2 (blocks 100–200): attack with 1000 regular + 15,000 spam users generating 630M total attempted demand (far exceeding the 150M/300M block capacity; each block is still capped at the gas limit with excess transactions excluded by the rising basefee). Phase 3 (blocks 200–300): recovery with 70M gas demand. Regular users have gas premiums from 5–15 Gwei and fee caps at basefee plus 10–20 Gwei. Spam users have gas premiums from 0.1–1 Gwei and fee caps at basefee plus 0.5–2 Gwei [1].

Table 3. Spam attack scenario: complete parameter specification for reproduction.

Parameter	Description	Regular Users	Spam Users
Count (Phase 1)	Users per block, blocks 0–100	700	0
Count (Phase 2)	Users per block, blocks 100–200	1000	15,000
Count (Phase 3)	Users per block, blocks 200–300	700	0
Gas per tx	$\mathtt{gas}\_\mathtt{used}\sim U(a,b)$	$U(50\mathrm{k},150\mathrm{k})$	$U(21\mathrm{k},50\mathrm{k})$
Gas premium	Tip, Gwei $\sim U(a,b)$	$U(5,15)$	$U(0.1,1)$
Fee cap offset	Above premium, Gwei	$U(10,20)$	$U(0.5,2)$
Attack intensity	Total gas demand/block	100M	530M

Attack duration: 100 blocks (60 s wall-clock). Random seed: NumPy RNG, seed = 42.

provides a complete, reproducible specification of the spam attack scenario.

3.4. Evaluation Metrics

All metrics are measured for each configuration across three scenarios (12 data points per metric) to isolate the block limit and mechanism effects.

3.4.1. Primary Metrics

We track basefee evolution (time-series trajectory in Gwei), gas utilization (gas used vs. target), convergence time (blocks to reach equilibrium), and basefee volatility (standard deviation and coefficient of variation).

3.4.2. Statistical Analysis Methods

Our analytical approach calculates per-configuration statistics (mean, median, standard deviation) and performs cross-configuration comparisons to isolate block limit effects (Configs 1 vs. 3, 2 vs. 4) and mechanism effects (Configs 1 vs. 2, 3 vs. 4). Time-series analysis examines convergence rates and transient dynamics. Variance validation across N = 10 random seeds for Configuration 1 (spam attack scenario) yielded a coefficient of variation of 0.15% for the peak basefee, confirming that aggregate metrics are dominated by deterministic demand patterns rather than per-transaction stochasticity. Given this negligible variance with 2000+ agents per block, we report point estimates without uncertainty bounds.

4. Results

We present simulation results for four configurations and three demand scenarios, each running 300 blocks (3 min at 600 ms block time). Section 4.1 first calibrates $r_{max}$; Section 4.2, Section 4.3, Section 4.4 and Section 4.5 present the main results.

4.1. Parameter Calibration

We evaluate $r_{max}\in \{0.02,0.05,0.10,0.15,0.20\}$ across all demand scenarios and sweep $MA\in \{3,5,10,25\}$ under the variable demand scenario.

4.1.1. Maximum Change Rate Sensitivity

Table 4. Maximum change rate sensitivity analysis (Configuration 3: 300M, 50%, per-block). “High demand” is a constant full-block load scenario used only in this analysis. Peak basefee in Gwei, ratchet multiple relative to MIN_BASE_FEE (0.16 Gwei), and coefficient of variation (CV) as percentage.

${\mathit{r}}_{\mathbf{max}}$	Scenario	Peak (Gwei)	Ratchet (×MIN)	CV (%)
0.02	High demand	0.53	3.3	11.6
0.02	Variable demand	0.17	1.0	1.7
0.02	Demand spikes	5.83	36.4	116.9
0.02	Spam attack	1.16	7.2	—
0.05	High demand	3.13	19.6	28.6
0.05	Variable demand	0.18	1.1	4.3
0.05	Demand spikes	15.53	97.1	101.8
0.05	Spam attack	2.50	15.6	—
0.10	High demand	59.64	372.8	55.7
0.10	Variable demand	0.20	1.2	8.8
0.10	Demand spikes	15.55	97.2	74.9
0.10	Spam attack	2.50	15.6	—
0.15	High demand	610.59	3816	63.1
0.15	Variable demand	0.22	1.4	13.3
0.15	Demand spikes	15.62	97.6	65.3
0.15	Spam attack	2.51	15.7	—
0.20	High demand	623.25	3895	8.7
0.20	Variable demand	0.25	1.5	17.9
0.20	Demand spikes	15.58	97.4	61.6
0.20	Spam attack	2.51	15.7	—

reports sensitivity results; the 300M configuration exhibits the largest parameter-dependent variation.

The results reveal an exponential relationship between $r_{max}$ and ratchet severity under sustained above-target demand. With the initial testnet value $r_{max}=0.10$, high demand produces a ratchet of $372.8\times$ MIN, rising to $3895\times$ MIN at $r_{max}=0.20$. This exponential scaling arises from compounding: each block multiplies the basefee by up to $(1+r_{max})$, and at 600 ms block times, 300 blocks represent only 3 min of wall-clock time during which compounding produces ${(1+r_{max})}^{300}$ maximum cumulative adjustment.

However, reducing $r_{max}$ below 0.05 degrades spam resilience. During the spam attack scenario (Config 3), $r_{max}=0.02$ produces a peak basefee of only 1.16 Gwei (7× MIN), while $r_{max}=0.05$ reaches 2.50 Gwei (16× MIN); peaks plateau above $r_{max}=0.05$ because the adjustment is bounded by the spam fee cap ceiling of 3.0 Gwei. At $r_{max}=0.02$, the basefee does not cross the 0.6 Gwei threshold (lowest spam fee cap) until late in the attack phase, leaving the cheapest spam transactions unpriced for most of the 100-block window. Fine-grained analysis (0.03–0.08 in 0.01 increments) confirms Config 3 spam peaks saturate near the fee cap above $r_{max}=0.04$; Config 1 (150M) shows greater sensitivity, rising from 0.71 Gwei at $r_{max}=0.03$ to 1.89 Gwei at $r_{max}=0.05$.

These results identify $r_{max}=0.05$ as a Pareto-optimal value for sub-second block environments: it reduces ratchet severity by $19\times$ relative to the initial testnet configuration ($r_{max}=0.10$) while maintaining adequate responsiveness across demand spike and spam attack scenarios. All subsequent simulations in this paper use $r_{max}=0.05$.

4.1.2. Moving Average Window Sensitivity

Table 5. Moving average window sensitivity (variable demand scenario, $r_{max}=0.05$). Peak basefee, overshoot relative to steady state, and coefficient of variation over last 100 blocks.

$\mathbf{MA}$ (Blocks)	Configuration	Peak (Gwei)	Overshoot (%)	CV (%)
3	150M, MA	0.257	20.3	16.4
5	150M, MA	0.257	20.5	16.1
10	150M, MA	0.258	22.2	15.1
25	150M, MA	0.267	17.9	11.5
3	300M, MA	0.178	7.1	4.3
5	300M, MA	0.178	7.0	4.2
10	300M, MA	0.176	6.5	3.8
25	300M, MA	0.171	5.5	1.5

reports the MA window sensitivity for the variable demand scenario (with $r_{max}=0.05$), where temporal smoothing effects are most visible.

Increasing the window size from $MA=3$ to $MA=25$ reduces basefee volatility by approximately $1.4\times$ for the 150M configuration (from 16.4% to 11.5% CV) and $2.8\times$ for the 300M configuration (from 4.3% to 1.5% CV), with modest overshoot (18–22% for 150M, 5–7% for 300M). Windows of $MA=3$ and $MA=5$ produce nearly identical results, confirming that effective smoothing requires windows substantially longer than a few blocks. These results support $MA=25$ as the preferred window size.

4.2. Moving Average Mechanism Evaluation

Configurations 2 and 4 implement MA-25 (25-block trailing average for basefee adjustment) and are compared against per-block counterparts (Configurations 1 and 3).

Table 6. The moving average (MA-25) vs. per-block mechanism comparison ($r_{max}=0.05$). MA-25 shows inconsistent behavior: significant overshoot in some scenarios (spam attack 300M: +47%, demand spikes 300M: +7%) and slight dampening in others. Per-block mechanisms provide more consistent performance.

Scenario	Config	Per-Block Peak (Gwei)	MA-25 Peak (Gwei)	Overshoot	Finding
Sine Wave	150M	0.26	0.27	+4%	Minimal difference
Sine Wave	300M	0.18	0.17	−4%	Slight smoothing
Demand Spikes	150M	7.89	7.13	−10%	MA slightly lower
Demand Spikes	300M	15.50	16.61	+7%	Modest overshoot
Spam Attack	150M	1.89	1.50	−21%	MA slightly lower
Spam Attack	300M	2.50	3.67	+47%	Significant overshoot

Note: Variance validation (N = 10 seeds) yielded CV < 0.2%; point estimates reported.

presents a peak basefee comparison across all scenarios.

MA-25 shows inconsistent behavior across scenarios (Table 6): differences are small for sine wave demand, but overshoot reaches 47% for a spam attack at 300M (3.67 vs. 2.50 Gwei), where the 25-block memory window prolongs elevated fees after the attack ends. Per-block mechanisms provide more consistent performance across all scenarios.

Figure 1 presents the basefee evolution for demand spikes comparing the per-block and MA-25 mechanisms at 150M, illustrating the MA-25 drift behavior under persistent above-target demand.

Based on these observations, the remainder of Section 4 focuses on per-block mechanism (Configurations 1 and 3).

4.3. Variable Demand: Sine Wave Pattern

Configuration 1 implements demand oscillating between 50M and 150M gas (centered at 100M target, 60-block period). Configuration 3 implements demand oscillating between 75M and 175M gas (centered at 125M).

Table 7. Variable demand (sine wave) performance comparison ($r_{max}=0.05$). Configuration 3’s lower peak basefee (31% reduction) reflects operation mostly below target utilization, demonstrating that higher block limits provide more headroom and lower fees for the same absolute demand pattern.

Metric	Config 1 (150M)	Config 3 (300M)	Comparison
Demand pattern	50M–150M oscillation	75M–175M oscillation	Scaled by limit
Center point	100M (at target)	125M (below target)	Design difference
Basefee range	0.16–0.26 Gwei	0.16–0.18 Gwei	31% lower peak
Peak basefee	0.26 Gwei	0.18 Gwei	31% reduction
Final basefee	0.16 Gwei	0.16 Gwei	Both return to MIN
Avg gas used	100M	125M	Higher absolute
Target utilization	100%	83.3%	Lower percentage

Note: Variance validation (N = 10 seeds) yielded CV < 0.2%; point estimates reported.

presents performance metrics.

Both configurations return to MIN_BASE_FEE at cycle completion. Config 3 achieves a 31% lower peak basefee (0.18 vs. 0.26 Gwei) because its demand oscillation stays mostly below its 150M target, while Config 1 demand regularly touches the 150M block limit (Figure 2).

4.4. Demand Spikes: Mixed Duration Patterns

Both configurations implement a baseline demand of 50M gas with spikes to block limits (150M for Configuration 1, 300M for Configuration 3). The 300-block simulation includes 15 spikes: six 5-block spikes, four 10-block spikes, three 20-block spikes, and two 60-block spikes.

Table 8. Demand spikes scenario performance comparison. Similar peak basefees despite 2× capacity difference reflect proportional spike scaling. Final basefee remains elevated (ratchet effect) as demand settles at target utilization after spikes end.

Metric	Config 1 (150M)	Config 3 (300M)	Comparison
Baseline demand	50M gas	50M gas	Same absolute
Spike magnitude	150M gas	300M gas	Scaled to limit
Spike pattern	15 mixed duration	15 mixed duration	Identical pattern
Basefee range	0.16–7.89 Gwei	0.16–15.50 Gwei	96% higher peak
Peak basefee	7.89 Gwei (49×)	15.50 Gwei (97×)	Config 3 higher
Final basefee	7.89 Gwei	15.49 Gwei	Both elevated
Avg gas used	126.6M	197.8M	Higher absolute
Target utilization	126.6%	131.8%	Similar excess

Note: Variance validation (N = 10 seeds) yielded CV < 0.2%; point estimates reported.

presents performance metrics.

Configuration 1 reaches a peak basefee of 7.89 Gwei (49× MIN) and a final basefee of 7.89 Gwei with average utilization at 126.6% of the target. Configuration 3 reaches a peak basefee of 15.50 Gwei (97× MIN) and final basefee of 15.49 Gwei with an average utilization at 131.8% of the target. Both configurations show the basefee responding immediately to spike onset (within 1 block).

Final basefee values remain elevated: 7.89 Gwei (49× above MIN_BASE_FEE) for Configuration 1 and 15.49 Gwei (97× above MIN) for Configuration 3 despite baseline demand returning to 50M gas (well below target). This “ratchet effect” occurs when demand settles near target utilization after exceeding it, producing zero basefee adjustment (multiplier = 1.0 when gas_used = target).

Ratchet Effect: Operational Definition. We define the ratchet effect as the condition where basefee satisfies

$${\mathtt{basefee}}_t>10\times \mathtt{MIN}\_\mathtt{BASE}\_\mathtt{FEE}\mathrm{for}t>t_{\mathrm{recovery}}$$

(7)

where $t_{\mathrm{recovery}}$ is the first block after congestion where $\mathtt{gas}\_{\mathtt{used}}_t\le \mathtt{TARGET}\_\mathtt{GAS}$ for 10 consecutive blocks. The threshold of $10\times$ (1.6 Gwei) represents a meaningful fee elevation above the minimum floor.

Table 9. Ratchet effect severity across scenarios and configurations. The effect is absent in the sine wave scenario (demand regularly drops below target), while it is present in demand spikes and spam attack scenarios. Severity is measured as the final basefee relative to $\mathtt{MIN}\_\mathtt{BASE}\_\mathtt{FEE}$.

Scenario	Config	Final Basefee	Ratio to MIN	Ratchet?
Sine Wave	1 (150M)	0.16 Gwei	1.0×	No
Sine Wave	3 (300M)	0.16 Gwei	1.0×	No
Demand Spikes	1 (150M)	7.89 Gwei	49×	Yes
Demand Spikes	3 (300M)	15.49 Gwei	97×	Yes
Spam Attack	1 (150M)	0.42 Gwei	3×	No
Spam Attack	3 (300M)	0.17 Gwei	1×	No

reports the ratchet severity across scenarios and configurations.

The ratchet effect occurs in two out of six per-block configuration-scenario pairs (33%), only in the demand spikes scenario where 60-block spikes sustain above-target utilization long enough to elevate basefee beyond the 10× MIN threshold. Spam attack does not produce a persistent ratchet with the corrected baseline: the basefee recovers to the minimum floor within 164 blocks after the attack ends (Config 1) or 102 blocks (Config 3). Even with the calibrated $r_{max}=0.05$, the demand spikes severity ranges from 49× to 97× MIN_BASE_FEE, confirming the ratchet is a structural property of sustained above-target demand. The mathematical root cause is analyzed in Section 5.1.3.

4.5. Spam Attack

The simulation implements three phases: Phase 1 (blocks 0–100) establishes a 70M gas baseline demand with 700 regular users, holding basefee at the minimum floor. Phase 2 (blocks 100–200) introduces attack with 1000 regular + 15,000 spam users generating 630M total attempted demand (exceeding block capacity; each block is capped at 150M/300M with excess excluded by rising basefee). Phase 3 (blocks 200–300) models recovery with 70M gas demand.

Table 10. Spam attack scenario performance comparison ($r_{max}=0.05$). Configuration 3’s higher capacity absorbs more spam per block, driving faster basefee escalation and a 32% higher peak than Config 1, but achieves faster post-attack recovery. Both configurations protect regular users throughout the attack.

Metric	Config 1 (150M)	Config 3 (300M)	Comparison
Attack demand	630M gas (attempted)	630M gas (attempted)	Exceeds block capacity
Capacity served	24%	37%	1.6× advantage
Basefee range	0.16–1.89 Gwei	0.16–2.50 Gwei	Config 3 peaks 32% higher
Peak basefee	1.89 Gwei (12×)	2.50 Gwei (16×)	Higher capacity → faster recovery
Final basefee	0.42 Gwei	0.17 Gwei	Config 3 near floor
Avg gas used	96.7M	124.9M	Higher absolute
Target utilization	96.7%	83.2%	Config 3 more headroom

Note: Variance validation (N = 10 seeds) yielded CV < 0.2%; point estimates reported.

presents performance metrics.

Configuration 1 reaches a peak basefee of 1.89 Gwei (12× MIN) and a final basefee of 0.42 Gwei after 300 blocks with an average utilization at 96.7% of the target. Configuration 3 reaches a peak basefee of 2.50 Gwei (16× MIN, 32% higher than Config 1) and a final basefee of 0.17 Gwei, recovering to near the minimum floor within the 300-block window with an average utilization at 83.2% of the target. Configuration 3’s larger block capacity absorbs more spam per block, driving faster basefee escalation during the attack but also enabling faster post-attack decay. Configuration 1 accommodates 24% of attack demand per block; Configuration 3 serves 37%.

Spam transactions carry fee caps ranging 0.6–3.0 Gwei; regular users carry fee caps 15–35 Gwei. At the calibrated $r_{max}=0.05$, the basefee crosses the 0.6 Gwei threshold (lowest spam cap) at attack block 54 for Config 1 and attack block 28 for Config 3, progressively excluding lower-fee spam transactions thereafter. The basefee does not exceed the 3.0 Gwei ceiling (highest spam cap) within the 300-block window under either configuration, meaning partial rather than complete spam exclusion occurs during the attack phase. Regular users maintain access throughout, as their fee caps (15–35 Gwei) remain well above the basefee at all times. After the attack ends, recovery demand of 70M gas falls below the 100M target, driving the basefee back toward the minimum floor: Config 1 recovers by block 364 and Config 3 by block 302 in the extended 1000-block validation (Figure 3).

4.6. MainNet Validation

To validate simulation predictions, we conducted controlled experiments on Injective MainNet (injective-core v1.18.2, 150M block limit, 100M gas target) using a chain-stresser (https://github.com/InjectiveLabs/chain-stresser, accessed on 3 March 2026) for load generation. Block data were collected into InfluxDB and visualized using Plotly (version 6.6.0); chart block indices begin at 0. Demand spikes experiments used 1000 parallel bank-send accounts in blocking mode with periodic burst intervals to reproduce above-target congestion. Spam attack experiments used the same 1000 accounts in non-blocking mode (--await=false), saturating the mempool without rate limiting.

Figure 4 shows the demand spikes experiment: gas usage saturates the 150M block limit during spike intervals, driving rapid basefee escalation. The ratchet effect is clearly visible. The basefee does not return to the minimum floor between consecutive spikes but accumulates progressively across the experiment window (logarithmic scale, ×MIN_BASE_FEE), directly confirming the simulation prediction for the demand spikes scenario (Section 4.4).

Figure 4. MainNet demand spikes validation (150M block limit, 100M gas target, injective-core v1.18.2). Top panel: basefee on a logarithmic scale (×MIN_BASE_FEE = 0.16 Gwei). Bottom panel: gas usage per block (millions). Gas saturates the 150M limit during spike intervals; the basefee accumulates progressively and does not recover to the minimum floor between spikes, confirming the ratchet effect predicted by simulation (Figure 5).

Figure 4. MainNet demand spikes validation (150M block limit, 100M gas target, injective-core v1.18.2). Top panel: basefee on a logarithmic scale (×MIN_BASE_FEE = 0.16 Gwei). Bottom panel: gas usage per block (millions). Gas saturates the 150M limit during spike intervals; the basefee accumulates progressively and does not recover to the minimum floor between spikes, confirming the ratchet effect predicted by simulation (Figure 5).

Figure 5. Demand spikes scenario: Configuration 1 (top, 150M limit, 66.7% target) vs. Configuration 3 (bottom, 300M limit, 50% target), both per-block at $r_{max}=0.05$. The basefee rises sharply during spike intervals and remains elevated after demand returns to baseline, illustrating the ratchet effect. Config 3 peaks nearly twice as high (15.50 Gwei vs. 7.89 Gwei) because its proportionally larger spikes (300M) drive proportionally larger fee increases. The persistent elevation confirms that ratchet recovery requires sustained below-target demand rather than automatic decay. Each subplot has three panels. Top panel: blue line = basefee (Gwei), red dashed = MIN_BASE_FEE reference. Middle panel: green line = gas used per block (millions), orange dashed = target gas, red dashed = block limit. Bottom panel: purple line = utilization ratio, orange dashed = target utilization (1.0).

Figure 5. Demand spikes scenario: Configuration 1 (top, 150M limit, 66.7% target) vs. Configuration 3 (bottom, 300M limit, 50% target), both per-block at $r_{max}=0.05$. The basefee rises sharply during spike intervals and remains elevated after demand returns to baseline, illustrating the ratchet effect. Config 3 peaks nearly twice as high (15.50 Gwei vs. 7.89 Gwei) because its proportionally larger spikes (300M) drive proportionally larger fee increases. The persistent elevation confirms that ratchet recovery requires sustained below-target demand rather than automatic decay. Each subplot has three panels. Top panel: blue line = basefee (Gwei), red dashed = MIN_BASE_FEE reference. Middle panel: green line = gas used per block (millions), orange dashed = target gas, red dashed = block limit. Bottom panel: purple line = utilization ratio, orange dashed = target utilization (1.0).

Figure 6 shows the spam attack experiment: the basefee escalates to approximately 2.5 Gwei (≈16× MIN) during the attack phase and decays symmetrically after attack cessation, matching the predicted bell-curve spam response (Figure 7). The block time drift to 2–3 s under sustained load is visible as increased bar spacing. This drift constitutes direct empirical evidence that the main conclusions hold under 2–3 s block times: the ratchet effect, fee escalation pattern, and spam-defense behavior observed all match simulation predictions. The robustness is structurally expected: the EIP-1559 update formula is per-block and block time does not appear in it, so the per-block severity is invariant to block time; drift to longer block times slows ratchet accumulation in wall-clock terms without changing the peak basefee, making the 600 ms results conservative upper bounds. Sensitivity analysis across additional fixed block-time regimes is identified as a future research direction.

Figure 7. Spam attack scenario: Configuration 1 (top, 150M limit) vs. Configuration 3 (bottom, 300M limit), both per-block at $r_{max}=0.05$. The basefee starts at the minimum floor (Phase 1, green), escalates during the attack phase (blocks 100–200, red), reaching 1.89 Gwei (12× minimum) for Config 1 and 2.50 Gwei (16× minimum) for Config 3, and then decays during recovery (blue). Config 3 peaks 32% higher due to greater per-block spam absorption but recovers faster. Partial spam exclusion begins at attack block 54 (Config 1) and block 28 (Config 3); full exclusion does not occur within 300 blocks as the basefee remains below the 3.0 Gwei spam ceiling. For the data lines: top panel—blue line = basefee (Gwei); middle panel—green line = gas used per block (millions); bottom panel—purple line = utilization ratio.

Figure 7. Spam attack scenario: Configuration 1 (top, 150M limit) vs. Configuration 3 (bottom, 300M limit), both per-block at $r_{max}=0.05$. The basefee starts at the minimum floor (Phase 1, green), escalates during the attack phase (blocks 100–200, red), reaching 1.89 Gwei (12× minimum) for Config 1 and 2.50 Gwei (16× minimum) for Config 3, and then decays during recovery (blue). Config 3 peaks 32% higher due to greater per-block spam absorption but recovers faster. Partial spam exclusion begins at attack block 54 (Config 1) and block 28 (Config 3); full exclusion does not occur within 300 blocks as the basefee remains below the 3.0 Gwei spam ceiling. For the data lines: top panel—blue line = basefee (Gwei); middle panel—green line = gas used per block (millions); bottom panel—purple line = utilization ratio.

4.7. Extended Horizon Validation

To validate that 300-block conclusions extend to longer horizons, we conducted extended 1000-block simulations (10 min at 600 ms, 10× the main analysis) for the two most policy-relevant scenarios. Under variable demand, the basefee oscillates stably across all 16 complete sine cycles with no drift (Config 1: 0.16–0.26 Gwei; Config 3: returns to exactly MIN), confirming long-run periodic stability (Figure 8). Under spam attack, the basefee peaks at 1.89 Gwei (Config 1) and 2.50 Gwei (Config 3) during the attack phase; then, it decays back to the minimum floor: Config 3 recovers by block 302 and Config 1 by block 364. Recovery is driven by the 70M gas post-attack demand falling below target, confirming that the basefee self-corrects when baseline load is properly below target (Figure 3).

5. Discussion

This paper provides the first comprehensive analysis of the EIP-1559 dynamic fee mechanisms adapted to sub-second block environments, using Injective operating at 600 ms block times. Appropriate parameter tuning enables high-throughput chains to implement dynamic fee markets with properties comparable to Ethereum while leveraging architectural advantages for faster convergence and spam response.

5.1. Main Findings

5.1.1. Sub-Second Block Environment Implications

The MA-25 mixed effects documented in Section 4.2 reveal a general principle: smoothing mechanisms that introduce temporal memory must scale their window size with block time. A 25-block window spanning 15 s at 600 ms is fundamentally different from the same window spanning 5–6 min on Ethereum. The mechanism “remembers” brief spikes for the entire window duration, producing counterproductive fee increases after demand has already subsided.

Conversely, the rapid spam mitigation observed in Section 4.5 demonstrates a key advantage of sub-second architectures: economic barriers emerge within seconds rather than minutes [2], and the basefee self-corrects to the minimum floor within minutes of attack cessation when baseline demand is properly calibrated below target, justifying lower minimum fees since spam attacks cannot sustain elevated fees beyond the recovery window.

Controlled mainnet experiments validate these predictions: demand spikes confirm the ratchet effect and progressive basefee accumulation, while spam attacks confirm rapid escalation (12–16× minimum in simulation, approximately 16× minimum in mainnet experiments at the calibrated $r_{max}=0.05$) and subsequent decay, which is consistent with simulation predictions.

5.1.2. Block Limit Scaling Trade-Offs

Doubling the block gas limit from 150M to 300M while adjusting target utilization from 66.66% to 50% produces scenario-dependent effects (Table 7, Table 8, Table 9 and Table 10). The block capacity and target utilization ratio affect fee dynamics through different channels: capacity determines how much absolute demand a block can absorb, while the target ratio sets the threshold above which fees increase. Sensitivity analysis at matched utilization ratios confirms that capacity primarily benefits spam attack scenarios, while the target utilization ratio drives variable demand outcomes. Lower target utilization benefits spam resistance but can backfire for oscillatory demand patterns that regularly exceed the target.

5.1.3. Ratchet Effect: Mathematical Analysis

The ratchet effect (Section 4.4 and Section 4.5) reveals a fundamental asymmetry in the EIP-1559 adjustment formula. The update produces three regimes: above target (basefee increases), below target (basefee decreases), and at target (no adjustment). The third regime is the root cause: when post-congestion demand settles at target utilization, the adjustment term equals zero regardless of the current basefee. The formula has no restoring force toward any reference level.

Asymmetric Dynamics. If demand stabilizes at exactly target utilization after a congestion episode, the basefee is frozen at its peak value:

$${\mathtt{basefee}}_t=B_{\mathrm{peak}}\forall t>t_{\mathrm{peak}}\mathrm{when}\mathtt{gas}\_{\mathtt{used}}_t=\mathtt{TARGET}\_\mathtt{GAS}$$

(8)

Recovery requires sustained below-target demand. For demand at fraction $\alpha$ of target ($0<\alpha <1$), the decay rate is shown below:

$${\mathtt{basefee}}_{t+n}=B_{\mathrm{peak}}\times {(1-(1-\alpha )\times r_{max})}^n$$

(9)

Theoretical Implications. The ratchet effect has two consequences for fee market theory:

1.

Target utilization is not an equilibrium. In control-theoretic terms, target utilization is a manifold of fixed points rather than a stable equilibrium. Any basefee value is a fixed point when the gas usage equals the target, creating path-dependent fee levels that depend on demand history rather than the current network state.

2.

Inflationary bias. The mechanism exhibits asymmetric sensitivity: congestion episodes ratchet the basefee upward, but recovery requires active below-target demand. Over time, this creates an upward bias in the average basefee relative to what a memoryless mechanism would produce.

Reset Mechanism Interaction. The 42,000-block periodic reset provides a hard upper bound on ratchet duration but is too coarse-grained to prevent re-accumulation if demand remains at target post-reset.

5.2. Implications for Fee Market Design

5.2.1. Contributions to EIP-1559 Research

This paper extends existing EIP-1559 analysis [1,2,3] by demonstrating that block time is not merely a scaling factor but fundamentally alters mechanism dynamics, particularly for smoothing approaches that introduce memory lag. The experimental evaluation of MA-25 represents a negative result with practical value: the smoothing window size must scale with the block time, and mechanisms designed for minute-scale blocks cannot be directly applied to second-scale environments without substantial parameter modification.

More broadly, this paper shows that EVM-standard fee mechanisms are not inherently coupled to Ethereum’s 12 s, probabilistic-finality architecture. With appropriate recalibration, EIP-1559 operates effectively in a sub-second BFT environment with structural advantages: spam mitigation completes in seconds rather than minutes, minimum fees can be set lower without compromising security, and deterministic finality eliminates reorganization-based MEV strategies.

5.2.2. Parameter Selection Framework

For high-throughput chains adopting EIP-1559-style fee mechanisms, several patterns emerge. Chains expecting smooth demand below target benefit from higher block limits with lower target percentages. Chains with frequent demand spikes approaching limits face more complex trade-offs. Chains vulnerable to spam attacks benefit from higher limits, which drive faster post-attack recovery at the cost of higher peak fees, due to greater per-block spam capacity.

The most actionable finding of this paper is the identification of $r_{max}=0.05$ as Pareto-optimal for sub-second fee markets. At this value, the ratchet severity under sustained demand is $20\times$ MIN, a $19\times$ reduction from the initial testnet configuration ($r_{max}=0.10$, severity $373\times$ MIN), while spam resilience is barely affected: at $r_{max}=0.05$, the Config 3 spam peak reaches 2.50 Gwei (83% of the 3.0 Gwei spam fee ceiling), matching $r_{max}=0.10$ performance, since both are bounded by the fee cap ceiling. Values below $r_{max}=0.03$ degrade spam responsiveness unacceptably (the basefee still rising when the attack phase ends), establishing a practical lower bound. The viable operating range for sub-second fee markets is therefore $r_{max}\in [0.03,0.06]$, with $r_{max}=0.05$ as the recommended default. The periodic reset mechanism (42,000 blocks, approximately 7 h) provides a safety net against indefinite basefee drift but is too coarse-grained to address intra-reset ratchet accumulation.

5.2.3. MEV Considerations

Our simulation models non-strategic block producers, but Maximal Extractable Value (MEV) represents an important real-world incentive layer that interacts with fee market dynamics. On Ethereum, MEV-aware validators can manipulate the basefee through strategic block filling [13], and no non-trivial fee mechanism achieves full incentive compatibility when producers have private valuations from transaction ordering [14,20].

CometBFT’s architecture partially mitigates these concerns through two mechanisms. First, the rotating proposer model limits any single validator’s ability to sustain basefee manipulation across consecutive blocks, unlike Ethereum, where validators may propose multiple sequential blocks. Second, Injective’s deterministic finality eliminates reorganization-based MEV strategies (time-bandit attacks), reducing the economic incentive for consensus-layer manipulation.

However, the within-block MEV (sandwich attacks, arbitrage, liquidation extraction) remains relevant for DeFi-focused chains, where searchers competing for block space with inflated premiums could amplify basefee volatility. Quantifying these effects through MEV-aware agent-based simulation is an important extension of this paper.

5.3. External Validity and Generalizability

Our findings combine chain-specific observations with insights that generalize beyond Injective. We distinguish these explicitly.

Injective/CometBFT-Specific Findings. The following results depend on Injective’s particular architecture and cannot be directly transferred: (1) the specific block gas limits (150M, 300M) and target utilization ratios tested, which reflect Injective’s transaction size distribution and validator capacity; (2) the 42,000-block reset interval, which is an Injective-specific design choice; (3) the absolute basefee values (0.16–2.50 Gwei under calibrated parameters), which depend on Injective’s native token economics; and (4) the MainNet validation results, which reflect CometBFT’s specific consensus behavior including block-time drift under load.

Generalizable Insights. The following findings should apply to any high-throughput blockchain implementing EIP-1559-style fee mechanisms with sub-second block times while also subject to the assumptions below: (1) temporal smoothing mechanisms with fixed block-count windows produce overshoot when the block time decreases, because the effective temporal memory compresses; (2) per-block adjustment mechanisms converge faster in absolute time proportional to block time reduction; (3) the ratchet effect is a structural property of the EIP-1559 formula independent of chain-specific parameters; and (4) higher block capacity accelerates both basefee escalation and post-attack recovery during fixed-intensity attacks, producing higher peaks but faster return to the minimum floor.

Transferability Assumptions. These generalizable insights require (1) sub-second BFT consensus providing deterministic finality, as chains with probabilistic finality face different fee dynamics due to reorganization risk; and (2) an EIP-1559-style multiplicative basefee adjustment formula, as additive or auction-based mechanisms would exhibit different dynamics.

5.4. Limitations and Future Research

This paper employs simulation-based analysis with several simplifications. The agent-based model represents user behavior through statistically distributed fee caps rather than capturing real-world transaction submission patterns, mempool dynamics, and strategic user behavior. Block producers are modeled as non-strategic actors, omitting MEV extraction strategies [20]. The simulation does not account for network propagation delays, chain reorganizations, or validator incentive structures.

Demand scenarios represent synthetic patterns designed to isolate specific mechanism behaviors rather than empirically derived transaction patterns. The 300-block (3-min) horizon was chosen to isolate transient dynamics of basefee adjustment, convergence, and spam response. Extended 1000-block simulations (Section 4.7) validate that these conclusions generalize to longer horizons: variable demand mechanisms are long-run stable, while demand spikes create a persistent ratchet effect that requires sustained below-target demand to resolve.

The parameter space exploration examines four configurations, representing a narrow slice of possible design choices.

Controlled MainNet experiments partially validate simulation predictions. Validation remains limited to short-duration controlled tests; long-term validation across diverse organic demand patterns remains necessary.

6. Conclusions

Across twelve simulation configurations, this paper provides evidence that EIP-1559 fee mechanisms can operate effectively in sub-second BFT environments when parameters are recalibrated for the temporal scale. Controlled mainnet experiments validate key predictions, confirming basefee stability and the ratchet effect.

Sensitivity analysis across $r_{max}\in [0.02,0.20]$ identifies $r_{max}=0.05$ as Pareto-optimal for sub-second EIP-1559 fee markets: it reduces ratchet severity to $20\times$ MIN while maintaining adequate spam resilience, providing simulation-based parameter guidance for MainNet deployment. The MA-25 mechanism shows mixed effects at this lower change rate: significant overshoot in some scenarios (spam attack 300M: +47%) but slight smoothing in others. Among the tested window sizes ($MA\in \{3,5,10,25\}$), MA-25 provides the strongest volatility reduction (1.4–2.8× lower CV than MA-3). Per-block updates provide more consistent performance with immediate responsiveness.

Block gas limit scaling produces scenario-dependent effects. Doubling capacity from 150M to 300M yields 31% lower peak fees during variable demand; during spam attacks, the 300M configuration peaks 32% higher due to greater per-block spam absorption but recovers to the minimum floor faster, while proportionally scaled demand spikes show higher basefee pressure at 300M due to sustained above-target utilization. Sub-second block times provide substantial advantages for spam mitigation, establishing initial economic barriers within approximately 28–54 blocks (17–32 s) compared to Ethereum’s 4–6 min, with full post-attack recovery within 364 blocks, supporting the viability of the low minimum basefee.

These findings demonstrate that one-size-fits-all approaches are suboptimal: block limit scaling affects fee dynamics differently under variable demand versus spam attacks, and smoothing mechanisms designed for minute-scale environments create overshoot in second-scale systems. Fee market mechanisms benefit substantially from tuning to their operational environment rather than direct transplantation across architectures.

Future research directions include extended simulations spanning multiple reset cycles to characterize long-run equilibrium properties, MEV-aware agent modeling for DeFi-focused chains, ratchet effect remedies (exponential decay, dual-threshold asymmetric adjustment), mempool lane integration, multi-chain fee market analysis, and extended real-world validation through MainNet data collection across diverse demand patterns.