freeradiantbunny.org

Definition 3.1. The Flare is the native token of Flare Network.

from Flare Network white paper

3.1 Flare technical use

"Flare’s technical purpose is to impose a cost upon transactions so as to disincentivize superfluous transactions i.e. network spamming. This is achieved via transaction fees."

"The Flare Network uses the Ethereum Virtual Machine (EVM) [Woo+]. The EVM defines a transaction’s computational complexity in terms of units of Gas."

"To avoid extremely lengthy or interminable transactions, Flare imposes a complexity limit, defined in Gas units."

"A Gas conversion rate between Gas and Flare tokens is set by the network."

"Thus, a transaction cost is defined as the complexity limit multiplied by the conversion between Gas and Flare. The transaction cost is burned rather than accruing to some set of participants. Both the complexity limit and Gas to Flare conversion rate are governance parameters, see section 5 for further information on governance."

Now that the Flare Network and Flare Token have been generally defined, the focus turns the 3 uses of the Flare Token, the processes that brought our attention to this document in the first place.

The Flare Dependant Application model and the 3 Uses of Flare

"The Flare Dependant Application model provides a blueprint for building applications on the Flare Network."

"These three components form the building blocks of a collection of applications that can be built using Flare, termed Flare Dependent Applications."

"Flare is used as the arbiter of network governance and a central component of an interlocking set of utilities that collectively form a novel way of structuring decentralized applications, termed Flare Dependent Applications."

"The SDA structure is intended to provide utility by allowing applications that deploy on Flare to optionally benefit from:"

1. The use of the Flare Time Series Oracle (FTSO), as described in Section 4.
2. The depth of interest and expertise that could be brought to bear over governance questions.

Collectively these can be termed the "network effects" (Footnote 3: Network_effect) of the SDA as the benefits increase with usage.

Each of the 3 SDA components is set in brief below.

SDA 1st Component: Collateral

Flare Used as Collateral

"Flare can be used as collateral within applications."

"The first component of the SDA is the usage of Flare as collateral for any application that requires collateralization."

"Unlike the native tokens of smart contract platforms that use some form of Proof of Stake that incorporates slashing [Ben], the use of the Flare token as collateral does not compete with network safety itself because Flare network safety is not reliant on the token."

"Any application on the network can use the Flare token as collateral."

"The first such application uses the Flare token to create a trustless 1:1 representation of XRP, FXRP [Net20]."

"Section 3 outlines the specification of Flare as a token that works like a master key for a potential series of other tokens and applications."

So, all of that information was about Flare tokens being used as collatoral. Now, we turn our attention to the second (of three) uses of Flare tokens.

SDA 2nd Component: FTSO Reward Function

Flare Used to Contribute to the Flare Time Series Oracle

...providing on-chain data estimates.

For information on Flare-mediated time series oracle see Section 4.

"Flare as a contributor, but not the sole contributor, to an oracle providing on-chain time series data estimates, called the Flare Time Series Oracle (FTSO)."

"Furthermore, as the network doesn’t require staking or computation returns for safety, the FTSO becomes the inflation function for Flare itself."

"In Section 4, the Flare time series oracle is presented."

"The second component of the SDA is the Flare Time Series Oracle (see Section 4), which provides a periodic on-chain estimate of the current value of any number of off-chain time series."

"The contributors to a specific time series consists at a minimum of Flare token holders but will under certain circumstances include the token holders of an application that relies on that time series, called F-asset holders."

"An F-asset could take any form given consent via governance from the Flare token holders."

F-asset Examples

"The Flare Time Series Oracle (FTSO) has a reward function which generates new Flare tokens. The new Flare tokens are used to reward Flare holding contributors."

"The determination by which contributors are rewarded is based on a process designed to economically incentivize honesty and is detailed in Section 4."

"The total amount of the reward is the inflation rate of the Flare token and is determined by governance."

"F-asset holders who contribute data are not directly compensated by the FTSO. They may be incentivized to contribute because doing so provides greater surety over the validity of the data and/or contribution rewards specified within the application itself."

The FTSO will initially provide data estimates for:

XRP/Flare

USD/Flare

BTC/Flare

XLM/Flare

"Of those, the token holders of the initial dependent application, FXRP [Net20], will contribute to the XRP/Flare price in addition to the Flare holders."

"The FTSO is extendable to include additional time series, as detailed in Section 5."

"All data produced by the FTSO is freely usable by any application in the system."

"Thus any application can reformulate and augment the data in anyway the designers see fit."

SDA 3rd Component: Governance

Flare Used as a Participation Token in Governance Schemes

For info about Flare-mediated governance see Section 5.

Flare enables "a governance methodology across all elements that rely on it."

"Flare’s native token, the Flare, is required for spam control at the network level. Because the safety of the network is not contingent on the token itself, Flare can be used in ways which would be unsafe for other networks."

"Next, in Section 5, the governance of the network is discussed, whereby Flare token holders can vote to modify network parameters."

"The third component of the SDA is the use of Flare for governance purposes."

"Flare is used in the governance of the network and parameters around the Flare token."

"It can optionally be used by applications to involve a wider set of participants in critical decision making."

"There are no set rules as to how Flare is used in the governance of an SDA or for how long."

A full presentation of the governance system is detailed in Section 5.

---

3.2.2 Mitigating a potential trade off

"The three elements of the SDA structure deliver optimal utility only if they work together. Indeed, it is necessary that there be no competition between using Flare as collateral and those same Flare tokens being used to contribute to the FTSO or governance systems. An impediment to using Flare for all three elements simultaneously is generated by the use of Flare as collateral. This is because it is locked in a smart contract so as to be available to compensate one or many counter-parties upon the determination of the application."

"When Flare is locked in an application as collateral, the provider of that collateral still potentially has a claim on all or part of it, which is enforced algorithmically by the smart contract. In most applications, that claim will be the original collateral amount plus any additions less any losses and/or expenses. Usually the claim would correspond to the amount that the collateral provider could extract from the system if they were to unwind their participation in the application. This claim will likely be variable over time and is termed the Flare claim."

If there were no way for the address to use the Flare claim amount to contribute to the FTSO (and potentially earn the FTSO reward) then the addresses owner faces an undesirable opportunity cost in deploying that Flare as collateral in the application.

A system of delegation is thus introduced to resolve this.

Delegation allows an address to bestow all or a fraction of the votes associated with its Flare tokens upon another address for the purposes of both FTSO and governance participation without moving or transferring those tokens.

Each Flare token holds one vote that can be contributed to the FTSO and a separate vote that can be contributed to governance.

These votes may be delegated to different parties.

The opportunity cost described above is then solved when any application that creates a Flare claim automates delegation of the claim amount to an address specified by the collateral provider.

Token owners are free to delegate and un-delegate their votes at any time.

Delegation can be structured such that one party can delegate to a second party and that second party can delegate to a third and so on.

This leads naturally to the notion of an addresses voting power, which is used both by the FTSO and the governance system.

To summarise, applications that use Flare as collateral and allow delegation of Flare tokens do not impact the FTSO or governance functions and usage of Flare as collateral does not undermine network safety. Flare holders can simultaneously earn the FTSO return, return from any dependent tokens and continue to participate in governance.

3.3 Flare creation and distribution

The Flare token will be distributed to the XRP ecosystem in what is intended to be a soft fork that generates considerable utility for the original chain (XRP), by enabling the use of XRP with Turing complete smart contracts, instead of trying to compete with it. A more apposite term for the process would be a utility fork.

3.3.1 Apportionment

A snapshot of the XRP Ledger will be taken at a specified date, detailed in section 3.3.2. At the inception of the Flare Network 100 Bn tokens will be created. 45 Bn tokens will be claimable for 6 months by XRP token holders excluding AUGUST 27, 2020 known Ripple Labs accounts. The claim amount is calculated against XRP holdings at the time of the XRP Ledger snapshot via the apportionment formula, see definition 3.10. At the end of the claim period, any unclaimed tokens will be deleted. 25 Bn tokens will go to Flare Networks Limited and 30 Bn tokens will go to the Flare foundation. The Flare foundation, see section 6, is a non profit organisation intended to help develop the Flare Network and facilitate network governance.

Definition 3.10. XRP holders, bar Ripple labs, can claim Flare tokens according to the following apportionment formula:

  x Flare = x XRP /(N − N Ripple ) ∗ 45 Bn,      (2)

where x Flare is the amount of Flare claimable, x XRP is the amount of XRP held at the snapshot date, N is the total amount of XRP in existence at the snapshot date, and N Ripple is the total amount of XRP known to be held by Ripple Labs at the snapshot date.

3.3.2 XRP snapshot date

Because many XRP tokens are held on exchanges, the XRP Ledger snapshot will be taken at a point in the future when a sufficient number of exchanges have articulated to their clients whether they will claim the Flare token on their behalf. An announcement will be made on https://flare.network when the snapshot has taken place. The delay to taking the snapshot gives those XRP owners whose tokens are held in an exchange account but who wish to participate in the Flare distribution the means to do so should their exchange not provide such an option. Known exchange accounts who opt not to pass the Flare token on to their clients but still retain an XRP balance at the time of the snapshot will be removed from the token distribution. Any tokens that would have been claimable by those accounts will be reallocated prorata to valid claim holders.

4 Time series oracle

The Flare Time Series Oracle (FTSO) provides an estimate of information pertaining to the external world which is required on-chain.

For the system to rely on one (or) more external information sources in order to provide this estimate would effectively introduce centralisation. By harnessing the decentralised nature of the network, estimates of a wide range of time series data can be computed via a decentralised oracle. This leverages the peer-to-peer nature of the network, whilst incentivising Flare users to contribute via the earning of rewards.

In the following,

• some background on decentralised oracles is first summarised in 4.1 and
• an overview of the FTSO is presented in 4.2.
• Next, in 4.3 the process of computing the estimate is detailed,
• followed by a description of the compensation scheme in 4.4 and
• of the pseudo-random number generator in 4.5.
• Finally, in 4.6, the FTSO's susceptibility to attacks by malicious parties is discussed.

4.1 Background

Decentralised oracles typically leverage the system participants in order to vote regarding the nature of a given proposition. For instance, the Schelling Coin protocol [But14], uses a commit and reveal scheme, in order to gather votes from network participants. This results in a distribution over the votes, of which the top and bottom 25% are then truncated. The median of the resulting distribution is taken as the price estimate, and the 50% of voters whose submissions were used are rewarded. Such schemes can be studied from a game theoretic perspective, whereby each participant has to make a choice in order to maximise their reward. For instance, the Schelling Coin scheme hinges on the idea that such a game has a Schelling point, i.e. a focal point.

Over recent years, the need to query external information to the chain has sparked the development of various approaches to oracles, such as TruthCoin consensus, Chainlink, Astraea or Terra. The core feature of an oracle should be a decentralised data feed exploiting the distributed nature of the underlying system whilst incentivizing players to be honest.

4.2 FTSO overview

The Flare time series oracle is a decentralized application that aims to generate accurate estimates of off-chain time series data on the Flare Network. The oracle takes as inputs estimates from two sets of participants: Flare holders and relevant F-asset holders. At regular and prescribed time intervals (a governance parameter), participants from both sets may (but are not obligated to) submit to the system their current estimates.

The resulting set of votes forms a distribution over the data estimates, termed the weighted estimate distribution, see definition 4.5. In order to remove outliers, which likely consist of errors and attempts to be malicious, only the middle 50%, as determined by number of votes, is retained. This results in the updated truncated estimate distribution, see definition 4.6. The weighted mean of the truncated distribution is then used as the value estimate for the next A blocks blocks, where A blocks is a system parameter. Holders whose votes contributed to the final output are then compensated, as described in the compensation scheme in definition 4.12.

4.3 Computing the estimate

The time series oracle yields an oracle estimate of a given variable. These are computed by processing estimates from relevant token holders at regular time intervals, termed voting rounds. At the start of each voting round, relevant token holders (as later defined) submit their data estimate, termed their vote, from which the oracle computes the oracle estimate. The votes are submitted using a commit and reveal scheme.

Definition 4.1. A voting round t is a time interval during which votes can be submitted. This is a system governance parameter.

Definition 4.2. The vote v t i at voting round t is the submitted estimate of the ith participating address.

Each oracle estimate is determined by two groups with competing interests: holders of Flare, and holders of the F-asset tokens issued in relation to the relevant data estimate. For simplicity of notation, in the following, a single data estimate is considered. The proposed procedure can then straightforwardly be extended to n different time series.

Definition 4.3. For a given voting round t, partaking addresses consist of: 1. Flare addresses who choose to participate in round t, 2. F-asset addresses who choose to participate in round t.

Next, each account casts their vote i.e. submits their estimate. The number of tokens associated with the voting addresses at the start of the voting round are considered. Say the voting power of address i is x Si if it is a Flare address, and x Fi F-asset if it is an F-asset address. If it is an F-asset address, the voting power is proportionally scaled by an adjustment factor Q S t Q F t, resulting in the adjusted voting power, see definition 4.4.

...

As the voting power of F-asset addresses are adjusted and scaled to the amount of assets held in voting Flare addresses, the total amount of voting power Q t is given by Q t = 2Q St .

Then, the submitted votes weighted by voting power (or adjusted voting power depending on address type) result in a distribution over data estimates, termed the weighted estimate distribution P t . Each vote cast is weighted by the amount of tokens held as follows.

...

Next, the distribution is truncated by computing 0.25Q t , and deleting the lowest and highest such votes i.e. 50% of the submitted votes are retained. This results in the truncated distribution P t 0 over a new set of prices i.e. a same or smaller set. Indeed, if address i initially had x i tokens, then all, some or none of these may be deleted after truncation.

...

Finally, the output of the oracle can be computed by taking the weighted mean of the resulting distribution.

Definition 4.7. The oracle estimate is the computed estimate at voting round t based on partaking votes. It is computed by taking the weighted mean of the truncated estimate distribution P t 0 and is denoted m t .

The following two examples illustrate how the oracle estimates are computed. For simplicity sake, these consider the case where all partaking accounts are Flare accounts.

Example 4.2. Alice, Bob, Charlie and Eve hold respectively 10, 20, 30 and 20 Flare tokens, and decide to participate in round t of price voting. They are the only four participants who choose to vote. In terms of weighted holdings, this results in a total of 10+20+30+20=80 votes. Alice submits a vote for 3, Bob for 4, Charlie for 5 and Eve for 6, which results in a distribution over prices P t . Next, the top 25% and lower 25% of votes are discarded i.e. the top 20 and lower 20 votes are removed. The resulting distribution P t 0 is now 10 votes for price 4 from Bob and 30 votes for price 5 10 from Charlie. The weighted mean of this distribution is m = 40 · 4 + 30 40 · 5 i.e. m = 4.75, which is the oracle output.

Example 4.3. Alice, Bob and Charlie hold respectively 100, 50 and 100 Flare tokens, and decide to participate in a round of price voting. They are the only three participants who choose to vote. In terms of weighted holdings, this results in a total of 100+50+100=250 votes. Alice submits a vote for 2, Bob for 3 and Charlie for 4, which results in a distribution over prices P t . Next, the top 25% and lower 25% of votes are discarded i.e. the top 62.5 and lower 62.5 votes are removed. The resulting distribution P t 0 is now 37.5 votes for price 2 from Alice, 50 votes for price 3 from Bob and 37.5 votes for price 4 from Charlie i.e a total of 125 votes have survived truncation. The weighted mean of this 50 37.5 distribution is m = 37.5 125 · 2 + 125 · 3 + 125 · 4 i.e. m = 3.0, which is the oracle output.

More generally, if there are n estimates to compute, Flare addresses who choose to vote will no longer submit a single vote per round, but a list of n votes v = (v 1 , . . . , v n ). This will result in n estimate distributions, which will then each be truncated, resulting in n truncated distributions. The weighted means m i for i = 1, . . . , n of the resulting truncated distributions are then computed, resulting in n oracle estimates m = (m 1 , . . . , m n ).

...

4.4 Compensation

Flare holders that submitted an estimate that remained in the distribution after truncation are compensated. The precise amount of Flare tokens minted for reward is a network governance parameter, which is initially set at 10% of Flare tokens in circulation per annum, and is termed the award rate, see definition 4.9. The Flare token holders can subsequently vote in order to change this, as set out in section 5. Note that although F-asset holders can participate, they do not get compensated. Instead, F-asset holders are incentivized to vote to ensure the integrity of the data related to the F-asset.

Definition 4.9. The award rate r A is the annual amount of Flare tokens minted as a percentage of Flare tokens in circulation at the beginning of the year to be awarded to successful votes i.e. votes surviving truncation. It is by default set to 10%.

The total minted tokens for compensation per year is then broken down over the number of voting rounds over the year, which is also a governance parameter. This determines the award a Flare holder can hope to earn for each voting round.

Definition 4.10. The voting rounds per year k is the number of voting rounds that occur in one calendar year.

...

Example 4.4. Say there are 1440 Flare in circulation in year 1 i.e. S tot = 1440. At a default award per annum rate of 10%, 144 Flare is minted for compensation. For k = 12, voting takes place on a monthly basis (note that in practice, it will be far more frequent). Then, every month 12 Flare are available for compensation.

If n oracle estimates are computed at round t, then only one of these is rewarded. In order to determine which, a pseudo-random number between 1 and n inclusive is drawn, via the on-chain pseudo-random number generator, see section 4.5. Say the pseudo-random number drawn is k, with 1 ≤ k ≤ n. Then, the addresses whose votes have survived truncation for the kth distribution and thus contributed to the computation of the kth oracle estimate are rewarded. Each address i whose vote contributed to the kth oracle estimate is rewarded a compensation amount a i , computed as per definition 4.12. Thus, each voting round, a new oracle estimate will be rewarded, providing an incentive for participant to vote across all prices.

...

5 Governance

The Flare token is used as the primary governance mechanism over the Flare Network, the Flare token and the Flare Time Series Oracle (FTSO). These elements are detailed in what is set out below. Flare can also be optionally used for governance over dependant applications. This is determined by the application itself and is not relevant to this paper. Certain updates from governance decisions can be automated, termed automated processes, whereas others, the non-automated processes can not. The latter typically require a more complex procedure, requiring for instance changes to the codebase. Automated processes that relate to a variable which can take a range of values are designed to increment slowly so as to avoid shocks to the system. An emergency automated process is defined for situations where there is general consensus amongst Flare owners that the variable under consideration needs to be altered rapidly.

...

Table 1: Governance parameters on the Flare Network. Decisions that can be automated are shown in black whereas decisions that require a code change, and are thus termed non-automated, are shown in blue.

5.1 Decision categories

Governance decisions are made through voting using the Flare token. Each Flare token equals one vote. Because different decisions have different impacts on the network, three decision rules are specified: simple majority (definition 5.1), super majority (definition 5.2) and super super majority (definition 5.3). Each of these places specific requirements on the number of Flare tokens participating in the voting process, as well as the number of votes for a proposition to pass. The Flare tokens held by the Flare Foundation (section 6) may not be used to vote and are considered not to exist for the purpose of governance.

Definition 5.1. For a simple majority decision, a proposition is confirmed if strictly more than 50% of votes cast are in favor of it and there is a minimum turnout of 30% of total Flare tokens.

Definition 5.2. For a super majority decision, a proposition is confirmed if strictly more than 2/3rd of votes cast are in favor of it and there is a minimum turnout of 50% of total Flare tokens.

Definition 5.3. For a super super majority decision, a proposition is confirmed if strictly more than 80% of Flare tokens vote in favor of it and there is a minimum turnout of 70% of total Flare tokens.

...

5.2 Direct and delegated voting

Flare will follow a liquid democracy 4 model whereby token holders are free to vote themselves or to delegate some or all of their tokens (votes) to another entity which votes on their behalf, as defined in 3.8. A voting entity that amasses delegated votes can be formed by any one or collection of people. One of those entities will be the Flare Foundation.

5.3 Voting considerations

The following sections cover governance voting over automated variables and more complex decisions which require code updates. Voting is based on an addresses voting power, as defined in 3.9. To avoid an attack on governance whereby tokens are shuttled from one address to another during the voting period, Flare restricts an address’s voting power to its voting power at the beginning of any voting period.

Definition 5.4. The governance voting period T G is the number of blocks over which voting takes place.

The voting power of an address for the purpose of governance is then the voting power of the address in the first block of T G.

5.3.1 Automated Process

For variables which can be updated automatically, initial parameters will be set at the instantiation of the network.

Variables that can be automated are either binary or can take values that are a finite subset of the real numbers.

Definition 5.5. An automated variable is either binary or takes on one of a finite set of values. It is set through network consensus.

For non binary automated variables, reaching agreement on both direction and magnitude of a change could be complex.

Therefore, for such a variable, a preset increment is set such that the governance decision is over whether to increment the variable in a particular direction, and not in the size of the step. This is initially set by the variable creator, but can itself be governed in an automated fashion.

Definition 5.6. A variable increment is a predefined incremental increase or decrease, relating to a specific automated variable.

For any automated variable, a minimum preset threshold of interest to increase or decrease the variable (or switch state if binary) must be reached to trigger a network wide governance vote. A governance vote is the process that decides on the change in a variable.

Definition 5.7. A governance vote trigger is a smart contract associated with each automated variable, and which runs as follows:

1. The smart contract accepts votes over a voting period T G .

2. Each Flare address can place a vote, up to its voting power in the first block of T G , for the variable to either change (binary) or decrease/increase (by the predefined increment).

3. If at any point during the voting period, the sum of the votes in a particular direction exceed the preset threshold, then a network wide governance vote takes place, as defined in 5.8.

4. If at the end of T G an insufficient amount of votes are accumulated to lead to a governance vote, the governance vote trigger is reset and reinstated.

---

Footnote 4: Liquid_democracy

---

Definition 5.8. The governance vote is a network wide vote that takes place if a governance vote is triggered, and proceeds as follows:

1. The governance vote trigger system for that specific variable is suspended for the duration of the governance vote, as defined by the number of blocks T G .
2. The vote trigger outcome (i.e. to change state or increase/decrease the variable value) becomes the proposition for the governance vote over the specified variable.
3. The votes for the proposition accumulated in the governance trigger are automatically set in favor of the proposition.
4. Additional votes are accumulated during T G using each addresses voting power from the first block of T G .
5. If at any point during the voting period the sum of the votes exceeds the minimum defined by the preset decision category, the variable is incremented by the predefined amount in the direction specified by the proposition.
6. 6. If at the end of T G an insufficient amount of votes are accumulated to lead to a change in the variable the governance vote trigger is reset and reinstated.

5.3.2 Emergency automated governance

The automated governance process is purposefully designed to iterate through values slowly so that the system and participants have time to adjust and arrange their affairs accordingly. In certain cases however it may be necessary to make larger adjustments quickly.

During each governance trigger voting period T G , any address with voting power may enter a proposed numeric value that is at least n + 2 variable increments away from the current value, where n is an integer and governance parameter.

This creates an additional governance trigger proposal that remains for the duration of the current voting period against which voting power can be expressed. The same rules as set out in 5.7 are applied. If sufficient votes are amassed, then network wide governance vote is held over this value. Otherwise, the new governance trigger is deleted at the end of the current governance trigger vote period. Multiple additional governance triggers may be proposed provided they are at least n variable increments away from each other.

Definition 5.9. The Emergency governance vote trigger is a process which runs as follows:

For a specific variable that can be changed by automated governance and referring to that variables governance trigger:

1. If during a period T G , an address with voting power sends a transaction to the governance trigger contract, containing\ a suggested numerical value for that variable and that numerical value is at least n + 2 variable increments away from the current value or n variable increments away from any other proposed value, then:
2. An additional voting proposition is created within the governance trigger contracts that sets the suggested numerical value as a new proposition which can accumulate votes.
3. As per the governance trigger process each Flare address can place a vote, up to its voting power in the first block of T G , for the variable to either change (binary), decrease/increase (by the predefined increment) or for any additional voting proposition.
4. If at any point during the voting period, the sum of the votes for any proposition exceeds the preset threshold, then a network wide governance vote takes place for that proposition, as defined in definition 5.8.
5. If, at the end of T G , an insufficient amount of votes are accumulated to lead to a governance vote, the governance vote trigger is reset, any additional propositions are deleted and the governance vote trigger restarted.

5.3.3 Non-automated process

Implementing governance decisions that require a codebase change follows a non-automated process, where definition 5.10 specifies the sequence of steps taken for such a change, from inception to implementation.

The set of decisions that such a process encompasses is broad. For example, this would include decisions such as updating the set of dependent applications in order to add or remove an application.

This, in turn, may require an addition or subtraction of a price feed at the FTSO or an issuance of tokens via a secondary utility fork.

Definition 5.10. A non-automated process proceeds as follows:

1. A proposal submission, whereby a proposal is submitted via a form hosted at https://flare.foundation.
2. The submitter will receive a unique code from the Flare website which must then be submitted to a smart contract on Flare.
3. The smart contract now sets a new variable (the identifier) against which voting power can be accumulated and a block by which to define a freeze of voting power.
4. Once the foundation observes that the transaction has occurred, the proposal is published on the website in order to be publicly accessible and viewed.
5. Additional votes for a proposal are submitted by transacting with the smart contract using the proposal identifier.
6. The voting period for the proposal is approximately 3 months after which the variable is terminated.
7. A foundation analysis trigger, the foundation will initiate analysis on any proposal which reaches 50% of all voting power.
8. A foundation report is an analysis on a proposal compiled by the Flare foundation, complete with findings and a recommendation. Foundation may reject the proposal and end the process for the following reasons: legality, the proposal if successful would exceed foundation resource management constraints, technical in-feasibility, network safety parameters.
9. A first hurdle, as per table 2 any proposal must accumulate voting power exceeding its decision category within its voting period.
10. If the proposal relates to updating the FTSO composition, F-Asset list and/or related time series, network parameter I or network parameter n, this will be the only vote and the changes will be directly implemented*.
11. A build and test, whereby if the proposal requires code changes, these will be implemented and tested on the Coston test network.
12. A second report is compiled by the foundation, whereby the foundation issues its recommendations for any proposal that requires a second vote.
13. An implementation vote. The foundation second report contains an identifier against which a second round of voting takes place. This round is always decided by a simple majority decision.

Certain non-automated decisions can be implemented by augmenting smart contracts or adopting new sets of smart contracts. Other decisions however require node operators to adopt a new version of the Flare Network code distribution.

It must be noted that nodes cannot be forced to run a new code distribution. The purpose of the non-automated methodology is to sort for potentially beneficial updates, involve the technical expertise of the Flare foundation to advise or build the update where applicable, utilize Coston as a testbed for those potential updates and then through voting show a weight of Flare tokens behind those updates. This weight of Flare tokens is then likely to incentivize nodes to adopt the update.

5.4 SDA interaction with Flare governance

An SDA interacts with Flare governance in a number of defined ways.

An SDA or potential SDA that wishes to add a data stream to the FTSO will use the non-automated governance process to propose the addition which may or may not be successful.

An SDA or potential SDA can use Flare token holders as their governance set in whole or in part for any duration without the consent of the collection of Flare token holders.

The participation of Flare token holders is entirely optional.