Avalanche Helicon Goes Live on Mainnet: C-Chain Acceptance and Execution Are Now Decoupled, and `latest` No Longer Means Final

What happened

Ava Labs published AvalancheGo v1.15.0 on September 8, 2026, scheduling Helicon for "11 AM ET (3 PM UTC) on Tuesday, September 22nd, 2026" on mainnet. The release notes are explicit: "All Mainnet nodes must upgrade before 11 AM ET, September 22nd 2026." The plugin version moved to 46, so Subnet-EVM and other plugins had to follow. Helicon had been live on Fuji since July 28, and the Avalanche Builder Hub reports that it activated on mainnet as scheduled.

Six ACPs are included:

• ACP-194: C-Chain continuous execution
• ACP-236: auto-renewed validator staking
• ACP-267: uptime required for rewards, raised from 80% to 90%
• ACP-273: minimum staking duration, cut from 336 hours to 48 hours
• ACP-283: dynamic minimum C-Chain gas price
• ACP-285: mean consumption rate, reduced from 10% to 7.5%

ACP-285 alone ramps in linearly over the 90 days after activation. By our arithmetic, the ramp completes around December 21, 2026.

Continuous execution changes what "final" means

ACP-194 has the largest technical impact. Previously, consensus could not move on until a block's transactions had executed, so consensus and execution took turns. After Helicon, consensus accepts blocks into a queue after validating gas bounds, and a separate executor drains that queue. Builder Hub's explainer shows settlement following roughly five seconds after acceptance.

The C-Chain RPC redefines named blocks to match. Per the v1.15.0 notes, latest is the last executed block, while safe and finalized are both the last settled block. pending defaults to the last executed block, or the last accepted block if api-resolve-pending-to-last-executed is set to false.

The rationale is to make throughput bounded by acceptance rather than execution. The cost is that three distinct moments now exist: accepted, executed and settled. Avalanche-specific code that never had to distinguish Ethereum's latest from finalized loses that assumption here. Bridges and indexers that treated latest as effectively final, relying on Snowman's fast finality, may now read executed-but-unsettled state.

ACP-283 replaces the 1 wei floor set by ACP-176 (Octane) with a stake-weighted median of validator votes, cast through a min-price-target setting. According to Builder Hub, observed minimum prices had sat around 10^5 wei, cheap enough that spam protocols such as XEN remained profitable. BlocksToDouble is set to 3,600, so under sustained voting pressure the floor can double or halve in roughly an hour. Builder Hub tells developers to "fetch fee parameters from the network instead of assuming a fixed floor."

The API has breaking changes too:

• The admin, warp and personal namespaces are removed.
• eth_accounts, eth_coinbase and eth_etherbase are removed, along with eight debug RPCs including debug_dumpBlock.
• avax.getAtomicTxStatus is deprecated in favor of avax.getAtomicTx.
• rpc-gas-cap is fixed at 50,000,000 and rpc-tx-fee-cap at 100 AVAX; configured values are ignored.

Staking changes and their rationale

The P-Chain changes aim at institutional capital. ACP-273 describes the two-week minimum as a direct conflict with institutional redemption timelines.

ACP-236 replaces a validator's fixed end time with a cycle duration (period) and an auto-compound ratio. It uses three new transaction types:

• AddAutoRenewedValidatorTx registers the validator.
• SetAutoRenewedValidatorConfigTx changes the configuration for the next cycle.
• RewardAutoRenewedValidatorTx is issued by consensus at each cycle's end.

If a cycle's uptime falls short, the validator is force-exited and that cycle's reward is forfeited.

Delegations do not auto-renew and must fit inside a single cycle, since continuation is not guaranteed for any validator. For staking providers, this means rework in three places:

• reward compounding;
• reading the new period, autoCompoundRewardShares and validatorAuthority fields in platform.getCurrentValidators;
• tracking delegation maturity.

Pitfalls to watch

The first pitfall is state sync. The notes warn that C-Chain state sync is not supported immediately around activation, and a syncing node may stall. After activation, the following limits apply:

• Restarting mid-sync starts the sync from the beginning.
• Disabling state sync after a partial sync may cause an unrecoverable FATAL error.
• A new Firewood node must set state-sync-enabled to false, or it shuts down with FATAL.

The only recovery is to delete the database. Setups that rebuild nodes automatically are the most likely to hit this.

The second is config compatibility:

• state-sync-ids is now a JSON array rather than a comma-separated string.
• api-max-duration accepts only a duration string such as "30s"; a number is rejected.
• commit-interval must be 4096 on Mainnet and Fuji.
• eth-apis is deprecated, and an unknown name in it is fatal.

Organizations that push configs through tooling may pass the upgrade itself and only fail at the next node rebuild.

The third is the scope of the uptime rule. The 90% bar applies only to staking periods that start on or after activation; earlier periods are still judged at 80%. With ACP-236, every new cycle is a new period, so 90% applies from the first renewal. Rewards remain all-or-nothing. The shorter the cycle an operator runs, such as 48 hours, the more directly a brief outage turns into a forfeited reward.

[Technical Insights & Actions]

1. On chains that decouple acceptance from execution, "included in a block", "reflected in state" and "irreversible" become separate moments. Code that treated latest as final because finality was fast will break the same way on any chain that moves in this direction, not just Avalanche. [Integrators] By your next release, inventory the block tags used by C-Chain bridges, deposit and withdrawal monitors, and indexers, and switch finality checks to finalized (the last settled block).
2. The minimum gas price can now double or halve in about an hour through validator votes. Hard-coded gasPrice, very low maxFeePerGas values and fixed fee estimates become sources of silently failing transactions. [Contract developers / Product teams] This month, remove fixed gas prices from submission code and compute fees from eth_feeHistory and the current base fee. At the same time, search for dependencies on removed RPCs such as eth_accounts.
3. Most of this release's breaking changes surface not on upgrade day but at the next node rebuild or resync. [Node operators] Within two weeks, add the state sync FATAL conditions (Firewood; disabling mid-sync) and the new config formats to your runbooks, and rehearse a from-scratch node rebuild in staging. Validators should alert whenever uptime drops below 90%.

[Sources]

• Ava Labs / ava-labs/avalanchego, "Helicon: Continuous Execution & Auto-Renewed Staking (v1.15.0)" (2026-09-08): https://github.com/ava-labs/avalanchego/releases/tag/v1.15.0
• Avalanche Builder Hub, "Helicon: Improved Staking Economics and Continuous Execution" (2026-09-08, updated after activation): https://build.avax.network/blog/helicon-upgrade
• Avalanche Foundation, "ACP-194: Continuous Execution": https://build.avax.network/docs/acps/194-continuous-execution
• Avalanche Foundation, "ACP-283: Dynamic Minimum Gas Price": https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/283-dynamic-minimum-gas-price

This article is a technical commentary based on publicly available information and is not investment advice.