Flare is a Layer 1, Ethereum Virtual Machine (EVM)-compatible blockchain specifically engineered to empower developers. It enables applications to seamlessly interconnect with various blockchains and the broader Internet, opening up new possibilities for decentralized monetization and high-integrity data solutions. At its core, Flare provides decentralized access to reliable external data, allowing developers to build next-generation applications that are both interoperable and data-rich.
How Does Flare Blockchain Work?
Flare’s architecture is designed for security, scalability, and decentralization. It combines innovative oracle systems with a robust consensus mechanism to create a trusted environment for smart contracts.
Consensus and Network Security
Flare utilizes a proof-of-stake (PoS) consensus mechanism built on Avalanche’s Snowman++ protocol. This ensures high throughput and fast finality for transactions. The native token, FLR, is integral to network operations. It is used for paying transaction fees, staking by validator nodes to secure the network, and providing collateral within the ecosystem.
Acquiring External Data: FTSO and State Connector
A standout feature of Flare is its native ability to bring reliable, real-world data on-chain through two key protocols: the Flare Time Series Oracle (FTSO) and the State Connector.
The Flare Time Series Oracle (FTSO) is a fully decentralized system that provides time-series data, such as cryptocurrency price feeds. It gathers data at regular intervals from an independent network of data providers who are incentivized based on the accuracy of their data. FLR token holders participate by wrapping their tokens into WFLR (an ERC-20 token) and delegating them to these providers. In return, they earn rewards, creating a system that continuously encourages the provision of high-quality data.
The State Connector is a revolutionary protocol that allows the Flare network to securely reach consensus on events happening outside of its own environment. This could be a transaction on another blockchain or data from a traditional web API. It uses a Request-Commit-Reveal (RCR) protocol combined with a branching mechanism.
- Request-Commit-Reveal: User requests for external data are batched into rounds. These are sent to attestation providers who retrieve the data and submit cryptographic proofs of its validity.
- Branching Protocol: Each validator node maintains a list of trusted attestation providers. If a node receives data that conflicts with the network's consensus, it will fork and halt until the discrepancy is resolved, ensuring unparalleled data integrity.
Together, these systems enable smart contracts on Flare to operate based on high-fidelity external information without relying on centralized sources.
Governance and the Canary Network
Flare features a decentralized governance model. The Flare Foundation can propose changes to the mainnet, which are then voted on by FLR stakeholders. Furthermore, Flare operates a real-world testing environment called the Songbird canary network.
Songbird is an experimental network with its own token (SGB). It allows developers to test new features and upgrades under real economic conditions before they are proposed for the mainnet. SGB holders can participate in the governance of Songbird, and successful proposals may later be elevated as Flare Improvement Proposals (FIPs) for a mainnet vote.
What Makes Flare Unique?
Flare’s uniqueness stems from its native integration of decentralized data acquisition protocols. Unlike many blockchains that rely on third-party oracle solutions, the State Connector and FTSO are secured by the Flare network itself. This native approach provides several key advantages:
- Enhanced Security: The oracle systems are protected by the same consensus mechanism that secures the network, reducing attack vectors.
- Decentralized Data Sourcing: By incentivizing a broad network of independent data providers, Flare avoids the pitfalls of relying on a single source of truth.
- Developer Empowerment: It enables a new class of "loosely coupled" applications that can freely interact with data across multiple chains and the internet, fostering immense innovation.
This architecture positions Flare as a foundational layer for the next wave of cross-chain decentralized applications (dApps). For developers ready to start building, the resources available can significantly accelerate the process. You can explore the developer documentation and tools to begin experimenting on the network.
Exploring the Flare Ecosystem
The Flare ecosystem is a vibrant and growing universe of components and participants that support the network's functionality and growth. Key elements include:
- Flare Wallet: Software for users to store, send, receive, and stake FLR tokens.
- Flare Block Explorer: A tool for viewing transactions, blocks, and network activity.
- FLR Token: The native asset used for fees, staking, and governance.
- Flare Portal: A gateway for users to interact with dApps, stake tokens, and delegate to FTSO data providers.
- Node Operators: Entities that run validator nodes (for consensus) or non-validating observer nodes (for relaying transactions and data).
- dApps and Data Providers: The essential builders and service providers creating applications and supplying data to the network.
The ecosystem also encompasses the Songbird canary network and its testnets (Coston and Coston2), which mirror the mainnet's structure for development and testing purposes.
The FLR Token: Uses and Functionality
The FLR token is the lifeblood of the Flare network, serving multiple critical purposes:
- Network Fees: FLR is used to pay for transaction and smart contract execution fees.
- Staking: Validators must stake FLR to participate in block production and network consensus, earning rewards for their services.
- Collateral: FLR can be used as collateral within various dApps built on the Flare network.
Wrapping (WFLR): Native FLR can be wrapped into WFLR, an ERC-20 token. WFLR unlocks additional functionalities:
- FTSO Delegation: It can be delegated to data providers to earn rewards.
- Governance: It grants holders voting rights in network governance proposals.
The creation of WFLR is a straightforward process where users deposit native FLR into a smart contract and receive an equivalent amount of WFLR in return. This wrapped token remains fully compatible with all other EVM-based applications on Flare.
Frequently Asked Questions
What is the primary goal of the Flare blockchain?
Flare aims to solve blockchain interoperability and secure data access. It is built as a Layer 1 solution that allows smart contracts to securely and trustlessly use data from other blockchains and the internet, enabling new use cases and monetization models for developers.
How does Flare ensure the data from its oracles is accurate?
The FTSO uses a decentralized network of competing data providers who are incentivized to provide accurate data through a reward system based on quality. The State Connector uses a cryptographic consensus process among attestation providers, with a branching protocol that safeguards against incorrect data being accepted by the network.
What is the difference between Flare and Songbird?
Flare is the main production blockchain network. Songbird is its canary network—an experimental, real-value environment used to test new features, upgrades, and governance models under real economic conditions before they are deployed on the mainnet.
Do I need to wrap my FLR tokens (into WFLR)?
You only need to wrap your FLR tokens if you wish to participate in specific activities like delegating to an FTSO data provider to earn rewards or engaging in on-chain governance voting. For simple holding or transferring, it is not necessary.
Can developers from other blockchain ecosystems build on Flare?
Yes. Since Flare is EVM-compatible, developers familiar with Ethereum, Avalanche, Polygon, and other EVM-based chains can easily port their applications over to Flare using familiar tools like Solidity and MetaMask.
What are the risks of delegating to an FTSO data provider?
The primary risk is that the provider performs poorly, which could result in lower rewards than expected. There is no risk of losing your staked principal (WFLR) through delegation, as the tokens remain in your custody and are never transferred to the provider.