FROM THE FLARE NETWORK:
Today we are delighted to make our detailed plans for the deployment of the Flare Network public. These plans can be fully explored by diving into our draft white papers covering the Network and its native token, Spark (here) and the trustless integration of XRP with Flare (here). The papers are in draft form and there will be optimization changes between now and the day Flare goes live. There should not be changes that materially deviate from the overview provided below. In this post we aim to highlight what we consider to be the most important aspects of Flare. A minimally technical overview of each important component will be posted over the following weeks, starting later this week with a walkthrough of Flare’s trustless integration of XRP, FXRP. Buckle in!
(A TL;DR is at the end of this post.)
What is Flare and why are we building it?
Flare exists to solve two key issues:
First, and of immediate importance to the building out of our industry is that 75% of the value that exists in public blockchain cannot currently be used in a trustless manner with smart contracts.
Second, and of both short term and long term consequence, there are potential issues with how scaling is being implemented for smart contract networks today. The majority of new networks use Proof of Stake or its variants. These protocols derive network safety from their native token.
The immediate issue inherent in Proof of Stake is that the consensus design doesn’t yet safely allow for alternate uses of the native token. If a token holder can obtain a higher yield (and with no possibility of slashing) by providing collateral to create a stablecoin than they can from staking, then as economic rationalists, they will likely do so. This diverts tokens away from staking and cannibalizes the safety of the network. (A highly insightful paper on this topic is here.) We suspect that this is perhaps the key reason why despite having comparatively higher transaction costs and far lower transaction throughput, Ethereum is still leading the way in DeFi.
A longer term issue is that as a Proof of Stake network gains usage and the value built on top of it increases, the value of the staking token must increase or the network will become unsafe. This is great for investors in the token but bad for people that want to see decentralization become part of the mainstream way of doing business. Why? Because in order for the token value that secures the network to rise, capital must be diverted from some other use to buy the token. Taken to the logical endpoint, if smart contract networks using proof of stake were to become the ubiquitous method of doing business, the scale of diversion of capital required from other endeavors, just to secure the value built on these networks, would make the cost of commerce unfeasibly high. For this reason it is extremely unlikely to happen. Proof of Stake and variants can scale transaction throughput but existing implementations can’t scale for value. In our opinion Proof of Stake is more of a stopgap than a solution.
How does Flare solve these issues?
Flare is at its core a new way of scaling smart contract platforms that does not link safety with the value of its token. Flare still requires a token for the operation of the network, principally to deter spam transactions. Flare’s token is called Spark. Because Spark doesn’t have network safety implications it is well suited to enable the trustless usage of non-Turing complete tokens with smart contracts.
Flare is the world’s first Turing complete Federated Byzantine Agreement (FBA) network. Nodes run the Avalanche consensus protocol with a key adaptation to the FBA consensus topology. FBA is unique as a consensus topology in that it achieves safety without relying on economic incentives that can interfere with high-value and high-risk use-cases. A criticism of pure FBA is that it leads to fragile structures of constituent nodes, permitting topology scenarios where a single node failure can cause a network-wide failure. For this reason, a specific setting of FBA called a Unique Node List (UNL) topology is prioritized that emphasizes clarity and ease-of-use while maintaining the open-membership property of FBA. The percentage overlap of the UNL is a governance defined parameter, with a lower overlap improving the open-membership property of the network. The Flare Network leverages the Ethereum Virtual Machine (EVM), enabling the network to run Turing complete smart contracts.
At network launch, built on top of Flare is then a protocol to safely enable the trustless issuance, usage and redemption, of XRP on Flare. This protocol is called FXRP. XRP safely and trustlessly becomes FXRP, on Flare, secured by Flare’s native token, Spark. XRP now effectively exists on a Turing complete network and once there, trustless interoperability with other networks is feasible, both through interoperability protocols such as Cosmos and Polkadot or with Ethereum via well defined bridge protocols. In short: Flare can be used as a smart contract platform for XRP or as a trustless pipeline for XRP to other networks.
Furthermore, the general methodology of FXRP is extendable to any non-Turing complete token and the ability to decide which other tokens to support and then extend the means to do so is built into the systems and governance of the network.
Flare brings together the value of the non-Turing complete tokens with the transformative power of smart contracts on a network that can scale for value as well as transaction throughput.
The complexity of getting XRP onto Flare is that there is no way for a smart contract on a public blockchain to control an address on the XRP ledger. The reason for this is that smart contracts currently have no adequate way of storing a secret key in a manner that is genuinely secret. To get XRP onto Flare using only code would require some group of participants to come together with a multi signature address which they collectively control, whereby if k of n parties sign a transaction the transaction is authorized. Any user of an asset issued by this multisig address would then have to trust that collection of users and thus the asset would be neither trustless or decentralized.
FXRP safely allows an XRP holder (an originator) to send their XRP to a set of addresses (called agents) on the XRP Ledger. The FXRP smart contracts on Flare then issue the originator FXRP on Flare which is 1:1 convertible with XRP and secured with Spark. When a holder of FXRP wishes to redeem it for XRP ( a redeemer) they send it back to the FXRP smart contracts on Flare. The agents then send the XRP to the redeemers address on the XRP ledger. If the agents don’t complete this redemption quickly enough the redeemer is compensated the value of their XRP plus an amount to compensate for transaction costs to rebuy the XRP.
With FXRP, no centralized intermediary is needed.
FXRP works as follows:
Owners of Flare’s native token, Spark, may send their tokens to a collection of smart contracts on Flare that are referred to as the FXRP system. Users who do this are providing collateral to the FXRP system. They are termed agents. Let us call one of the agents Bob. There will be many agents in the FXRP system.
Let’s say that Bob has inserted 5000 Spark tokens into the FXRP system. In this example 10 Spark tokens can currently be bought for 1 XRP token. The FXRP system demands a collateral ratio of 2.5, meaning that at all times an agent must have provided to the system 2.5 times the value of the FXRP the system has apportioned to them in Spark tokens. FXRP is valued here as 1:1 with XRP. Hence Bob’s 5000 Spark tokens allows the system to issue 200 FXRP.
When someone, say Alice, wants to create FXRP they send a transaction to the FXRP system with a fixed fee of 0.1% of the value of XRP that they want to mint into FXRP. Alice is termed an originator. The transaction also tells the FXRP system what address to send the FXRP to on Flare, once it is minted, and what address the XRP will originate from on the XRP Ledger. If there is available capacity in the FXRP system, collateral to secure the amount of FXRP being created is locked for a certain period against Alice’s upcoming transaction. This way Alice does not have to trust Bob. In return, a set of instructions are generated for Alice telling her what address (Bob’s address) to send the XRP to on the XRP ledger and what last ledger index to use. If there isn’t capacity in the system to issue the desired amount of FXRP then Alice is refunded the fee.
Alice then sends the correct amount of XRP plus a creation fee in XRP to Bob’s address on the XRP ledger. The creation fee is the vast bulk of the money Bob will earn for locking up his Spark collateral, note that his earnings are predominately in XRP. Flare observes this transaction using a system called the State Connector, defined in Section 2 of the Flare white paper (and the subject of a future blog post). The FXRP is then minted by the system and delivered to Alice’s nominated address on Flare.
The 2.5x collateral ratio must be maintained at all times. If the price of XRP increases against Spark, such that the value of Bob’s collateral falls below 2.5 times the FXRP issued against it, then Bob has a limited time to either add more Spark tokens as collateral or buy and redeem FXRP tokens to bring his collateral ratio back in line. For example, say 200 FXRP tokens are issued against Bob’s 5000 Spark tokens and the price of XRP/Spark increases to 12. Bob now needs to either add 1000 Spark to the system or buy and redeem 33.34 FXRP to reduce his apportionment of issued FXRP to 166.66.
If Bob doesn’t have access to additional Spark tokens it is not financially onerous for him to reduce the balance of FXRP supported by his address. Bob’s collateral enabled the FXRP system to issue 200 FXRP tokens, in the process of doing so Bob has received 200 XRP tokens on the XRP ledger. Thus if Bob doesn’t have additional capital to purchase Spark tokens he can either sell sufficient XRP for FXRP on an exchange such that he can redeem at least 33.34 FXRP or remaining in a purely decentralized environment if there are other agents in the FXRP system with sufficient excess collateral in he can mint sufficient FXRP and immediately redeem it. The second scenario essentially shifts the obligation to the rest of the system. If Bob does nothing and remains in default against the collateral ratio, Bob’s collateral will be automatically auctioned off for the amount of FXRP issued against it, which in this case is 200. Bob retains any remaining collateral after this operation.
Let’s say that Bob opted to add additional Spark as collateral. Now some time later Alice who owns all of the 200 issued FXRP wants to redeem the whole amount back to the XRP ledger. Alice simply makes a transaction with the FXRP system sending the FXRP to the system and telling it what address she wants credited. The system then issues a set of instructions to Bob telling him how much XRP to send and where along with two XRP ledger number deadlines by which the transaction must be completed. If Bob completes the transaction by the first deadline his collateral is entirely unlocked. If Bob fails by the first deadline but succeeds by the second he is charged a small penalty fee and the rest of his collateral is unlocked. The penalty fee is burned.
If Bob fails to complete the transaction by the second deadline it is termed a redemption failure. Alice is then compensated with Spark tokens to the value of her redeemed XRP plus a 1% increase to cover transaction costs of buying back the XRP, this is drawn from Bob’s collateral. Of Bob’s remaining collateral 50% is burned as a penalty and the other 50% returned to him. Alice may then buy replacement XRP on an exchange. Alternatively, assuming there are other agents on Flare with issued FXRP and people who wish to sell it, Alice can buy more FXRP on Flare and redeem it against those agents.
Spark and Dependent Applications
FXRP is the first example of something we term a Spark Dependent Application (SDA). An SDA is defined as an application that uses in its construction some combination of: Spark for collateral, The Flare Time Series Oracle and Spark token holders for governance. Each of these elements is entirely optional and an application can operate on Flare only interacting with Spark for payment of transaction costs. For example, FXRP uses Spark as collateral, the Flare Time Series Oracle for the XRP/Spark price and the Spark token ownership set for governance over certain parameters such as the FXRP creation fee and the collateral ratio. The SDA model is intended to provide a template for extending each of the three components to an arbitrary number of applications. Using Spark as collateral across all applications is straightforward, the most important element was to consider how a safe oracle methodology could be created over multiple time series.
Flare Time Series Oracle
Ownership of the Spark token allows for the contribution to the Flare Time Series Oracle (FTSO). The purpose of the FTSO is to form accurate estimates of data on Flare from off-chain whilst retaining decentralization. The FTSO is structured to provide many estimates of individual time series. The XRP/Spark price is an example of a single time series.
Each time series output by the FTSO will generally have two groups of participants: the first being Spark token holders and the second being the holders of the dependent application token, which is termed an F-asset. In the FXRP application the F-asset is the FXRP token itself. For a more complex application like a derivatives application where the application requires multiple time series the F-asset may be something more akin to an issued governance token.
For each time series, the FTSO asks each relevant set of participants to provide an estimate. Spark holders will provide estimates for all time series and F-Asset holders will provide estimates over only the time series related to their F-Asset. Those estimates are then processed as defined in section 4 of the Flare whitepaper and output by the system.
The incentive for F-asset holders to provide data to the system is the safety of their application. Spark token holders are incentivized by the potential to earn something called the oracle reward. This is an amount of Spark tokens that are minted by the system. The oracle reward is an annual rate split uniformly across each FTSO estimate period. For example, if the rate is 10%, there are 365 estimates in a year and a starting number of Spark tokens of 100, then 10 Spark will be created in 1 year and ~0.03 Spark minted and rewarded per day. Spark token contributors can earn this reward by contributing data that is deemed to be “correct”. The precise mechanics are set out in the white paper. Importantly all Spark token holders are implicitly staked in the system as if they do not earn the reward either through non contribution or providing “incorrect” estimates they lose value to token holders who are rewarded. This is Flare’s version of block rewards.
The FTSO will be initiated to provide the following prices for: XRP/Spark, USD/Spark, BTC/Spark, and XLM/Spark. Only XRP/Spark will have a corresponding F-asset at the outset. Additional time series and their related F-assets can be proposed and accepted through the Governance process.
The FTSO will in reality provide estimates every couple of seconds. Not every Spark holder will want or be able to run hardware to contribute to the FTSO and separately they might not be interested in voting for network governance. Therefore the votes for both responsibilities can be detached from the token itself and separately delegated to other parties. The delegation may be cancelled at any time and when a token is transferred from one address to another the delegation is automatically cancelled such that the voting rights go with the token. The mechanism also allows SDA’s such as FXRP to delegate Spark votes back to the ultimate owner who can then re-delegate those votes further to entities he wants to vote on his behalf. So if Bob has 5000 Spark tokens in the FXRP application, it will delegate the votes from those tokens to an address specified by Bob. If Bob wants a dedicated data provider to contribute to the FTSO on his behalf, Bob can then re-delegate his votes for the FTSO to the data provider. Importantly this means that Bob doesn’t have to choose between earning Spark by providing collateral to the FXRP application and potentially earning the reward from the FTSO, he can do both. Any SDA that makes Spark tokens unavailable to their underlying owners, provided there is a definition in the application as to whom the underlying owner is, can implement the delegation procedure.
Governance & Foundation
Flare is governed entirely by Spark token holders through voting. SDA’s may optionally request to be governed by Spark token holders.
Certain decisions can be made in an automated manner on-chain, such as changing the transaction cost, the oracle reward rate or, looking at FXRP as an SDA, changing the collateral ratio and creation fee. Other decisions such as adding a new time series to the FTSO and linking its proposed F-asset, changing network consensus parameters or more complex long-term updates require a code change. The Flare white paper sets out a proposal, development and testing regime for manual changes which can be initiated and voted on by Spark token holders. To help implement that process and execute the agreed changes there will be a Flare foundation. The foundation will be a non-profit, to be incorporated in the coming months. It is to be responsible for 5 key areas: grants, investments, research and development, education, publicity and partnerships.
It is the research and development function that allows the foundation to be an integral part of the network update process, even going so far as to analyze, report on and then build, test and deploy proposed network code changes.
The foundation must be highly transparent and not waste money. Two reports per year on its activities and expenditure will be complied and published. The foundation is intended only to take direction from the Spark token holders and not to set the agenda. As such, it may not: contribute to the FTSO in any way, deploy any of its Spark holdings as collateral for any application on the network and it may not use its Spark holdings to vote in any governance vote. It may not assign its Spark tokens to others to do so. Furthermore, written into the foundation’s constitution will be the obligation that if a governance vote agrees that the foundation no longer serves a beneficial purpose then the foundation must wind its activities down and burn all of its remaining token holdings at the earliest opportunity.
The best community to own the asset that enables the use of XRP with Turing complete smart contracts is the community that will use it and benefit from it: XRP holders. Flare is not doing an ITO. Instead, it is doing what we term a utility fork. We believe it’s the first of its kind.
A fork traditionally has sought to take the user base of an existing network and depart entirelyfrom that network, usually to have an antagonistic relationship with the original chain. In contrast, a utility fork is intended to bring value back to the original chain instead of moving away from it. Flare lets XRPL do what it does best, fast settlement, whilst bringing to XRPL, smart contracts and the feasibility to create a trustless pipeline to other blockchains. We think this is a truly powerful combination and a perfect example of utility.
100 Billion Spark tokens will be created to mirror the quantity of XRP that exists. There are approximately 45 Bn XRP tokens that do not belong to Ripple labs. The objective of the distribution is that XRP holders other than Ripple can claim approximately a 1:1 amount of Spark to their XRP holding. 45 Bn Spark will be claimable by XRP holders (stripping out known Ripple labs addresses). 25 Bn Spark will go to Flare Networks Limited which is Flare’s for-profit organization. 30 Bn Spark will go to the Flare foundation.
As many XRP owners actually use exchanges to hold their XRP tokens, there is a possibility that a holder of XRP who wishes to claim Spark tokens may be unable to because either the exchange claims the Spark and retains them rather than passing them on, or alternatively doesn’t claim them at all. To allow XRP owners to take part in the distribution either by pressuring their exchange to distribute the Spark tokens or to move exchange to one that does, the snapshot of the XRP ledger will be taken at a date nearer to launch. A list of participating exchanges will be posted on Flare’s website and updated periodically. The snapshot ledger number will be posted to the website when the snapshot has been taken.
Flare is the world’s first Turing complete Federated Byzantine Agreement (FBA) network. It integrates the Ethereum Virtual Machine (EVM) and does not derive safety from a token. On top of this is built a protocol to safely enable the trustless issuance, usage and redemption, of XRP on Flare. This protocol is called FXRP. The general methodology of the protocol and the system that connects Flare to other networks is extendable to any non-Turing complete token. Trustless interoperability with other networks is feasible, both through interoperability protocols such as Cosmos and Polkadot or with Ethereum via well defined bridge protocols.
Flare’s token, Spark is created through what may be the first ever utility fork whereby the origin network, in this case the XRP Ledger, benefits through increased utility. 100 Billion Spark tokens will be created at the outset of the Flare network, of which 45 Billion will be claimable by existing XRP holders excluding Ripple Labs. This mirrors the existing amount of distributed XRP such that current XRP holders will be able to claim approximately 1 Spark token for every XRP token held. 25 Billion tokens will go to the developers, Flare, and 30 Billion tokens will go to a non-profit foundation called the Flare foundation. Spark token holders can earn a return on their Spark tokens both through committing Spark tokens as collateral to secure the trustless issuance and redemption of FXRP and by contributing data to the Flare time series oracle. These functions do not compete with each other.
The Spark token is used for governance of the network through voting. With the exception of grants and investments to help develop Flare, the foundation takes technical direction from the Spark token owners. A key role of the foundation is to help execute upgrades and changes to the network, agreed by governance vote, that cannot be implemented without a code change. Importantly, written into the foundation’s constitution, will be a bylaw that the foundation must be wound down and all Spark tokens held by the foundation burned, if the Spark token holders agree that its existence is no longer beneficial to the network.
Flare brings together the value of the non-Turing complete tokens with the transformative power of smart contracts on a network that can scale for value as well as transaction throughput.
Answers to Two Questions:
Is Spark creating Proof of Stake by the backdoor?
Only issued tokens that require collateral, such as FXRP, are secured with Spark. The network does not use Spark for safety in coming to consensus.
What happened to the native stable coin mentioned in your previous blog?
We had (what we think are) very strong concepts for a USD denominated stable coin, but it required extensive re-engineering of the Ethereum Virtual Machine which would have delayed launch and had unpredictable effects on future compatibility with the EVM. Spark as it is structured, offers much greater utility and benefit to both the XRP community and to the XRP ledger.
Read More Here: https://flare.ghost.io/theflarenetwork/