On 5 November 2026, Anza told Solana validators "URGENT UPGRADE to Agave 4.4.1 is recommended or you will be forked off", and the Solana Status account named Agave 4.4.1 or Firedancer v26.10.6 (both per Solana Compass). The deadline was epoch 1079, which began on 6 November at 13:34 UTC (our on-chain check). Three days after it began, no outlet we read has said how much stake had upgraded. Our query of Solana's public RPC at 2026-11-09 16:13 UTC puts 59.7% of active stake on a version named in the warning, while 38.1% (142 validators, about 165M SOL) still advertises Agave 4.4.0. Those validators are still voting, and their vote credits show no large drop after the change activated.
Key Takeaways
- The gate, loaderv3_programdata_size_floor, changes how loaded data size is charged for loader-v3 ProgramData accounts (Agave PR #16769). It activated at slot 466,128,000, the first slot of epoch 1079, on schedule.
- Anza's own PR text is short. A commit message from the Tachyon fork, quoted on the PR #16769 page, says ProgramData "was never locked" and the result "depended on execution order and nodes could diverge".
- Gossip data shows 45.2% of stake on Agave 4.4.1, 14.5% on Firedancer 26.10.6, 38.1% on Agave 4.4.0 and 2.2% on other versions or with no entry.
- We found no sign of lost votes among the Agave 4.4.0 group, but vote credits cannot detect a divergence that needs a rare transaction pattern.
- This is a snapshot, and gossip versions are self-reported.
What Anza Asked For
According to Solana Compass, Anza told mainnet-beta validators at 19:20 UTC on 5 November to upgrade to Agave 4.4.1 before epoch 1079, estimated to start around 13:30 UTC on 6 November. Its wording, as quoted: "URGENT UPGRADE to Agave 4.4.1 is recommended or you will be forked off." The Solana Status account said all mainnet staked and unstaked validators, including RPC servers, must upgrade to Agave 4.4.1 or Firedancer v26.10.6. The same day, the fix went from merge to release: GitHub shows the Agave backport merged on 5 November and both releases published that day.
That left roughly 18 hours between Anza's post and the epoch boundary (19:20 UTC on 5 November to 13:34 UTC on 6 November, our arithmetic). CryptoTicker says Agave 4.4.0 began rolling out on 30 October, so operators moving to 4.4.0 needed a second upgrade within a week. Operators had also needed a specific client version for Alpenglow on 21 October (see our Alpenglow report).
What the Agave 4.4.1 Fix Does
The only functional change in the Agave 4.4.1 release notes is a backport (PR #16775) of PR #16769, "fix(svm): apply ProgramData size floor during account loading". The PR text is short: it says it wants to "support loaderv3_programdata_size_floor". According to the PR page, the gate changes the size charged for a loader-v3 ProgramData account to the transaction base size plus the larger of the account's data length and the size of the ProgramData metadata, and adds implicit read locks on those accounts. A bank-hash test value changed in the same PR.
The PR does not say why in plain words, and the page does not describe the change as consensus-breaking. A commit message from the Tachyon fork, quoted on the PR page, says ProgramData "was never locked" and that the result "depended on execution order and nodes could diverge", because a non-conflicting transaction could create or change ProgramData at the same time. That is the fork's explanation, not Anza's. The release note for Firedancer v26.10.6 says only "Adding support for loaderv3_programdata_size_floor feature" and describes the release as "a mainnet ready release".
PR #16775 carries a "conflicts" label and was merged with 51 checks passing.
What the Chain Shows
The feature account for loaderv3_programdata_size_floor (ID 8whkDenELnfwYLirBc4Wb4H2Z1z5K7tiykpdxJS7cWg1, from Solana Compass and the PR page) was activated at slot 466,128,000. That is the first slot of epoch 1079, with a block time of 13:34:20 UTC on 6 November, four minutes after Anza's estimate. The gate went live as planned.
For versions, we joined Solana's gossip node list to the vote accounts, so each validator's stake is matched to the version its node advertises. At 2026-11-09 16:13 UTC in epoch 1081, with 697 vote accounts and about 434M SOL of active stake, the split was:
| Advertised version | Stake | Share | Validators | Delinquent |
|---|---|---|---|---|
| Agave 4.4.1 | 196.1M SOL | 45.2% | 414 | 4 |
| Agave 4.4.0 | 165.2M SOL | 38.1% | 142 | 1 |
| Firedancer 26.10.6 | 63.0M SOL | 14.5% | 91 | 0 |
| Other versions | 9.2M SOL | 2.1% | 21 | not split out |
| No gossip entry | 0.4M SOL | 0.1% | 29 | not split out |
The 142 validators still advertising Agave 4.4.0 hold about 165M SOL. The largest of them holds 3.85% of all stake, and the ten largest together about 17%, so this is not a long tail of small operators. The "other versions" row includes 7.2M SOL on a version string of 0.1.1 across six validators, which we could not identify, plus small amounts on 0.0.0, 5.0.0-alpha.0, 4.5.0-beta.0 and older builds. We do not know whether those builds carry the fix.
Are the Older Validators Still Voting?
Yes, on both measures we have, with limits described below. Only 1 of 142 Agave 4.4.0 validators is delinquent, against 4 of 414 on 4.4.1 and none of 91 on Firedancer. We also compared vote credits, which are the credits a validator earns for each vote, reported per epoch by getVoteAccounts. Weighted by stake, the average credits earned per epoch stayed within about 1.5% of the epoch before the gate for both Agave groups. Firedancer 26.10.6 validators dipped about 4% in epoch 1079 and recovered; we do not know why, and restarts during upgrades are one possibility we cannot test. Groups are defined by the version advertised today, not the version running in epochs 1078 to 1080.
| Group | Epoch 1078 (before gate) | Epoch 1079 (gate activates) | Epoch 1080 |
|---|---|---|---|
| Agave 4.4.1 | 100 | 100.7 | 99.9 |
| Agave 4.4.0 | 100 | 100.4 | 98.8 |
| Firedancer 26.10.6 | 100 | 96.0 | 99.5 |
We expect a node that had actually forked off to stop earning credits, so a large drop in the Agave 4.4.0 row would have been the signal. That is our inference from how voting works, not a sourced statement. We see no large drop.
What This Does and Does Not Show
It shows the gate activated, a large share of stake kept the older version, and that group kept voting. It does not show that the old version is safe. The Tachyon commit message, not Anza's PR text, describes a divergence that depends on transaction patterns, specifically transactions that change ProgramData while another transaction loads it. If no such transaction has landed since 13:34 UTC on 6 November, old and new nodes would agree and nothing would be visible, and vote credits cannot detect that. A large share of stake not moving within days has several possible explanations, including slow operations cycles, stale gossip version strings and builds that carry a backport. We cannot tell which applies.
What Stakers Are Told
Solana Compass's explainer says a validator that falls out of step stops earning for its delegators until the operator upgrades and rejoins, and crypto.news says the effect on any operator would have to be shown from vote credits and reward records. Neither reports an observed case. The exposure described is lost rewards; on principal, see how Blockdaemon and Solflare described delegated stake in our report on the Solflare validator incident, which we could not verify ourselves. The version a staker's validator advertises is public in gossip data, but we do not track individual operators here.
What to Watch Next
- The 4.4.0 stake share. If 38.1% falls over the next days, operators are catching up. If it does not, possible reasons include slow operations cycles, stale gossip strings or builds that carry a backport.
- A divergence report. A public statement from Anza or an operator that nodes on the old version diverged would change the picture.
- Anza's follow-up. No post-mortem or statement on compliance was in the sources we read.
- The unidentified builds. What version 0.1.1 is, and whether the 4.5.0-beta and 5.0.0-alpha builds carry the fix (a backport to v4.5, PR #16776, was merged the same day).
- The next urgent upgrade. Operators have now had two version deadlines in about two weeks (21 October and 6 November). For an earlier validator-operations story, see our earlier coverage of a Solana validator's uptime.
Known Discrepancies
Descriptions of this upgrade vary in how strong they are, and few say what the chain shows.
| Claim in circulation | What the sources support |
|---|---|
| The upgrade was mandatory | Anza's quoted line pairs "recommended" with a stated consequence, and Solana Status says all validators "must upgrade" (both per Solana Compass). Nothing enforces it except the consensus rules themselves. The GitHub release page's "recommended for general adoption" is generic release wording. |
| Non-upgraded validators fork off | Solana Compass and Anza use "forked off". Solana Compass's explainer says such a node drops out of consensus and its votes stop counting. CryptoTicker adds the network as a whole should not suffer an outage if most stake upgrades in time. crypto.news is an explainer: it describes the effects as possible and says it is unclear whether any validator diverged. |
| Every validator had to upgrade | Solana Status said all mainnet staked and unstaked validators must upgrade, including RPC nodes (Solana Compass). Our data covers staked validators only. |
| Epoch 1079 starts at 13:30 UTC | Estimated at 13:30 UTC. On chain, the feature account activated at slot 466,128,000, block time 13:34:20 UTC. |
| Anza posted on 5 November | Solana Compass gives 19:20 UTC. Other outlets give only the date. GitHub shows releases at 16:24 (Firedancer) and 18:33 (Agave) without a time zone. |
Sources and Methodology
We read Solana Compass, CryptoTicker and crypto.news, and the primary GitHub pages for Agave PRs #16769 and #16775, the Agave v4.4.1 release and the Firedancer v26.10.6 release. We did not find or read Anza's original post, so its wording is quoted from Solana Compass. Our data comes from Solana's public mainnet-beta RPC at 2026-11-09 16:13 UTC (epoch 1081): getClusterNodes for each node's advertised version, getVoteAccounts for stake, delinquency and epoch credits, and getAccountInfo on the feature account. Versions are self-reported in gossip and can be stale or custom. We matched them to vote accounts through the node identity and grouped them by version string: "4.4.1", "4.4.0" and "26.10.6" (which we treat as Firedancer 26.10.6); everything else is "other". A node missing from gossip is counted separately. "Active stake" here is activated stake across all 697 vote accounts, delinquent ones included. The vote-credit comparison uses current stake weights and today's version groups. We attempted a leader-slot skip-rate comparison, but the public RPC refused the method (HTTP 403), so we do not have one.
- Solana Compass, "Agave 4.4.1 Urgent Upgrade: Solana Validators Must Patch Before Epoch 1079 or Fork Off, Anza Says", 5 November 2026
- GitHub, anza-xyz/agave PR #16775, "fix(svm): apply ProgramData size floor during account loading" (v4.4 backport), 5 November 2026
- GitHub, anza-xyz/agave PR #16769, "fix(svm): apply ProgramData size floor during account loading", 5 November 2026
- GitHub, Agave v4.4.1 release, 5 November 2026
- GitHub, Firedancer v26.10.6 release, 5 November 2026
- crypto.news, "What happens to Solana validators that miss the Agave 4.4.1 upgrade?", 9 November 2026
- CryptoTicker, "Solana below $90: Agave 4.4.1 upgrade becomes mandatory", 6 November 2026
- Solana mainnet-beta public RPC (our queries), 9 November 2026; CoinGecko API, SOL price data, 9 November 2026
This article is analysis, not security or investment advice. Validator software and versions change quickly, and every figure here carries the date it was checked.