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 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 open/close architecture where individual parts of the program's 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.

Who can upgrade the kernel

Every Realms DAO's on-chain execution guarantee rests on one assumption its own governance cannot check: that the program holding its treasury will not be replaced underneath it. SPL Governance is deployed under Solana's upgradeable loader, so someone can replace it. The question has an exact answer, and it is worth reading in full because it is unusually good.

The default program's ProgramData account names an upgrade authority of HF7gCq7BMB6cFfhharTGGm31sqDdpmvLTgF4WEoW8y9n. That address is off the ed25519 curve, so it is a program-derived address and not a wallet – no private key exists for it. Reading the last transaction it authorised settles which program derives it: the upgrade at slot 431,624,473 on 8 July 2026 logs GOVERNANCE-INSTRUCTION: ExecuteTransaction from a second SPL Governance deployment at version 3.1.1, which then invokes the loader. SPL Governance is upgraded by an SPL Governance proposal. The kernel governs itself with its own machinery, one deployment removed.

The realm that holds that authority is named Realms Security council 8, and its parameters are all on-chain:

• Seven seats, one vote each. The council mint has zero decimals and a total supply of 7; ten member records exist and seven of them hold a deposit of exactly 1. The community mint attached to the same realm has a supply of 0.
• Community voting is switched off. The governance account's community_vote_threshold is Disabled and its minimum community weight to open a proposal is u64::MAX. Only the council votes.
• Five of seven carries it. The council_vote_threshold is YesVotePercentage(60), measured against the whole council supply, and the program rounds the requirement up (get_min_vote_threshold_weight). Sixty per cent of seven is 4.2, so four votes – 57 % – is not enough and five are required. The veto threshold is the same 60 %.
• 72 hours of voting, then a 24-hour cool-off in which only Deny and Veto votes are accepted, with council vote tipping set to Early, so a fifth yes ends the vote the moment it lands.
• No timelock. The governance's transactions_hold_up_time is 0 – the config imposes no delay of its own between a proposal succeeding and its instruction executing.
• The council can resize itself. The same PDA that holds the upgrade authority is also the mint authority of both the council and community mints, so a passed proposal can issue an eighth seat.

Read against the alternatives this is a strong answer: not a founder's keypair, not a company multisig, but a quorum rule enforced by the same program it governs, with every parameter publicly readable. Read strictly it is still a small-committee arrangement with no delay attached: five people can, in principle, replace the program that executes the treasury decisions of every Realms DAO, and there is no window in which those DAOs could react. That is the honest shape of the trust assumption, and it is one almost no Realms DAO states in its own documentation.

Who maintains it

The other half of the same question is who writes the code that gets deployed, and the answer changed quietly. Solana Labs archived the Solana Program Library monorepo – last push 11 March 2025 – and broke its programs out into individually maintained repositories under the solana-program organisation. Thirty-nine repositories live there today: token, token-2022, stake-pool, the associated-token-account program, memo, and the rest. Governance is not among them.

What happened instead is that maintenance moved to a community fork. The archived README now opens with a one-line redirect – "This repo still exists in archived form, but the maintained version has now relocated to" the Mythic Project's copy – and that fork, together with the Realms front-end and the addin library, is where the work now happens. It is live work, not a courtesy fork: the program repository was pushed the day this page was last checked, and the on-chain deployment was upgraded a month before that.

So the governance layer of an entire L1's DAO ecosystem sits outside the official program organisation of that L1, maintained by a separate team, and upgraded by a seven-member council. None of those three facts is a defect on its own. Together they are the thing a DAO choosing Realms should know it is choosing, and the wider pattern is covered on DAO tooling discontinuity.

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. As the section above shows, the program's own governance is exactly this shape.
• 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 – and the same question applies one layer down, to the governance program itself.
• 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 answers the same question by welding the weight function into the contract instead of exposing it as a plug-in. A caper does tally: a proposal carries up to four executable options plus a standing “do nothing”, holders rank all of them on one ballot, and a Borda fold picks a leader that must clear 1.5 / option_count of the weight cast – and a leading “do nothing” fails the proposal outright. Every ballot carries the same canonical weight w = (t · v) / (V · T), so there is no registrar to reconfigure – not because there is no weight function, but because the one there is cannot be swapped without replacing the logic component. A legislative pass then earns a trigger, which opens the market window and locks the trailing TWAP as a baseline; the action executes only if the window’s own TWAP closes at or above that baseline. The tunable SPL Governance hands a DAO – which holdings count, and how much – is the one thing a caper does not expose.

That weight, compute_vote_weight, prices two things at once: how far a member’s ballot moves the tally, and their claim on the treasury at exit. t is the caper tokens held; v is a soulbound token that accrues at 0.01 per XRD on both legs of every trade and at 1 per ballot cast, and a zero in either input still yields zero, so a holder who has neither traded nor voted has no exit to take. Those v tokens can never move peer-to-peer – deposit is restricted to the caper’s own immortal state component – but they are fully divisible (DIVISIBILITY_MAXIMUM), because a per-XRD accrual rate cannot mint whole units. Where a Realms DAO’s members can exit only by selling into a secondary market, exit() gives every member who has taken part a pro-rata claim on the treasury at exactly that weight, pre-burn – a built-in credible exit rather than a purely political one.

The upgrade question above has a structural answer too. A caper’s state tier – treasury and proposal record – is deployed once and never migrated, so past decisions do not depend on anyone’s continued authority. The logic tier can be replaced, but only by an UPGRADE proposal raised on the $CAPER caper itself, resolved the same way every other proposal is and routed through the protocol registry: there is no separate council, and no key that shortcuts it. Same job as SPL Governance – own and move a treasury without a signer set – with the price of the thing being governed, rather than a configurable weight function, as the settlement rule. See Caper proposals.

References

The upgrade-authority, council and mint figures on this page were read directly from Solana mainnet on 13 August 2026 via getAccountInfo, getProgramAccounts and getTransaction against the public RPC, and decoded against the program's own account layouts.

• SPL Governance program README – Mythic-Project/solana-program-library, the maintained line · the archived solana-labs original, which carries the relocation notice.
• the solana-program organisation – the 39 repositories the SPL monorepo was broken into; governance is not one of them.
• governance.rs and proposal.rs – the GovernanceConfig field order and the threshold-rounding rule used to decode the council's parameters.
• 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).