Index

General Information
Part A: Information about the offeror or the person seeking admission to trading
Part B: Information about the issuer, if different from the offeror or person seeking admission to trading
Part C: Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D: Information about the crypto-asset project
Part E: Information about the offer to the public of crypto-assets or their admission to trading
Part F: Information about the crypto-assets
Part G: Information on the rights and obligations attached to the crypto-assets
Part H: Information on the underlying technology
Part I: Information on the risks
Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts

2026-06-10

This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The operator of the trading platform of the crypto-asset is solely responsible for the content of this crypto-asset white paper.

This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.

The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.

FALSE

The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.

Warning
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.

FLR is the native crypto-asset of the Flare network. Flare is an EVM-compatible Layer 1 blockchain designed for data-intensive and interoperable applications, with native data protocols built into the network.

As of June 1 2026, the total supply of FLR is [105930915074 from https://supply.flare.network/flare-total] according to the official Flare Supply Dashboard.

FLR is used for transaction fees, network security through staking, participation in governance, and delegation to the Flare Time Series Oracle.

Holders of FLR may transfer FLR, use it to pay transaction fees, stake it to validators, delegate it to data providers, and participate in governance, subject to the applicable Flare protocol rules, wallet requirements, smart contract conditions, and applicable law. Governance may modify protocol parameters or network rules through the Flare governance process.

Holding FLR does not confer shareholder rights, ownership rights in Flare Foundation or any other legal entity, redemption rights, rights to guaranteed income, or claims against an issuer.

Not applicable

The token has been admitted to trading to the trading platform operated by Bitstamp Europe S.A. on its own initiative.

TRUE

Flare foundation (Stichting Flare Networks)

The legal issuer of FLR has not been fully identified in official public sources by reference to a complete registry extract, registration number, registered address or legal entity identifier.

However, the official Flare white paper https://dev.flare.network/pdf/whitepapers/20221231-TheFlareNetworkAndFLRToken.pdf, identifies the Flare Foundation as a non-profit entity incorporated in the Netherlands and states that its remit is to support network traction and ongoing operations.

Official Flare materials also indicate that the Flare Foundation has an ongoing role in the project. For example, Flare states that FLR operates as a core component of network security, data provision, governance and transaction execution, and that the Flare Foundation is expected to bring forward governance proposals relating to FLR’s role in network activity. FIP.16 further states that, at least initially, the Flare Foundation will act as the entity responsible for certain protocol-owned block-building arrangements.

Accordingly, based on our best assessment, Flare Foundation is regarded as the entity most closely associated with the development, launch, initial distribution and continuing support of FLR and the Flare network, subject to confirmation of its full legal name, registration details, registered address and management body from an official registry extract or direct confirmation from Flare Foundation.

V44D

Herengracht 420, Amsterdam

NL-NH

Herengracht 420, Amsterdam

NL-NH

2022-01-01

Not applicable

Flare Foundation is a non-profit entity that supports the development, growth and operation of the Flare network and its ecosystem. Its activities include supporting the development of the Flare protocol, promoting adoption of the network, supporting governance initiatives, ecosystem development and incentive programs, and facilitating the continued operation and advancement of the Flare network.

Not applicable

Bitstamp Europe S.A.

5GGB

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

2015-05-19

549300XIBGTJ0PLIEO72

Bitstamp Europe S.A. is registered with the Luxembourg Trade and Companies Register under the number B196856.

Robinhood Markets, Inc with its registered office at 85 Willow Road, Menlo Park, California 94025, USA.

Bitstamp Europe S.A., acting in its capacity as a crypto-asset service provider (CASP) and operator of a trading platform, has prepared this crypto-asset white paper to support the admission to trading of the crypto-asset on its platform and to provide users with the information required under Regulation (EU) 2023/1114 (MiCA).

Bitstamp Europe S.A. is a Crypto-Asset Service Provider authorised with the CSSF under the number N00000003 to provide the following crypto-asset services:

• providing custody and administration of crypto-assets on behalf of clients;
• operation of a trading platform for crypto-assets;
• exchange of crypto-assets for funds;
• exchange of crypto-assets for other crypto-assets;
• execution of orders for crypto-assets on behalf of clients;
• reception and transmission of orders for crypto-assets on behalf of clients; and
• providing transfer services for crypto-assets on behalf of clients.

Bitstamp Europe S.A. is a payment institution authorised by the CSSF under number Z00000012 to provide the following payment services:

3.a) execution of direct debits, including one-off direct debits,

3.b) execution of payment transactions through a payment card or a similar device,

3.c) execution of credit transfers, including standing orders and

6.) money remittance.

Bitstamp Europe S.A. has notified the cross-border provision of payment services and of crypto-asset services in all EU and EEA member states.

Bitstamp has admitted the asset to which this white paper relates to, to trading on its own initiative on its trading platform.

Robinhood Markets, Inc. is the parent holding company of the Robinhood group.

MiCA Crypto Alliance Limited

MiCA Crypto Alliance Limited was mandated to assist in the white paper preparation by Bitstamp Europe S.A. Bitstamp Europe S.A. retains the role of person seeking admission to trading.

Flare

Flare

FLR

Flare is a Layer 1 blockchain designed to support decentralised applications that require reliable access to data from other blockchains and external sources. The network is EVM-compatible and incorporates native protocols that provide decentralised data acquisition and delivery directly at the protocol level.

The project aims to improve the blockchain applications by enabling secure, decentralised access to high-integrity data. Flare's core protocols include the Flare Time Series Oracle (FTSO), which provides decentralised data feeds, the Flare Data Connector (FDC), which enables the acquisition of external and cross-chain data, and the FAssets system, which is designed to enable the use of assets from other blockchains within the Flare ecosystem without reliance on centralised intermediaries.

The native crypto-asset of the project is FLR, which is used for transaction fees, network security, governance participation and interaction with the network's native protocols.

FALSE

Not applicable

Past milestones

In December 2022, Flare announced 9 January 2023 as the date for the Flare Token Distribution Event, following the network reaching the decentralisation threshold required to commence token distribution.. On 9 January 2023, FLR became live and the first 15% of the public token distribution was distributed, with the remaining 85% to be distributed monthly over 36 months, subject to the outcome of FIP.01.

In September 2024, Flare Time Series Oracle v2 went live on Flare mainnet, introducing changes to FTSO rewards. In December 2024 and January 2025, FXRP and FDOGE went live on Songbird as part of the FAssets testing process. In September 2025, FAssets went live on Flare mainnet, starting with FXRP v1.2.

FlareDrop is the governance-defined FLR distribution program established under FIP.01, through which a portion of the FLR supply was distributed over 36 monthly installments to eligible network participants, including holders of wrapped FLR and, where applicable, staked FLR. The program was designed to broaden FLR ownership and encourage active participation in the Flare network. The FlareDrop program concluded on 30 January 2026. In April 2026, Flare published its plan for FLR under FIP.16, including reductions to inflation, protocol-level MEV capture and the routing of broader network revenues through FIRE.

Future milestones

Future milestones include the continued implementation and rollout of FIP.16 tokenomics changes, including changes to FDC fees, fee redirection to FIRE, FAssets-related fee mechanisms, Flare Confidential Compute fees, MEV capture mechanisms, and changes to P-Chain staking economics. FAssets are already live on Flare mainnet, beginning with FXRP v1.2, and future milestones include the further scaling of FAssets following mainnet launch. These milestones remain subject to the applicable governance approvals, protocol implementation, network upgrades and deployment timelines.

At network genesis, 100,000,000,000 FLR tokens were created. FLR allocations are divided between the Flare community, Flare partners, the team, advisers, backers and inflation-related rewards. The Flare community allocation comprises 9,787,578,628 FLR allocated to the Flare Foundation, 4,278,738,206 FLR allocated to the Initial Token Distribution, 24,246,183,166 FLR allocated to the FlareDrop and 20,000,000,000 FLR allocated to the Incentive Pool, representing a subtotal of 58,300,000,000 FLR.

Following the approval of FIP.01, the initially circulating supply was reduced to 15,000,000,000 FLR tokens. In addition, from October 2024 to January 2026, 66,293,390 FLR tokens were burned on a monthly basis from certain backer allocations, resulting in an increase in the proportion of tokens allocated to the community from 58.3% to 59.6%.

The Flare partner allocation comprises 12,965,300,324 FLR allocated to Flare Labs and 10,000,000,000 FLR allocated to the Flare VC Fund, representing a subtotal of 22,970,000,000 FLR.

The team, advisers and backers allocation comprises 7,000,000,000 FLR allocated to the founding team, 1,500,000,000 FLR allocated to the rest of the team, 3,000,000,000 FLR allocated to the future team, 2,000,000,000 FLR allocated to advisers and 3,100,811,196 FLR allocated to backers, representing a subtotal of 16,600,000,000 FLR.

Under the applicable allocation rules, delegation, FlareDrop claiming and governance voting rights differ by allocation category.

The public distribution comprised 28,524,921,372 FLR, of which 4,278,738,206 FLR were distributed in the initial airdrop during the Token Distribution Event on 9 January 2023, and 24,246,183,166 FLR were distributed through FlareDrops over 36 monthly distributions.

FlareDrops ended on 30 January 2026. Under FIP.16, the target annual inflation rate is reduced from 5% to 3%, and the annual inflation hard cap is reduced from 5,000,000,000 FLR to 3,000,000,000 FLR. All native FLR paid as transaction fees are burned.

Not applicable

Bitstamp Europe S.A. has admitted the token to trading based on its market considerations.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account. If a client wants to hold the token in their own wallet, they will need to (i) provide an external blockchain wallet address, where the crypto-assets will be sent if a withdrawal is initiated and (ii) satisfy all other requirements applicable to a withdrawal in line with the Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account and a client does not need to fulfill any other technical requirement to hold the crypto-assets on their Bitstamp account, apart from have either a computer or phone with an internet connection and appropriate software in order to interact with the Bitstamp services.

Not Available

Bitstamp Europe S.A.

BESA

Investors can access the trading platform through https://www.bitstamp.net or via the Bitstamp applications.

There are no costs involved in creating an account on the trading platform, however trading fees and other costs apply in accordance with the fee schedule available at https://www.bitstamp.net/fee-schedule.

Not applicable

There are no conflicts of interest arising at the moment of writing the white paper in relation to the offer or admission to trading. Bitstamp Group has a strict Code of Conduct and Trading Policy in place. They both mitigate the possibility of conflicts of interest.

In accordance with the Code of Conduct all officers, directors, employees, agents, representatives, contractors and consultants (and other persons, regardless of job or position), are required to report any situation where there is the potential for conflict of interest between their interests and interests of Bitstamp. The Trading Policy that is in place within the Bitstamp Group prohibits all forms of market manipulation and has been designed to prevent insider trading.

Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.

Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.

Crypto-assets other than asset-referenced tokens or e-money tokens

FLR functions as the native crypto-asset of the Flare network and is used to pay transaction fees, support network security through staking, participate in governance, delegate voting power to FTSO data providers, and interact with applications and protocols deployed on the network. FLR enables holders to execute transactions, deploy and interact with smart contracts, participate in validator staking, contribute to decentralised data provision through delegation, and vote on governance proposals affecting the network and its protocol parameters.

FLR also supports the functionality of Flare's native protocols, FTSO, which provides decentralised data feeds, the FDC, which enables the acquisition of data from external systems and other blockchains, and the FAssets system, which enables the use of assets originating on non-smart contract blockchains within the Flare ecosystem.

Not applicable

FLR is the native crypto-asset of the Flare network. Flare is an EVM-compatible Layer 1 blockchain designed for data-intensive and interoperable applications, with native data protocols built into the network.

As of June 1 2026, the total supply of FLR is [105930915074 from https://supply.flare.network/flare-total] according to the official Flare Supply Dashboard.

FLR is used for transaction fees, network security through staking, participation in governance, and delegation to the Flare Time Series Oracle.

Holders of FLR may transfer FLR, use it to pay transaction fees, stake it to validators, delegate it to data providers, and participate in governance, subject to the applicable Flare protocol rules, wallet requirements, smart contract conditions, and applicable law. Governance may modify protocol parameters or network rules through the Flare governance process.

Holding FLR does not confer shareholder rights, ownership rights in Flare Foundation or any other legal entity, redemption rights, rights to guaranteed income, or claims against an issuer.

Flare

https://flare.network

2026-07-11

2026-07-10

Not applicable

English

3KXTVG1Q5

DVRV6HSK5

FALSE

TRUE

TRUE

Not applicable, holders of the FLR crypto-asset do not, solely by acquiring or holding FLR, acquire any ownership, equity, profit participation, repayment, redemption or compensation rights against any identified issuer, the Flare Foundation, Flare Network or any other natural or legal person. Holding FLR does not give rise to contractual claims or entitlements against any natural or legal person.

Accordingly, all functionalities associated with FLR are functional and protocol-based. These functionalities are further described in F.2.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable

FALSE

Not applicable

TRUE

Not applicable

Not applicable

FALSE

Not applicable. FLR does not operate a demand-based supply mechanism designed to maintain price stability. The total supply is affected by protocol-defined inflation emissions and by the burning of all transaction fees on execution, as further described in field D.9.

FALSE

Not applicable

FALSE

Not applicable

There is no written legal agreement between the issuer and the crypto asset-holder that sets out the laws that govern the legal relationship between those two parties. In the absence of such an agreement, the laws that govern that relationship will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

There is no written legal agreement between the issuer and the crypto asset-holder that sets out which jurisdiction's courts will have authority to deal with a dispute between the crypto asset-holder and the issuer. In the absence of such an agreement, the laws of the competent court will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

Not applicable as DTI is provided in F.13

Networking, transport and session

Flare Mainnet exposes public remote procedure call interfaces over HTTPS for synchronous request-response queries and over WebSocket for persistent, event-driven subscriptions. Bootstrapping nodes provide stable initial connection points for operators joining the network.

3 distinct node roles exist. An RPC node reads blockchain data and submits transactions without participating in consensus. A validator node secures the network by validating transactions and participating in consensus. A Flare Entity combines a validator node with a data-provider system for the Flare Systems Protocol, which encompasses the Flare Time Series Oracle and Flare Data Connector sub-protocols. This tiered structure separates application access, block production and protocol-level data provision into distinct operational responsibilities.

Serialisation

Transactions comply with EIP-2718 typed transaction envelopes and are encoded with Recursive Length Prefix. EIP-2718 standardises the byte-level representation of distinct transaction types. Recursive Length Prefix is a deterministic serialisation scheme that converts transaction fields into a canonical byte sequence, ensuring every validator reaches an identical interpretation of the same transaction before processing.

Cryptography and key formats

Accounts use 20-byte addresses generated using the Elliptic Curve Digital Signature Algorithm over the secp256k1 curve. Transaction inclusion within a block is verified through Merkle Patricia Trie proofs evaluated against the receipts root committed in the block header, providing cryptographic assurance of membership without reprocessing the full block.

Ledger

The ledger advances through validator agreement. Validators participate in Snowman++ consensus, agree on a set of transactions and add the resulting block to their local copy of the ledger. Block verification operates at 3 levels: block header verification, block body validation and transaction-in-block verification through Merkle Patricia Trie proofs against the block header receipts root.

Execution

Flare is fully EVM-compatible. The supported opcode set extends through the Cancun hard fork, meaning any contract deployable on an Ethereum Cancun-compatible environment may also be deployed on Flare. Transaction fees follow two formats: legacy transactions are priced as gas used multiplied by gas price; EIP-1559-style Type 2 transactions are priced as the sum of base fee and priority fee multiplied by gas consumed. All transaction fees under both formats are burned on execution, permanently removing them from the circulating supply.

Token standards

FLR is the native currency of Flare Mainnet and is not deployed as a contract-token standard. Its functions, consisting of paying transaction fees, staking to validators, delegating to the Flare Time Series Oracle and participating in network governance, arise from its native-currency status within the protocol.

The Flare Systems Protocol smart-contract repository implements Solidity contracts for the Flare Systems Protocol and its sub-protocols, including the Flare Time Series Oracle and the Flare Data Connector. These contracts support enshrined data-protocol functions on the network but do not alter FLR's classification as native currency.

External APIs

Flare Mainnet exposes public HTTPS and WebSocket RPC endpoints. Additional API resources are available for the data availability layer and for Flare Data Connector attestation verifiers, covering EVM-compatible chains, Bitcoin, XRP, DOGE and Web2Json attestation types. RPC nodes allow applications to access and relay transactions without participating in consensus.

Implementation and architecture

The Flare node implementation is go-flare, a modified version of avalanchego and coreth incorporating Flare- and Songbird-specific features, including prioritised contract handling and daemon contract invocation. Avalanchego provides the base consensus and networking layer; coreth provides the EVM-compatible execution environment.

3 node roles shape the infrastructure topology. An RPC node provides read and transaction-submission access without consensus participation. A validator node validates transactions and participates in consensus. A Flare Entity combines a validator node with a data-provider system for the Flare Systems Protocol. Together, these roles separate application access, block finalisation and protocol-level data provision.

A Flare Entity consists of six components. The Flare System Client manages interactions with FTSO smart contracts, including data collection, submission, voter registration and protocol system tasks. The C-chain Indexer tracks Flare Systems Protocol-related blockchain transactions and events, enabling data calculations and downstream action triggers. The FTSO Client provides anchor feed submissions and median data to the System Client. The Fast Updates Client submits block-latency feeds to Fast Updates contracts. The Feed Value Provider retrieves live price data from exchanges and supplies current feed values to the FTSO Client. The FDC Client provides Flare Data Connector voting-round data to the System Client.

Runtime and build parameters

Go-flare publishes hardware requirements, compilation instructions and software prerequisites. The build process requires Go version 1.23, gcc, g++ and jq. Public container images are hosted on Docker Hub and GitHub Packages and are signed using Cosign with the GitHub OIDC provider, allowing operators to verify image provenance before deployment.

Dependencies

Go-flare is built on avalanchego version 1.13.0 and coreth version 0.15.0 release candidate 0, with Flare-specific modifications applied to both layers. The Flare Systems Protocol smart-contract repository is written primarily in Solidity, with TypeScript forming the bulk of the remaining codebase, and supports on-chain contract logic alongside off-chain tooling for the Flare Entity components.

Flare Mainnet runs Snowman++, a Byzantine fault-tolerant consensus protocol from the Avalanche Snow family of probabilistic protocols, operating on both the P-chain and C-chain. Byzantine fault tolerance means the protocol continues to reach correct agreement when a bounded proportion of participating validators behave incorrectly or adversarially within the protocol's assumptions.

Proof-of-Stake is the Sybil-resistance mechanism. Validators must hold a minimum self-bond of 1,000,000 FLR on the P-chain to participate in consensus. Delegation is handled in-protocol, and validator selection for block proposal is weighted by total stake, comprising each validator's self-bond plus any stake delegated to it.

Snowman++ introduces a soft proposer mechanism. At each block height, a fixed number of validators is sampled using stake-weighted selection without replacement. This number is governed by the protocol parameter maxWindows, currently set to six. Sampled validators are assigned time-based eligibility delays dictated by the parameter WindowDuration, currently set to five seconds. The validator with the shortest assigned delay has first opportunity to produce a block; additional validators become eligible progressively if no block is produced.

Flare targets a block time of approximately 1.8 seconds and achieves single-slot finality. Once a block is accepted through the consensus process, it is considered immediately final with no block-depth requirement and no reorganisation risk.

Transaction ordering within a block is determined by the block proposer. The default behaviour applies a priority gas auction, giving precedence to transactions offering higher fee priority.

The Snowman implementation uses a Topological structure to track the strongly preferred chain branch. For each consensus round, validators report their currently preferred chain rather than a single block or binary value. Votes propagate transitively towards genesis, respecting parent-child relationships: a vote cast for a leaf block implicitly supports its parent, provided the parent has not already been finalised. Kahn's topological ordering algorithm ensures that each block is processed in correct parent-child sequence and is not processed more than once.

Validator registration is permissionless. Any node may become a validator by performing a self-bond transaction on the P-chain, linking stake to the node's unique Node ID. Registration requires staking keys consisting of a TLS certificate and private key, alongside a separate BLS signer key used for proof of possession. In the current Phase 2, validation is open to all participants meeting the minimum self-bond requirement, without restriction. To be eligible for full protocol rewards, validators must also operate a Flare Entity to contribute as a data provider.

Network-level fees

Flare Mainnet supports two transaction fee formats. Legacy transactions are priced as gas used multiplied by gas price. EIP-1559-style Type 2 transactions are priced as the sum of base fee and priority fee multiplied by gas consumed. All fees under both formats are burned on execution, permanently reducing circulating supply rather than flowing to block producers.

FIP.16, approved by governance on 24 April 2026, additionally proposes a substantial increase in the minimum base gas fee as part of a broader restructuring of FLR tokenomics. This adjustment depends on a network upgrade and is subject to phased rollout; its implementation status should be confirmed against the FIP.16 proposal and associated release notes.

Validator incentives

Validators secure the network through staking, with a minimum self-bond of 1,000,000 FLR required for registration. Validators verify transactions, participate in Snowman++ consensus and produce blocks. Full reward eligibility requires also operating a Flare Entity that actively contributes data to the Flare Time Series Oracle and Flare Data Connector protocols. A Flare Entity must remain available and performant across all Flare protocols to satisfy the minimal conditions for rewards, as introduced by FIP.10.

Protocol-level rewards are available for FTSO delegation, FLR staking and FAssets agent participation. The 36-month FlareDrop distribution, which incentivised token wrapping during the network's initial period, concluded on 30 January 2026. Protocol-level rewards for FTSO delegation, FLR staking and FAssets participation are unchanged by this conclusion.

Annual inflation was originally defined under FIP.01 on a stepped schedule: 10% of circulating supply in Year 1, 7% in Year 2 and 5% from Year 3 onwards. FIP.16, approved on 24 April 2026, restructures these parameters, targeting an annual inflation rate of 3% with an annual hard cap of 3,000,000,000 FLR following full rollout. Rollout is phased: some parameters take effect shortly after governance execution while others depend on a network hard fork and co-ordinated releases. Live supply, emissions and burn data are available via the FLR Tokenomics Dashboard.

Governance of parameters

Governance is the structured process through which the community proposes, votes on and implements changes to the network. Flare Improvement Proposals apply to Flare Mainnet, are initiated by the Flare Foundation and use Wrapped FLR and staked FLR as voting tokens. Approval requires a simple majority of cast votes exceeding 50%, with no quorum requirement. Smart-contract changes can be executed automatically via governance contract calls; proposals requiring off-chain co-ordination or complex system updates are executed by the Flare Foundation.

The Management Group is a governance body composed of eligible Flare Time Series Oracle data providers. Its original responsibilities, established under FIP.02, covered monitoring and reporting FTSO data-provider collusion and voting collectively on punitive actions against confirmed malicious providers. Following FIP.08, FIP.11 and FIP.12, its mandate expanded to include voting on new FTSO data feeds, new Flare Data Connector attestation types and adjustments to defined protocol parameters. Qualification requires active participation in the core protocols, eligibility for rewards and a clean recent conduct record.

FALSE

TRUE

Independent security reviews have been conducted of the Flare node software, core smart contracts, staking systems, Flare Systems Protocol components and data-protocol infrastructure. The Flare Developer Hub audit index groups completed reviews by protocol and component, covering validators, core smart contracts, staking, FTSO, Flare Data Connector, FAssets, Smart Accounts and associated off-chain systems. The index notes that security audits identify potential vulnerabilities at a specific point in time and do not guarantee the absence of future bugs or vulnerabilities.

The following reviews cover the node implementation, core smart contracts, staking infrastructure and Flare Systems Protocol components most directly relevant to FLR's Layer 1 operation. Additional audits of the FTSO protocol, Flare Data Connector, FAssets and Smart Accounts components are published on the Flare Developer Hub audit index.

FYEO — Secure Code Review of the Flare Network Validator Codebase — August 2022

• Object: Remote code security review of the Flare Network validator codebase. The scope covered security posture, security measures, potential issues, recommendations and validation of code against documented intended functionality.
• Results: Five findings were identified. One was high severity, concerning unrestricted calls to add_validator on permitted Node IDs. 3 were low severity, concerning unsafe file-close handling, missing length checks and discrepancies between permitted validator sets. One was informational, noting incomplete State Connector code.
• Actions: The report concluded that the reviewed code implemented the documented functionality to the extent reviewed.

FYEO — Secure Code Review of the Golang Validator on the Flare Network — February 2023

• Object: Code security review of the Golang Validator codebase from the public go-flare repository at specified commits, including a re-review commit. The methodology covered architecture review, code review against technical documentation, and use of manual methods and custom scripts, with no dynamic testing conducted.
• Results: One finding of informational severity was identified, concerning a standard function call not replaced with a DaemonCall in the GetAttestation function.
• Actions: The finding was marked as remediated.

Coinspect — Smart Contract Audit, Flare Network Launch — June 2022

• Object: Source code review of Flare Network smart contracts on the launch audit branch, with subsequent review of a final version and a version incorporating fixes. The objective was to evaluate the security of smart contracts in scope at network launch.
• Results: No high-risk or medium-risk issues were found. Five low-risk issues were identified alongside informational items.
• Actions: Several low-risk and informational items were marked as fixed. The code changes and additions in scope did not introduce security vulnerabilities to the existing system.

Coinspect — Top Level Client Source Code Security Review — May 2024

• Object: Source code review of the Top Level Client, a critical off-chain component of the Flare Systems Protocol. The Top Level Client requests data from Flare Systems Protocol subsystems, forwards it to the blockchain, monitors on-chain signature submission, relays signatures once the threshold is met and manages voter registration.
• Results: 6 findings were identified. 4 were classified as solved, comprising two high severity, one medium severity and one low severity. 2 were classified as caution-advised, comprising one medium severity and one low severity.
• Actions: Solved items were fully addressed or accepted as security posture improvements. Caution-advised items were partially addressed; their risk was not fully mitigated at the time of publication.

Coinspect — C-Chain Indexer Source Code Security Review — April 2024

• Object: Source code review of the C-chain Indexer, which interfaces with a C-chain node and stores Flare Systems Protocol-related transaction data for downstream consumption by other Flare systems.
• Results: 4 findings were identified. 2 were solved, comprising one medium severity and one low severity. Two were caution-advised, both medium severity, concerning fallback-method abuse to conceal transactions and malicious contracts simulating legitimate function signatures.
• Actions: Caution-advised items were partially addressed; their risk was not fully mitigated at the time of publication.

Coinspect — Staking Phase 2 Off-chain Services Source Code Review — November 2023

• Object: Source code review of the off-chain Mirroring Services implementing the Flare Staking Phase 2 Mirroring Protocol. The reviewed scripts voted on and mirrored staking positions, operating alongside peripheral services such as indexers and linking P-chain state with C-chain state.
• Results: seven findings were identified and all were classified as solved, comprising one high severity, two medium severity, one low severity and 3 no-risk items.
• Actions: all seven findings were resolved.

Coinspect — Staking Phase 2 Smart Contract Security Review — September 2023

• Object: Source code review of a merge request implementing the Flare Staking Phase 2 feature. The staking system mirrors P-chain operations to the C-chain, increasing P-chain stakers' C-chain balances for reward distribution using a trusted-entity voting mechanism to commit the Merkle root of P-chain transactions.
• Results: Six findings were identified, comprising 3 low-risk and 3 informational. Low-risk findings concerned insufficient protection against fabricated stake entries, unbounded mirrored stake accumulation leading to perpetual reward eligibility and zero-value mirrored stakes creating processing delays.
• Actions: All six findings were classified as solved.

Halborn — Fast Updates Go Client Security Assessment — May 2024

• Object: Security assessment of the Fast Updates Go client source code. The methodology comprised manual code review, logical issue and misimplementation testing, custom script testing, static analysis, vulnerability scanning, secure data-handling review and runtime-behaviour testing.
• Results: 1 finding of low severity was identified, concerning an unencrypted private key file. No critical, high, medium or informational findings were identified.
• Actions: The finding was resolved by encrypting the private key file with AES-GCM using a user-provided password.

Market volatility and liquidity

FLR is subject to crypto-asset market conditions including speculative demand, sentiment shifts, trading volumes, token distribution events and macroeconomic factors. Secondary market liquidity varies across venues and can narrow significantly during market stress, widening execution spreads. Changes to circulating supply, inflation rate or ecosystem incentives can affect liquidity and price discovery for buyers and sellers.

Exchange access and jurisdictional restrictions

Access to FLR on trading venues, custodians and related services is subject to venue listing decisions, exchange terms and jurisdictional restrictions. Service access may be limited, suspended or made unavailable for technical, security, legal or other reasons, which can affect users' ability to trade, access custody or interact with related services at expected times.

Irreversibility and transaction execution

FLR transactions on Flare Mainnet are final on acceptance by consensus and cannot be reversed at the protocol level. Erroneous transfers, incorrect address entry or compromised signing credentials result in permanent, unrecoverable loss. No dispute mechanism or protocol-level reversal path exists for executed transactions.

Delisting Risks

Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.

Foundation operating and structural risk

The Flare Foundation is a non-profit entity incorporated in the Netherlands and has no contractual obligation to any FLR holder. Its continued operation, funding and organisational capacity depend on its own governance and the sustainability of its token allocation and ecosystem programmes. A reduction in the Foundation's operational capacity, a change in its leadership or an inability to fund ongoing network development could affect the pace and direction of protocol development, the initiation of governance proposals and the availability of ecosystem support, without any recourse mechanism for holders. The Foundation's token allocation of 9,787,578,628 FLR is excluded from governance voting and FlareDrop claiming, meaning the Foundation's own position in the network is structurally separated from holder participation rights.

Foundation-initiated governance risk

Flare Improvement Proposals for Flare Mainnet are submitted exclusively by the Flare Foundation. Approval requires a simple majority of cast WFLR and staked FLR votes, with no minimum quorum requirement. The Foundation determines which proposals are brought forward, their scope, framing and timing. FLR holders may vote on proposals once submitted but cannot independently initiate proposals or compel the Foundation to submit, withdraw or modify any proposal. Governance outcomes, including changes to inflation, validator incentives, fee parameters and the phased rollout of provisions such as those under FIP.16, are therefore subject to the Foundation's proposal authority and sequencing decisions. The Foundation's own token allocation is excluded from voting, but the concentration of proposal initiation authority in a single entity nonetheless shapes the range of outcomes holders can influence.

Management Group discretion risk

The Flare Foundation established the FTSO Management Group through the governance process and retains the authority to expand, restrict or redefine its mandate through further Flare Improvement Proposals. The Management Group's current powers, including chilling and permanent banning of data providers for collusive or malicious conduct, were defined under FIP.02 and subsequently extended by FIP.08, FIP.11 and FIP.12. Certain categories of sanctionable conduct are deliberately left undefined in the current mandate to allow management of novel situations. This means that the scope of actionable conduct is subject to the Foundation's future governance design decisions, and changes to the mandate could affect data provider operations and delegator reward outcomes without requiring holder consent beyond a simple majority vote on any amending FIP.

Regulatory and jurisdictional exposure

The Flare Foundation operates as a non-profit entity under Netherlands law and has not obtained a licence or registration as a crypto-asset service provider, financial institution or equivalent entity in any jurisdiction. Changes in the regulatory classification of FLR, the application of financial-services legislation to the Foundation's activities, or the introduction of new jurisdiction-specific restrictions on native Layer 1 tokens could affect the Foundation's ability to continue supporting the Flare network, publishing governance proposals or administering ecosystem programmes. Regulatory action directed at the Foundation or at the Flare network more broadly, including enforcement, injunction or mandatory restructuring, could affect FLR's availability on trading venues, the continuity of protocol development and the Foundation's capacity to fulfil its stated remit. The Foundation's materials acknowledge jurisdiction-specific restrictions on certain communications, and the Foundation places responsibility on users to ensure their participation is lawful in their location, which limits the Foundation's own disclosure obligations in jurisdictions where it has not registered.

Token utility and demand dependency

FLR value depends on active demand for its protocol functions: paying transaction fees on Flare Mainnet, staking to validators, delegating to the Flare Time Series Oracle, participating in network governance and contributing collateral to the FAssets ecosystem. A sustained reduction in network usage, validator participation, oracle delegation, FAssets activity or broader ecosystem growth can reduce FLR demand and affect its market value.

Supply, inflation and distribution risk

FLR genesis supply was 100,000,000 tokens, with the initial circulating supply reduced by FIP.01. Under FIP.01, annual inflation was set at 10% in Year 1, 7% in Year 2 and 5% from Year 3. FIP.16, approved 24 April 2026, targets 3% annual inflation with a hard cap of 3,000,000,000 FLR per year and also excludes certain token pools from the inflatable supply calculation, reducing headline-rate emissions further. The 36-month FlareDrop distribution concluded on 30 January 2026. The remaining allocation schedule for team, advisor, partner and foundation tranches continues to increase circulating supply over time. FIP.16 rollout is phased and depends on a network hard fork not yet completed, meaning the governance-approved parameters are not all currently in effect.

Governance concentration and voting power risk

Governance votes on Flare Mainnet are weighted by WFLR and staked FLR balances. Of the genesis supply, 80.2% is eligible to vote whilst the Flare Foundation and Flare VC Fund allocations, representing 19.8%, are not permitted to vote. Vote power can be consolidated through delegation without transferring the underlying tokens. Concentrated balances, co-ordinated delegations or persistently low participation rates can allow a small number of holders to determine governance outcomes, including proposals affecting inflation, validator incentives, fee parameters and protocol design.

Wrapped FLR and delegation mechanics

WFLR is a wrapped ERC-20 representation of FLR used for governance voting and FTSO delegation. Delegation assigns voting power and FTSO contribution to a chosen data provider without transferring the underlying tokens, but does not guarantee reward performance. Incorrect wrapping, delegation to inactive or poorly performing providers, smart-contract interaction errors or failure to actively manage delegations across protocol changes can reduce actual rewards or governance participation, sometimes without immediate notification to the holder.

Staking lock-up and validator selection risk

FLR staked to validators is transferred from the C-chain to the P-chain and cannot be withdrawn on demand. Staking positions are subject to the duration terms, delegation caps, validator reward caps and maximum eligible-validator counts in effect at commitment time. FLR delegated to an over-subscribed or under-performing validator may earn reduced rewards or forfeit them entirely under the minimal participation conditions introduced by FIP.10. Staking conditions and parameters are subject to governance change.

Reward variability

Protocol rewards for FTSO delegation, FLR staking and FAssets participation depend on a pass-based eligibility system introduced by FIP.10. Providers gain a pass each epoch they meet all minimal conditions and lose a pass each epoch they fail any condition. A provider with zero passes that fails any condition loses all rewards for that epoch. Reward levels are further subject to inflation parameters, governance changes to reward allocation and the phased rollout of FIP.16 provisions affecting staking and data-provider fee shares. Delegators inherit the performance risk of their chosen provider.

Key custody and wallet risk

Control over FLR depends entirely on the security of the private key associated with the holder's address. Loss, theft or compromise of private keys, staking credentials, backup phrases or signing devices results in permanent, unrecoverable loss of access to FLR, staking positions, governance voting power and reward claims. Validator operators additionally hold staking key files — a TLS certificate/private key pair and a BLS signer key — whose loss can permanently lock staked FLR until the staking period expires. No recovery mechanism exists at the protocol level.

Privacy and public-chain traceability

All FLR transactions, contract interactions, staking positions, FTSO delegations and governance votes are recorded on a public blockchain and accessible via block explorers and the Flare Systems Explorer. On-chain records can be monitored, analysed and linked to addresses, enabling activity tracking, balance inference and behavioural profiling by any party with access to the public ledger. No protocol-level privacy mechanism exists for native FLR activity.

Roadmap and protocol-change execution

Flare deploys protocol changes through a staged progression from testnet to Songbird Canary-Network before Flare Mainnet. Despite this process, upgrades incorporating new consensus parameters, contract redeployments or staking-mechanic changes can introduce integration failures, delayed timelines or unexpected production-network behaviour. Several FIP.16 provisions depend on a hard fork whose date is not publicly fixed, and delays in those deployments could affect validator economics, fee structures and inflation parameters for an indeterminate period.

Information and service continuity risk

Official Flare websites, RPC endpoints, explorers, portals and third-party tooling can contain errors, experience outages or return stale data. Holders relying on a single information pathway for balance monitoring, transaction preparation or governance participation face exposure to service-level interruption that may not coincide with any failure of the Flare consensus layer itself.

Validator and data-provider operations

Full protocol reward eligibility requires validators to operate both a validator node and a Flare Entity providing active data contributions to FTSO and FDC. Under the pass-based minimal conditions system, a Flare Entity must sustain 80% uptime with at least 1,000,000 FLR active self-bond, submit FTSO anchor values within a 0.5% band in 80% of voting rounds, provide at least 80% of expected block-latency feed updates and participate correctly in 60% of FDC voting rounds per reward epoch. An entity with zero accumulated passes that fails any single condition loses all rewards for that epoch. Extended downtime, hardware failures or misconfigured data systems can cascade into complete reward forfeiture, affecting both the operator and delegators.

Off-chain systems dependency

The Flare Systems Protocol relies on a set of off-chain services — the Flare System Client, C-chain Indexer, FTSO Client, Fast Updates Client, Feed Value Provider and FDC Client — that manage private keys, interact with deployed smart contracts and submit time-sensitive protocol transactions. Failures, misconfigurations or key-management weaknesses in any of these services can interrupt FTSO submissions, FDC voting, reward aggregation or protocol finalisation. These are operational dependencies external to the on-chain consensus layer.

FDC implementation and proof-window risk

FDC attestations can only be constructed for external-chain states within the documented time window, currently no older than 14 days from the event. Proof data that is not retrieved and committed within this window cannot be retroactively recovered. Delays in data-provider availability, off-chain infrastructure failures or missed proof-construction windows can prevent smart contracts from completing operations that depend on FDC-verified external data. Applications with time-sensitive redemption, payment or settlement flows are particularly exposed.

FAssets implementation and agent dependency

FAssets minting and redemption rely on agent availability, sufficient agent collateral above governance-defined thresholds, FDC-verified payment proofs, timely underlying-chain payments and executor activity. Agent non-performance, expired FDC proofs, collateral shortfalls or failed underlying-chain payments can prevent or delay minting and redemption. If no agent responds to a redemption request within the required time limit, the process enters a default-payment or liquidation path that may produce unfavourable execution conditions for the redeemer.

Core Vault governance and custody dependency

The FAssets Core Vault is multisig-controlled and governed by Flare. Governance oversight applies to pause decisions and to return-request processes for collateral held within the vault. Return requests carry no defined maximum processing time, meaning collateral held in the Core Vault can remain unavailable for an indeterminate period if governance does not act promptly. Users relying on the Core Vault for collateral liquidity are exposed to governance inaction or delayed execution.

Third-party infrastructure and service dependency

Flare's protocol operation and user experience depend on external providers including RPC node operators, bridge infrastructure, indexers, analytics services and wallet SDKs. Flare's terms acknowledge that third-party services operate under their own terms and that Flare does not control their availability. Outages, policy changes, security incidents or service termination at any such provider can impair transaction submission, state visibility, integration functionality and user-facing access without any failure of the Flare consensus layer.

Client releases and node upgrade coordination

The go-flare client is a Flare-specific modification of Avalanche software, and release notes require node operators to upgrade before specified network dates. Failure to upgrade can result in a validator falling out of consensus, misprocessing blocks or losing block-production eligibility. Version skew between operators running incompatible client versions has the potential to affect network-wide reliability during transition windows. Backup of staking key files before upgrades is required to preserve validator identity; omitting this step can lead to permanent loss of a validator's Node ID if the host is replaced.

FIP.16 incomplete rollout risk

Several provisions of FIP.16, approved by governance on 24 April 2026 with 98.06% of cast votes, are not yet live on Flare Mainnet. These include a substantial increase in the minimum base gas fee, the Flare Income Reinvestment Entity framework for routing protocol revenue, protocol-owned block building and MEV capture, and revised P-chain staking economics with a minimum 20% infrastructure provider fee share. Holders and participants may have expectations based on the approved proposal that are not met by the current live network state. Rollout depends on the v1.13.0 node upgrade, a subsequent fee increase and associated contract redeployments, each of which may be delayed or introduce complications.

Legal recourse and liability limitation

Flare's terms of service include a mandatory arbitration clause, limitations on liability and reserved rights to modify or discontinue services without notice. Holders may have limited procedural recourse for disputes related to service availability, information accuracy or the exercise of contractual rights, and may not be able to pursue claims through ordinary court processes in their jurisdiction.

FAssets emergency-pause and transfer-restriction risk

FAssets incorporate a three-level emergency pause mechanism. A start-operations pause prevents new minting. A full pause halts all FAsset operations. A full-and-transfer pause freezes all FAsset movement. These controls can be exercised during upgrades, critical security incidents, regulatory requirements or protocol failures. Holders of FAssets can face inability to transfer, redeem or interact with FAsset positions for the duration of any active pause, with no guaranteed timeframe for resumption.

Consensus and validator-layer risk

Flare uses Snowman++ Byzantine fault-tolerant consensus with stake-weighted proposer selection. The protocol can tolerate a bounded proportion of faulty or adversarial validators, but faults above the tolerance threshold, network partitions, divergent client versions or implementation defects in go-flare can affect transaction inclusion, block production or network liveness. Stake concentration among a small number of validators increases the impact of any single operator failure or targeted attack.

Transaction ordering and MEV risk

Within each block, transaction ordering is determined solely by the block proposer. The default behaviour applies a priority gas auction, allowing proposers to reorder, delay or selectively exclude pending transactions to maximise fee income or extract additional economic value. Users can face front-running, sandwich execution or censorship of individual transactions by a validator holding the proposer role for the relevant block. FIP.16 §4.4 describes protocol-owned block building and MEV capture as a future roadmap item, but no on-chain MEV-mitigation mechanism is currently live on Flare Mainnet.

Client and software implementation risk

The go-flare client combines upstream Avalanche components with Flare-specific modifications including prioritised contract handling and daemon contract invocation. Bugs, dependency vulnerabilities or incorrect configuration in either layer can disrupt validator operation, break node synchronisation or impair transaction processing. Upstream Avalanche releases introduce version dependencies that may require timely co-ordinated upgrades to avoid compatibility failures.

FTSO oracle risk

The Flare Time Series Oracle uses approximately one hundred independent data providers, stake-weighted Verifiable Random Function sampling, a commit-reveal mechanism and anchor feeds to produce price data. Feed instability, provider collusion or cartelisation, stale data submissions, extreme market volatility or an insufficient number of active providers can produce inaccurate or delayed price feeds. Applications and smart contracts that accept FTSO values without independent validation inherit this oracle risk directly into their price-dependent logic.

FDC attestation and data-availability risk

The Flare Data Connector validates external blockchain state through attestation rounds requiring more than 50% signature weight from active data providers. Conflicting attestations, unavailable off-chain proof data, divergent Merkle roots between providers or insufficient provider support can leave an attestation round unresolvable, preventing contracts from receiving the verified external-chain data they require. Incorrect attestations by a majority of providers would produce incorrect Merkle roots stored on-chain with no automatic correction path.

Smart-contract and upgradeability risk

Flare protocol services depend on deployed smart contracts including FSP contracts, FTSO contracts, FDC contracts and FAssets contracts. Design defects, access-control errors, reentrancy vulnerabilities, incorrect upgrade execution or errors in contract-address resolution can affect reward distribution, attestation processing, token-related services or FAssets operations. Contract upgrades executed via governance proposals introduce additional risk of unintended state changes or logic errors that take effect on-chain before being widely detected.

FAssets collateral and liquidation risk

FAssets depend on agent over-collateralisation, FTSO-sourced collateral pricing, automated liquidation triggers and challenger monitoring for illegal underlying-chain operations. Large or rapid price movements can breach collateral ratios before liquidators act, and in extreme scenarios liquidation may not be economically profitable, leaving the protocol exposed to under-collateralised positions. Oracle price lag relative to real-time market conditions creates windows in which collateral ratios are calculated on stale values, increasing the risk of delayed liquidation.

Bridge and cross-chain messaging risk

FXRP and related FAssets can use cross-chain mechanisms including FDC-verified underlying-chain payments and LayerZero OFT messaging with decentralised verifier networks. Bridge faults, message-relay failures, supply desynchronisation between chains, verifier network unavailability or destination-chain failures can prevent or delay cross-chain asset movement and create discrepancies between represented and actual underlying asset balances.

Infrastructure, RPC and explorer risk

Users and applications rely on RPC endpoints, block explorers, systems explorers, indexers and data APIs to read Flare network state and submit transactions. Rate limits, service outages, data-parsing errors, stale block data or inconsistent responses across multiple RPC providers can impair state visibility, transaction construction and application functionality even where Flare consensus continues operating normally. No protocol-level guarantee of RPC service availability exists.

Quantum computing risk

Flare Mainnet uses ECDSA over secp256k1 for account address derivation and transaction signing, inheriting the Ethereum cryptographic architecture. ECDSA is vulnerable to attack by a sufficiently powerful quantum computer using Shor's algorithm, which could reconstruct a private key from its exposed public key, enabling unauthorised control of any address whose public key appears on-chain. Validator staking keys incorporate BLS signatures for proof of possession, which rely on pairing-based elliptic-curve cryptography that is equally susceptible to quantum attacks using Shor's algorithm on the underlying pairing groups. Keccak-256 hashing used in address derivation and block commitments is relatively more resistant due to Grover's algorithm providing only a quadratic speedup, but this does not address the account-key vulnerability. No post-quantum migration pathway has been publicly documented for Flare Mainnet. This risk is prospective, shared across all EVM-compatible networks and without a known near-term threat, but the absence of a confirmed migration roadmap means it is currently unmitigated at the protocol level.

Issuer-Related Risks

• Foundation-initiated governance risk: The Flare Foundation and Flare VC Fund allocations, totalling 19.8% of genesis supply, are excluded from voting on Flare Improvement Proposals. Approval of any FIP requires a simple majority of cast WFLR and staked FLR votes, separating proposal initiation from approval authority. Smart-contract changes approved by governance can execute automatically via on-chain governance calls, reducing reliance on manual Foundation execution.
• Management Group discretion risk: Management Group punitive actions, including chilling and permanent banning of data providers, are subject to a defined governance process requiring a collective vote by eligible Management Group members rather than unilateral enforcement. Decisions are implemented through governance contract calls or Flare Foundation execution depending on the nature of the action.

Crypto-Assets-Related Risks

• Supply, inflation and distribution risk: All FLR transaction fees are burned on execution, providing an automatic and continuous deflationary offset to inflation. FIP.16 reduces the annual inflation rate from 5% to 3% and introduces a hard cap of 3,000,000,000 FLR per year, constraining maximum supply expansion once the relevant network upgrade is completed. Excluded token pools — including the burn address and FIRE pools — are removed from the inflatable supply base, further reducing realised inflation versus headline rates.
• Governance concentration and voting power risk: The Flare Foundation and Flare VC Fund are structurally excluded from voting on Flare Mainnet proposals, removing 19.8% of genesis supply from governance influence. Voting weight is proportional to WFLR and staked FLR balances at the Vote Count Block snapshot, and vote power can be transferred to a designated address without moving the underlying tokens, distributing participation opportunities across the holder base.
• Staking lock-up and validator selection risk: Validator staking parameters define a delegation factor limiting total delegated stake per validator, a cap on reward shares per validator and a maximum number of validators eligible for rewards per epoch. These parameters constrain excessive concentration of staked FLR with a single validator and set transparent boundaries on staking return calculations.
• Reward variability: The pass-based minimal conditions system creates direct accountability for data providers. Providers gain a pass for meeting all participation requirements in a reward epoch and lose a pass for failing any requirement. A provider with zero passes who fails any minimal condition loses all rewards for that epoch, aligning financial incentives with sustained availability and performance. Minimum requirements are quantitatively defined: 80% uptime and 1,000,000 FLR self-bond for staking, 80% of voting rounds within the 0.5% FTSO band, 80% of expected block-latency submissions and 60% of FDC voting rounds.
• Key custody and wallet risk: Validator staking key files — a TLS certificate/private key pair constituting the Node ID and a BLS signer key for proof of possession — must be backed up to a persistent location separate from the node before registration or upgrade. Hardware-based signing is available for account transactions, keeping private keys off internet-connected systems and reducing online exposure. These requirements are technical prerequisites for validator operation rather than optional guidance.

Project Implementation-Related Risks

• Validator and data-provider operations: The pass-based reward system creates measurable financial consequences for operational failures. Loss of all rewards in an epoch occurs when a provider with zero accumulated passes fails any single minimal condition, making sustained uptime and protocol participation directly tied to economic outcomes for both operators and their delegators.
• Off-chain systems dependency: The Flare System Client, C-chain Indexer and staking mirroring services have each been subject to independent security audits. Identified findings, including high-severity key-management and availability issues, were tracked by severity and remediation status. An Immunefi bug-bounty program has been in operation since July 2024, covering protocol-critical vulnerabilities with rewards for findings including validator key exfiltration and network disruption.
• FAssets implementation and agent dependency: FAssets agents must maintain collateral above governance-defined thresholds enforced by smart contracts. Collateral is locked and inaccessible to agents during active FAsset positions. FDC payment proofs are required to confirm underlying-chain transactions before minting completes. Liquidation mechanics with economic incentives for third-party liquidators activate before the safety collateral threshold is breached, providing a buffer period during which profitable collateral recovery is expected.
• Roadmap and protocol-change execution, and client releases: Protocol changes are deployed through staged environments: Songbird Testnet Coston, then Songbird Canary-Network, then Flare Testnet Coston2 before Flare Mainnet. This progression allows protocol failures to surface before production. Release instructions require validator key backups before any version transition, reducing the risk of permanent identity loss during upgrades.
• FAssets emergency-pause and transfer-restriction risk: The FAssets pause mechanism provides graduated controls proportionate to the severity of the triggering event. A start-operations pause restricts new minting only, a full pause halts all FAsset operations and a full-and-transfer pause freezes all movement. This hierarchy allows targeted restrictions without triggering a complete freeze unless the situation warrants it.

Technology-Related Risks

• Consensus and validator-layer risk, and client and software implementation risk: Multiple independent security reviews have been conducted of the Flare validator codebase, the Golang validator client and Avalanche-version upgrade transitions. Identified findings were tracked and remediated. The Immunefi bug-bounty program includes blockchain and DLT critical impacts within scope, with USD 100,000 rewards for total network shutdown, permanent chain split, permanent fund freeze and validator TLS or BLS key exfiltration without direct machine access. All submissions require a proof of concept.
• FTSO oracle risk: FTSO employs approximately one hundred independent data providers, stake-weighted VRF sampling for commit-reveal participation, anchor feeds tracking a broader baseline for cross-validation, and volatility incentives that penalise outlier submissions. Feed stability is monitored using a defined 0.2% deviation band metric. Provider misconduct including collusion is subject to Management Group oversight with defined chilling and banning procedures.
• FDC attestation and data-availability risk: FDC requires more than 50% signature weight from active data providers to finalise each attestation round. The resulting Merkle root is stored on-chain and is independently verifiable against individual FDC proofs through the published verification interface, allowing contracts to validate attested data without trusting any single provider.
• Smart-contract and upgradeability risk: Protocol contract addresses are discoverable through the Flare Contracts Registry, the designated on-chain source for current deployed addresses, reducing the risk of interacting with outdated or incorrectly substituted contracts. Independent audits have been completed across FAssets, FTSO, FDC, staking and core protocol components, with findings tracked by severity and remediation status across multiple auditors including Coinspect, Halborn, Zellic and OpenZeppelin.
• FAssets collateral and liquidation risk: Agent collateral is locked in smart contracts and cannot be withdrawn during active FAsset positions. Governance-set collateral-ratio thresholds with distinct safety and liquidation bands define the trigger conditions for liquidation, providing a buffer between normal operation and solvency-impairment events. Liquidator economic incentives activate before the safety threshold is breached. Challenger monitoring creates incentives for third parties to identify and report illegal underlying-chain payments, further reducing the window in which protocol violations persist undetected.
• Bridge and cross-chain messaging risk: FXRP OFT uses LayerZero messaging with decentralised verifier networks for cross-chain message integrity verification, avoiding reliance on a single centralised relay. FAssets use FDC verification of underlying-chain activity, requiring more than 50% attestation weight before accepting external chain events on-chain. These dual verification layers provide cryptographic assurance for cross-chain operations independent of bridge operator behaviour.
• Bug bounty program: An Immunefi bug-bounty program covering Flare's blockchain infrastructure, smart contracts and web applications has been in operation since 16 July 2024. Maximum rewards reach USD 100,000 for critical blockchain/DLT impacts and USD 125,000 for critical smart-contract impacts. All submissions require a proof of concept. The program is triaged by Immunefi with arbitration available for contested reports.

Bitstamp Europe S.A.

549300XIBGTJ0PLIEO72

Flare

Flare Mainnet runs Snowman++, a Byzantine fault-tolerant consensus protocol from the Avalanche Snow family of probabilistic protocols, operating on both the P-chain and C-chain. Byzantine fault tolerance means the protocol continues to reach correct agreement when a bounded proportion of participating validators behave incorrectly or adversarially within the protocol's assumptions.

Proof-of-Stake is the Sybil-resistance mechanism. Validators must hold a minimum self-bond of 1,000,000 FLR on the P-chain to participate in consensus. Delegation is handled in-protocol, and validator selection for block proposal is weighted by total stake, comprising each validator's self-bond plus any stake delegated to it.

Snowman++ introduces a soft proposer mechanism. At each block height, a fixed number of validators is sampled using stake-weighted selection without replacement. This number is governed by the protocol parameter maxWindows, currently set to six. Sampled validators are assigned time-based eligibility delays dictated by the parameter WindowDuration, currently set to five seconds. The validator with the shortest assigned delay has first opportunity to produce a block; additional validators become eligible progressively if no block is produced.

Flare targets a block time of approximately 1.8 seconds and achieves single-slot finality. Once a block is accepted through the consensus process, it is considered immediately final with no block-depth requirement and no reorganisation risk.

Transaction ordering within a block is determined by the block proposer. The default behaviour applies a priority gas auction, giving precedence to transactions offering higher fee priority.

The Snowman implementation uses a Topological structure to track the strongly preferred chain branch. For each consensus round, validators report their currently preferred chain rather than a single block or binary value. Votes propagate transitively towards genesis, respecting parent-child relationships: a vote cast for a leaf block implicitly supports its parent, provided the parent has not already been finalised. Kahn's topological ordering algorithm ensures that each block is processed in correct parent-child sequence and is not processed more than once.

Validator registration is permissionless. Any node may become a validator by performing a self-bond transaction on the P-chain, linking stake to the node's unique Node ID. Registration requires staking keys consisting of a TLS certificate and private key, alongside a separate BLS signer key used for proof of possession. In the current Phase 2, validation is open to all participants meeting the minimum self-bond requirement, without restriction. To be eligible for full protocol rewards, validators must also operate a Flare Entity to contribute as a data provider.

See H.5

2026-01-01

2026-06-02

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at : www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Land use: 2693.05556 m²

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Estimates on individual node weight, hazardous components and depreciation rate are used.
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Usage of natural resources is approximated through land use metrics. Land use, water use and water recycling are calculated based on energy mix-specific estimates of purchased electricity land intensity, purchased electricity water intensity, and water recycling rates.
Full methodology available at: www.micacryptoalliance.com/methodologies