GOVERNANCE SPECIFICATION · OPEN FOR COMMENT

Federation Governance Specification

A public specification for the $GFOF DAO governance system, built on Realms. Parameters are proposed for public comment before any governance infrastructure is deployed. The DAO does not deploy until after the $73K bond completes.

Version: v0.1 Status: DRAFT · OPEN FOR COMMENT Published: 2026-05-26 Deploys: POST-BOND
// CONTENTS
  1. Status of this document
  2. Design principles
  3. Platform
  4. Voting power
  5. Proposed parameters (v0.1 — for comment)
  6. What governance cannot do
  7. What governance controls
  8. The council question
  9. The first proposal
  10. Phased rollout
  11. Open questions for public comment

SECTION 01Status of this document

This is a draft specification, published before code, for public comment. It is version 0.1.

Nothing in this document is a committed parameter. Per the Federation's standing discipline (corrections #003), no governance number — proposal threshold, quorum, voting period, approval percentage — becomes a commitment until a specification defines it, the public has had the opportunity to comment, and the parameter is ratified. The figures below are proposed starting points, presented with their reasoning so that the reasoning can be challenged. They will change in response to comment. When they stabilize, a later version of this document will mark them as settled, and the first on-chain governance vote will ratify them.

SEQUENCE

The Federation DAO does not deploy until after the $73K bond completes. This specification exists now so the design is settled in the open before any of it goes live — the same spec-before-code discipline applied to the lending mechanism at /liquidation-spec.

SECTION 02Design principles

Governance is not a feature the Federation is adding because DAOs are expected. It is the mechanism by which the project's discipline survives the people who started it. A governance system designed well outlasts its founders; a governance system designed as theater concentrates power while appearing to distribute it.

Four principles govern every choice in this document:

Genuine token-holder governance, not a gatekept shell

Many projects launch "DAOs" that are centralized shells with marketing attached — token holders are locked out by councils, multisigs, or proposal gates that only insiders can pass. The Federation's governance is designed so token holders can propose, vote, and execute without requiring core-team permission. Where any centralized control exists during the transition, it is minimal, disclosed, and time-boxed with a defined sunset.

On-chain and verifiable, consistent with the rest of the project

Every proposal, every vote, every treasury action is recorded on-chain and publicly inspectable. Governance uses the same transparency posture as the corrections log and the live-RPC treasury page. No off-chain "signaling votes" that the team then interprets at its discretion.

Governance has limits, and the limits are the point

A DAO that can vote to do anything can vote to undo the discipline that makes the project worth governing. This specification defines, explicitly, what governance cannot do — including things a simple majority might want to do in a moment of pressure. The constraints are not a hedge against token holders; they are a commitment that the project's core disciplines survive even a vote to abandon them.

Spec before code, parameters before deployment

The governance system is fully specified and publicly reviewed before it is deployed. Parameters are proposed here, refined through comment, and ratified by the first governance vote — not set unilaterally and announced as done.

SECTION 03Platform

The Federation DAO will be built on Realms (the web interface for spl-governance, the on-chain governance program built by Solana Labs). This choice was committed publicly in the Week 07 Research Log and the bond-trigger commitment thread, and this specification confirms it.

Reasoning: Realms is the native Solana governance standard, with proposals, votes, and treasury actions recorded entirely on-chain. It is the same infrastructure used by established Solana protocols. Its on-chain-everything property matches the Federation's transparency posture — there is no off-chain layer where votes get reinterpreted.

The governance stack:

The Federation does not fork Realms or build a custom governance frontend in v0.1. Custom UI is a possible later addition, specified separately if pursued. Starting on standard, audited infrastructure is the disciplined default.

SECTION 04Voting power

What confers voting power

Voting power is conferred by holding the $GFOF community token. One token, one vote, subject to the exclusions below. The DAO is a Community Token DAO in Realms terms — governance is gated by token ownership, and voting weight is proportional to tokens held at the time of the vote.

Locked dev tokens do not vote

The 13% dev allocation locked across the four Streamflow contracts does not participate in governance voting. This is a deliberate design choice and one of the more important in this document.

Reasoning: the dev tokens are locked for supply discipline — to demonstrate the team will not dump and to immobilize a large block of supply until 2026-2028. Allowing those same tokens to vote would give the team a 13% governance bloc while the tokens are nominally "locked," which would contradict the decentralization principle. Locked-for-discipline should not double as locked-for-control. The cleaner design excludes them from governance entirely.

OPEN FOR COMMENT

The alternative — letting locked tokens vote — is the more common DAO default, but the Federation's positioning argues against it. If the community comments otherwise during the review period, the decision is revisited.

The Founding Member NFT does not confer voting weight

The Founding Member NFT (snapshot at the migration block) is recognition, not governance power. It does not grant additional votes, voting multipliers, or proposal privileges. This was stated when the NFT was first committed and is reaffirmed here: the NFT is a permanent role marker for the bond-era community, nothing more. Governance weight comes from tokens held, full stop.

SECTION 05Proposed parameters (v0.1 — for comment)

Every figure in this section is a proposed starting point. The reasoning is given so it can be argued with. None is committed.

5.1 Proposal threshold

Proposed: 0.1% of circulating supply to submit a proposal.

Reasoning: a proposal threshold prevents spam — without one, the proposal queue fills with noise and real proposals get buried. But set too high, and only the largest holders can ever propose, which recreates the gatekeeping this design exists to avoid. 0.1% of a 1B supply is 1,000,000 $GFOF — a meaningful but not exclusionary stake. As circulating supply and token value change post-bond, this threshold may warrant adjustment, which is itself something governance can vote on.

5.2 Quorum

Proposed: 10% of eligible voting supply must participate for a vote to be valid.

Reasoning: quorum prevents a tiny group from passing proposals while everyone else is inactive. But voter apathy is real in every DAO, and a quorum set too high means nothing ever passes — which paradoxically concentrates power in whoever can reliably turn out votes. 10% is a deliberately moderate starting point. The Federation would rather start moderate and raise quorum through governance once participation patterns are known than start high and discover the DAO is paralyzed.

5.3 Approval threshold — two tiers

Proposed: two classes of proposal with different bars.

Reasoning: not all decisions carry equal weight. A routine treasury allocation should not require the same bar as a change to the governance system's own rules. The two-tier structure makes high-stakes changes deliberately harder to pass than routine ones — which protects the discipline anchors from a transient majority.

5.4 Voting period

Proposed: 5 days for standard proposals, 7 days for constitutional proposals.

Reasoning: the voting window must be long enough for a globally distributed token-holder base to participate across time zones, and short enough that the DAO can actually act. 5 days covers a full week's worth of weekday and weekend availability. Constitutional proposals get the longer 7-day window because their stakes justify maximum participation opportunity.

5.5 Execution timelock

Proposed: 48-hour hold between a proposal passing and its execution, extended to 72 hours for any treasury action above a threshold to be defined in v0.2.

Reasoning: a timelock is a safety mechanism. It gives the community a window to react if a malicious or erroneous proposal passes — to raise alarm, to coordinate, to exit if necessary — before the action executes on-chain. The larger the treasury impact, the longer the window should be. This is standard practice in mature governance systems and is non-negotiable in principle; the exact durations are open for comment.

SECTION 06What governance cannot do

This is the section that distinguishes the Federation's governance from a DAO that can vote to do anything. The following are outside the scope of governance and cannot be changed by any vote, standard or constitutional:

OUTSIDE GOVERNANCE SCOPE

Governance cannot unlock the dev tokens early. The four Streamflow contracts are immutable by design. No governance vote can accelerate, cancel, or modify them. They unlock on their contractual schedule (2026-2028) or not at all.

Governance cannot delete or alter the corrections log. The corrections log is append-only by design and by discipline. No vote can remove an entry, edit a historical entry, or suspend the logging discipline. A governance system empowered to erase its own accountability record would defeat the purpose of having one.

Governance cannot introduce paid promotion. Correction #007 — no paid promotion — is a foundational discipline, outside governance scope. A DAO vote cannot authorize paying for coverage, shilling, or any form of the paid promotion the project has committed against.

Governance cannot publish a quantum-security claim. Correction #012 — no quantum-security claims — is outside governance scope. The constraint stands regardless of vote.

Governance cannot commit numbers without a spec. Correction #003 applies to governance itself. A proposal cannot commit an APY, a multiplier, an allocation size, or any mechanism parameter that lacks a published specification. The proposal can direct that a spec be written; it cannot skip the spec.

Governance cannot reintroduce mint or freeze authority. These are revoked at the Raydium migration and cannot be restored. Supply is fixed at 1 billion permanently.

These constraints are not anti-democratic. They are the terms under which token holders acquired the token in the first place — the disciplines that defined the project. Governance distributes control over everything those disciplines leave open. It does not distribute the power to abandon the disciplines, because the disciplines are what the token represents.

If the community ever genuinely wishes to change one of these constraints, the honest mechanism is not a governance vote — it is a publicly argued, corrections-logged proposal to amend the constitution itself, with the change documented permanently as a departure from the original terms. That path exists. It is deliberately heavier than a normal vote, and any use of it is itself a permanent corrections-log event.

SECTION 07What governance controls

Governance has real, meaningful authority over everything the constraints leave open:

Governance authority is genuine. The constraints in Section 06 are narrow and specific; everything outside them is the community's to decide.

SECTION 08The council question

Realms permits an optional "council" — a small set of wallets holding a council token, with elevated permissions. Many Solana DAOs use one.

PROPOSED POSITION

No permanent council. A permanent council is precisely the gatekeeping structure the design principles argue against. If a small group of wallets can gate or override token-holder votes, the DAO is a shell.

The one defensible use of a council is a time-boxed transition council during the initial setup period — a small group (the founding team plus optionally one or two trusted community members) that exists only to execute the mechanical setup of the DAO and steps down via a scheduled, automatic sunset. If a transition council is used:

Proposed for comment: whether to use a transition council at all, or to launch with pure token-holder governance from the first block. The Federation leans toward minimal-or-none, and is publishing this question rather than deciding it unilaterally.

SECTION 09The first proposal

Per the bond-trigger commitments, the Federation's first governance proposal is already determined in topic: confirm or amend the framework for allocating the 10% rewards/reserve bucket.

The framework itself will be drafted as its own specification (separate from this governance spec) and published for review before the proposal opens. The first proposal is therefore a test of the governance system on a real, bounded decision with a pre-published spec — exactly the conditions under which governance should be exercised.

The first proposal will not be a trivial "ratify the team's choice" vote. The rewards/reserve framework spec will present genuine options with tradeoffs, and the proposal will let token holders choose or amend. If the first exercise of governance is theater, the whole system is theater.

SECTION 10Phased rollout

Governance does not arrive all at once. The proposed sequence:

  1. Pre-bond (now): this specification published, public comment period open.
  2. Comment integration: v0.2 of this spec incorporates feedback, settles parameters.
  3. Bond completion: Realms DAO setup begins (per the committed roadmap).
  4. DAO deployment: the DAO is created on Realms with the ratified parameters; treasury authority transferred per the spec; transition council (if any) installed with its sunset scheduled.
  5. First proposal: the rewards/reserve framework proposal opens once its underlying spec is published and reviewed.
  6. Ongoing: governance operates; parameter adjustments happen through constitutional proposals as the DAO learns.

Each step that constitutes a public commitment is logged on /corrections when it occurs.

SECTION 11Open questions for public comment

The Federation is specifically seeking comment on:

  1. Proposal threshold: fixed token amount or percentage of supply? What level?
  2. Quorum: is 10% too low, too high, or right for a project at this stage?
  3. Locked dev tokens: confirmed exclusion from voting, or should they participate?
  4. Transition council: none at all, or minimal-and-sunset? If sunset, on what trigger?
  5. Timelock durations and the treasury threshold above which the longer hold applies.
  6. Anything in Section 06 (what governance cannot do) that the community believes should be inside governance scope rather than outside it.

Comments can be raised through the channels the Federation operates. Substantive comments may be addressed directly in v0.2 of this specification.

CLOSING

Governance is the mechanism by which a project's discipline outlives the people who started it. Designed honestly, it distributes real control over everything the project's core disciplines leave open — while placing those disciplines themselves beyond the reach of a transient majority. This is version 0.1. It proposes; it does not commit. Spec before code. Comment before deployment. Receipts throughout. — Voss, out.

REVISION HISTORY

v0.1 2026-05-26 Initial publication. All parameters proposed for comment. Public comment period open. DAO deploys post-bond.
galacticfederation.co · Liquidation Spec · Research · Corrections · X / Twitter · Telegram
Galactic Federation of Finance — $GFOF on Solana. Not financial advice. Always DYOR.
v17.25 · governance-spec · deployed 2026-05-26