Skip to main content

System Protocols

The Flare Systems Protocol encompasses the following core system protocols:

  1. P-chain Stake Voting Protocol
  2. Signing Policy Definition Protocol
  3. Validator Uptime Voting Protocol
  4. Reward Voting Protocol
  5. Random Number Generation Protocol (dependent on the FTSOv2 Scaling)

Protocols with voting frequencies tied to reward epochs are implemented directly on the FlareSystemsManager smart contract, while others operate as sub-protocols. Each sub-protocol has a unique protocol ID, except for the system protocols mentioned above.

P-chain Stake Voting Protocol​

  • Protocol ID: 1
  • Voting Frequency: Per voting epoch
  • Description: Functions similarly to sub-protocols, using the Flare Systems Client to submit signatures for Merkle tree-based protocol messages. It captures stake and delegation records from the P-chain during each voting epoch.
  • Finalization: Occurs on the Relay contract.
  • Incentives: Rewards for timely signing and finalization come from inflation. However, mirroring weights to delegators is not incentivized.

Infrastructure: Utilizes a Flare P-chain indexer, requiring a specially configured observation node.

Signing Policy Definition Protocol​

  • Voting Frequency: Per reward epoch

  • Description: Ensures that voter weights for the next reward epoch are locked and signed by a threshold weight of current voters. This information is relayed to other EVM chains, enabling cross-chain message relaying.

    Phases:

    • Random Number Acquisition: Triggered 2 hours before the end of the reward epoch. The random number is fetched via the FTSO scaling protocol.
    • Vote Power Block Selection: Occurs after random number acquisition to select a block for vote power.
    • Voter Registration: Lasts 30 minutes, allowing self-registration based on the selected block’s weights.
    • Signing Policy Snapshot: Snapshots voter addresses, weights, and thresholds for the next reward epoch.
    • Signing Policy Sign Phase: Ends when the threshold of signatures is reached. Delays beyond 20 minutes incur penalties.

  • Finalization: Via the signNewSigningPolicy function.

  • Incentives: No direct rewards; instead, delays incur penalties by burning fee claims based on the extent of delay.

Infrastructure: Utilizes the Flare indexer.

Validator Uptime Voting Protocol​

  • Voting Frequency: Per reward epoch
  • Description: After each reward epoch, voters submit signed lists of validator NodeIDs with sufficient uptime (≥80%). Voting concludes when a threshold weight (e.g., 60%) is reached.
  • Finalization: Through the signUptimeVote function.
  • Incentives: Collective penalization for delays by blocking reward claims.

Infrastructure: Requires a connection to a local node, reusing the Flare P-chain indexer infrastructure.

Reward Voting Protocol​

  • Voting Frequency: Per reward epoch

  • Description: After each reward epoch, and once uptime voting is complete, voters aggregate reward claims across sub-protocols into a Merkle tree. A final Merkle root is voted on, enabling the RewardManager contract to verify and pay out rewards.

    Process:

    • Sub-protocols submit reward claims based on participation data.
    • The aggregated claims form a Merkle tree, with voting to confirm the root.

  • Finalization: Via the signRewards function.

  • Incentives: No special rewards; delays penalize all voters by blocking reward distribution.

Infrastructure: Uses sub-protocol-specific scripts and data from the Flare indexer.

Random Number Generation Protocol​

  • Description: Random numbers are generated by the FTSOv2 Scaling. These are used for masking commits and are calculated from reveals during the scaling process. The random number forms part of a Merkle tree, confirmed via the Relay contract.

Additional Non-System Sub-Protocols​

  • Protocol ID 14: FTSOv2 Scaling
  • Protocol IDs 20+: FDC Instances
    • Multiple instances allow scaling, lower finalization thresholds, and segregation based on maturity and security considerations.