Chapter 1:
An Introduction To Flare
Chapter 1: An Introduction To Flare
What is Flare?
Flare is the blockchain for data.
It is a Layer 1 like Ethereum, with added data acquisition functionality. Flare can therefore offer developers decentralized access to high-integrity data from other chains and the internet. This enables the creation of dapps with new use cases and monetization models. It also allows these dapps to serve multiple chains through a single deployment.
Flare is Ethereum Virtual Machine (EVM) based, meaning any applications written in Solidity to run on any other EVM chain can also be used on Flare.
What problem is Flare trying to solve?
We believe that blockchain-based dapps have to be more relevant and useful to the broader population if we are to see the industry truly grow.
One of the key constraints is the limited variety of decentralized data available on-chain, which makes it difficult to build dapps that can have a genuine role in people’s lives. This is why the majority of current DeFi use cases are focused on financial speculation rather than anything connected to the real world.
Flare’s mission is to make blockchain more useful by providing dapp builders with secure access to a greater variety of decentralized data. This will enable the creation of new types of dapps that are more relevant to more people, driving wider adoption and usage of blockchain technology.
What is unique about Flare’s technology?
Flare has two data acquisition protocols which are secured by the Layer 1 network.
They are native to Flare, so developers don’t need to rely on other third party data oracle solutions, which can be centralized and expensive.
The Flare Time Series Oracle (FTSO) delivers highly-decentralized time series data feeds to dapps on Flare. Currently, the FTSO provides digital asset price pairs and updates every 3 mins.
The State Connector enables Flare to safely and trustlessly come to consensus over an event that has taken place externally to the network, for example a blockchain transaction between two parties or the content of an API on the internet.
Together, these protocols give developers decentralized access to high-integrity data from other chains and the internet. That’s why we call Flare the blockchain for data.
Both the State Connector and FTSO are used in the recent demonstration of purchasing an NFT on Flare using the token of a different blockchain.
Chapter 2:
Native Data Acquisition Protocols
Chapter 2: Native Data Acquisition Protocols
The State Connector
The State Connector enables off-chain event data to be brought on-chain and used by dapps. This is data that can not change, such as whether a transaction has happened on a different blockchain, or a sporting result held in a web2 database.
It does this in a decentralized manner with independent attestation providers needing to come to consensus on the data before it is made available on the network. To our knowledge no other oracle currently does this.
An example use of the State Connector is to verify whether a transaction has taken place on another blockchain, such as whether 1 Bitcoin has been transferred from address A to address B.
The Flare Time Series Oracle
The FTSO is a highly-decentralized protocol for safely retrieving external time series data for use on Flare, such as digital asset price pairs. It takes data at predetermined intervals (currently 3 minutes) from an independent network of data providers, which are incentivized to deliver accurate data.
The FTSO system computes an estimate for each time series and makes it available for any user or application to request. This data can be used for any number of use cases, such as asset prices in a decentralized lending protocol.
Approximately 100 independent data providers are incentivized by the network to deliver this information accurately. The rewards that each data provider receives for successful provision of decentralized data are then shared with all token holders that have delegated to them.
The website FlareMetrics.io provides statistics on the performance of all of the network’s data providers.
Chapter 3:
Using FLR Tokens
Chapter 3: Using FLR Tokens
Delegating to the FTSO
Delegation is the temporary assignment of your FLR or SGB tokens to Flare Time Series Oracle data providers to support the delivery of decentralized data to the network. The tokens can be undelegated at any time, and they are not locked from being used for other purposes.
Token holders receive a share of the rewards earned by the data providers they have delegated to. The more accurate a data provider’s submissions and the larger the number of tokens delegated to them, the more rewards they receive and are able to share with their delegators. This creates a positive feedback loop incentivizing the provision of accurate data, whereby the most successful data providers will attract the most delegations.
Flare FTSO Delegation Rewards can be claimed every 3.5 days, while Songbird rewards are claimable once a week.
To help with the decision on which data providers to delegate to, websites like FlareMetrics.io include performance statistics.
Staking to Flare Validators
Flare is transitioning to a staking model in three phases. Now phase two has been reached, it is possible for anyone to delegate stake to validators on the network. This can be done using the new staking tool found at https://staking.flare.network. There is also a Command Line Interface (CLI) version for developers and more advanced users.
When a token holder delegates FLR to a Flare validator, their FLR are locked for a period of time. Participants choose how much stake to delegate and for how long their stake will be locked. The minimum stake that can be delegated is 50k FLR and the shortest staking period permitted is 14 days.
Read the how-to guide in the technical docs for step by step instructions on using the new staking tool.
FlareDrops
24.2 billion FLR are being provided to anyone who holds WFLR in 36 monthly FlareDrops. The first FlareDrop was 17 March 2023, when approximately 670 million FLR were claimed by WFLR holders.
It is likely that token holders will need to move their FLR tokens off exchange and into a software or hardware wallet to be able to wrap them into WFLR.
Wrapped FLR
FLR is the native token used for payments and transaction fees. FLR can also be wrapped into an ERC-20 variant, WFLR. WFLR tokens have additional functionality and can be delegated to FTSO data providers or used to participate in network governance. These two uses are not mutually exclusive and do not prevent the tokens from being used in other EVM-compatible dapps and smart contracts on Flare.
Tokens can be wrapped natively in Bifrost Wallet, or by connecting to the Flare Portal when using a different hardware or software wallet.
Autoclaiming
Both the FlareDrops and FTSO Delegation Rewards can be automatically claimed and wrapped to maximize compounding. This feature will also be available on Songbird in the near future.
Songbird
Songbird is the canary network for Flare. It is an operational blockchain with a defined token supply that allows new features or applications to be tested under production conditions before they are deployed on the main network. This is in contrast to a testnet which generally has an unlimited token supply.
Governance
Governance on Flare originates from two primary sources. First, the Flare Foundation can submit governance proposals for the Flare mainnet and Songbird canary network, which FLR and SGB token holders can vote upon. Second, future developments will implement a bicameral system where SGB token holders can submit and vote upon governance proposals for the Songbird network with the intention of them being advanced as Flare Improvement Proposals if they are successful.
Proposals are visible in the Proposals Repository and when active can be voted on using the Flare Portal.
Ecosystem partners
Flare.Builders is a third party catalogue of the different projects being built on the Flare and Songbird networks.
