Solana Governance: SIMDs, Proposal Support, and Validator Voting

1. Discussion

   An author tests an idea with engineers, operators, users, and other affected participants. GitHub SIMD Ideas is the current idea-stage venue named by SIMD-0001; the Solana forums provide additional public discussion and historical context.

2. The proposal record

   An SGP records a high-level directional question for a stake-weighted signal, while a SIMD describes a detailed technical change, its rationale, tradeoffs, compatibility concerns, and intended implementation. Review is documented in the relevant proposal repository.

3. On-chain governance

   When a proposal is placed into svmgov, active stake can first support moving it forward and then participate in a formal For, Against, or Abstain vote. This stake signal is separate from the document's GitHub status.

4. Engineering and activation

   A result does not write or deploy protocol code. Relevant teams must implement and test the change, ship it in software, coordinate any feature activation, and verify its mainnet status.

Do not use the words accepted, approved, implemented, and activated as synonyms. They answer different questions about review, stake preference, completed engineering work, and live network behavior.

The pinned SGP process distinguishes the instruments by the question they answer. An SGP asks whether the network should pursue a high-level direction and is decided through stake-weighted on-chain governance. A SIMD explains how a material protocol change would work and follows technical review. svmgov is the on-chain program and CLI that records proposal creation, preliminary support, voting, overrides, and finalization; it is not another document type. An accepted SGP can lead to one or more SIMDs, but the current process does not require an SGP for every SIMD.

SGP-0001 proposes a Solana Constitution for network-level governance. The draft describes it as a governance social contract: a canonical reference for coordination and interpreting network signals, not a legal constitution, self-executing smart contract, or protocol-code update. SGP-0001 itself requests no new runtime code, schema change, or funding; it treats the deployed svmgov and NCN snapshot infrastructure as existing dependencies.

Its proposed principles are stake sovereignty; validator stewardship; network-level control; transparency and auditability; optimistic, agile, consent-driven coordination; and decentralization, positive-sum economics, and neutrality. The draft assigns distinct roles: stakers own proportional voting power and may override a validator allocation; validators sponsor proposals and cast block or split ballots; maintainers steward the record and check downstream technical work against an accepted mandate; developers implement accepted directions through SIMDs, client work, and releases; and the NCN establishes the canonical stake snapshot used for voting weights.

The draft would also formalize an escalation path. Most technical work could continue through optimistic SIMD review, but enough sponsor support for a systemic or contentious SIMD, or a related set of SIMDs, could elevate the directional question into an SGP for a network vote. An SGP would not replace the detailed SIMD work needed to implement the result.

Status matters here. As of the Constitution status date on this page, the exact SGP-0001 commit linked on-chain still identified the document as Draft, its review pull request remained open, and the on-chain proposal was in Support Phase. Those are three different records. Support freezes a commit for sponsorship and possible advancement; it is not the formal vote, an Accepted outcome, or ratification of the Constitution. The draft must therefore be read as a proposal, not as an already binding governance document.

• The proposed operating path is Draft → Final Draft → Support → Review → NCN Snapshot → Voting → Accepted, Rejected, or Inconclusive → Implemented → Activated, with Withdrawn and Expired as additional outcomes.
• Its proposed defaults are a 100,000 SOL active-stake submission floor, a 15% sponsor threshold, a seven-epoch support window, seven review epochs, one snapshot epoch, and three voting epochs.
• It also proposes one-third turnout quorum and a two-thirds For threshold calculated over For + Against + Abstain participation.
• Under the draft, Accepted means quorum and the two-thirds threshold were reached; Rejected means quorum was reached without that threshold; Inconclusive means quorum was missed and is treated as no network mandate rather than a direct rejection. An elevated SIMD would then return to the optimistic technical path.
• Its amendment path would allow minor wording or articulation changes to be batched in one SGP, while parameter changes or adding or deleting whole articles would require standalone SGPs with justification and evidence.

Do not treat those draft voting parameters as current policy. The pinned repository README instead specifies no quorum and calculates the two-thirds approval threshold from For + Against, excluding Abstain. That conflict remains material while the Constitution pull request is open. Before acting, compare the frozen proposal text, current repository policy and documentation, live proposal state, and on-chain configuration.

Accepted, implemented, and activated remain separate outcomes. For a typical directional SGP, acceptance would create a network mandate that still needs detailed SIMDs, client work, releases, and any required activation. SGP-0001 specifically says a future successful formal vote would ratify this governance social contract and make it authoritative immediately without a separate activation epoch. That proposed governance effect would not deploy protocol code or create legal enforcement, and preliminary support does not produce it.

SIMD-0001 is a Living meta-SIMD, so it is the current process reference. Its main lifecycle is Idea → Draft → Review → Accepted → Implemented → Activated, with Living, Stagnant, and Withdrawn available for proposals that follow a different path.

1. Idea

   Check earlier work, explain the problem, and gather feedback in the SIMD Ideas discussions before writing a formal proposal.

2. Draft

   Fork the official repository, copy its proposal template, document motivation, design, drawbacks, and alternatives, then open a pull request. The pull request number becomes the SIMD number.

3. Review

   The author gathers and integrates feedback. Relevant core contributors and community members examine security, tradeoffs, compatibility, and implementation consequences in the public GitHub record.

4. Accepted

   The design has passed its review threshold. Acceptance creates no guarantee that another team will implement it; the process calls for implementation and, where relevant, feature-activation tracking issues.

5. Implemented

   The relevant development work is complete. This still does not mean the feature is active on mainnet.

6. Activated

   The change has been implemented, tested, and finally activated on mainnet beta. This is the status to look for when asking whether protocol behavior has actually changed.

An older forum guide describes gathering early feedback through the forums or community channels. Those archives remain useful, but follow the living SIMD-0001 and current repository instructions when they differ from older guidance.

1. Created

   A validator meeting the proposal-creation stake requirement submits an on-chain title and a link to the full proposal text. The validator guide currently documents at least 100,000 SOL of stake to create; check current global configuration before relying on that number.

2. Support

   Validators can add their active stake to the support total. The documented default threshold is 1,500 basis points, or 15% of total cluster stake. Crossing it sets the proposal's voting flag and records the snapshot state used for the next phase.

3. Snapshot and operator consensus

   The NCN snapshot system establishes the stake-weight data and publishes a consensus result used to verify voting power. A proposal can be activated for voting before its formal start_epoch, so this transition state must be inspected explicitly.

4. Formal voting

   During the voting window, validators allocate their snapshot-verified active stake among For, Against, and Abstain. Delegators can optionally override the allocation for eligible stake accounts they control.

5. Finalized

   After end_epoch, finalization locks the tallies. Finalization records the governance result; it does not automatically implement or activate the subject of the proposal.

• Support means: this proposal has enough preliminary validator interest to advance toward formal voting.
• Support does not express For, Against, or Abstain and must not be reported as a yes vote.
• A validator can support only while the proposal remains eligible for support; once voting is true, further support is closed even if the formal voting epoch has not started.
• A formal vote happens only inside the proposal's voting window and allocates stake among three positions.
• Support may be voluntary while a delegation, allowlist, or community program can separately require formal voting from participants in that program.

Advancing a question is not the same as answering it. Support opens the path to a vote; the formal vote records the position.

The official guide lists validator identity signing authority, access to a Solana RPC endpoint, and access to the operator proof service. Any active stake can support or vote; the higher stake requirement applies to creating a proposal. Use a trusted operations environment and the latest official release tag rather than building the development branch by default.

git clone https://github.com/solana-foundation/solana-governance.git
cd solana-governance
git checkout "<LATEST_RELEASE_TAG>"
cd svmgov/cli
./install.sh
svmgov init

Replace the release placeholder with a tag from the official Releases page and verify that the installed svmgov version matches it. Complete interactive configuration only on the trusted operator host. Never paste signing material, local configuration, validator identity details, or operational access information into an issue, chat, screenshot, or public research note.

Use the public proposal portal to discover current activity, then use the CLI to inspect on-chain state. Read the linked full proposal and discussion before taking any action. An unfiltered list is a safer starting point than assuming a human-readable status filter captures every transition state.

svmgov list-proposals --network mainnet
svmgov proposal "<PROPOSAL_ID>" --network mainnet

• Confirm the network and proposal identifier from an official source.
• Inspect voting, finalized, start_epoch, and end_epoch, not only the displayed status label.
• Open the proposal's linked source text and check that its title, scope, and discussion match what you intend to evaluate.
• Check whether you are in support, an activated pre-voting transition, formal voting, or finalization.

Before supporting, verify that the proposal is not already voting or finalized, that its support period remains open, and that the validator has not already supported it. Supporting adds the validator's active stake to the threshold; it does not choose a voting position.

svmgov support-proposal \
  --proposal-id "<PROPOSAL_ID>" \
  --network mainnet

After the threshold is crossed, wait for the snapshot and formal voting window. Do not repeat support simply because a list view still displays the word support; inspect the proposal fields first.

Formal votes use basis points. The For, Against, and Abstain allocations must add to exactly 10,000 basis points, where 10,000 equals 100% of the validator's eligible voting weight. The following 70/20/10 split demonstrates the arithmetic only; it is not a recommendation for any proposal.

svmgov cast-vote \
  --proposal-id "<PROPOSAL_ID>" \
  --for-votes 7000 \
  --against-votes 2000 \
  --abstain-votes 1000 \
  --network mainnet

A validator can change an existing allocation while the proposal is still in the voting phase. The replacement values must also total 10,000 basis points.

svmgov modify-vote \
  --proposal-id "<PROPOSAL_ID>" \
  --for-votes 8000 \
  --against-votes 1000 \
  --abstain-votes 1000 \
  --network mainnet

Before approving either action, re-open the proposal, verify the voting window and allocation, and review what the CLI will submit. Governance participation is an operator decision; this guide does not recommend a position on any proposal.

By default, a validator's formal vote represents its snapshot-eligible active stake, including delegated stake. The svmgov override flow lets a delegator who controls an eligible stake account express a different allocation for that account during formal voting.

The override adjusts the validator's effective weight so the same stake is not counted twice. It requires stake-account proof data and the appropriate staker authority. Because this is a sensitive signing workflow, follow the current official staker guide directly rather than copying account-specific examples from third-party posts.

1. Read the primary text

   Start with the official proposal repository, linked proposal document, review discussion, and any implementation tracking issue.

2. Identify the action

   Decide whether the current stage asks for preliminary support or a formal vote. Never treat those actions as equivalent.

3. Verify on-chain state

   Check voting, finalized, start_epoch, and end_epoch immediately before acting; do not depend on a cached page or one status word.

4. Use a released tool

   Build an official release tag, verify the installed version, and compare commands with the matching documentation.

5. Review the allocation

   For a formal vote, confirm that For, Against, and Abstain total exactly 10,000 basis points and reflect the intended position.

6. Protect operations

   Keep signing material and machine-specific details private, use the trusted operator workflow, and independently verify the proposal after acting.

7. Track what happens next

   After a result, follow implementation, releases, testing, and feature activation separately. A finalized proposal is not proof of active mainnet code.

Primary repositories and official governance documentation come first. Forums and the unofficial SIMD index are useful discovery aids, but they do not replace the proposal's GitHub record or current on-chain state. Operational guidance and the SGP-0001 status snapshot were checked on the separate dates shown on this page.