Skip to main content

Governance

Governance is the structured process for making decisions about the Flare and Songbird networks. It empowers the community to guide the evolution of the protocols, playing a crucial role in progressive decentralization.

Through this framework, participants can:

  • Propose changes and improvements.
  • Vote on submitted proposals.
  • Observe the execution of approved proposals.

Official proposals are published on the Flare Governance Proposals website. Community members cast their votes via the Flare Portal.

Proposal types and networks​

Three distinct proposal types facilitate network changes, each tailored to a specific network and purpose, with unique voting mechanics:

Flare Improvement Proposals (FIPs)​

  • Purpose: Introduce enhancements or changes specifically for the Flare Mainnet.
  • Network: Flare Mainnet
  • Initiator: Flare Foundation
  • Voting Tokens: WFLR (wrapped FLR) and staked FLR
  • Voting Mechanism: Acceptance-based.
    • Default Status: Rejected
    • Approval Condition: Requires a simple majority (more than 50%) of the cast votes to be in favor.
    • Quorum Requirement: None

Songbird Test Proposals (STPs)​

  • Purpose: Allow for rapid testing and validation of potential changes on Songbird Canary-Network before potentially proposing them (as FIPs) on Flare Mainnet.
  • Network: Songbird Canary Network
  • Initiator: Flare Foundation
  • Voting Tokens: Wrapped SGB (WSGB)
  • Voting Mechanism: Rejection-based.
    • Default Status: Accepted
    • Rejection Conditions: The proposal is rejected only if both of the following conditions are met simultaneously:
      1. Quorum Threshold: At least 75% of the total circulating SGB supply participates in the vote.
      2. Majority Against: More than 50% of the cast votes are against the proposal.
    • Outcome: If either the quorum is not met OR the vote against is not a majority, the STP is accepted.

Songbird Improvement Proposals (SIPs)​

  • Purpose: Introduce enhancements or changes specifically for the Songbird Canary Network, independent of Flare Mainnet testing.
  • Network: Songbird Canary Network
  • Initiator: Flare Foundation
  • Voting Tokens: Wrapped SGB (WSGB)
  • Voting Mechanism: Acceptance-based.
    • Default Status: Rejected
    • Approval Condition: Requires a simple majority (more than 50%) of the cast votes to be in favor.
    • Quorum Requirement: None

Voting process​

Eligibility and Vote Power​

To vote on a proposal, users must hold the relevant network's governance tokens at the time the Vote Count Block is determined:

  • FIPs (Flare): Requires holding WFLR or having staked FLR.
  • STPs & SIPs (Songbird): Requires holding WSGB.

Your Vote Power corresponds directly to the amount of eligible tokens held at the snapshot time (Vote Count Block).

The Flare Foundation announces proposals well in advance, providing token holders ample time to wrap their FLR or SGB if they wish to participate in upcoming votes.

Vote Count Block​

Since token balances change constantly, a specific block number is chosen before voting commences to serve as a snapshot of account balances. This Vote Count Block determines each participant's voting power for that specific proposal.

To prevent users from acquiring tokens solely to influence a vote just before it starts, the Vote Count Block is selected randomly within a predefined period after the proposal's announcement.

Vote transfer​

Users can transfer their voting power to another address without transferring ownership of their tokens. This is useful for consolidating voting power from multiple wallets into one voting address.

  • An address can transfer its votes to only one other address.
  • An address can receive transferred votes from multiple addresses.
  • Transferred votes cannot be further re-transferred.
  • Once activated, all current and future voting power from the delegating account is transferred to the designated address until the delegation is explicitly canceled.

Example: If Alice transfers her votes while holding 100 WSGB, her designated address receives 100 votes. If she later acquires another 100 WSGB, her designated address will automatically have 200 votes in the next proposal, provided the transfer remains active.

Voting procedure​

Each governance proposal follows a structured lifecycle:

  1. Proposal Announcement: The Flare Foundation publishes the detailed proposal on the Flare Governance Proposals site, the main Flare website, and official social media channels.
  2. Notice Period: A minimum period (typically one reward epoch) allows the community to discuss the proposal, ask questions, and identify potential issues. Flawed proposals might be cancelled during this time.
  3. Block Selection Period: A window during which the random Vote Count Block is determined.
  4. Voting Period: Token holders cast their votes on the Flare Portal. This period usually lasts one week (approximately two reward epochs).
Governance Proposal DiagramGovernance Proposal Diagram

Proposal execution​

Once a proposal is formally accepted through the voting process, its implementation depends on the nature of the required changes:

  • Smart Contract Execution: Changes implemented directly within protocol smart contracts can often be executed automatically via governance contract calls.
  • Manual Execution: Proposals requiring offchain actions, coordination, or complex system updates are typically executed by the Flare Foundation.
  • Future Automation: The system is designed to incorporate more on-chain automation for execution as the protocols evolve.

Management Group​

Introduced via FIP.02 (Flare) and STP.03 (Songbird), the Management Group is a specialized governance body composed of eligible FTSO data providers.

Initial Role:

  • Monitor and report instances of collusion among Flare Time Series Oracle (FTSO) data providers.
  • Vote collectively on punitive actions (like chilling or banning) against providers confirmed to be acting maliciously.

Expanded Responsibilities (Post-FIP.08, FIP.11, FIP.12):

Following subsequent approved proposals, the Management Group's mandate grew to include voting on:

Qualification: To be part of the Management Group, data providers must be active participants in the core protocols, eligible for rewards, and have a clean recent conduct record (i.e., not recently punished).

Together, these responsibilities position the Management Group as a key governance body within the ecosystem - responsible not only for safeguarding protocol integrity but also for guiding its ongoing evolution.