Tired of brute-forcing Basefee parameters? RIGID gets you closer.

Every transaction on an EVM chain pays a base fee - the minimum gas price required for inclusion in a block. Introduced with EIP-1559, this mechanism was meant to make fees more predictable.

At Blocknative, we’ve expanded our gas analytics services from 2 to over 40 chains in just a few months, and we’ve learned a lot in the process. One key takeaway: calculating fees in a multichain environment is anything but straightforward, yet indispensable if we are to enable smoother crosschain flows, use cases, and UX.

In this article, we’re going to focus on one critical piece of the puzzle: Base Fee calculation.

We started with what seemed like the most straightforward assumption: base fee is a deterministic value. If we have the right formula and parameters, calculating it should be trivial. After all, EIP-1559 defines it precisely, and many chains claim to follow it.

But we quickly ran into a core issue - the parameters themselves were elusive. The most critical one, the gas target, wasn’t consistently or reliably documented. We turned to block explorers like BlockScout and Etherscan to pull it directly. That got us part of the way - but as we validated the values across blocks, we realized many were inaccurate or stale.

At Blocknative, we’ve been deep in the gas space for years. And yet, this effort - to surface just one number reliably across chains - pushed us to build custom tooling, apply creative brute force strategies, reverse engineer opaque logic, and even reach out directly to protocol teams. Some teams didn’t even have a definitive answer to how their base fee was calculated on a block-by-block basis.

This experience wasn’t just frustrating - it was revealing.

If we, with all our focus on real-time gas, had to jump through this many hoops to provide clean data to the ecosystem… what does that mean for all the other builders working on wallets, crosschain protocols, or UX tooling, for whom gas is just one moving part among many?

We believe it shouldn’t be this hard. That’s why, at Blocknative, we see it as our mission to untangle gas mechanics and make them transparent and accessible - for every chain, and every developer.

Once we realized that relying on explorer values wasn’t sufficient, we kicked off a deeper, layered effort to accurately compute base fees across chains. What followed was a mix of research, engineering, and detective work - and every step was necessary to uncover how different chains interpret or diverge from EIP-1559 in practice.

Here’s how we approached it:

• Cross-checking Block Explorer Data

We started by building a script to fetch gas targets from explorers like BlockScout and Etherscan. But discrepancies across blocks quickly made it clear: these sources were often unreliable. Inconsistent values across chains meant we couldn’t trust this data for robust prediction.

• Testing Known Parameter Combinations

Next, we implemented a script to try all known combinations of base fee parameters (target gas, elasticity, denominator) - essentially validating hypotheses against real chain behavior. This worked surprisingly well for many chains that closely followed the Ethereum L1 model or its derivatives.

• Brute-Forcing Unknowns

For networks where no known combination worked, we brute-forced through parameter ranges to identify values that matched block-by-block behavior. This gave us a solid fallback when documentation was outdated, incorrect, or entirely missing - which turned out to be more common than expected.

• Extracting Data from OP Stack ExtraData

A breakthrough came when we discovered that some OP Stack forks (like Holocene) encode EIP-1559 parameters in the extraData field of block headers. We wrote a dedicated parser to extract these values, and used them to update our models across OP Stack-derived networks. This pattern greatly simplified the process for the chains in that ecosystem.

• Custom Reverse Engineering for Complex Chains

That left a handful of outliers - networks like Arbitrum, Sei, Avalanche, Scroll, Moonbeam, and Ronin - that didn’t expose parameters directly and relied on custom logic. For these, we analyzed the source code and began reconstructing their CalcBaseFee logic ourselves.

On Moonbeam and Ronin, our reverse-engineered models matched 100% of block data. For Arbitrum, Sei, and Scroll, we got close - but small mismatches persisted so we reached out to the teams.

• Contacting Protocol Teams

In cases where our calculations didn’t align perfectly with onchain values, we reached out to the protocol teams directly. To our surprise, even some internal teams couldn’t immediately clarify their base fee mechanics - either because the logic had evolved, or the tooling hadn’t caught up. It was a strong signal: if the protocol maintainers themselves can’t verify gas calculations easily, how can anyone else? 

This reinforced how opaque and fragmented gas logic has become across the ecosystem.

Now that we’ve walked through the work it took to successfully decode base fee behavior across chains, let’s get concrete. What exactly are these parameters that so often go undocumented or differ chain to chain? 

To understand what’s been so hard to pin down - and what any reliable fee infrastructure must account for - we first need to look closely at how EIP-1559 defines base fee mechanics.

Ethereum’s London upgrade (August 2021) introduced an Ethereum Improvement Proposal, EIP-1559, overhauling the gas fee market. In EIP-1559, each block has a Base Fee – the minimum gas price per unit required for inclusion – that adjusts algorithmically based on congestion. The base fee rises or falls to target a fixed block utilization, while any optional Priority Fee (often referred to as a tip) incentivizes validators to prioritize a transaction. Typically, the base fee portion is burned (permanently removed from circulation), whereas the priority fee is paid to the block producer. This mechanism is designed to make fees more predictable for users by smoothing out sudden price spikes.

The base fee is deterministically calculated to target a fixed gas usage per block.

At the heart of the mechanism is this formula:

Where:

• baseFee(n+1) is the base fee in the next block

• baseFee(n) is the base fee in the current block

• gasUsed is the gas consumed in that block

• targetGas is the desired gas usage per block

• denominator determines the maximum rate of change per block
  

While not directly in the formula above, the elasticity multiplier plays a crucial role in setting the targetGas. It defines how much the block's overall gas limit can expand or contract to meet demand. The targetGas is always calculated as: 

targetGas = blockGasLimit  / elasticity multiplier

Ethereum L1 uses:

• Elasticity multiplier: 2

• Block gas limit: 30M

• Target gas: 15M (30M / 2)

• Base fee change denominator: 8

This means the base fee can increase or decrease by up to 12.5% per block, depending on how full the block is. If usage matches the target exactly, the base fee stays constant. If the block is completely full, it rises. If it’s nearly empty, it drops.

Since 2021, Layer 2s and alt-L1s have taken over a large share of EVM transaction volume. While many claim to follow EIP-1559, the reality is far more fragmented.

Each chain implements its own version of gas mechanics - some tweak the elasticity multiplier, others adjust the denominator, some encode parameters in fields like extraData, and a few don’t follow the formula at all. These differences are rarely published in a structured, machine-readable format, making it hard for developers and automated systems to reliably calculate fees across chains.

To understand the scale of this fragmentation, take a look at the table below. It lays out the Base Fee calculation parameters for some of the Blocknative Gas Network's chains. Notice the variations in Denominator, Elasticity, and Custom Logic even among chains claiming EIP-1559 compliance.

Table of Base Fee calculation parameters:

Base fee calculations are often described as simple and deterministic. In practice, they are neither. Chain-specific implementations, undocumented parameters, and edge-case behaviors make it difficult to model gas costs reliably - even for EIP-1559 chains.

This complexity directly impacts developers and infrastructure teams working across ecosystems. Without clear, machine-readable parameters, fee estimation becomes fragile, integration is slower, and user experience suffers.

At Blocknative, we analyzed 40+ chains and encountered the same issues repeatedly. The root cause was clear: the lack of a standard interface for exposing gas market configuration.

To address this, we introduced RIGID - the Rollup Interoperable Gas Interface Declaration - an onchain interface that enables any chain to specify its gas market rules in a format that is easy to read, verify, and integrate, both for developers and automated agents.

We’re proposing RIGID to the community as a foundation for more reliable gas infrastructure across chains.

For more details, refer to the RIP draft here: https://github.com/ethereum/RIPs/pull/73
Join the conversation about RIGID on Eth Magicians