Descout
Guide··6 min read

What Helicon Changes on Avalanche's C-Chain and P-Chain

Helicon has been Active on Avalanche's Fuji Testnet since July 28, 2026; Mainnet activation is Not yet scheduled. Here is what the six-ACP upgrade changes and what validators need to do before it lands.

Drafted by the Descout article deskHow this was made
Share:
What Helicon Changes on Avalanche's C-Chain and P-Chain - Tutorial and guide

Helicon is Avalanche's next Primary Network upgrade, and it activates six Avalanche Community Proposals (ACPs) at once. It changes how the C-Chain executes blocks and prices gas, and it rewrites several Primary Network staking rules — how long a validator can stake for, how much uptime it needs, and whether it has to re-stake at all, according to Avalanche's own builder documentation. Team1, @avaxteam1 — Avalanche's global community and builder network — calls it "Avalanche's biggest staking and C-Chain upgrade since genesis."

Where it stands right now

Helicon has been Active on Avalanche's Fuji Testnet since July 28, 2026 at 15:00 UTC, per Avalanche's activation-status table. Mainnet activation is listed as Not yet scheduled — the status reads Pending, with no date attached. Fresh local and custom networks are the exception: they run with Helicon's rules Active by default from genesis, so only Fuji and Mainnet validators are waiting on a rollout.

That testnet activation is worth separating from when the wider community heard about it. @avaxteam1 posted a rundown of the upgrade on Aug. 6, 2026 — over a week after the Fuji activation itself — pointing builders to Avalanche's blog post and docs for the technical detail Descout's earlier coverage of that post didn't have space to unpack. Fuji nodes also need a Helicon-capable build: the activation shipped in AvalancheGo v1.15.0-fuji, a Fuji-only release that refuses to start against a Mainnet configuration and does not yet support C-Chain state sync while Helicon is active, per the same docs.

What changes on the C-Chain

Two of the six ACPs land on the C-Chain, Avalanche's EVM-compatible chain.

Continuous Execution (ACP-194) decouples consensus from execution. Instead of executing a block's transactions before a validator accepts it, a block is now considered valid once its transactions can be paid for, and execution happens afterward through a queue that a concurrent executor clears — with the resulting state root recorded after a delay rather than immediately, per the ACP-194 spec. The docs' own developer guidance is blunt about the side effects: several C-Chain RPC namespaces are deprecated alongside the change, and Avalanche tells C-Chain developers to read its execution docs and the v1.15.0-fuji release notes rather than assume existing behavior holds.

Dynamic minimum gas price (ACP-283) replaces the C-Chain's fixed 1-wei price floor with one that validators set by voting, using the same stake-weighted mechanism ACP-176 and ACP-226 already established. Avalanche's own writeup of the proposal frames the change as a response to spam: at close to zero gas cost, protocols like XEN have run proof-of-work mining on-chain, forcing wallets to artificially inflate gas prices on failing transactions as a stopgap. The new floor is meant to bind during quiet periods while leaving the existing ACP-176 fee mechanism to handle congestion.

What changes for P-Chain validators

The other four ACPs rewrite Primary Network staking mechanics.

Auto-renewed staking (ACP-236) lets a validator set a cycle duration and an auto-compound percentage instead of a fixed end date; the P-Chain settles rewards and starts the next cycle automatically at each boundary. Renewal is conditional — a cycle that misses the uptime bar ends the validation instead of renewing it — and delegations still cannot auto-renew, per Avalanche's staking-changes writeup.

Uptime requirement (ACP-267) raises the bar for earning rewards from 80% to 90%, applied to any validation whose start time is at or after Helicon's activation — a validation already running keeps its 80% bar, but every auto-renewed cycle starts fresh after activation and is always held to 90%. Avalanche L1 validators are unaffected; they keep whatever uptime their own subnet transformation sets. The reward model otherwise stays all-or-nothing with no partial payout and no slashing, per the docs.

Minimum staking duration (ACP-273) drops from two weeks to 48 hours on Mainnet, and from 24 to 12 hours on Fuji; custom networks default to one hour, per Avalanche's docs. Delegators keep the existing minimum, and the one-year maximum is unchanged.

MinConsumptionRate (ACP-285) — the floor of the staking-reward curve — drops from 10% to 7.5%, phased in linearly over the 90 days after activation rather than all at once, per the same source. MaxConsumptionRate is untouched, so the cut mainly compresses rewards on short staking periods. Descout has covered separately what the Avalanche Foundation says this change is meant to do for AVAX's value capture — this guide is only about the mechanical change.

What validators and builders need to do

Avalanche's docs break the to-do list out by audience:

  • Fuji validators: upgrade to a Helicon-capable release, then check that the node clears 90% uptime rather than 80% — any validation started now is judged against the higher bar. Avalanche recommends calling info.uptime on the node itself and cross-checking against the public validator health dashboard, since a node's own view of its uptime can be misleading.
  • Mainnet validators: nothing is required yet, since activation is not scheduled — but the uptime bar will rise when it lands.
  • C-Chain developers: read the Continuous Execution docs and the v1.15.0-fuji release notes before assuming request/response behavior is unchanged, given the deprecated RPC namespaces.
  • Exchanges and custodians: the staking minimums and the uptime threshold both move together. Any product copy quoting a two-week minimum staking period becomes wrong the moment Mainnet activates — the real number becomes 48 hours.

What's still open

Mainnet has no scheduled activation date. Avalanche's own status table lists it as "Pending," and the docs note that a release supporting C-Chain state sync under Helicon is expected before that scheduling happens — implying the Fuji rollout is not yet considered feature-complete for a Mainnet cutover. There's no public timeline to point to beyond that; readers tracking activation should watch Avalanche's own docs and Team1's X account rather than assume a date.

Sources

Share: