SPL Governance is the on-chain program that most decentralized autonomous organizations on Solana run on, and Realms is the open-source web app that fronts it. The program is, in its maintainers' words, "a program the chief purpose of which is to provide core building blocks and primitives to create Decentralized Autonomous Organizations" – deliberately "DAO type and asset type agnostic" so a treasury, a protocol, or an NFT community can all be governed by the same primitive. It is the Solana equivalent of what OpenZeppelin Governor plus Safe are on the EVM: a canonical governance kernel that everything else composes around.

The primitive: a realm, two mints

Everything in SPL Governance hangs off a realm. As the program README puts it, the "Realm account ties Community Token Mint and optional Council Token mint to create a realm." Members deposit governing tokens into the program and use "the deposited amount as their voting weight to vote on Proposals." That is plain token-weighted voting at the base layer.

The optional council mint is what makes the model expressive: a realm can run two voting populations at once. A small trusted council can hold veto or fast-track powers over the same DAO the broad community token governs – the program notes "users can submit Proposals that have a different voting population from a different mint that can affect the same DAO." It is the on-chain version of the two-chamber pattern many DAOs reach for, without bolting on a separate tool.

Realms: the shared front-end

Almost no one interacts with the raw program. Realms is the open-source UI – "a sophisticated, fully on-chain platform designed to simplify and enhance the management of decentralized autonomous organizations on the Solana blockchain" – that the large majority of Solana DAOs deploy and operate through. Its docs frame a realm around three moving parts: "DAOs, proposals, and votes."

Because the front-end is shared and open source, a new Solana DAO gets a working governance surface – proposal creation, delegation, treasury views, member lists – without building any of it, the same way an EVM project reaches for Tally or Snapshot rather than shipping its own governance app. Realms and the program are maintained together by the Mythic Project.

Proposals, votes, and a governed treasury

A "Proposal is an instance of a Governance created to vote on and execute a given set of instructions." It moves through draft → voting → executing → completed, and a "vote is tipped once it passes the defined vote_threshold" – early resolution once the outcome is mathematically settled, rather than always waiting out the clock.

What separates SPL Governance from a pure off-chain signalling tool is that the treasury is the DAO. Assets are held in specialised governance accounts that only a passed proposal can move:

• ProgramGovernance – controls program (smart-contract) upgrades.
• MintGovernance – controls an SPL token mint (issuance).
• TokenGovernance – controls transfers out of a token account (the treasury proper).

Because execution is on-chain and account-scoped, a Realms DAO owns and moves its own funds by vote – the proposal is the transaction, not a request for a multisig to act later.

The plugin architecture: voter-weight addins

The program is "modular and uses an open/close architecture where individual parts of the program\u2019s behavior can be customized through external plugins." The default one-token-one-vote weight "can be swapped with a custom program implementation" – an addin that computes each member's voting power however the realm wants. This is the most consequential design choice in the stack: governance math is pluggable.

The addins in wide use:

• Voter Stake Registry (VSR) – the dominant one, built by the Blockworks Foundation. It lets a realm "control which token mints can be used to vote, and at what scaling factor", and lets members "lock up tokens with different vesting schedules" where "locked up tokens may have extra voting weight." It also supports clawback of locked grants. That makes VSR Solana's vote-escrow (ve) analogue – time-lock for weight.
• NFT voter – voting power derived from NFT holdings across accepted collections, for NFT-native communities.
• Quadratic and Gateway plugins – a quadratic-weighting addin, and a Civic-gateway addin that gates voting behind identity/uniqueness passes.

An addin can also cap the max voter weight, so quorum is measured against an effective supply rather than the raw mint – the same accounting problem token-weighted systems everywhere have to solve.

In production

SPL Governance and Realms are the default governance layer for the Solana ecosystem. Marinade runs its mDAO in Realms with MNDE locked under VSR; Jito governs JTO, StakeNet, and its NCN fee routing through it; Mango, Metaplex, and Grape are long-running Realms DAOs; and Helium governs HNT through its own fork of VSR after migrating to Solana. Because the program and UI are shared, these DAOs differ mainly in which addin and which council setup they choose – the kernel underneath is identical.

Limits and failure modes

• Council centralisation. The council mint that makes two-chamber governance possible is also the usual point of centralisation – an early-stage realm is frequently a small multisig council wearing a DAO's clothes until the community token is genuinely distributed.
• Upgrade authority. A DAO is only as trustless as its ProgramGovernance discipline. If the realm's own program upgrade authority isn't itself governed (or is retained by the team), the on-chain execution guarantees are advisory.
• Plugin trust. A voter-weight addin is unrestricted code that decides who has power. A buggy or malicious registrar config can silently mis-weight votes, and VSR lockups concentrate weight with the earliest, longest-locked holders – the ve trade-off in full.
• Turnout. On-chain execution does not fix voter apathy; a realm still has to reach quorum, and many run on a thin active minority.

How Caper approaches this

SPL Governance's pluggable weight is its strength and its exposure: VSR turns voting power into freely-tradeable capital plus an optional lockup multiplier, so a large enough bag – or a long enough lock – still buys the most say. Caper is built the other way. Its vote weight is a fixed formula, not a swappable addin: w = (t · v) / (V · T), where a member's held governance tokens t are multiplied by their earned, non-transferable votes v (the compute_vote_weight formula in the Caper contracts). A zero in any input yields zero, so a bag that never participates captures no control.

Those votes are a soulbound proof-of-vote token (non-divisible, with mint and burn locked to the DAO's own immortal state component) – there is no VSR-style registrar to reconfigure and no market to buy weight on. And where a Realms DAO's members can only exit by selling on a secondary market, Caper's exit gives every member a pro-rata claim on the treasury sized at exactly that canonical weight, pre-burn – a built-in credible exit rather than a purely political one. Same job as SPL Governance – own and move a treasury by vote – with participation, not capital, as the unit of power. See Caper proposals.

References

• SPL Governance program README – solana-labs/solana-program-library
• Mythic Project fork – current maintainer of the program and Realms UI
• Realms documentation · developer resources: spl-governance
• governance-ui – the open-source Realms front-end
• Voter Stake Registry (Blockworks Foundation) · governance-program-library (NFT / quadratic / gateway addins)