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

What Changes

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.

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. Run AvalancheGo v1.15.0 or later. A node on an older release cannot follow Mainnet after the Helicon activation on September 22, 2026 at 15:00 UTC. v1.15.1 is an optional upgrade and uses the same plugin version (46). 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 v1.15.0 removed the admin, warp and personal C-Chain RPC namespaces. 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 after the block that contains the transaction executes.

Exchanges and custodians. The minimum validator staking period and the uptime threshold changed at Helicon. Since September 22, 2026, the minimum validator staking period on Mainnet is 48 hours. The minimum delegation period is still two weeks. Validations that start at or after the activation need 90% uptime.