Solidus Governance

How the Solidus protocol evolves: the proposal process, voting mechanics, treasury management, committee structure, and the timeline for decentralization.

Overview

Solidus governance is a progressive system. In Phase 1, the founding team controls protocol upgrades and treasury allocation. Governance rights expand as the network grows and decentralizes. Full DAO governance — where no single entity has privileged control — is a Phase 4 objective.

This document describes the governance system as it will exist at mainnet launch (Phase 2). Earlier phases have lighter governance; later phases transfer more authority to the DAO.

Solidus Improvement Proposals (SIPs)

All protocol changes, parameter updates, and treasury allocations proceed through the SIP (Solidus Improvement Proposal) process.

SIP Types

Core SIPs may not be submitted at all until the 90-day protocol stability window has passed from mainnet launch. No core protocol changes in the first 3 months.

SIP Lifecycle

IDEA → DRAFT → REVIEW → DISCUSSION → VOTE → IMPLEMENTATION → ACTIVATION

Discussion extension: If a SIP receives more than 50 comments in the final 7 days of discussion, the discussion period extends by 14 additional days automatically to ensure all concerns are addressed.

SIP Template

## SIP-XXXX: [Title]
 
**Type:** Core / Standard / Treasury / Informational / Emergency
**Status:** Draft / Review / Discussion / Vote / Approved / Rejected / Implemented
**Proposed by:** [DID or pseudonym]
**Created:** YYYY-MM-DD
**Discussion:** [Link to governance forum thread]
 
### Summary
[One paragraph. What does this change and why?]
 
### Motivation
[Why is this change needed? What problem does it solve?]
 
### Specification
[Precise description of the change. For parameter changes: current value → proposed value.
For protocol changes: before/after pseudocode or protocol comparison.]
 
### Rationale
[Why this approach over alternatives? What alternatives were considered?]
 
### Backwards Compatibility
[Is this a breaking change? What is the migration path?]
 
### Security Considerations
[Does this change the threat model? What new attack vectors does it introduce or close?]
 
### Implementation
[Link to reference implementation, or description of what implementation requires.]
 
### References
[Supporting research, prior art, related SIPs.]

Voting Mechanics

Who Can Vote

Voting rights are proportional to staked SLDS. You must have SLDS staked for at least 7 days before a vote begins to be eligible. This prevents last-minute stake acquisition for vote manipulation.

Voting weight formula:

voting_weight = staked_SOLID × sqrt(days_staked / 30)

The square root of days staked rewards long-term participants over short-term voters, but does not give them unbounded advantage.

Delegation: Token holders can delegate their voting weight to another address. Delegated votes count toward quorum and toward the 30-day lock requirement. Delegation can be changed at any time, effective for the next vote.

Quorum

A vote is invalid unless 30% of total staked SLDS participates (either directly or via delegation). A vote that fails quorum is automatically extended by 7 days. If quorum is still not reached, the SIP is returned to Discussion status.

This quorum requirement prevents low-participation governance attacks (where a small motivated group passes changes the broader community would reject).

Approval Thresholds

No single entity may cast more than 10% of the total voting weight. If a single address (or delegated cluster from one identified controller) would exceed this threshold, their effective weight is capped at 10%. This concentration cap applies after delegation is resolved.

Voting Process

1. Proposal posted on-chain. When the Discussion period ends without a decisive rejection, the SIP moves to Vote status and is posted on the governance smart contract.

2. Snapshot taken. A snapshot of staked SLDS balances and delegation assignments is taken at the vote start block. Subsequent changes to stake or delegation do not affect this vote.

3. Voting window. 14 days during which eligible stakers can cast votes: YES, NO, or ABSTAIN. Abstain votes count toward quorum but not toward approval.

4. Outcome determination. At vote end: if quorum met and approval threshold met → Approved; if quorum met and threshold not met → Rejected; if quorum not met → Extended or returned to Discussion.

5. Veto window. After approval, there is a 7-day veto window in which the Security Council (see below) can veto a SIP if it poses an existential security risk. The Security Council cannot veto based on disagreement with direction — only clear security issues.

Treasury

Sources of Treasury Funds

Treasury Governance

Treasury funds can only be spent through an approved Treasury SIP. The treasury smart contract enforces this: no withdrawal without an on-chain approved SIP reference.

Standing budget (automatic, no SIP required):

• Security Council operations: 50,000 SLDS/year (covers hardware, ops, stipends)
• Core developer grants: up to 200,000 SLDS/year per developer (set by annual SIP)
• Bug bounty pool: 100,000 SLDS/year (automatic top-up)

Discretionary spending (Treasury SIP required):

• Protocol audits
• Research grants
• Partnership development
• Ambassador and hackathon programs
• Infrastructure grants for validators in underserved regions

Treasury Transparency

All treasury transactions are on-chain and publicly viewable via the Explorer (explorer.solidus.network/treasury). Monthly treasury reports are published by the Treasury Committee, showing:

• Opening balance
• Income received (by source)
• Expenditures (by SIP reference)
• Closing balance
• SLDS/USD valuation at month-end

Governance Committees

Five standing committees coordinate community activity between formal SIP votes. Committees advise, propose, and coordinate — they do not have unilateral authority over protocol changes.

Committee Selection: Self-nomination + community vote during a 2-week nomination window every 6 months. The top vote-getters by staking weight fill available slots. Founding team members may not hold committee positions after Phase 3 (progressive decentralization).

Committee Authority:

• Committees may post Informational SIPs without a vote
• Committees may sponsor Standard SIPs (removes 14-day discussion extension risk)
• Committees cannot spend treasury funds without an approved Treasury SIP
• Technical Committee may invoke the Emergency SIP process alongside the Security Council

Security Council

The Security Council is a 7-member multisig with authority over emergency interventions only. It cannot spend treasury funds or change protocol parameters — only invoke the Emergency SIP process and exercise the 7-day post-vote veto.

Composition (at mainnet launch):

• 3 founding team members
• 2 external security researchers (selected by community vote)
• 1 legal/compliance representative
• 1 rotating community representative (elected every 3 months)

Multisig requirement: 5-of-7 to invoke emergency SIP, 4-of-7 to veto.

Dissolution: The Security Council is dissolved by community vote after Phase 4, when the DAO governance system is sufficiently mature. After dissolution, emergency patches require a 51% of Core Validator approval (same 48-hour fast-track process, but without a central multisig).

Governance by Phase

Immutable Properties

The following properties are fixed at genesis and cannot be changed through any governance process. Changing them would require a hard fork with extraordinary social consensus — effectively creating a new protocol.

• Total SLDS supply: 1,000,000,000 (1 billion). No new issuance possible.
• Cryptographic primitives: Ed25519, BLAKE3, BBS+ (selective disclosure, live on testnet, audit pending). Groth16 ZK-SNARKs are on the roadmap. Post-quantum migration, if needed, is a hard fork, not a SIP.
• BFT safety properties: The requirement for 67% supermajority finality and the minimum of 3f+1 validators for fault tolerance.
• Identity binding: Validators must be verified humans. This requirement cannot be removed through governance.
• Concentration cap: No single entity may control more than 10% of voting weight. This cap applies to governance, not economics.

Governance Parameters (Changeable via Standard SIP)

Appeals

Any participant who believes a governance decision was made in bad faith (vote manipulation, quorum fraud, incorrect execution of an approved SIP) may file an appeal within 30 days of the decision.

Appeals process:

1. Submit appeal to governance forum with evidence
2. Technical Committee reviews within 14 days
3. If Technical Committee finds merit: matter goes to a fresh on-chain vote with a 60-day discussion period
4. If Technical Committee dismisses: appellant may request Security Council review (one escalation permitted per DID per 12 months)

Appeals cannot reverse executed on-chain transactions (e.g., slashing events) but can result in compensatory treasury payments if the appeal succeeds.

Governance Resources

• Forum: forum.solidus.network (off-chain discussion)
• On-chain proposals: gov.solidus.network (SIP voting and treasury)
• SIP repository: github.com/solidus-network/sips
• Governance dashboard: gov.solidus.network/dashboard (vote status, delegation, history)
• Committee schedules: gov.solidus.network/committees