By Seated on a tenuous perch atop the Flare network’s governance process is the Flare Foundation. The foundation is a non-profit organization responsible for the development and improvement of the network. It is constrained by five guiding principles:
1. No voting
2. No collateral
3. No oracle participation
4. The right to dissolve
5. Reporting
The first two principles seem simple, but they are important in maintaining the network’s decentralized structure. The initial distribution of Spark grants the Flare Foundation a large stipend of tokens. Spark tokens are used as collateral for the network and are also used to vote on network governance issues. If the Flare Foundation were able to vote with these, it would give them an inordinate amount of power in the network’s democratic process, which would essentially make the network centralized. As they cannot vote, and they cannot hold collateral, they are not able to exert direct control on the network’s democratic governance process through these mechanisms, and they would not be able to influence the price and reward ratios by leveraging the large amount of Spark tokens they were gifted for the development of the network. If the Flare foundation were permitted to use their Spark as collateral, they could satisfy collateralization needs almost entirely themselves, particularly during the early development of the network, which would scare other independent participants away. And if interested parties wanted to make income through staking rewards, it would be difficult to do so because of the large amount of Foundation tokens potentially being used to stake.
Ripple is also not being credited Spark tokens for their large XRP holdings. Doing so would give Ripple a tremendous influence over the governance process of the Flare Network. Cryptocurrency Exchange XRP holdings are also being accounted for to prevent organizations from keeping tokens themselves and skewing the democratic process with their XRP holdings. If each Spark token counts as one vote, handing these tokens without restriction to exchanges that hold large XRP reserves would be handing these organizations a massive amount of voting power for the Flare Network.
“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 Spark token on their behalf. An announcement will be made on https://flare.xyz 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 Spark distribution the means to do so should their exchange not provide such an option. Known exchange accounts who opt not to pass the Spark 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 pro-rata to valid claim holders.”
What’s not clear to me in this process is how the Flare Network is avoiding a scenario similar to the attempted Steem hijack, wherein exchanges colluded and staked tokens to cast votes on the Steem blockhain without user permission. The Flare Foundation has indicated that they are accounting for exchange crypto assets to exclude organizations that aren’t giving their users the option to claim Spark in the distribution process, so they clearly have some account of XRP wallet addresses controlled by these exchanges, and should be able to prevent Spark associated with these accounts from voting.
After the initial distribution of Spark, if these exchanges begin opening custodial crypto wallets for holding Spark tokens, I don’t see why they wouldn’t be able to move the tokens to a new unknown exchange wallet, or even several new wallets prior to the announcement of a new voting proposition and cast votes from these accounts once the voting opened on the network. Tracking these movements before each vote is possible but seems cumbersome and distinguishing an independent transaction by a large stakeholder wallet from one created by the exchanges themselves to mimic one seems difficult.
This is where having a foundation at the head of the development and implementation of network features could come into play. The legality of casting a vote without permission is dubious. Casting a vote on behalf of a user who is holding cryptocurrency on an exchange is like writing a letter on behalf of a user to a public official or signing their name on a petition without prior authorization. As any proposed governance change would need to be developed and vetted by the Flare foundation, the foundation could ignore the results of that particular vote by virtue of the fact that the exchanges were not granted permission to vote on a user’s behalf. The Flare Network whitepaper indicates that the Flare Foundation can reject any confirmed proposals that would fundamentally break the security and decentralization of the network, and the foundation could treat an amendment passed by stolen votes as such an issue.
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.”
Of course, this is a two-sided issue, where the foundation, operating in bad faith, could reject a legitimate amendment. In that case, the community can vote to dissolve the foundation.
The Flare Network also depends on information external to the blockchain to maintain decentralization. The data is gathered from external sources by the Flare Time Series Oracle, which the Flare Network whitepaper describes as “a decentralized application that aims to generate accurate estimates of off-chain time series data on the Flare Network.”
Time series data is a confusing descriptor for someone who is non-technical, but the Flare Network’s blog indicates that these will be data sets that initially include “…prices for: XRP/Spark, USD/Spark, BTC/Spark, and XLM/Spark.”
Time-series data refers to things like price indices tied to a specific period of time since both the price data and the time of the gathering is important to maintain things like collateralization of the network. If the price of XRP spikes suddenly, the Flare network needs to have accurate “time series data” to ensure that there is a sufficient amount of Spark in the network staked as collateral so that there’s no incentive to take XRP placed in the network and run away with it if there’s a large discrepancy between the price of XRP and the amount/value of Spark collateral in the network.
The price reporting is done by stakeholders, so as to not introduce centralization issues that could be tied to price reporting. Trusting a single party or group with control over the oracle services would give them leverage over the system itself. They could hold the network hostage by threatening to throw the collateralization calculation out of whack with false price indicators if the network refused to implement a policy that benefitted their specific group. Control over the reporting of external XRP data could also give a group of attackers incentive to mess with the collateralization ratios to try to make a profit.
The Flare Network records time-series reporting from two different types of stakeholders. The first is from Spark holders, who are given a financial reward for accurate data reporting. The second comes from the dependent application holders like holders of FXRP who, according to the foundation’s blog, are incentivized to participate because accurate data is tied to the security of their applications.
The FTSO balances competing economic interests against each other to ensure accurate reporting data:
“In this case, the F-asset is FXRP, and the time series oracle provides the on-chain XRP/Spark price, based on the estimates being submitted by both holders of Spark and FXRP. By virtue of holding either FXRP or Spark, both these groups have an implicit stake in the system i.e. an incentive to act honestly, as accurate pricing maintains the systems integrity and utility.”
The counterbalancing of interests is similar in practice to the left/right dichotomy present with American political parties. The underlying principle is that this counterbalancing of powers acts a break on the kinds of wide-sweeping societal changes that often end up causing a great deal of harm. A real-world example of this kind of harm is the Dekulakization that took place in the Soviet Union, where the Soviets liquidated the prosperous peasant cast and engineered a famine that killed 3.9 million people in Ukraine.
The stakes for the Flare network are not quite as high, but the above example should be an indication of why weighing competing political and economic interests as a governance tool are important as a function for any decentralized technology or political/democratic system. For the Flare Network, the financial incentives provided to Spark holders motivate them to report accurate data. For F-Asset holders, if they allowed Spark holders to report inaccurate data, they stand to lose money once the security of their application is broken. In essence, non-participation in the oracle services could wind up costing them a great deal of money even though they’re not granted a direct financial benefit from participating in the vote.
The associated documentation for the Flare Network indicates that voting, both with governance issues, and oracle issues, follows a form of delegative democracy called liquid democracy wherein voters have the choice to either cast a vote themselves or to assign their votes to a trusted delegate. The Flare Network whitepaper indicates that one of these delegates will be the Flare Foundation.
Speculating on the nature of the political landscape of the Flare Network is very difficult as it’s incredibly early in the development of the network, and we can’t be certain that the idea will even find widespread adoption. Nevertheless, I find it likely that during the initial stages of the development of the network, the Flare Foundation voting bloc, which we can look at as being a structure akin to a political party, will have a majority of the network’s voting power. This isn’t necessarily a bad thing. Vitalik Buterin argued in an unrelated comment that the ideal initial setup for decentralized networks is dictatorship – far away from how the Flare Foundation is formally structured, as stakeholders are permitted to vote on governance issues independently of the foundation.
These kinds of initial top-heavy approaches are not unprecedented or even undesirable within the early lifecycles of decentralized systems.
As the network develops, it’s likely that incumbents with divergent interests and goals from the foundation will develop and form voting blocs or alternative political parties. That is not to say that these groups will be interested in harming the network, but they generally will be as self-interested as any of the comparable political parties (Republicans or Democrats) can be while still wishing to maintain the health of the overall system. As they’re all participating in the network economically, they have a vested interest in maintaining these functions of commerce.
Another possibility, which I find more likely if the network fails to find widespread adoption, is that the Flare Foundation’s voting bloc retains a majority of the voting power for the network, making it the network’s single viable voting bloc.
One interesting feature with voting delegates is that they can be either a single person or group of people. At face value, it seems dubious to trust a large amount of voting power to a single person as a delegate, but I suppose if they are also a large stakeholder and trusted member of the community, they would have an interest in maintaining the value proposition in their stake. Spark holders also have the option transfer a portion of their votes to a delegate:
Delegation allows an address to bestow all or a fraction of the votes associated with its Spark tokens upon another address for the purposes of both FTSO and governance participation without moving or transferring those tokens.”
I’m not certain how far this delegate granularity extends. Given the option, I would consider using a trusted delegate for Time Series Oracle participation, but I would rather directly vote on more foundational proposals.
Another issue brought up in the whitepaper, and one that I find difficult to wrap my head around is the participation of staked Spark tokens in accumulating FTSO rewards. The whitepaper outlines that spark holders using their Spark as collateral to generate FXRP will still be able to participate in votes for the Flare Time Series Oracle by delegating their votes to another address:
“If there were no way for the address to use the Spark 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 Spark 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 Spark tokens upon another address for the purposes of both FTSO and governance participation without moving or transferring those tokens. Each Spark 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 Spark claim automates delegation of the claim amount to an address specified by the collateral provider.”
Does this mean that staked Spark tokens can’t participate in the FTSO without delegating to another address? That’s what it sounds like in the quote above. Keep in mind I’ve never participated in a DeFi blockchain voting process, so it’s difficult to picture what this might look like in-practice from just reading a white paper.
A recent reply to this question by @FlareNetworks:
Voting
Spark tokens are the primary mechanism by which users vote, with one token corresponding to one vote. The whitepaper indicates that propositions can fall under three different voting difficulty categories. These are: Simple Majority, Super Majority, and Super Super Majority. Each of these categories has a minimum voter turnout rate as well as a specific goalpost number that is required for a proposition to pass:
For the most difficult category of propositions (Super Super Majority), the required voter turnout rate is 70% of total spark tokens. For the proposition to pass it also must capture a threshold of at least 80% of votes in favor of the amendment. The Super Majority category would be the most familiar to citizens of the United States as Super Majorities are required to pass constitutional amendments.
Most of us are accustomed to citizens in a democracy being granted a single vote. Having more voting power simply by virtue of an individual having more of an intangible asset seems contrary to the democratic spirit. Nevertheless, it’s important to keep in mind these are very different structures. It’s far easier to verify identity in the real world than it is on a pseudonymous blockchain. And a DeFi platform won’t be required to embed itself in the physical world to the extent that a formal government would (providing welfare, collecting tax, buildings roads, funding healthcare, the military, policing, holding territory, maintaining borders, defending sovereignty, etc.).
In most western democracies, we are accustomed to casting votes for representatives. We’re often not required to vote directly on an issue. Direct-democracy of that nature is comparatively rare in large nations – not unheard of, as elected officials sometimes put issues to a popular vote. It is far more common for most decisions to be made by our representatives found in whatever major political party manages to capture the seat of power, either by winning a majority or forming a coalition.
The liquid democracy model isn’t strictly a direct democracy model, but it allows individuals to vote for each separate issue if they wish. The voting process found in the Flare Network seems designed to enable voting for participants in a pseudonymous network, where it’s difficult to have identity verification of the kind found in a formal nation-state. Nevertheless, I could envision the process of voting through single delegates or a group of delegates leading to the same kinds of factionalism and party politics that we find in traditional democracies. And the delineation between something that exists online and something that interacts with the physical worlds is increasingly becoming blurred. The question then becomes, how does the foundation counteract the notions and issues of plutocracy that spring up whenever we have a voting scheme that is ostensibly tied to associated wealth in a network? Their answer to this issue is to have stringent requirements to pass propositions, depending on the impact these propositions could have on the network, and by balancing major stakeholder’s economic interests against the value of an asset that they hold a large amount of.
Major stakeholders, or the voting blocs mentioned above, even though they may have a large amount of voting power, may have difficulty reaching the requisite voting thresholds to pass the kinds of propositions that fall under super and super super majority categories. Even though a stakeholder might be wealthy in terms of spark assets, their influence on amendment propositions is limited by the stringent requirement of both voter turnout and the large percentage required to pass the amendment.
Some may question the difference between the foundation operating one of the network’s most powerful voting delegates versus them being allowed to vote with their Spark reserves. As I indicated above, it’s likely that the foundation’s voting bloc will be trusted by a large portion of the community during the Flare Network’s early lifecycle, which would give them a majority of the vote. I suspect that average users won’t have the wherewithal or the motivation to vote directly on every single proposition that is put forward onto the Flare Network, so trusting the foundation as a voting delegate would be a convenient decision. The difference between the two approaches of allowing the foundation to vote with their Spark as opposed to operating a powerful voting delegate is that the former is permanent power as long as they keep a large enough portion of their Spark reserves, whereas the latter is temporary power, likely to dilute over time as new personalities and groups emerge that the community trusts enough to act as their delegate, or if the Foundation operates in a manner that members of the community oppose. Allowing the foundation to vote with their Spark holdings is permanent tyranny, whereas operating a major voting delegate is temporary stewardship.
If you enjoyed this article and would like to support future content, please consider signing up for Coil using my affiliate link.
