Songbird

Proposals

Canary down the mine.

The term canary network is typically used to refer to a production blockchain that is specifically designed to allow new features to be built and tested under real-world conditions, before making them available on it's parent network.

Canary networks, although considered a testing playground for developers, are actually live environments, with their tokens having have real-world value.

So, where does the term come from? It originated from coal mining and specifically the term canary in the coal mine, where real canaries would be used as an early warning sign, to detect toxic gases.

In the context of software testing and deployment, it refers to the practice of rolling out a new software release or feature to a small subset of users before deploying it to a broader user base. This allows the development team to monitor and identify any potential issues with the new release in a controlled environment. If problems arise with this canary group, it can serves as an early warning sign of issues that may need to be resolved before releasing to a wider group of users.

Flare's canary network is called Songbird.

Songbird has played a crucial role in allowing developers to build and test the core protocols in a live production environment, ahead of launching on Flare.

Read on to discover more about Songbird and it's role within the Flare ecosystem.

Brief History

Songbird launched almost one year before Flare, in September-2021, with its FTSO system up and running a month later. The second core component, the State Connector went live in March-2022.

Songbird's native token is $SGB and it's wrapped version $WSGB. You can find out more details about network inflation, token supply and distribution by clicking each of these links.

Role

Songbird has three core goals:

  • Test Flare technology in a live environment prior to deployment on Flare.
  • Provide dApp builders with a live testing environment. Whilst it is good practice for teams to launch their products on Songbird first, it's worth pointing out that there are no rules making this mandatory.
  • Serve as the lower house in a bicameral governance structure, thus giving the community the ability to submit and vote for proposals on Songbird so that, when approved, they may be considered by the Flare Foundation for inclusion on the Flare network.
Real Usage

Since it's inception we have seen many dApps built on Songbird, some of which have since been released on Flare. There are DeFi product suites, NFT marketplaces and decentralised exchanges to name a few, with the list growing daily. There are some valuable resources available to help you find out more about the types of applications being built on Songbird (and Flare, of course). Flare Builders has a comprehensive list and is certainly worth checking out.

More Information
Select category
Role

A data provider's role is to gather information from real-world sources and submit it to the FTSO.

​If the FTSO deems this information accurate, in relation to other submissions, then the provider is rewarded, along with any token holders who have delegated votes to them.

Data sourcing

Data providers can obtain the required data from any source they wish. With regards to crypto price data, typical sources would be exchanges, price aggregators and other oracles.​

It's important to have access to many different sources, as the data obtained may differ considerably.

Infrastructure

Building out reliable and resilient infrastructure is critical to the success of any data provider. 

​Often providers choose to run their infrastructure using a cloud based solution, such as AWS, or Google Cloud.​

A typical provider setup can include dedicated nodes, a price submitter tool, a database to organise and an application to process the data.

Algorithms

Once data has been gathered, it needs to be analysed and processed in some way before being submitted to the FTSO.​

The data needs to validated and checks made to ensure any 'bad' data is excluded. This can all be done automatically, based on pre-defined conditions.​

Each provider should create their own unique algorithms, that process the data in a way that ensures the final output represents what they themselves deem to be accurate.

Algorithms

Once data has been gathered, it needs to be analysed and processed in some way before being submitted to the FTSO.​

The data needs to validated and checks made to ensure any 'bad' data is excluded. This can all be done automatically, of course, based on pre-defined conditions.​

Each provider should create their own unique algorithms, that process the data in a way that ensures the final output represents what they themselves deem to be accurate.

Delegations

Accurate submissions lead to more rewards, which in turn should lead to a provider gaining more vote power.​

There is a cap on the maximum vote power any one provider can obtain, before the rewards their delegators receive are diluted.

​Some providers also offer other incentives to gain additional vote power. This includes building useful tools for the community and NFT giveaways, amongst other things. 

Service fees

Data providers charge a fee for the service they offer. It's how they are able to fund the operation of their service.

​The FTSO system gives a provider the freedom to set any fee they choose; however the higher the fee they charge, the less rewards their delegators will receive, which could drive them to delegate to a alternative provider.