30th March 2022
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. LayerCake: 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. LayerCake enables the use of FAssets on Flare as well as any chain integrated with Flare via a LayerCake bridge.
3. Relay: Safely relay any information, including off-chain data, 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 over the coming months for developers looking to help scale the ecosystem.
The State Connector has now been fully deployed on Songbird. Over the next couple of weeks the decentralized consensus model will also be rolled out and validation will incrementally shift from its current model to being run entirely by the FTSO providers. This brings the project to the point at which it is possible to launch Flare. To mitigate Flare launch technical glitch risks, an audit with Trail of Bits, one of the most reputable firms in the space, has been booked to start on May 16th. This will run for three weeks and provided no issues are found, Flare will aim to launch on July 4th. The team will confirm this date in mid June when the audit completes.
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: LayerCake Bridges Batch 1 Launch: The first batch of LayerCake 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: LayerCake Bridges Batch 2 Launch: The second batch of LayerCake bridges. These will focus on connecting Flare to all major smart contract chains and connecting key smart contract chains to each other.
If any issues are identified in the audit, these will be publicly reported immediately, provided they do not pose a risk to Songbird. In the case issues are deemed to jeopardize network security on Songbird they will be reported as soon as a fix has been deployed on Songbird.
The team is also working on a governance proposal to introduce SGB as part of the Flare governance mechanism. Whilst not limited to, it will include: 1) An SGB bonding system over the governance of the build of bridges between Flare and networks below the top 75 by market capitalization. The aim of this is to provide a mechanism to signal which bridges in this category to build and in what order, through choosing those with the most bonded SGB. 2) An SGB bonding system for community generated governance proposals. Again the aim here is to sort through governance proposals by creating a priority mechanism based on bonded SGB.
Both mechanisms will include economic incentives in FLR accruable to those that bonded their SGB to the winning proposals over bridges and governance. The finer details are still being worked on to avoid any unintended economic incentives.
All of us at Flare look forward to delivering the cross-chain future and building out this ecosystem. The first community call will be held in late April.