Proposal Process Framework

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

  1. 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
  2. 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
  3. 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
1 Like