Thoughts on the design of Flare's protocols

It begins with the FTSO. This decentralised oracle network is rewarded most via the network’s native inflation. Its role is not limited to providing decentralised price feeds to dApps on Flare and other chains. Rather, the FTSO also provides the incentive mechanisms for an independent pool of data providers to progress onto becoming validators of the network. This is due to the Flare’s network’s consensus mechanism, where the probability of a validator being chosen to confirm transactions is proportional to their vote power and reward rate.

Now, it’s important that vote power is distributed across the validators as to minimise the risk of transactions becoming faulty. If the vote power distributions are unbalanced, it not only affects the FTSO system, it also impacts the validation of blocks.

Before we dive deeper into vote power on Flare, its important to note that the FLR token contains separate vote power contracts called wFLR - one for delegating vote power to your favourite data providers who are incentivised to feed in good prices; and the other for governance voting in Foundation or Community initiated proposals. These two processes can occur whilst the native token FLR is free to use in the dApp ecosystem, for example using FLR in the marquee DeFi infrastructure dApps known as F-Assets and LayerCake (more on this later).

In addition to delegating vote power to FTSO providers and earning reoccurring inflation payments, which helps to maintain a user’s value in this ecosystem (proxy participant), vote power is also used to vote in governance proposals. This design is also incorporated in the SGB token, and the Songbird community is currently experiencing the first community vote as per STP-01. This is practice for ecosystem participants. In order for this ecosystem to thrive, an in order for the participants to thrive, voting in governance is essential. This is because, through game theoretic Community initiated FIPs, Songbird voters have the ability to earn additional native tokens, at the expense of others, by supporting proposals only if they will be passed on Flare.

The other vote power property is that its delegations and interactions are stored in the network’s history; they can be viewed to verify or they can be used for targeted smart contracts interactions. Airdropping a token to accounts that have vote power is one example. In fact, this is how the future public community distributions of the FLR token will take place, if FIP-01 governance proposal is accepted on Flare. In addition to all the benefits presented here, distributing the FLR token to accounts which have vote power will keep value inside the ecosystem. Those who are not contributing their value (vote power delegations) will be penalised by having their stake in the ecosystem inflated away. The 36 months of participant-based rewarding mechanism will shift value between all FLR holders. The net impact is that value will shift to those who keep their liquidity in the system (including new participants) - at a time when it is most crucial to have. Hence, the 36 months of distributing incentives is a hedge against slow network adoption.

Recalling the fact that the network validators’ success depends on their vote power and reward rates, theoretically then, the best validators are also the best data providers. These data providers have the option (permissionless) to serve an additional infrastructure role as attestation providers - fetching deterministic data from external blockchains and return those results independently to the State Connector. The State Connector system will come to consensus on the fetched data and then publish the state proofs to Flare (and in the future to other blockchains). Every role that data provider offers is another source of income for them. Their economic reward is (generally) reflective of their value. They are operating in an open competition.

However, we cannot forget the power of the community here. It is the community’s vote power that has the ability to shift the dynamics of the infrastructure provider’s services. As FTSO is a service, so is validating and providing attestations. And, in the same way that the FTSO system passes on some of its service rewards to their delegators (fee), it is not unreasonable to expect that Flare’s validator system (operated by the same entities as in FTSO) will offer the ability to pass on validator rewards to their delegators. NB: Validator rewards are 20% of total native inflation, FTSO is 70%.

Let’s talk about Songbird. The inclusion of a Canary network was/is a game changer. The Songbird network has succeeded thus far. It has provided ecosystem participants the ability to experiment with Flare’s protocol designs; to trustlessly earn native SGB rewards without custody risk; to learn whilst building strong rooted relationships as well as business models that will be ready to port over to Flare. Songbird has also succeeded in its ability for the community to respond to issues, namely FTSO collusion, through implementing changes described in STP-01 and in future proposals.

So far I have briefly discussed some components of Flare and Songbird’s base layer design. The open, permissionless and incentive driven systems serve a foundational layer for its community to create valuable dApps and thrive. With decentralised prices and states that are available and trustless, developers can build some very interesting dApps on Flare, which would otherwise incur excessive cross-chain risks. Two such examples are F-Assets and LayerCake protocols, which are currently in development by a build partner to Flare. Although not yet confirmed, I believe this development partner to be Flare Networks Limited (FNL). This for profit organisation is creating a low risk collateral system to enable non-smart contract value to be represented onto Flare. The demand on the minter side is equally as powerful as the demand on the agent side. For both users, the F-Asset system represents the ability to trustlessly interact with cross-chain DeFi dApps powered by Flare, as well as earn yield on their value. The entities with strong FLR balances and whom understand how to contribute to the ecosystem will be positioned well in the role as agents, and will enjoy the ability to run safer delta neutral strategies to earn cross-chain assets as fees for supporting the system with their FLR collateral.

These dynamics are similarly expressed in LayerCake’s protocol design. Entities known as bandwidth providers hold strong balances of cross-chain assets and FLR, can deploy their collateral to LayerCake and insure cross-chain value moving across chains. Bandwidth providers receive a fee in the originating chain asset, paid by the bridge user. This presents another opportunity for any well capitalised entity to capture fees by putting their cross-chain assets to work. I believe centralised exchanges and multi-crypto asset funds will/have appetite for such designs. For the bridge user, if their value is represented on Flare they will receive the native FLR token as rewards from the cross-chain incentive pool, which ultimately converts the bridge user into a native participant due to the incentive structures designed around the native FLR token (FTSO and monthly distributions).

There are other Flare developer partners who are building powerful cross-chain services such as Relay, which will allow secured and staked relay of data (prices and states) between many chains, including Flare. This will help facilitate a never before seen level of composability and interoperability in DeFi.

On top of an open and permissionless arena for providing data, the system has embedded key incentive mechanisms around the native FLR token, which has been designed with multiple use cases for maximal on-chain participation and sustained value creation. With decentralised prices and states on Songbird and Flare, developer teams have a process to safely create and deploy their dApps in a cross-chain friendly ecosystem. This is how the creators of Flare architectured a system to “Connect Everything”.

- Ash W ☀️