Overview
This document outlines the process for GNS token-related governance proposals. Currently, this process is focused on proposals that affect GNS tokenomics and distribution. Product-related proposals are not included in this scope.
Key Principles
- All GNS token-related changes, including team initiatives, must follow this process
- Ensures transparency and community input on all GNS governance decisions
- Creates a standardized path for proposal discussion and implementation
- Maintains clear documentation of decision-making rationale
Process Stages
1. Community Ideation (1-3 days)
- Venues: Telegram and Discord community chats
- Purpose: Workshop ideas and gather initial feedback
- Participants: Open to all community members
- Recommended: Run informal polls to gauge sentiment
- Outcome: Sufficient interest to move to forum phase
2. Forum Discussion (3-7 days)
- Venue: Official Gains Network forum (Proposals - Gains Network)
- Purpose: Formal proposal and discussion
- Required Components:
- Overview of proposed changes
- Benefits and expected impact
- Justification/rationale
- Risk assessment and mitigations
- Implementation scope (if applicable)
- Participants: Community discussion led by proposal author
- Team Involvement: Will participate and amplify discussions as needed
3. Snapshot Vote (3-7 days)
- Venue: Snapshot — https://snapshot.box/#/s:gains-network.eth
- Eligible Proposers: Currently limited to team and community representatives — will expand over time
- Vote Duration: 3-7 days depending on proposal complexity
- Quorum: 10% of supply
- Vote Type: Majority vote
- Delivery: Team & multisig group
Proposal Guidelines
Scope
- Currently limited to GNS token-related proposals
- Examples include:
- Tokenomics adjustments
- Fee distributions impacting stakers
- Staking modifications
Sample Proposal Format
Title: [GNS-00] Proposal Name
Overview:
Brief description of the proposed change
Justification:
- Why this change is needed
- Supporting data/analysis
- Community benefit
Impact Analysis:
- Expected outcomes
- Metrics for success
- Timeline
Risks and Mitigations:
- Potential downsides
- Risk mitigation strategies
- Contingency plans
Implementation:
- Technical requirements (if any)
- Timeline
- Required resources
Example
See the recent SSS to Burn proposal which included:
Implementation Categories & Prioritization
Implementation Types
- Parameter Adjustments
- Changes to existing contract parameters
- Examples: Fee splits, OTC splits, OC burn
- Timeline: Can typically be actioned on immediately after vote ends
- Priority: High - these are low effort, high impact changes
- Contract Configuration
- Changes requiring contract interactions but no new development
- Examples: Modifying max OC burn,
- Timeline: 1-2 weeks depending on testing requirements
- Priority: Medium-High - requires thorough testing but no new code
- Feature Development
- Changes requiring new code or significant contract modifications
- Examples: New staking mechanisms, distribution models
- Timeline: Will be added to development roadmap
- Priority: Evaluated against existing roadmap items
- Note: May take multiple months depending on complexity
Prioritization Framework
Parameter Adjustments
- Implemented according to vote timeline
- No impact on development roadmap
- Executed by multisig after timelock
Contract Configuration
- Minor impact on development activities
- Requires internal testing before deployment
Feature Development
- Added to development backlog
- Prioritized during planning
- Timeline communicated back to community
- May require multiple governance votes as details are finalized