We are excited to release our updated plans on the development and launch of Flare. At Flare we have been conducting extensive testing of the network and the various core Flare protocols that are intended to provide utility. Our testing has now reached a point with many elements where little more can be understood from further testing on an isolated test network. We will now progress to live testing on an operational blockchain in an adversarial environment. In the next 6 weeks we will be releasing a “Canary” network for Flare called Songbird.
What is a Canary Network?
A “Canary network” is an operational blockchain with a defined (and hence scarce) token supply that is intended to be used to test features for a related main net. On a Canary network users have a balance that cannot just be replenished at will. This is in contrast to a testnet which generally has an unlimited token supply available in increments to any user through a faucet.
The defined and scarce token supply may confer value to the token, potentially making it attractive to attackers such that testing is as “real” as it can possibly get. This allows for the hardening of the system under testing. Polkadot is the originator of the Canary network concept, with their Kusama Network.
What is the purpose of Songbird?
Songbird is the Canary network for Flare, it will have two distinct phases. Prior to the launch of Flare, Songbird will be instrumental in the continued testing of the Flare Time Series Oracle, the StateConnector and F-Asset systems and the network architecture. The FTSO and F-Asset protocols will be live on Songbird with F-Assets generated from the underlying tokens.This will improve the security, stability and credibility for the ultimate launch of Flare.
Post Flare launch, Songbird is intended to be a long term network for testing governance led changes to Flare, such as the incorporation of new F-Assets, changes to the FTSO, F-Asset systems or any other network change.
In all periods Songbird has two other core uses. First, advanced testing and community building for applications that wish to launch on Flare. Ideally all applications that launch on Flare, especially those that utilize the FTSO and F-Asset systems will test initially on Songbird. Second, as a way for FLR token holders to familiarize themselves with key Flare protocols such as delegation to the FTSO, minting of F-Assets and usage of applications that build on Flare without putting their FLR tokens at risk.
Flare will launch with all the tested core protocols, FTSO, initial F-Assets and StateConnector. The use of Songbird as the testbed for potential updates to Flare means that between Flare and Songbird, Songbird will often be the more advanced network. Innovations and new dApp launches will happen first on Songbird and then may be rolled out on Flare after testing. This makes Songbird its own type of network which may be useful, in isolation, to applications that do not need the intended stability of Flare, but which wish to enjoy the core Flare protocols and potentially more advanced features that Songbird may offer ahead of Flare. This might generally appeal to lower value applications whereas Flare might appeal to applications handling greater amounts of value.
Songbird Token
Songbird will have its own token, Songbird ($SGB), which will be distributed once only and in the same ratio to all the same recipients of the FLR distribution. Total starting supply will be 15 Billion with initial inflation of 10% per annum through the FTSO and validator rewards systems. This means for every 1 XRP that was held at the time of snapshot 0.1511 SGB will be allocated.
There will be no pre-defined minting rewards pool, instead that supply will remain with the Flare Foundation. If you claimed FLR through self custody, you will use the same Ethereum style address but with a different chain ID to access Songbird. If you claimed your FLR through an exchange they will receive SGB on your behalf. You will need to ask them to distribute it to you.
Governance
Similar to Flare the SGB token can be used to perform a governance role. Unlike Flare this would not be over the implementation of changes to Songbird itself (as Songbird is subordinated for Flare for that purpose). Governance could however be useful in adding additional chains, prices and F-Assets, that haven’t been suggested by Flare governance, to the Songbird state connector, FTSO and F-Asset protocols respectively.
Launch order
Songbird will launch first as a pure EVM smart contract network this will enable testing of the network architecture and for the initiation of testing of third party dapps. Subsequently the FTSO, State Connector and F-asset systems will be enabled.
Flare Launch
Flare will launch after substantial testing of all systems on Songbird with the current final security audit scheduled to finish at the end of September.
Chaos warning
Songbird should not be considered a production ready network. It is for testing of the integrity of the proposed production network (Flare), proposed governance updates over time, the Flare core protocols and dApps launching on Flare. The Flare team makes no promise to continue support or development of Songbird in the future. The team at Flare and likely the various teams testing their dApps on Songbird will be actively trying to find and exploit bugs and other issues and break the network. Please therefore be aware that Songbird comes with a potential for loss of liveness, token loss and risk that is potentially greater than main net deployments. Measure twice, cut once.
https://flare.xyz/introducing-songbird/
