Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Governance

This section describes how the WANNA ecosystem is governed, which parameters are subject to governance, and how control is intended to transition over time from a foundation-led model to a token-holde

Governance is centered around the WANNA token, which functions as the coordination asset for:

  • risk and collateral parameters

  • economic and revenue allocation rules

  • protocol upgrades and roadmap priorities

  • treasury and ecosystem decisions

1. Governance Design Principles

The WANNA governance model is designed around the following principles:

  • Safety Before Speed Changes to risk and collateral parameters must not endanger peg stability or solvency. Governance is constrained by hard safety limits.

  • Progressive Decentralization Early stages rely more on a foundation / multisig for execution. Over time, decision-making authority is gradually transferred to WANNA token holders.

  • Transparency & Auditability Governance decisions, parameter changes, and treasury movements should be traceable and, where possible, verifiable on-chain.

  • Alignment with Long-Term Users Voting power is intended to reflect long-term commitment rather than purely short-term speculation (e.g., via staking / locking models).

2. Governance Scope

Over time, WANNA governance is expected to influence, refine, or control the following areas:

2.1 Risk & Collateral Parameters

  • Target collateral ratios (CR) and safety margins (σ).

  • Liquidity thresholds (LCR, FX-LCR) for GUSD and G-Series.

  • Exposure caps and haircuts per:

    • asset

    • chain

    • custodian or protocol

2.2 Economic & Revenue Allocation

  • Allocation of Net Surplus between:

    • risk buffers and reserves

    • ecosystem / growth incentives

    • Buy-back & Burn (B&B)

    • operational budgets within defined limits

  • High-level policies for:

    • Earn products

    • fees and spreads at various protocol layers

2.3 Asset, Partner, and Strategy Whitelisting

  • Addition or removal of:

    • collateral assets (stablecoins, RWAs, tokens)

    • RWA, lending, and brokerage partners

    • oracle and bridge providers

  • Criteria for:

    • security audits

    • liquidity

    • regulatory/compliance fit

2.4 Protocol & Network Upgrades

  • Major upgrades to:

    • GUSD and G-Series core modules

    • oracle and price feed logic

    • G-Series Mainnet and payment stack parameters

  • Governance over:

    • fee schedules and gas policies

    • onboarding of new chains or deployment environments

2.5 Treasury & Ecosystem Funds

  • Use of treasury and ecosystem pools for:

    • grants

    • strategic investments

    • liquidity support

  • Guardrails on:

    • maximum outflows per period

    • required transparency and reporting

3. Progressive Decentralization

Governance is not fully open from day one. Instead, it follows a staged path aligned with the roadmap phases:

Phase 1–2: Foundation-Led with Guardrails

  • Many critical functions (e.g., parameter changes, contract upgrades) are managed by:

    • a foundation

    • a multisig committee composed of core contributors and key partners

  • Focus:

    • stability of GUSD/G-Series

    • conservative risk management

    • operational readiness

  • Governance Role (WANNA):

    • advisory or signaling mechanisms (off-chain voting, discussions)

    • initial setup of parameters and policies

Phase 3–4: Hybrid Governance

  • Gradual shift of specific powers to token governance, especially around:

    • revenue allocation (buffers vs. B&B vs. incentives)

    • asset / partner whitelisting

    • non-critical parameter tuning

  • The foundation / multisig retains:

    • emergency powers

    • legal and compliance responsibilities

    • oversight of high-risk changes

Phase 5 and Beyond: Protocol-Led Governance

  • Increasing use of on-chain governance for:

    • parameter updates

    • treasury deployments above defined thresholds

    • network-level decisions (e.g., mainnet upgrades)

  • Emergency and safety roles are still preserved, but with:

    • clear mandates

    • transparent rules

    • and stronger token-holder oversight

4. Governance Mechanics (Conceptual)

The exact technical implementation of governance may evolve, but it is expected to include:

4.1 Proposals

  • Who can propose:

    • core contributors and foundation in early phases

    • later extended to WANNA holders or delegates who meet certain thresholds (e.g., minimum staked / locked WANNA)

  • Proposal Types:

    • parameter changes (CR, LCR, haircuts, B&B ratios)

    • whitelisting / blacklisting assets and partners

    • treasury allocations and incentive programs

    • protocol / mainnet upgrade decisions

4.2 Voting & Delegation

  • Voting Power:

    • typically based on WANNA holdings

    • optionally weighted by staking / locking mechanisms (e.g., ve-style)

  • Delegation:

    • holders may delegate their voting power to:

      • professional governance participants

      • DAOs

      • trusted individuals

  • Thresholds & Quorum:

    • minimum participation (quorum) and approval thresholds defined to avoid low-quality decisions.

    • critical changes (e.g., risk limits, mainnet rules) may require higher quorum or supermajority.

4.3 Execution

  • Non-Critical Changes:

    • can be implemented via timelocked on-chain transactions after successful votes

  • Critical / Emergency Changes:

    • may still require multisig or guardian confirmation in early phases

    • gradually moving to fully on-chain execution when safe and compliant

5. Emergency Roles & Safety Overrides

To protect users and the protocol during adverse events, a limited set of emergency roles may exist, especially in earlier phases:

  • Guardians / Emergency Committee:

    • can temporarily:

      • pause minting / certain redemptions

      • pause B&B

      • disable risky strategies or partners

      • adjust parameters within strict safety bounds

  • Scope & Limits:

    • clearly defined in documentation (what they can and cannot do)

    • subject to:

      • on-chain logging

      • post-event review

      • potential sunset / reduction of powers over time

The goal is to balance user protection and system resilience with the long-term move toward decentralized control.

6. Participation & Responsibilities

WANNA holders who choose to participate in governance are expected to:

  • Act Informed:

    • review proposals carefully

    • understand risk implications for GUSD / G-Series

  • Consider Safety:

    • prioritize solvency and stability over short-term token price movements.

  • Respect Regulatory Constraints:

    • avoid governance actions that would clearly push the protocol into untenable legal risk.

Governance is a responsibility, not just a right.

7. Disclaimers

  • No Governance Guarantee:

    • Governance rights may be restricted or modified to comply with legal, regulatory, or security requirements.

  • Not a Legal Board or Shareholder Vote:

    • WANNA governance is a protocol-level coordination mechanism and does not necessarily grant:

      • corporate control

      • equity rights

      • or legal ownership of entities

  • Evolving Model:

    • The governance framework may evolve as:

      • regulation develops

      • the ecosystem grows

      • and community expectations mature

    • Any such changes should be publicly communicated and, where possible, approved by token governance itself.

PreviousBuy-back & BurnNextToken sale Terms

Last updated