Solana is Rebuilding its Social Contract

Executive Summary

Thank you to Max Sherwood and Nate for their feedback and help with the research behind this report.

Solana is formalizing its governance process following lessons learned from the contentious SIMD-228 vote. This community-led initiative, stewarded by Dr. Nick Almond (Jito) and Tushar Jain (Multicoin Capital), aims to produce two foundational documents: a Declaration articulating Solana's core values, and a Constitution defining how the network changes.

• Staker Override: The most fundamental shift enables any SOL staker to vote directly on governance proposals, with their stake weight deducted from their validator's total. This transforms Solana into a "representative democracy with voter override."
• Dual-Track System: SIMDs (technical changes) move forward "optimistically" without votes. SGPs (systemic changes) require broad network consensus.
• Critical Infrastructure: A Node Consensus Network (NCN) of 7–10 operators will coordinate voting through cryptographically-verified stake snapshots, enabling staker override at scale.
• Current Status: The governance documents remain in active development. The voting infrastructure is being tested, with the NCN on mainnet and the voting program deployed on testnet.

Key Takeaway: Solana is building governance infrastructure that matches its technical sophistication — prioritizing legitimacy, minimizing overhead, and enabling true staker sovereignty.

Introduction

Earlier this year, the Solana network underwent a major stress test. The governance vote on SIMD-228 was, by market cap, one of the biggest in crypto history. While it proved Solana's social layer could handle a high-stakes debate, the process itself revealed significant opportunities for improvement. It became clear that to match its world-class technical infrastructure, Solana needed a more robust governance infrastructure.

The vote succeeded, but the process exposed cracks: inconsistent expectations, procedural ambiguity, validator-staker misalignment, and the absence of authoritative guidelines on how Solana governs itself.

This need gave birth to a community-led initiative to produce two documents: The Declaration articulates Solana's core values — transparency, permissionlessness, open governance, accelerating innovation and maximizing revenue while committing to network security/stability, mass adoption, speed, privacy, and economic value creation. The Constitution defines how the network changes: proposal lifecycles, thresholds, quorum, staker sovereignty, validator sponsorship, and maintainer responsibilities. In effect, the Declaration defines why Solana exists, and the Constitution defines how Solana changes.

This report documents the ongoing attempt to correct that imbalance: a community-driven effort to formalize Solana's values, constitutional rules, and governance process; the tensions that shaped those documents; the participation flux across the three public meetings; what the development process is like; and why the plan for a Breakpoint mass-signing ceremony was cancelled. This effort is stewarded by Dr. Nick Almond, Head of Governance for Jito, and Tushar Jain of Multicoin Capital. "We approached the foundation to get them to help us with this. The foundation never approached us on this topic," Nick mentioned. The organizers see themselves as "stewards of this information gathering process," focused on achieving "broad social consensus" and "legitimacy."

Nick Almond has tons of multi ecosystem governance experience and Multicoin was one of the more vocal VCs during the SIMD-228 vote. Tushar himself stated, "The governance experiment was a success even though the outcome wasn't the one I advocated for."

The Shift to "Staker Override"

The most fundamental change in Solana's proposed governance model is the introduction of staker override. Historically, validator voting was the primary mechanism for deciding network proposals. In parallel, Turbin3, Exo Tech, and Solana Foundation core contributors have been focused on building the on-chain voting system that enables this staker sovereignty.

Any staker can vote directly, even if their validator chooses not to participate. When a staker casts their vote, their stake weight is simply deducted from their validator's total potential voting power. This creates a "representative democracy with voter override," empowering individual SOL holders without forcing them to switch validators over a single disagreement.

During the SIMD 228 vote, Validators simulated staker override by manually splitting their stake across different voting options. Brian Long from Triton One stated, "Stakeholders appreciated the process so much and the fact that we could do the split votes and have a conversation. They actually increased their stake with me." So, it wasn't the assumed situation of, "If I don't like you, I'm going to move my stake."

Giving every staker a direct voice is a critical step in maturing the network's governance, ensuring the protocol's direction truly reflects the will of its stakeholders. Although a minority subset of validators raised concerns about staker override, arguing that stakers uninvolved in operational or technical contexts should not influence outcomes. This view, while acknowledged as reasonable, did not prevail. Nate from Turbin3 informed me that people should understand what they're voting on, but a lack of understanding should not strip stakers of their voting rights.

Nate from Turbin3 was able to give some insight into the design rationale for the new onchain voting function. This update does not change how the SVM works. Some folks wanted it to be a part of the VM, but realistically, the group does not have enough bandwidth to do so at the moment. This reinforces the theme of implementing governance in a manner that does not hinder Solana's primary mission of building Internet capital markets and increasing bandwidth, reducing latency (IBRL).

Less is More: The Art of "Governance Minimization"

The system is explicitly designed to avoid forcing a network-wide vote on every single change. This practice can lead to voter fatigue, slow down development, and create unnecessary conflict.

"I am a governance minimization guy. I absolutely believe in this… we also don't want to end up just squabbling about governance all the time, which is the worst possible outcome for pretty much anything."

To achieve this, the community is establishing a two-track system for network changes:

• SIMDs (Solana Improvement Documents): This existing track is for technical, core developer-centric changes. To maintain agility, SIMDs will continue to move forward "optimistically" without requiring a network-wide vote.
• SGPs (Solana Governance Proposals): This is a new track for significant, systemic changes to the network's economics, architecture, or core strategy. These are the big decisions that do require broad consensus and will go to a vote.

A crucial safety mechanism bridges these two tracks: a SIMD can be "elevated" to a network-wide vote if a sufficient amount of stake signals that it has "drifted outside of consensus." This creates a balance between developer speed and network-wide alignment.

Participation & Drop-Off

Across the three meetings, the participation profile told a story of its own:

Meeting 1

• ~43 sign-ups, the most diverse stakeholder group
• High morale, intense interest, early belief in a Breakpoint signing of the Declaration, broad expectation-setting around consensus-building

Meeting 2

• ~115 sign-ups, the most significant total interest
• Proof that demand for governance knowledge exists

Meeting 3

• ~19 actual participants
• Steep drop-off in contributor diversity
• Explicit conversation about governance apathy
• Acknowledgment that Solana should avoid overengineering governance relative to the actual appetite

This drop-off revealed the legitimacy risks of pushing toward a ceremonial signing without deep, broad representation. The stewards engaged with other parties, such as the foundation, core developers, Anza, and Mert, and plan to engage the broader community throughout December and January.

The GitHub Maintainer Disagreement

The core tension centered on who maintains the canonical GitHub repos. The Foundation and core engineers argued for continuity, quality control, and prevention of spam — a practical stance aligned with Solana's "ship fast" culture. Some validators countered that centralized repo control undermines the optics and legitimacy of a community constitution.

The Foundation argued they must serve as initial maintainers because:

• They already steward the SIMD process and must ensure continuity.
• Without gatekeeping, governance could be overwhelmed by spam and low-quality proposals.
• Excessive bureaucracy could push developers to bypass governance entirely.
• Repository control is not political power; votes are on-chain and cannot be manipulated by maintainers.

This was the "responsibility to prevent chaos" argument.

Validators rebuttal:

• A community-driven constitution hosted under Foundation-controlled repos undermines the claim of decentralization.
• External observers could delegitimize the process by pointing to centralized administrative control.
• At a minimum, non-Foundation maintainers or rotating seats should exist to signal permissionlessness.

This was the "governance must look decentralized to be accepted as decentralized" argument.

The compromise, initial Foundation stewardship with required transparency and justification for decisions, reflects pragmatic gatekeeping with decentralized oversight. A temporary concession to reality, but not a permanent power structure. I predict there will be consistent pressure regarding this facet in the future.

Under the Hood: The Node Consensus Network (NCN)

This section is for readers who want to understand more about the inner workings of the development process. The staker override system is enabled by Solana's Node Consensus Network (NCN), a distributed infrastructure layer coordinating the voting process. The governance voting implementation is based on Jito's tip router architecture, a battle-tested system for coordinating distributed consensus in production.

How NCN Consensus Works

The NCN operates with 7–10 independent operators who collectively reach consensus on governance snapshots. At a designated slot, each operator generates a Merkle tree representation of the network's stake distribution, capturing which wallets control which stake and establishing voting eligibility. The snapshot generation process involves operators backing up their validator's ledger state, generating a full Solana snapshot for the target slot, and then creating a "MetaMerkle" snapshot — a compressed Merkle tree representation of all active stake accounts.

The BallotBox and Voting Mechanism

Each operator signs their snapshot and submits it on-chain to a "BallotBox" account, where the governance program tracks all submissions and tallies votes toward consensus. When the configured consensus threshold is reached, the winning ballot — the merkle root and hash that received the most operator votes — is considered the canonical snapshot.

Once the threshold is met, any operator can invoke the finalize-ballot instruction, which creates a "ConsensusResult" account and finalizes the result onchain. This is a purely executional step that does not confer discretion over the outcome. If consensus cannot be reached within the voting duration, a designated tie-breaker admin can invoke the set-tie-breaker instruction to set the result manually — a last resort rather than normal operation.

Stake Pool Intelligence

The NCN implements sophisticated logic for handling different types of staking arrangements. For SPL stake pools, it redirects voting power from the program-derived address (PDA) to the actual manager authority. For Marinade's liquid staking program, it routes to the operations wallet. Sanctum pools maintain their existing validator-level voting. Individual stakers vote directly through their withdraw authorities.

NCN Operator Incentivization

The incentive structure for NCN operators is still being finalized, though the Solana Foundation has confirmed it will provide incentives. If participation is purely voluntary, the operator set may skew toward well-funded entities or those with other strategic interests, creating centralization risks.

The technical requirements create natural barriers to participation. The snapshot generation is memory-intensive. These operators run full RPC nodes with specific client, memory and hardware requirements: currently, Agave version 3.0.6+, 200M shred ledger limits, and approximately 500GB of snapshot storage.

A Balancing Act

A significant part of the discussion has focused on selecting the appropriate numerical parameters to make the system work.

• Proposal Sponsor Threshold (set at 15% of stake): This is the "attention gate" — the amount of stake required to signal that an issue is important enough for a network-wide vote. The 15% level was chosen because many large institutional holders are often "lazy" and won't engage at the proposal stage. They will, however, participate once an official vote is called.
• Vote Quorum (set at ~33.3% of stake): The quorum was a point of significant discussion. The final proposal landed on one-third to strike a balance between requiring a strong signal and avoiding gridlock, where setting the bar too high makes it "really difficult to get any clear decisions."

Proposal Lifecycle

Phase 0 — Proposal Formation

This phase captures how ideas enter the system and how Solana distinguishes between technical changes (SIMDs) and strategic, economic, or governance-driven changes (SGPs).

1. Proposal Ideation Begins — Anyone — developer, validator, researcher, or community member — can originate a proposal.
2. Determine Proposal Type — If the change is purely technical, it enters as a SIMD. If strategic, economic, or governance-impacting, it is framed as an SGP.
3. SIMD Path — A draft SIMD is posted to GitHub. The core dev community conducts technical peer review. If the change is not systemic, it proceeds through the normal merge and release path. If it is, it must be elevated to an SGP.
4. SGP Path — The proposer drafts an SGP on GitHub, setting the stage for a validator-led escalation process.

Phase 1 — Proposal Creation

This phase kicks off once a proposal is designated for SGP treatment. The draft must collect 15% of the total stake from validators who agree it should advance. Once the sponsor threshold is met, a validator calls the create_proposal instruction, and the proposal enters the chain-level lifecycle.

Phase 2 — Support Gathering

Once in SGP Draft state, validators have one epoch to signal whether the draft should progress. If support is below 15%, the SGP expires. If support reaches 15%, the proposal is activated for network-wide voting.

Phase 3 — Voting

After a 10-epoch discussion period, a snapshot slot captures stake distribution. A 3-epoch voting window opens where validators cast votes and stakers can override their validator's vote at any point. Overrides can occur even after the validator votes.

Phase 4 — Outcomes

• Quorum fails (<33%): Network indifference. Elevated SIMDs revert to optimistic pass; direct SGPs lack sufficient signal.
• Quorum achieved, YES ≥66%: Proposal PASSED with a strong network mandate.
• Quorum achieved, YES <66%: Proposal REJECTED. Consensus denied.

Solana's voting system is fundamentally veto-driven. By default, developers can ship (optimistic pass), and governance exists to stop or ratify systemic decisions — consistent with Solana's fast shipping culture.

Conclusion

The Breakpoint signing ultimately didn't happen because the community recognized an important truth: apparent consensus isn't the same as real consensus. Rather than forcing a symbolic moment prematurely, the group chose to pause and let the process mature. This wasn't a setback — it was a signal that the community is committed to building genuine alignment.

The disagreements, limited participation, and still-forming institutional roles aren't failures; they're areas of active growth and opportunities to strengthen the mandate before making it official. In governance, optics without substance erode legitimacy faster than openly acknowledging fragmentation.

A wise man once told me, "Governance is like a fire extinguisher, you tend to overlook it when it's not needed, but it's crucial when shit hits the fan."

This was quite evident during the SIMD-228 vote.

Sources:
Solana Governance Voter Snapshot Repo
Sol Gov Operator Test Guide

Prepared by: Othman Gbadamassi