SPL Governance is the on-chain program that most decentralized autonomous organizations on Solana run on, and Realms is the 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.
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.
Almost no one interacts with the raw program. Realms is the 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, 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.
One half of that sentence stopped being true. The repository behind the V1 app is still open, but the documentation now sends users to v2.realms.today, and its own developer page states that the Realms UI is a private repository and that access is by request (Realms). The program and the SDKs remain open source. What a DAO can no longer do is read, fork or self-host the interface its members actually vote in – a distinction worth keeping separate from the program’s own licence, because the two are now on different terms.
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:
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 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:
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.
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. They differ mainly in which addin and which council setup they choose.
What is not identical is the kernel: several of the largest run their own deployment of the program rather than the shared one – Jito at jtogv…, Drift at dgov7…, Pyth at pytGY… among them, all separate upgradeable programs, and Realms’ own treasury tooling carries a long list of such program IDs. That matters for the section below: a DAO on its own deployment is not exposed to the council that upgrades the default program, and has instead its own upgrade-authority question to answer.
The stack also has a market layer now. Sowellian Governance, which the documentation introduces as drawing on Robin Hanson’s futarchy, splits a decision in two: holders vote on the objectives, and a betting market decides the method, with payouts settled on the outcome and the treasury taking a bond or a 1% rake from losing bets (Realms). Its program was deployed to mainnet on 26 August 2026. Its own agent documentation also records a known bug: cancel a proposal before the vote is registered and the bet tokens are permanently locked, because no refund instruction exists (Mythic Project). That is the futarchy idea shipped as a plugin, with the plugin-trust caveat below attached to it from the start.
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:
community_vote_threshold is Disabled and its minimum community weight to open a proposal is u64::MAX. Only the council votes.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 %.Early, so a fifth yes ends the vote the moment it lands.transactions_hold_up_time is 0 – the config imposes no delay of its own between a proposal succeeding and its instruction executing.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.
There is a second half to the question, and it is newer. Reading the program’s own logs on 19 September 2026, the deployed default program identifies itself as VERSION:"3.1.6". The highest version published as source anywhere is v3.1.3, and the Solana verified-build service reports the on-chain program as not verified, with no executable hash recorded, while naming that same v3.1.3 commit as its declared source. So the binary now executing every Realms DAO’s treasury decisions cannot be reproduced from anything published. The council arrangement above is a good answer to who may replace the program; it is not an answer to what the program currently is. For a page that argues the trust assumption is at least publicly readable, this is the caveat that has to travel with 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.
5tPU1s… at slot 431,127,240, 08:26 UTC, no error, the program logging GOVERNANCE-INSTRUCTION: ExecuteTransaction (read from mainnet on 19 September 2026). Nothing was exploited. rekt.news reports the proposal as BIP #76, filed by an anonymous wallet six days earlier and passed on 2.9% turnout with the governance’s instruction hold-up time set to zero seconds. The timelock this page flags as absent from the program’s own council is absent from ordinary realms too, and it is the only thing that would have given anyone a window to react.The plugin bullet also has a concrete case now. An Accretion Labs review dated 10 September 2025 found a critical flaw in the Metaplex Core NFT voter plugin – a missing program-ownership check that let a voter present fake NFTs and vote with them – plus a high-severity issue allowing votes to be cast on proposals that did not yet exist. Both were fixed. The plugin library now holds eight programs, and the Civic gateway addin the infobox names is client-side code rather than a program in that repository.
SPL Governance lets each DAO plug in its own weight function, and the common choice, the voter stake registry, counts tradeable tokens with an optional lockup bonus, so a large enough bag or a long enough lock still carries the most say. Caper builds the weight rule into the contract instead of exposing it as a plug-in. A member's weight comes from the caper tokens they hold together with vote tokens they earn only by voting, so a big bag alone can't capture control, and a holder who has never voted has no weight at all.
A proposal offers one or more actions beside a standing "do nothing", and members rank them all on one ballot; if "do nothing" leads, the proposal fails. A winning action must then hold up in the caper's own market: it runs only if the token's price over a set window holds at or above where it stood before the window opened. See how a proposal executes.
Where a Realms DAO's members can leave only by selling into a secondary market, any caper member who has voted can exit any time for their fair share of the treasury, and the same weight that sets their say sets that share.
The upgrade question above has a structural answer too. A caper's state, its treasury and its record of proposals, is deployed once and never migrated, so past decisions do not depend on anyone keeping authority. The logic that runs on that state can be replaced by an UPGRADE proposal passed on the $CAPER caper. Until the protocol operator retires its admin badge, which Caper's deployment plan schedules for after mainnet launch, that badge can replace the logic too.
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. The deployed version, the BonkDAO execution and the Sowellian deployment were read the same way on 19 September 2026, the first from the program’s own transaction logs and the second from the block at slot 431,127,240.
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.