Building Decentralized Governance for Solana: Giving 1.2M Stakers a Voice

TL;DR ⚡

• What you’ll learn: How a Snapshot-based NCN computes stake weights at a specific slot, reaches consensus on a Merkle root, and enables stake-weighted voting with delegator override.

• Why it matters: Governance legitimacy breaks down when delegators can’t cast a vote independently of their validator, SIMD-228 made that clear.

• Exo Edge: A lightweight, auditable design where heavy computation stays off-chain, but verification happens on-chain via Merkle proofs.

Introduction

The SIMD-228 debate, a contentious proposal to replace Solana’s fixed inflation schedule with a dynamic, stake-based rate, highlighted a critical gap: over 1.2 million stakers had no direct voice in network governance. Validators voted on their behalf, and the proposal failed despite 61% support (short of the 66% supermajority required). Stakers had no mechanism to vote independently of their validator.

This post details a Snapshot-based Node Consensus Network (NCN) developed as part of the Solana governance initiative. It enables stake-weighted voting—allowing stakers to override their validator’s vote, with all verification happening on-chain.

The Bigger Picture: The Solana Constitution

This work is part of a broader governance initiative unveiled at Breakpoint 2025 by Tushar Jain (Multicoin Capital) and Nick Almond (Jito). The Solana Constitution (V5.0) proposes a formal framework built on Stake Sovereignty:

The Constitution establishes two core principles:

• Representative Democracy — Validators vote on behalf of their delegated stake

• Staker Override — Individual stakers can override their validator’s vote

Two Tracks of Governance

The Constitution distinguishes between two proposal types:

If a SIMD is sponsored by validators whose stake totals ≥15%, it triggers a full network vote requiring 2/3 supermajority to pass.

Key Governance Parameters

The Snapshot NCN powers the Voting Period by providing the decentralized, trustless calculation of stake weights for a given slot.

What is a Node Consensus Network?

A Node Consensus Network (NCN) is a decentralized system in which distributed nodes collaborate to validate and agree on information. NCNs include oracles, cross-chain bridges, and solver networks, any system that requires distributed consensus.

The pattern is simple:

1. Operators run off-chain processes independently

2. They compute a result (prices, distributions, snapshots)

3. They submit their agreement on-chain

4. Consensus is reached when enough operators agree

On Solana, Jito has pioneered this pattern, providing both the infrastructure for building NCNs and a production example that directly informed the design of the Snapshot NCN.

Jito Restaking: Economic Security for NCNs

Jito (Re)staking is an infrastructure platform that provides economic security for NCNs on Solana. It allows new networks to leverage existing staked capital for economic security, rather than bootstrapping from scratch.

The Jito Tip Router

The Jito Tip Router is a production NCN distributing MEV tips to validators. Each epoch, NCN operators:

1. Compute the correct tip distribution

2. Build a Merkle tree of the distribution

3. Vote on-chain to reach consensus on the root

4. Tips are distributed via the on-chain program

The Governance Snapshot NCN follows the same pattern—instead of tip distributions, it computes stake snapshots. Instead of claiming tips, users submit votes with Merkle proofs.

Why a Lightweight NCN

While Jito Restaking provides a robust framework for economic security, the Snapshot NCN opts for a simpler approach:

For governance snapshots, operator reputation and Solana Foundation whitelisting provide sufficient security. Jito Restaking can be integrated later if economic security becomes necessary.

System Architecture

The system consists of two on-chain programs: one to establish the source of truth (stake snapshots) and another to manage the voting logic. This separation allows different teams to develop each component independently, and the Snapshot NCN can serve future governance applications beyond the current voting program.

Solana Governance Architecture

The Snapshot NCN (gov-v1) acts as an oracle of stake weights. Operators independently compute a Merkle root of all stake accounts at the proposal’s snapshot slot, then vote on-chain to reach consensus. Once consensus is reached, the agreed-upon root becomes the source of truth for that vote.

The Voting Program (govcontract) handles the voting logic—proposal creation, vote casting, and delegator overrides. When a user submits a vote, the Voting Program calls into the Snapshot NCN program via cross-program invocation to verify the user’s stake weight against the consensus root.

Deep Dive: The Snapshot NCN

Two-Tiered Merkle Trees

To allow both validators (aggregate weight) and individual stakers (specific weight) to vote efficiently, the system uses a two-tier structure:

At the upper bound of expected network scale (~1000 delegations/validator, ~2000 validators), proof verification takes ~21 SHA256 hashes = ~6,300 CUs—well within transaction limits.

How Snapshots Are Generated

Snapshot generation begins when the target slot passes. The CLI backs up the ledger’s full and incremental snapshots, then uses agave-ledger-tool to copy the relevant blockstore range. From there, it loads the snapshot via the Solana runtime, replays blocks to the exact target slot, and creates a frozen Bank object representing account state at that moment.

With the bank state reconstructed, the CLI queries Bank.stakes_cache for all stake delegations, groups them by the validator they’re delegated to, and calculates each account’s active_stake using StakeHistory and the current epoch.

Stake can be delegated either through native staking or via a stake pool. For native stakers, the withdrawer authority serves as the voting wallet. Stake pools present a challenge: the pool’s stake authority is a PDA that can’t sign transactions. For SPL Stake Pools, the voting wallet is assigned to the pool manager; for Marinade, which uses its own staking program, the voting wallet is assigned to a dedicated operations key. Sanctum pools require no special handling, since they already delegate to a small set of specific validators; the stake is counted directly under those validators.

Once all stake accounts are processed, the CLI builds the two-tier Merkle tree: a StakeMerkleTree for each validator’s delegators, then a MetaMerkleTree containing all validators with their respective stake roots. The final output is a snapshot file containing the Merkle root and proofs for every MetaMerkleLeaf. Stake-level proofs are generated on demand when users query the Verifier service.

Operators then submit their computed Merkle root and snapshot hash on-chain. Once enough operators agree (the configurable consensus threshold), a ConsensusResult account is created—making the snapshot official.

Integration: The Voting Program

The Voting Program is developed by a separate team (Turbin3) and integrates with the Snapshot NCN as follows:

1. Initialization — Each proposal specifies a target epoch, with the snapshot slot fixed at 1,000 slots after the epoch begins. Once a proposal receives enough support, the Voting Program calls the Snapshot NCN program to initialize a BallotBox for that snapshot slot. Operators then begin generating and voting on the snapshot.

2. Finalization — Once the BallotBox reaches consensus, the Snapshot NCN program calls back into the Voting Program to finalize the proposal and open voting.

3. Verification — When users submit votes with their Merkle proofs, the Voting Program calls the Snapshot NCN program to verify each proof against the consensus root. Votes are weighted by the verified stake. Stakers can also override their validator’s position by submitting their own vote—even before the validator has voted.

Infrastructure: The Verifier Service & CLI

The Verifier Service

Expecting every voter to download a full snapshot and rebuild the Merkle tree client-side is impractical. The Verifier service solves this by pre-indexing the snapshot and serving proofs on demand. When a user wants to vote, they query the Verifier for their proof, then submit it to the Voting Program.

The Verifier is intentionally decoupled from snapshot generation. Generating snapshots requires heavy infrastructure—ledger access and the full Solana runtime—but only runs once per proposal. The Verifier, by contrast, needs to stay online for the entire voting period to serve proof requests.

Since whitelisted operators are required to run the Verifier, it was designed to be self-contained and low-maintenance: a single SQLite-backed binary with no external dependencies, configurable entirely through environment variables. Each operator runs their own instance, forming a decentralized network of Verifier servers with natural load balancing and redundancy.

Despite the simple infrastructure, benchmarks show even a minimal EC2 instance can comfortably handle the estimated peak voting demand:

Estimated peak demand is ~4,800 req/s, accounting for concurrent users, multiple proof requests per vote, retries, and headroom.

The CLI

For operators, the CLI automates the entire snapshot workflow. The await-snapshot command watches for the target slot to pass, backs up the ledger and snapshots, and generates the Merkle tree—all without manual intervention. This reduces operator friction and ensures every operator produces an identical snapshot.

Conclusion

This system gives 1.2 million stakers a voice in Solana governance. By moving the heavy computation off-chain and using Merkle proofs for on-chain verification, the cost of proving any individual’s stake weight grows logarithmically with the number of accounts—capped at ~6,300 CUs at the expected network scale.

A few lessons emerged from this project. Simple beats complex: a lightweight NCN with whitelisted operators is sufficient for governance snapshots, and Jito Restaking can be integrated later if economic security becomes necessary. Delegator overrides matter: stakers gain real agency to vote independently of their validator’s position. And decoupling is valuable: separating the Snapshot NCN from the Voting Program allowed different teams to develop each component independently, and the Snapshot NCN can be reused for future governance applications.

Developers can explore both the Snapshot NCN and the Voting Program. For stakers: watch for the first governance vote—your stake is your voice.

References

Solana Constitution:

• Solana Constitution Website

• Constitution Draft Document

• Breakpoint 2025: Solana Governance Talk

SIMD-228:

• SIMD-228: Market-Based Emission Mechanism

Jito NCN & Restaking:

• Understanding Node Consensus Networks

• Announcing Jito (Re)staking

• What Is Jito TipRouter?

• Jito Tip Router (GitHub)

Code Repositories:

• Snapshot NCN (gov-v1)

• Voting Program (govcontract)