Record-first governance, respecting validators
Token holders decide; the chain records the decision. Governance v1 is fully implemented and active on mainnet: its activation gate at height 8,900,000 has been reached, so governance transactions are live.
Active on mainnet (activated at height 8,900,000)
Approval is recorded on-chain; execution is deliberate
The authoritative governance decision is the on-chain approval record. Governance records that a proposal passed. It does not push code, force upgrades, or change consensus; those are carried out off-chain by maintainers and validators who remain in control.
governance.model
- decision
- on-chain approval record
- voting_source
- allowlisted SRC-20 token
- voting_power
- frozen balance snapshot
- ballots
- public (v1)
- on-chain exec
- TreasurySpend only
Two authorities, clearly separated
SRC-20 token holders
Holders of a single allowlisted, fixed-supply / non-mintable governance token create proposals and vote. Voting power is a balance snapshot frozen at proposal creation, so moving tokens after the snapshot cannot change the outcome.
Validator-quorum authority
Admin actions, enabling a governance asset, and cancelling someone else's live proposal, are authorized by a quorum of the active validator set, not a personal council key. The bar is a basis-point threshold (GovernanceParams.validator_authority_threshold_bps): required approvals = ceil(active_validators × bps / 10000). Non-signing validators abstain but still count in the denominator; for the current two-validator network,6667 requires both, and 10000 requires all. The governed treasury address is separate and base58-configured.
Create → snapshot → vote → tally → record
- 1
Create create_threshold
A holder whose snapshot power meets the asset threshold opens a proposal and posts the deposit bond.
- 2
Snapshot gov_snapshots
Eligible balances are frozen from TOKEN_BALANCES at creation. Transfers afterward do not change voting weight.
- 3
Vote
Holders cast Yes / No / Abstain, weighted only by the frozen snapshot, never by live balances.
- 4
Tally
After the window, quorum and the pass threshold are evaluated over snapshot power.
- 5
Record / Execute / Cancel
Passed proposals are Recorded, or Executed for a TreasurySpend payout. The proposer, or a validator quorum, may cancel a live proposal.
proposal.bond
Deposit bond
When a bond is configured, it is escrowed to a canonical governance address at creation, the proposer must cover fee + bond.
Escrow
at creation
Return
good-faith / proposer cancel
Burn
spam / quorum fail / validator-quorum cancel
execution.kind
RecordOnly vs OnChain
Most classes, process, RPC surface, token/economic, genesis/validator, activation height, migrations, are RecordOnly. The one on-chain auto-exec path is a TreasurySpend: a single native-Koppa payout from the configured treasury to a beneficiary fixed at creation. Every other OnChain proposal is rejected.
What governance cannot do
These limits are enforced by the node, not by policy.
- enforced
Force a validator to upgrade its binary or genesis.
- enforced
Mutate chain parameters, the validator set, or consensus on-chain.
- enforced
Move funds, except the single TreasurySpend native payout.
Four governance modes, strictly separated
Governance v2 extends v1 with native-Koppa consensus voting and SRC-833 equity voting. Each mode has its own electorate, weight rule, and authority boundary, none substitutes for another.
mode.validator-quorum
Validator-quorum authority
- Administrative authority for narrow protocol actions (e.g. registering governance assets).
- Not public monetary governance, it cannot release reserve or mint.
- Thresholds count the full active validator set: validators that do not sign remain in the denominator.
mode.sum-20
SUM-20 token governance
- Fixed-supply, non-mintable SUM-20 tokens vote with balance weight.
- Electorate is snapshotted at proposal creation, later transfers do not change a vote.
- Cannot carry native monetary actions.
mode.native-koppa
Native-Koppa consensus governance
- One eligible address = one vote; no stake weighting, no delegation.
- Eligibility requires a minimum Koppa balance and holding a qualifying allowlisted asset, snapshotted at proposal creation.
- Consensus/monetary changes pass at a fixed 6667 bps of yes+no votes.
mode.src-833
SRC-833 equity governance
- Share-class voting: votes = shares × votes_per_share.
- Controller-attested, commitment-aware voting path, holders prove membership against a chain-derived balances root.
- No public holder table is ever exposed; scoped to equity contexts, never native supply.
Reserve release and future minting are native-only
The ProtocolReserve's governance pools and any future supply expansion beyond 800B are executable only through native-Koppa consensus governance. The monetary-policy gate is deployed in runtime genesis and activates at height 9,200,000; because chain_getChainParams does not expose every gate, the status below uses that operator-verified height and flips to active from the live block height.
- Reserve release gatestatus unavailable
- MonetaryPolicyMint gatestatus unavailable
- Activation height9,200,000 (deployed)
- Required governance modeNativeEligibility only
- Required pass threshold6667 bps (fixed)
- Validator-quorum authority cannot release reserve or mint.
- SUM-20 and equity governance cannot release native reserve or mint native Koppa.
- Future monetary expansion is disabled unless explicitly activated through native governance; reserve release is protocol-gated and requires native-Koppa governance once the gate activates.
The monetary-policy gate is deployed in runtime genesis and activates at height 9,200,000; the state above is derived from the live block height, not a chain_getChainParams field (which does not expose every gate).
Reserve pools and release paths
Governance execution is narrow and typed
Every on-chain execution class is explicitly allowlisted; everything else fails closed. These boundaries are enforced by the node at both proposal creation and execution.
- enforced
Validator-quorum is not a substitute for native monetary governance, monetary classes reject it.
- enforced
Policy Account token-admin execution is allowlisted to exactly five audited token operations.
- enforced
Native reserve-release and mint actions must be NativeEligibility proposals, enforced at creation and execution.
- enforced
Equity governance is for eligible equity/share-class contexts; it cannot touch native supply.
Governance parameters, read from the chain
Gate heights and configured thresholds fetched from the public RPC on load. This is configuration status, not live participation data; fields a node does not expose are labeled rather than invented.
governance.params · live
- governance_enabled_from_height
- not exposed by current RPC
- validator_authority_threshold_bps
- not exposed by current RPC
- quorum_bps
- not exposed by current RPC
- pass_threshold_bps
- not exposed by current RPC
- voting_period_blocks
- not exposed by current RPC
- max_snapshot_holders
- not exposed by current RPC
- min_koppa_for_eligibility
- not exposed by current RPC
- monetary_policy_enabled_from_height
- height 9,200,000
- service_grants_enabled_from_height
- height 9,200,000
RPC unreachable, no configuration values are shown rather than estimates.
The monetary_policy and service_grants gates are two of seven post-supply gates that chain_getChainParams does not expose. The site uses their operator-verified runtime-genesis height (9,200,000) and derives active/pending from the live block height, so they are never shown as null/dormant.