Helicon Upgrade
What the Helicon network upgrade changes on the C-Chain and P-Chain, when it activates on each network, and what validators need to do.
Helicon Upgrade
Helicon is a Primary Network upgrade that activates six Avalanche Community Proposals. It changes how the C-Chain executes blocks and prices gas, and it changes several Primary Network staking rules, including how long a validator can stake for, how much uptime it needs, and whether it has to re-stake at all.
Activation Status
| Network | Activation | Status |
|---|---|---|
| Fuji | July 28, 2026 at 15:00 UTC | Active |
| Mainnet | September 22, 2026 at 15:00 UTC (11:00 AM ET) | Scheduled |
| Local and custom networks | Active from genesis | Active by default |
Nodes must run a Helicon-capable release
Mainnet activation ships in AvalancheGo v1.15.0. Mainnet nodes must be running it before September 22, 2026 at 15:00 UTC.
Fuji activation shipped earlier in AvalancheGo v1.15.0-fuji. That release is Fuji-only, refuses to start against a Mainnet configuration, and does not support C-Chain state sync once Helicon is active.
What Changes
| ACP | Change | Chain |
|---|---|---|
| ACP-194 | Continuous Execution: consensus and execution are decoupled through a queue, and state roots are recorded after a delay | C-Chain |
| ACP-236 | Auto-renewed staking: validators can renew automatically at the end of each cycle instead of expiring | P-Chain |
| ACP-267 | Validator uptime requirement rises from 80% to 90% | P-Chain |
| ACP-273 | Minimum validator staking duration drops to 48 hours on Mainnet and 12 hours on Fuji | P-Chain |
| ACP-283 | The C-Chain minimum gas price becomes dynamic, set by stake-weighted validator preference | C-Chain |
| ACP-285 | MinConsumptionRate drops from 10% to 7.5%, ramped over 90 days | P-Chain |
Staking Changes in Detail
Auto-Renewed Staking (ACP-236)
A validator can now specify a cycle duration (period, in seconds) and an auto-compound percentage instead of a fixed end time. At each cycle boundary the P-Chain settles rewards and starts the next cycle automatically. Three transactions are involved: AddAutoRenewedValidatorTx, SetAutoRenewedValidatorConfigTx, and RewardAutoRenewedValidatorTx, the last of which is issued by block builders rather than by you. Their binary layouts are in the P-Chain transaction format.
autoCompoundRewardShares is expressed in millionths, in the range [0, 1000000]: 0 restakes the principal only and pays out every reward, 500000 splits rewards evenly between restaking and payout, and 1000000 restakes everything. Whatever is restaked is added to the validator's weight, capped at MaxValidatorStake; anything above the cap is paid out instead.
Renewal is conditional on reward eligibility, so a cycle that misses the uptime requirement ends the validation rather than renewing it. Delegation is unchanged and cannot auto-renew: a delegation must still fit inside the validator's current cycle.
How to stop an auto-renewed validator. There is no dedicated exit transaction. You issue a SetAutoRenewedValidatorConfigTx with period set to 0, signed by the validatorAuthority owner you nominated when the validator was added. The validation then stops at the end of the current cycle and the stake unlocks, rather than renewing.
What this looks like over the API. An auto-renewed validator is reported by platform.getCurrentValidators with three extra fields: validatorAuthority, nextPeriod and autoCompoundRewardShares. Its endTime is the end of the current cycle, not the end of the validation, and on each renewal startTime and endTime roll forward while txID stays the same. Tooling that infers "this validator is leaving" from a near endTime, or that treats a moving endTime as a new validation, needs updating.
See AVAX Staking for Professionals for the operational detail.
Uptime Requirement (ACP-267)
The threshold for earning rewards rises from 80% to 90%. This is not a genesis parameter change. The 90% figure is applied when the network decides reward eligibility for any Primary Network validation whose start time is at or after Helicon activation:
- A validation that started before activation is still judged against 80%.
- A validation that starts after activation needs 90%.
- Every cycle of an auto-renewed validator starts after activation, so auto-renewed validators are always held to 90%.
- Avalanche L1 validators are unaffected and keep the uptime requirement set by their own subnet transformation.
The reward model is unchanged in every other respect. It remains all or nothing, there is no partial payout, and there is no slashing: a validator that misses the threshold forfeits rewards but keeps its principal.
Minimum Staking Duration (ACP-273)
The minimum duration for a Primary Network validator drops from two weeks to 48 hours on Mainnet, and from 24 hours to 12 hours on Fuji. Custom networks default to one hour.
Delegators are not affected and keep the existing minimum, which is still two weeks on Mainnet. ACP-273 raised reducing the delegation minimum as an open question and it was not adopted, so the reduction applies to validators only: internally HeliconMinStakeDuration is consulted when building validator rules but not delegator rules. The maximum staking duration is unchanged at one year.
A short validation cannot be delegated to
Because the two minimums now differ, a delegation has to satisfy two conditions at once: it must last at least two weeks, and it must fit entirely inside the validator's staking window. A validator that stakes for only 48 hours satisfies neither for any possible delegation, so it cannot receive delegations at all. A delegator targeting it is rejected with ErrStakeTooShort or ErrPeriodMismatch.
The same applies per cycle to auto-renewed validators: the relevant window is the current cycle, not the lifetime of the validation. A validator that wants delegations needs a period of at least two weeks, plus enough room left in the current cycle for the delegation to fit.
Minimum Consumption Rate (ACP-285)
MinConsumptionRate, the lower bound of the reward curve, drops from 10% to 7.5%. The change is phased in rather than applied at once: it ramps linearly over the 90 days following activation, and the rate applied to a staking period is the one in effect at that period's start time. A stake starting 45 days after activation therefore uses roughly 8.75%.
MaxConsumptionRate is unchanged, so the effect is concentrated on short staking periods. See the staking rewards formula for how the two bounds combine.
What You Need to Do
Validators on Fuji. Upgrade to AvalancheGo v1.15.0-fuji or later. Then check that your node clears 90% uptime rather than 80%, since any validation you start now is judged against the higher threshold. Call info.uptime on your own node and cross-check against the validator health dashboard, because a single node's view of its own uptime can be misleading.
Validators on Mainnet. Upgrade to AvalancheGo v1.15.0 before September 22, 2026 at 15:00 UTC. A node still on an older release when Helicon activates will not follow the upgraded chain. Plan for the uptime threshold as well: any validation you start on or after activation is judged against 90% rather than 80%, and validations already running keep the 80% requirement.
C-Chain developers. ACP-194 changes when state is available relative to block acceptance, and several C-Chain RPC namespaces are deprecated alongside it. Read Continuous Execution and the v1.15.0 release notes before assuming existing behavior holds. Public API nodes no longer serve avax.getAtomicTxStatus. Poll avax.getAtomicTx instead: it returns blockHeight once the transaction is accepted.
Exchanges and custodians. The staking minimums and the uptime threshold both move. If you quote a two-week minimum staking period to users, that number becomes 48 hours on Mainnet on September 22, 2026.
Is this guide helpful?