Solana Governance Frontend Hardcodes 60% Quorum, Contradicting the One-Third Rule in SGP-0001

As Solana SOL$94.50+3.9%'s first on-chain governance vote approaches its voting phase, the official frontend at governance.solana.com has a display error: it shows a 60% quorum requirement for proposals, while the actual governance rule sets quorum at one-third of network stake.

The vote covers three Solana Governance Proposals: SGP-0001 (the Solana constitution), SGP-0002 (an accelerated SOL disinflation schedule), and SGP-0003 (variable transaction fees). Voting opens at epoch 1021, scheduled for August 23. Unless a pending fix merges and deploys before then, anyone visiting the portal will see the wrong threshold.

What the 60% Quorum Code Gets Wrong

The discrepancy is documented in pull request #170 to the official solana-foundation/solana-governance repository, submitted by contributor 0xIchigo on August 21, 2026.

The frontend code sets REQUIRED_QUORUM_PCT = 0.6, hardcoding a 60% figure that directly contradicts SGP-0001 Article IV.3, which specifies quorum as one-third of network stake. The governance site's own FAQ already states the correct one-third threshold, leaving the live interface in conflict with both the specification it implements and the documentation alongside it.

A related calculation error compounds the problem. The interface measures participation against live validator stake totals, which shift as stake moves between validators. Displayed percentages change even when no new votes have been cast, because the denominator moves. SGP-0001 Article IV.2 specifies that stake distribution is fixed at the pre-vote snapshot for the entire voting period.

On-Chain Votes Are Counted Correctly Despite the Frontend Bug

The display error does not change how votes are counted. Submissions through the portal are recorded and weighted using the snapshot stake fixed at the start of the voting period, as the governance specification requires. The error is in what participants see on screen, not in what the contracts record or how the tally is produced.

PR #170 Must Deploy Before Epoch 1021 to Correct the Display

PR #170 addresses both problems. It replaces the live-stake denominator with the total from the proposal's own snapshot, moves the quorum marker from 60% to one-third, and introduces slot validation to ensure only the correct snapshot total is used. Where snapshot data is unavailable, the corrected frontend will display "snapshot total unavailable" rather than calculating against an incorrect figure or showing a false zero.

The fix must merge and deploy before epoch 1021 opens. If it does not, voters will encounter either the outdated 60% threshold or an unavailability indicator during the voting window. Either outcome would be cosmetic; the on-chain tally proceeds correctly regardless.

The SOL supply implications of SGP-0002 and the fee mechanism changes in SGP-0003 have drawn the most staking-community debate ahead of the vote. HSDT, a Nasdaq-listed Solana treasury company and validator, publicly announced plans to vote for SGP-0001 and against SGP-0002 and SGP-0003.