Solana Constitution presentation with Tushar Jain and Nick Almond at Breakpoint 2025

Solana’s First Governance Vote Opens Sunday—But Its Live Quorum Display Is Wrong

By Isaac • August 22, 2026 11:32 am • Comments

Solana is about to put three major questions to its validators in the network’s first formal onchain governance vote.

The vote opens with epoch 1021 on Sunday. But one number on the public governance frontend is already wrong.

The live interface still points users toward a 60% quorum calculation. Solana’s governing rules say the real test is one-third of the stake captured in the proposal snapshot.

Trending: Solana Just Cut Its Clock for the First Time—What 350ms Really Means for SOL

The distinction reaches beyond presentation. A quorum tells the market how much stake must participate before a vote can become a valid signal.

The good news is that the error appears to be in the display layer, not the onchain vote verification or final tally.

CryptoSlate traced the mismatch to the production frontend. Its report says the interface is still using a 60% path based on live stake even though the governance system is supposed to evaluate participation against the fixed snapshot taken for the proposal.

That fixed denominator matters. Validators and delegators need to know that the goalposts will not move as stake shifts during a three-epoch voting window.

The formal process was built for exactly that reason. Solana’s new governance system takes a stake snapshot before voting begins, then uses cryptographic proofs to connect each vote to eligible stake.

Nick Almond, head of governance at the Jito Foundation and one of the people who helped test the system, announced its launch earlier this month:

The official Solana Governance FAQ describes a system in which validators vote with weight tied to active stake, while individual delegators retain the ability to override the way their validator allocates their portion.

Before voting opens, a Node Consensus Network produces the canonical stake snapshot. That snapshot fixes the eligible stake and gives the system a stable denominator for the rest of the proposal lifecycle.

Once voting begins, validators may allocate their stake among For, Against and Abstain. Delegators who disagree with their validator can use their own proof to override that allocation for their stake.

The FAQ also separates proposal support from the formal ballot. A proposal first needs support from 15% of active stake.

It then moves through review and a dedicated snapshot epoch before the three-epoch vote opens. Supporting a proposal advances it to a vote; it does not count as a yes vote on the proposal itself.

The Solana Constitution separates participation from approval and measures both against a proposal’s fixed stake snapshot. At least one-third of snapshot stake must participate for quorum.

A proposal then needs support from two-thirds of the decisive votes to pass.

Abstentions count toward the participation threshold but not toward the yes-vote supermajority. That lets a validator or delegator help establish quorum without being counted on either side of the final approval test.

The constitution also freezes a proposal’s text before the snapshot and gives the network a defined three-epoch voting window. Votes and delegator overrides are recorded onchain, creating a public record of how the eligible snapshot stake was allocated while ballots were open.

A passing result is an advisory mandate for the network, not an automatic code change. Any technical implementation still has to move through the development, testing and activation work that follows.

That distinction prevents a governance result from being mistaken for instant execution.

Taken together, those rules give participants a stable denominator, a known deadline and separate tests for turnout and approval. They also explain why the frontend’s live 60% path is more than a cosmetic typo: it presents a different participation hurdle from the one the constitution says governs the vote.

That is why showing 60% as quorum is misleading. It combines the wrong threshold with the wrong denominator just as validators are preparing to vote.

The current slate reaches well beyond process mechanics.

The first proposal is the Solana Constitution, which would formalize how validators, delegators, developers and other participants steer the network.

The second would double Solana’s disinflation rate. That would reduce new SOL issuance more quickly and bring the network toward its long-run inflation floor sooner.

The third addresses resource and inclusion fees. It would change how base transaction costs are divided between validator compensation and token burning.

SolanaFloor summarized the three-vote window ahead of epoch 1021:

The published voting timeline says all three proposals crossed the 15% support threshold in epoch 1012. Their review period ran through epoch 1019, the stake snapshot occupies epoch 1020 and formal network voting runs from epochs 1021 through 1023.

Finalization is scheduled for epoch 1024 after the voting window closes on August 29.

The same timeline tracks a separate JitoSOL holder process because a liquid-staking pool must determine how its pooled stake will be cast. Holders voted through Realms, the result feeds a Jito DAO security-council action, and the pool’s bloc vote must land during the network window. That sequence shows why a fixed snapshot and clear dates matter for large delegated positions.

None of these results is predetermined. The disinflation and fee proposals affect validator economics, staking returns, token issuance and daily SOL burn in different ways.

The constitution also raises a broader question: whether Solana can convert years of informal debate into a process that participants trust when the stakes are real.

The frontend bug is therefore arriving at the worst possible time—but there is a bounded fix.

Pull request 170 would replace the live-stake calculation with the proposal’s fixed snapshot total, preserving the denominator established before ballots are cast. It would also stop displaying participation when matching snapshot metadata is unavailable, instead of presenting validators and delegators with a number that looks authoritative but is built on the wrong basis.

As of Saturday morning, that fix had not yet been merged into the production frontend.

The distinction between interface and protocol is important. The public page helps humans understand the vote, but the governance program performs the actual stake-proof verification and tally.

A wrong progress display can confuse voters and observers. It does not, by itself, rewrite the onchain quorum rule or change a valid ballot.

The code change is deliberately narrow. It reads the snapshot total associated with the proposal instead of recalculating participation against a live network total.

When the required snapshot metadata cannot be matched, the interface would show participation as unavailable. That is more honest than turning incomplete data into a precise-looking percentage during a live governance event.

The change also has to reach production before voters begin relying on the public progress display.

Still, Solana should not enter its first formal vote asking participants to ignore a prominently displayed threshold.

The network has spent months building a system around transparent snapshots, stake-weighted ballots and delegator overrides. The frontend needs to describe that system as precisely as the code enforces it.

If pull request 170 lands before epoch 1021, the issue becomes an early correction before the first ballot window opens.

If it does not, voters should watch the onchain proposal state and the constitution’s one-third snapshot rule—not the live 60% path still shown by the interface.

Solana’s governance experiment begins Sunday. The first test covers what validators choose and whether the network can make the rules legible while they choose it.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.

 

Search ProCoinNews