# Governance

> Overview of governance in the Flare Systems Protocol.

> For the complete documentation index, see [llms.txt](/llms.txt). Markdown versions of documentation pages are available by appending `.md` to the page URL.

Source: https://dev.flare.network/network/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](https://proposals.flare.network/) website. Community members cast their votes via the [Flare Portal](https://portal.flare.network/).

## Proposal types and networks[​](#proposal-types-and-networks "Direct link to 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)[​](#flare-improvement-proposals-fips "Direct link to 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)[​](#songbird-test-proposals-stps "Direct link to 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)[​](#songbird-improvement-proposals-sips "Direct link to 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[​](#voting-process "Direct link to Voting process")

### Eligibility and Vote Power[​](#eligibility-and-vote-power "Direct link to 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[​](#vote-count-block "Direct link to 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[​](#vote-transfer "Direct link to 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[​](#voting-procedure "Direct link to Voting procedure")

Each governance proposal follows a structured lifecycle:

1.  **Proposal Announcement:** The Flare Foundation publishes the detailed proposal on the [Flare Governance Proposals](https://proposals.flare.network/) 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](https://portal.flare.network/). This period usually lasts one week (approximately two reward epochs).

![Governance Proposal Diagram](/img/docs/network/governance/governance.light.svg)![Governance Proposal Diagram](/img/docs/network/governance/governance.dark.svg)

## Proposal execution[​](#proposal-execution "Direct link to 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 onchain automation for execution as the protocols evolve.

## Management Group[​](#management-group "Direct link to Management Group")

Introduced via [FIP.02](https://proposals.flare.network/FIP/FIP_2.html) (Flare) and [STP.03](https://proposals.flare.network/STP/STP_3.html) (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:

-   Adding new data feeds to the [FTSO protocol](/ftso/overview).
-   Adding new attestation types to the [FDC protocol](/fdc/overview).
-   Adjusting specific protocol parameters as defined in [FIP.11](https://proposals.flare.network/FIP/FIP_11.html) and [FIP.12](https://proposals.flare.network/FIP/FIP_12.html).

**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.