Flare Rollout Process

Flare Rollout Process

In 2020 we set out to build a chain that would allow a few tokens from early L1’s to be used with smart contracts. This is not the Flare that we will be delivering.

Through extensive additional engineering and research, we have further developed our initial ideas and protocols to build something much more exciting.

Flare enables a breakthrough in decentralized cross-chain functionality. Existing solutions are unsatisfactory: As an example, the reality of token bridging is that almost all existing systems are heavily centralized. These bridges are essentially a digital adaptation of the historical banking model, thus they actually control your tokens whilst being unregulated. Those that are genuinely decentralized are constrained to use an existing method of communication, the light client relay, that forces a choice between being slow or unsafe.

Furthermore, light client relays do not work with all consensus protocols (e.g. probabilistic-finality BFT) and suffer from being incompatible with optimized smart contracts that are written outside of a blockchain's virtual machine environment. Such optimized smart contracts are increasingly being used.

When Flare launches, it will be a technologically advanced cross-chain interoperability network that answers many of the issues inherent in the space today. It will enable a safer and properly decentralized cross-chain future. Nothing else we are aware of comes anywhere close.

With Flare’s open protocols, developers are given the tools to build an extensive array of interoperability solutions.

Flare is building three core interoperability products:

1. FAssets: Providing non-smart contract chain tokens (e.g. $BTC, $XRP, $LTC, $ALGO, $DOGE and others) with smart contract functionality on Flare.

2. Layer Cake: Safe, genuinely decentralized bridges between smart contract platforms, both to and from Flare (e.g. Flare and Solana) and also between 3rd party chains (e.g. Ethereum and Solana) secured by Flare. Layer Cake enables the use of FAssets on Flare as well as any chain integrated with Flare via a Layer Cake bridge.

3. Relay: Safely relay any information between any set of chains secured by the State Connector. This gives developers total decentralized dApp composability, all secured by Flare. As an example of this system we will be setting up a relay of the FTSO prices to Solana.

Again - nothing comes close to what we are building with Flare. This is why our strapline has changed to “Connect Everything”.

The initial rollouts of these three products will be coordinated by Flare for specific chains of key importance. To meet anticipated demand, we will also be launching an incentive program for developers to expand the connectivity of the Flare ecosystem. Bridges and relays based on Flare’s defined product model (above) will be built by 3rd parties and certified by Flare. We will be launching the Flare Foundation Grants Program for developers looking to help scale the ecosystem.

Anticipated order of events on Songbird


SB01: State Connector Activation: Completed.

SB02: Updated consensus activation: To be initiated over the next couple of weeks.

SB03: State Connector Client Release: Release of an example client side package for the State Connector. This allows State Connector attestors to correctly submit events to the State Connector system. Anyone can build a client side, Flare is simply releasing a reference implementation.

SB04: FAsset A Launch: This version of the FAsset system enforces the Agent to hold 100% of the underlying token on the underlying chain. This allows for a lower collateral ratio on Flare than 2.5X. This is the version of the FAsset system that will most likely be used for “Self Minting”.

SB05: Layer Cake Bridges Batch 1 Launch: The first batch of Layer Cake bridges, likely with Terra & either Ethereum or Solana.

SB06:  FAsset B Launch: This version of the FAsset system uses a 2.5X collateral ratio on Flare, but allows the agent to hold less than 100% of the tokens on the underlying chain.

SB07: FTSO Performance Upgrade: The FTSO system will undergo optimizations with the aim of increasing both the number of possible price series and the number of possible data providers into the 1000’s.

All major changes to existing systems, such as upgrading the FTSO, will be subject to Songbird governance.

Anticipated order of events on Flare

Several key events here have the same definitions as above, so won’t be repeated. Please reference the Songbird section for details on FL03, FL05, FL06 & FL07.


FL01: Flare Launch: Main network launch and distribution of the initial 15% of tokens.

FL02: Governance Update On Token Distribution: The team has been working on a governance proposal regarding the token distribution. The proposal intends to achieve three things:

1) Remove the risk of an exchange failing to pass on future token distributions.

2) Substantially increase the incentive to engage with the network.

3) Provide positive tax implications such that a majority of recipients can avoid generating a taxable event until they claim their token allocations and withdraw them from the system. This would give the recipient autonomy for when they wish to trigger a tax event.

The governance vote for this proposal will only take place once 75% of the initial 15% distribution is freely available to take part in the governance vote. In the case of exchanges, this means that the token will have been distributed and can be withdrawn from the exchange. The proposal details will be published with ample advance warning before Flare launches.

FL04: Songbird Bridge Launch: This will allow all Songbird tokens to be bridged to Flare and vice versa.

FL08: Layer Cake Bridges Batch 2 Launch: The second batch of Layer Cake bridges. These will focus on connecting Flare to all major smart contract chains and connecting key smart contract chains to each other.

Learn more about:

> State Connector

> Flare Time Series Oracle

> Layer Cake

> FAssets