Anza urges Solana validators to install Agave 4.4.1 before epoch 1079
Validators running outdated software could be forked off Solana’s mainnet-beta consensus and lose network rewards when epoch 1079 begins on Nov. 6.
Anza is urging Solana mainnet-beta validators to upgrade immediately to Agave 4.4.1, warning that operators who remain on older versions could be excluded from consensus when epoch 1079 begins. The transition is expected at approximately 13:30 UTC on Nov. 6, 2026, giving operators roughly a day to complete the change.
What Anza is asking validators to do
Anza, the engineering firm behind the Agave validator client, issued its advisory on Nov. 5. The release contains a critical compatibility fix that standardizes the data size for loader-v3 ProgramData accounts.
The change is required ahead of an upcoming feature-gate activation. Solana uses feature gates to activate protocol changes at defined points, meaning validators must run compatible software before the network reaches the relevant epoch.
Operators that fail to upgrade face two immediate risks:
- Being forked off the network when epoch 1079 starts.
- Losing participation in consensus and associated network rewards while running an incompatible version.
The warning does not indicate a change to Solana’s core economic model or block-production rules. Instead, it addresses how upgradeable programs are deployed and stored through loader-v3, a foundational component of the network’s program infrastructure.
Agave rollout and alternative client support
The recommendation follows the recent rollout of Agave v4.4.0, which Anza tagged as stable and recommended for general mainnet use on Oct. 30. That release underwent a phased deployment, with the share of stake running the new version increased from 10% to 20% before the broader recommendation was issued.
The latest advisory makes Agave 4.4.1 the immediate target for operators on the Agave client. Validators using a different implementation have another option: Firedancer 26.10.6 has been confirmed to meet the new requirements.
The client compatibility details highlight the importance of validator software diversity and coordinated release management on Solana. A validator’s version determines whether it can correctly interpret network rules and remain aligned with the rest of the cluster during a feature activation.
What This Means
For most Solana users, the upgrade should be operationally invisible if validator participation remains high. The principal risk is concentrated among operators that miss the deadline, because incompatible validators could lose consensus connectivity and rewards at the epoch transition.
The short notice also underscores the need for rapid coordination between Anza, validator operators and alternative client teams. If enough stake fails to upgrade, network liveness and consensus participation could face disruption. With Firedancer 26.10.6 already confirmed as compatible, however, the immediate issue is validator readiness rather than a planned change to user-facing functionality or network economics.