Increasing the Gas Capacity in the Avalanche Network and Its Impact

One of the most consequential yet under-discussed developments in the EVM ecosystem happened on the Avalanche C-Chain over the past few months: validators increased the network's target gas consumption by 30%, from 1.6 million to 2.1 million gas per second. Enabled by the Octane upgrade that went live on April 6, 2025, this increase positions Avalanche to become one of the lowest latency, highest throughput EVM L1 experiences available. Having written about Avalanche L1s back in July, watching the C-Chain itself scale is the natural complement, and the approach they are taking is genuinely novel.

What Changed and Why It Matters

The gas target determines how much computational work the network processes per second. A higher target means more transactions, more smart contract operations, and ultimately lower fees for users. The 30% increase from 1.6M to 2.1M gas/sec directly raises the ceiling on how many transactions the C-Chain can handle before congestion pricing kicks in.

For users, this translates to higher potential transactions per second during peak demand, lower transaction fees due to reduced congestion, and better application performance for gas-intensive operations like DeFi and gaming.

For developers building on the C-Chain, the practical impact is that applications can scale further before needing to consider migrating to a dedicated Avalanche L1.

The Octane Upgrade: Dynamic Gas Target Adjustment

What makes this particularly interesting from an engineering perspective is how the increase happened. Traditional blockchain upgrades require hard forks, which are coordinated network-wide software updates that are complex, risky, and politically fraught. The Octane upgrade introduced a fundamentally different mechanism: dynamic validator signaling.

Under this system, Avalanche Primary Network validators can set their preferred gas target values directly. The network calculates the effective gas target based on the weighted preferences of participating validators. Validators that do not set a preference effectively abstain by defaulting to the current value.

This is a significant governance innovation. Instead of requiring everyone to agree on a hard fork, the network can adjust capacity parameters organically based on the technical assessment of the validator community. It reminds me of how TCP congestion control works: participants signal their capacity, and the network finds equilibrium.

Having spent years in the developer tools space where we constantly debated how to ship infrastructure changes safely, I find this approach compelling. It reduces the coordination overhead of scaling decisions while keeping the process decentralized. The Avalanche Foundation has been iteratively increasing their validator preferences while monitoring network health metrics, essentially doing a controlled, gradual rollout of higher capacity.

How They Ensured Network Stability

Increasing throughput is not free. More gas per block means more computation, more state growth, and more network traffic. The Avalanche team monitored several key performance indicators throughout the process, and the results are reassuring.

Block Verification Times

As gas targets increase, blocks can contain more gas and take longer to execute. The team set a threshold of no more than 5% of consensus time spent on block execution. Despite a small initial increase, validator nodes stayed below this threshold, meaning consensus remained stable even with larger blocks.

Disk Usage and State Growth

Higher gas consumption means more potential state growth. All validators must maintain the full chain state on disk, so unsustainable growth rates would be a real problem. The observed rate of about 3 to 4 GB per day remained relatively constant through the increase. State growth did not spike, which indicates the network is not accumulating storage debt.

Peer-to-Peer Network Health

The strongest signal of network stability: the percentage of successful peer queries showed no noticeable decrease throughout the gas target increases in June and July. If validators were struggling to keep up, they would fail to respond to peer queries about block proposals. The fact that query success rates held steady means the vast majority of nodes are handling the increased processing demands without issue.

These are the right metrics to watch, and the fact that they were monitored through iterative increases rather than a single jump shows engineering discipline. It is the same approach I would take for any infrastructure scaling event: gradual rollout with clear rollback criteria.

What Is Coming Next: SAE and Firewood

The 30% increase is just the beginning. Two major technical upgrades in development will enable substantially larger capacity improvements.

Streaming Asynchronous Execution (SAE)

Outlined in ACP-194, SAE introduces a fundamental architectural change: separating block execution from consensus. Currently, consensus must wait for blocks to execute before proceeding. SAE introduces a continuous execution thread that operates independently.

Why this matters: current gas targets must be conservative enough to handle worst-case execution times without delaying consensus. With SAE, gas targets can align with average-case execution times instead. This is a multiplicative improvement since you are no longer constrained by your slowest block.

This is analogous to the evolution from synchronous to asynchronous I/O in web servers. The same hardware handles dramatically more throughput once you decouple the processing pipeline.

Firewood Database Integration

The Firewood database is designed to significantly improve blockchain storage operations and reduce validator storage requirements through optimized data layout for blockchain access patterns, state pruning to maintain only recent state data, and reduced operational burden on validators.

By lowering the per-validator cost of higher throughput, Firewood enables the network to support even higher gas targets without increasing hardware requirements. This is critical for maintaining a decentralized validator set. If scaling requires expensive hardware, only well-funded validators can participate.

My Take: Why This Approach Wins

What excites me about Avalanche's scaling strategy is the combination of pragmatism and ambition.

Pragmatic. They are not waiting for a single revolutionary upgrade. They are shipping incremental improvements, measuring results, and iterating. The gas target increase was done in controlled steps with clear monitoring. This is how you scale production systems. I learned this firsthand at GitLab where we scaled infrastructure serving millions of developers.

Ambitious. The roadmap is clear. SAE and Firewood are not theoretical. They are in active development with defined architectural goals. The combination of dynamic gas targets, asynchronous execution, and optimized storage could make the C-Chain competitive with the highest-throughput EVM chains while maintaining decentralization.

Developer-friendly. For builders on the C-Chain, this is pure upside. More capacity means lower fees, better user experiences, and the ability to build more demanding applications without immediately needing a dedicated L1. Combined with the Avalanche L1 model for applications that need dedicated block space, developers have a clear scaling path.

The Broader EVM Landscape

Avalanche's approach contrasts with how other EVM chains handle scaling:

• Ethereum relies primarily on L2s for throughput, with the L1 focused on data availability
• Solana takes the monolithic approach with a single high-performance chain
• Avalanche offers both: C-Chain scaling and dedicated L1s for applications that need them

This multi-tier strategy feels right to me. Not every application needs its own chain, but some do. The C-Chain gas increase makes the shared environment viable for more applications, while L1s remain available for those that need isolation.

As a developer working across the Web3 ecosystem, I want the chain I build on to have a credible scaling roadmap that does not require me to re-architect my application every time demand grows. Avalanche's approach, with gradual capacity increases, backward-compatible upgrades, and dedicated chains when needed, provides that confidence.

---

The Avalanche C-Chain gas target increase is a technical achievement that deserves more attention. For the latest on Avalanche development, check the Avalanche Builder Hub and follow @AvaxDevelopers for updates on SAE, Firewood, and future capacity improvements.