What Do FTSO Signal Providers Do? | Flare Network

What do FTSO Signal Providers Do?

So you might be curious about becoming a Signal Provider on Flare Network but you have no clue where to start, or you just want to understand what these guys do because you’re going to be delegating your FLR tokens to them.

I’m going to keep this as simple as possible. If you are interested in the more technical side, you’ll see that in later content that I’m currently working on.

There are three groups of users who utilise the FTSO system: Applications, Delegators & Signal Providers.

Applications are the end users of the system, they utilise the information that the FTSO system outputs. Any application can access the output data, but one example is the F-Asset system which requires the current price of each F-Asset for its regular operations.

Delegators have the job of delegating their FLR tokens to Signal Providers that are providing accurate data to the FTSO and in return they are rewarded with FLR, minus a fee that Signal Providers take.

Signal Providers on the other hand have a more technical role. They must code their own systems and algorithms to collect data from outside of the Flare Network.

Being a Signal Provider carries a lot of responsibility and they must perform mission critical tasks such as:

~ Maintaining a very high uptime.

~ Providing accurate and reliable data to the FTSO.

~ Submitting data on a high frequency.

A Signal Provider that frequently misses data submission deadlines or sends data to the FTSO which falls outside of the median that other providers submit - potentially will have their reputation hurt.

As well as damaged reputation, their delegators will not receive the compensation that they are expecting.

These are very important considerations for Signal Providers who must ensure they build robust and reliable systems to best serve their delegators.

FTSO System Overview

The FTSO system is a collection of smart contracts, there are a number of core smart contracts that handle the FTSO systems functions. If you don’t already know, a smart contract is essentially a piece of code on the blockchain that anyone can interact with. They are programmed to have functions that achieve a certain goal.

So, it’s important to note that each time series that Flare ingests is called an “FTSO” and an individual contract for that FTSO exists. As an example, Signal Providers can submit the price data for XRP/USD, and there is an individual smart contract that this data must be sent to.

But, when we look at the FTSO system more holistically, we see other smart contracts that will be utilised.

Some of the functions across these contracts include the ability for Signal Providers to set the fee they wish to charge their delegators, as well as to update their fee in the future. Keep in mind, when a Signal Provider updates their fee, the new fee does not come into effect immediately, it allows a period of time to lapse where delegators can notice the change and adjust their delegation if required.

Submitting Data

Signal Providers have a lot of freedom in the way they source data. It can be done in any way they please.

Some such methods include using Restful API’s or WebSockets to collect data from various exchanges. They could be decentralised exchanges, centralised exchanges or any other place that they can source pricing data from for the required tokens.

An even wilder example that Hugo Philion has mentioned is a Signal Provider that consists of a network of other “sub” Signal Providers. It’s really up to your imagination as to how pricing data can be sourced.

Irrespective of how Signal Providers source their data, they must conform to the procedures set out by the FTSO system.

All Signal Providers will need to be whitelisted to be eligible to submit data. Whitelisting is done on a per FTSO basis in that each provider needs to register for each time series they are submitting data for.

This is primarily done to control the maximum number of Signal Providers on the Flare Network to mitigate potential performance issues. This limit can be adjusted by governance vote later.

Once the Signal Provider has been whitelisted, they must also maintain a certain amount of voting power to be allowed to submit data. This means that if the Signal Provider doesn’t have enough FLR holdings, both private and delegated combined, they may not be able to submit data for a particular FTSO.

So long as the Signal Provider is whitelisted and has enough voting power, they can begin sending data to the FTSOs and be rewarded for doing so.

Submitting data to the FTSO is a process in and of itself, Signal Providers must follow a “commit and reveal scheme”.

To understand what this means, imagine a Signal Provider puts their price data submission inside a locked box, then hands the box to the FTSO (this is the “commit”). No one but the Signal Provider knows what the contents are. When the content inside the locked box, the price data, is needed, the Signal Provider sends the key to the FTSO which allows the FTSO to access the contents to complete the “reveal”. This is put in place to prevent “lazy” providers using data sent by other signal providers.

This process is repeated many times per hour, roughly every four minutes.

Reward Functions

Delegators will most likely be delegating to more than one Signal Provider but as long as one or more of these providers are submitting data within the median, Delegators will be eligible for compensation.

This compensation is pooled into the Reward Manager smart contract. This simply means that the compensation that you are due is not automatically sent to you but rather you must claim it. The frequency at which you claim rewards is limited, so bear that in mind, it may be possible that rewards will only be able to be claimed daily; irrespective of the frequency that you earn the rewards.

For the average Delegator, this should be a simple process as third-party applications such as wallets, or even Signal Providers themselves, will offer interfaces for Delegators to click a few buttons and have their rewards sent to their wallet allowing for compounding of their rewards. It will even be possible to have your reward sent to a wallet that wasn’t even involved in the delegation process, if you so choose.

If Delegators wanted even more granularity, it’s possible to claim rewards individually from each Signal Provider that a delegation has been made. If you have delegated to Providers A & B, when Provider A has generated 50 FLR and Provider B has Generated only 15 FLR , delegators can make a claim for just the amount due from Provider A.

There are many functions that the FTSO system provides that are built with immense consideration for the entire Flare ecosystem. We have only touched on the most relevant ones today.

If you have any questions about this process, leave a comment and I’ll find an answer for you.