Blockchain Governance Overview: EOS Mainnet
--
This article provides an overview of the current design of blockchain governance for the EOS Mainnet from the perspective of one of the early participants.
The questions are drawn from the Wharton Cryptogovernance Workshop’s 37-question “long version” questionnaire. (I had a hand in creating it.) Both the long and short versions of the questionnaire provide a common set of questions, the answers to which should provide a reasonably thorough overview of the governance of a specific blockchain system.
My goal here, working in parallel with others from the Wharton Cryptogovernance Workshop (WCW), is to provide several overviews of functioning systems, public and private. Our hope is that these overviews will serve to advance the state of the art and science of blockchain governance, by letting practitioners and academics look at many different systems that have all been examined through a common lens.
Wharton Network Governance Disclosure Questionnaire
I. Respondent(s)
1. Which network are you providing answers for in this questionnaire?
EOS Mainnet
2. Name of respondent(s)? (Legal names, pseudonyms, usernames, etc. are all valid responses)
Thomas B. Cox, EOS: thomasbcox23, Twitter: @TBCox
a. What is your role in the network?
I helped design (under the direction of Dan Larimer) the default governance settings that were made available prior to the software release, and I followed governance developments closely thereafter for about nine months.
II. Background
3. How do you define the purpose, goals, or scope of the network?
The stated goals of EOS Mainnet at launch (as I understood them) were to create an EOSIO software based mainnet that reflected the EOS token distribution and that would be attractive to business usage. Because the launch was performed by the community and had no involvement from Dan Larimer or Block.one (authors of the EOSIO software), the “purpose, goals, and scope” were and are defined by the community that launched it and that today operates it.
4. What do you consider success for the network? Do you have metrics to measure success? If so, what are they?
I consider “success” to be “a public mainnet with predictable uptime and throughput that allows token holders to govern the system and allows smart contract developers to create and run innovative projects that solve user needs.”
My personal metrics for success would include:
● Stable token price (price has actually fallen substantially — I should note that I have no objective reason for assuming the token price would or even should be stable)
● Large number of tokens used to vote for BP (> 30%) and for referenda (> 15%). In fact, voter turnout was for the first year somewhat lower for BP selection, and VERY much lower for referenda. (BP selection now achieves 40% turnout.)
● Continual evolution of the software with new features coming online at least annually. (This goal has been exceeded.)
● Increasing number and variety of DApps offered (success)
● Increasing number of users onboarding (success)
● Robust second-layer offers to mitigate bottlenecks or issues endemic to a DPOS public mainnet (yes via LiquidApps VRAM and DSPs)
5. What, if any, are the coordinating entities associated with this network, and what are their functions? (E.g. foundation, development corporation, DAO, etc.)
● The “top 21 BPs” are dynamically defined by the software as the BPs with the most votes. By virtue of getting votes, a BP that enters into the Top 21 gets its signature included in the dynamic multisig called “eosio.prods” — any transaction signed by 15 of the Top 21 will bypass security checks and, if the code is valid, it will be executed.
● Block.one provides software development coordination in an unofficial and informal capacity
● The EOS Alliance attempted to be an information clearinghouse for governance discussions, but has gone dark
● ECAF used to be the mainnet’s designated arbitration / dispute resolution group, but its role ended when the BPs replaced the EOS Constitution with the End User Agreement (“EUA”) on or about 18-Apr-2019. ECAF issued only a handful of dispute resolution findings before being dissolved.
● Beyond discussion forums and the EOS Alliance, there is currently no other known coordinating entity for token holders, though voting patterns suggest there may be one or more that are either formal but private, or informal.
6. Are network participants identified (i.e. keypair associated with accounts or UTXOs, wallet number, government ID, etc.)? If so, how?
EOS mainnet actions are taken by accounts. Accounts can have many keys. Each account is uniquely identified by a 12-character alphanumeric string [a-z][1–5] that is the account name. A new account can be created using any unique new name of the creator’s choice (new names are not system assigned nor random).
III. Stakeholder Groups
7. Are there currently groups without whom the project collapses? (e.g. the group of core developers pre-launch; the group of funders) — if so, describe them.
No, the project is past this point.
8. Does the network’s dry code (coded/machine-executable) recognize or delineate different groups? If so, how and who?
The dry code identifies only these groups:
● Token holders
o Who have not deployed smart contracts
o Who have deployed smart contracts
● Registered BPs in three mutually exclusive subgroups
o Unpaid standby
o Paid standby — Receiving vote pay only
o Active BPs in the top 21 — Receiving both vote pay and block production pay
Every account has to have at least a small number of tokens in order to exist. There are no code based distinction among accounts or account holders, other than to notice whether one has chosen to deploy a smart contract. Every account is theoretically capable of deploying a smart contract.
Every registered BP has the opportunity, based on its current vote totals, to move through the three subgroups with each election. (Votes are tabulated every 60 seconds but the change of BPs in the lineup takes longer than that to be implemented: 60 seconds to count the votes, 165 seconds to reach finality, then anywhere from zero to up to 126 seconds for the prior round to complete.) This is automated and deterministic.
There also exists via LiquidApps a class of virtual users with virtual accounts, but they are not visible to the Mainnet and are not defined by its dry (or wet) code.
9. Are different groups delineated by the wet code (informal/social, formal/legal structures) of the network? If so, how and who?
The only formal wet code structure of the Mainnet is the EUA. The EUA text can be found here. By my reading, it creates only one additional groups beyond those created by the software (BPs, token holders): it defines a mainnet User as “ Any person or organization of persons who maintain(s) direct or indirect ownership of an EOS account, or EOS-based property connected to an EOS account.”
10. Are there groups, not already incorporated in answers to prior questions, directly affected by the network’s operation (positively or negatively)? If so, who and how?
● The LiquidApps virtual users are affected by network congestion
● Developers. (Perhaps already covered as ‘token holders who deploy smart contracts’)
● Users of games/DApps who may be unaware the game/DApp is run on EOS Mainnet.
● Operators of proxy voting services.
● I’m unaware of any other groups not previously covered.
11. Are there groups, not already incorporated in answers to prior questions, indirectly affected by the network’s operation (positively or negatively)? If so, who and how?
I’m unaware of any, beyond butterfly-wings effects. Perhaps EOS token short-sellers might fall in here. Analysts.
12. Are there other groups that impact or are impacted by the network not identified in answers to questions 7–11? If so, who?
Not that I can identify.
In the following questions, we use intrinsic groups to refer to the groups identified in questions 7, 8, and 9; and extrinsic groups to refer to groups identified in questions 10, 11 and 12.
13. How can users gain access to/exit each intrinsic group?
How to access each intrinsic group:
● To become a token holder: buy tokens and create an account (or pay someone to create an account for you)
● To become a token holder with a deployed DApp: become a token holder as above, and then create a DApp (create a smart contract)
● To become a registered BP: become a Token Holder, then invoke the ‘regproducer’ system contract action
● BP with vote pay: invoke ‘regproducer’ and then get enough votes to cross the payment threshold
● BP with both vote pay and block production pay: invoke ‘regproducer’ and then get enough votes to be in the Top 21 BPs
● One can voluntarily exit the set of registered BPs by invoking ‘unregprod’ system contract action.
14. How can each intrinsic group gain the ability to interact with the network, or with other groups (including access/contributions/mere observation)?
Each intrinsic group can equally access the network to submit transactions.
Each group is defined by its powers, and the powers are gained by an individual by entering each group, by performing the action required to enter it (i.e. deploy a DApp or collect votes).
A user/account must stake some amount of EOS tokens to network bandwidth and CPU, and buy some RAM with tokens, in order to submit transactions. More RAM may be required to deploy DApps.
Any account may submit a transaction to be signed by one or more others.
Any person (with or without an account) can anonymous query the EOS public mainnet via one of the block explorers provided by the community.
There are off-chain communications around code contributions. These are mostly coordinated by active BPs and also by Block.one, publisher of the EOSIO software, using GitHub and Telegram as primary mechanisms.
15. Are there mechanisms to prevent or limit the interaction of an intrinsic or extrinsic group with the network, or with other groups? If so, how do those mechanisms operate?
Everything under this heading is handled by the code and operates on intrinsic groups only. Limits on users include:
● CPU and network bandwidth usage is limited to an amount proportional to the tokens staked and/or leased for the purpose of utilizing either CPU or network; the system limits each account’s usage based on their amount staked for each resource, and the availability of that resource.
● RAM usage is controlled by each account purchasing RAM at a variable rate based on RAM availability using a market making mechanism.
16. Are there mechanisms to include specific intrinsic or extrinsic groups in the various aspects of the network? If so, how do those mechanisms operate?
Nothing currently beyond what the code does as described above.
17. Does the network and its governance accommodate an increase in the number of groups, diversity, or size of an intrinsic group? How?
All of the intrinsic groups can expand without limit, except the Top 21, where the number 21 is fixed in the code.
18. Are there groups identified in question 7–12 whose interests you believe should NOT be considered by the network’s governance? Which groups and why?
No.
19. What are the costs of exiting the network? (eg. loss of data, time, money, status, connectivity)
To exit the network would involve probably selling one’s tokens and RAM. That would involve either a capital gain or loss. One can also sell or burn one’s account. Exiting would mean a loss of ability to submit transactions, to be a BP, and to deploy DApps.
To exit the network would not involve a loss of access to (most) data as the chain is capable of being queried anonymously by non-account-holders. The exception would be access to data controlled/restricted by encryption or obfuscation systems, such as that provided by PrivEOS.
20. What are the costs of exiting a particular intrinsic group? (eg. loss of data, time, money, status, connectivity)
In addition to the above, exiting any of the BP groups would involve the opportunity cost of not earning future vote pay or block pay.
IV. Incentive Schemes
21. What behaviours does the network seek to incentivize?
The EOS Mainnet seeks to incentivize any and all behavior by a BP that will result in that BP receiving votes, because having votes results in earning “vote pay”. In addition, earning enough votes to reach the Top 21 results in receiving “block pay” for every block successfully created.
There is a savings account (called “eosio.saving”) for a Worker Proposal System (WPS) but the community has not created an agreed mechanism for tapping that fund. Thus the savings account mechanism is not currently incentivizing any particular behavior. The intention was for the fund to be tapped to pay for software contributions, upgrades, bug fixes, etc. but this is not yet occurred and does not appear likely to.
There has arisen a semi-formalized pay-for-votes arrangement whereby some BPs offer “rebates” and “incentives” to their voters, effectively paying those voters from the income stream provided by vote pay and block pay.
22. How are such behaviours incentivized, implicitly or explicitly? (E.g., financial benefits, belief in shared values, costs of network failure, or costs of exiting the network)
The two behaviors currently incentivized are (A) vote-seeking and (B) block production, and the sole mechanism for both is the award of system tokens created via an inflation function.
In theory, reliable block production is incentivized by voters, as voters should withdraw votes from unreliable BPs. In practice this has occurred only sporadically. Most voters appear to have a high tolerance for poor BP performance (as of November 2019).
The pay-for-votes mechanism is incentivized explicitly by payments by participating BPs using the system token.
23. When and how do participants have ‘skin in the game’ (exposure)? (E.g. financial, reputation, legal, etc)
For token holders, the sole skin-in-the-game mechanism is the token price. Large holders of tokens are presumably constrained from system-harming behavior by a desire not to reduce the value of their tokens.
There is NOT any slashing mechanism for token holders who choose BPs that fail to make blocks, nor do BPs suffer any direct impact other than the loss of ‘block pay’ for blocks they fail to make.
There previously (from launch in June 2018 to about April 2019) appeared to be a social contract whereby BPs provided various network-enhancing “public goods” type services to benefit all token holders (block explorers, code, tools, etc) but that social contract has largely collapsed in favor of BPs being incentivized to buy votes, and voters being incentivized to shop their vote around for the greatest return. Most BPs no longer invest in network-enhancing activities.
24. In the case that the network is already launched, how well are the incentives functioning in practice? What unintended consequences are visible or anticipated, if any? Were revisions to the incentive schemes made, or are they planned?
The mechanics of vote pay and block pay have functioned flawlessly.
The social contract between token holders (voters) and BPs has evolved (or devolved) as described above.
25. Is there a fund or system for paying for infrastructure, protocol upgrades, development work, network enhancements and/or other work deemed to be in the interest of the network?
a. If no: what are the incentives for upgrades and enhancements?
YES
b. If yes: what is funded by whom? Who performs the work? Who judges the work? What recourse is there if work is below quality?
There is a WPS fund as described above in question 21. It is funded automatically by 4% inflation (the remaining 1% inflation is used to pay both Vote Pay and Block Pay). These tokens are collected into the “eosio.saving” account.
The community has not established a mechanism for tapping this fund, so it has not been used to pay for anything.
The community did perform a one-time burn of the balance of “eosio.saving” that removed 34 million EOS tokens then worth $167 million from the system on or about 08-May-2019.
c. If yes: How is the fund protected from looting, capture, or other forms of abuse? What reporting requirements, if any, are individuals and teams who receive funds from “coordinating entities” or “the protocol” required to adhere to?
As above, there is no such fund operating today.
V. Governance Powers
26. What do you consider the sources/roots of the network’s governance legitimacy/authority?
I personally consider all public mainnets to be might-makes-right systems, where whatever the code allows you to do, is okay to do. To the extent there is a lineage of legitimacy, it’s from the EOS White Paper, and the EOS token sale, and the fact that EOS mainnet has a genesis block that matches the details of the EOS token sale.
27. Who has power to introduce proposals (non-binding signals, binding votes, or other proposals)?
a. Which of the “stakeholder groups”, as very broadly defined in Section II, have which types of policy setting power?
There are two methods — “signals” via votes on proposals in the Referendum system, and proposed msig transactions. Any token holder can create either. Both are recorded on-chain.
b. How does a stakeholder group attain or lose this power?
n/a — the power is inherent in owning tokens on the mainnet. Anyone can do either.
28. Who has policy setting (“legislative”) power to decide on proposals?
a. Which of the “stakeholder groups”, as very broadly defined in Section II, have which types of policy setting power?
The top 21 BPs decide on proposals. They typically do so by trying to guess what token holders want, since BPs hold their positions solely due to votes from token holders. A BP who displeased a large group of voters would lose his money-making position in the Top 21.
One could conceivably say that the token holders set policy, but I disagree. Token holders could set policy directly by voting in large numbers in the Referendum system, but they only vote in small numbers (2–3% of all tokens). Token holders could also set policy by voting for BPs who agree with the token holders’ policy preferences, but today there is no public evidence of explicit policy setting via voting.
b. How does a stakeholder group attain or lose this power?
The power is inherent in the ‘prods’ ability that the EOSIO code grants to the top 21 BPs. A given BP gains ‘prods’ power by joining the top 21 by getting votes as described above in that section.
The power to vote for BPs is inherent in owning tokens.
29. Who has implementation (“executive”) power to execute (carry out or enact) proposals, once decided upon?
a. Which stakeholder groups have which types of executive power?
The top 21 BPs carry out proposals via the ‘prods’ power which is used to enact system changes, upgrades to the System Contract, etc.
b. How does a stakeholder group attain or lose this power?
A given BP gains ‘prods’ power by joining the top 21 by getting votes as described above in that section.
30. Who has interpretive (“judicial”) power to decide how to apply an agreed policy to a specific instance?
a. Which stakeholder groups have which types of interpretive power?
There is no such group or institution today. The Top 21 BPs have the power (but no explicit authorization) to do this — but they have no process for so doing.
b. How does a stakeholder group attain or lose this power?
N/A
31. Does this network facilitate transparency with regard to the use of governance powers? (i.e., are there “information clearing mechanisms” for instances of abuse or effective use)
o How do these mechanisms operate?
The only on-chain mechanism is the inherent transparency of the network and the ability of the chain to be queried.
There are extrinsic groups formed off-chain who attempt to do this, including EOS Go, Everything EOS, EOS Watchdogs, etc.
o Are there different degrees of transparency for different stakeholder groups?
No. There is no on-chain differentiation of transparency for different intrinsic groups.
o How does a stakeholder group attain or lose this power?
n/a — no such power is formally in existence
VI. Governance Procedure
32. How are conflicts resolved?
There is not currently any process, mechanism or institution for conflict resolution. An earlier institution, ECAF, was disbanded.
33. What checks and balances/systems of accountability exist among the governance powers in Section V?
Voters have a check on BPs because voters can vote BPs out within 2 minutes. That is the only check-and-balance of which I am aware.
34. Is there an explicit system for signals (non-binding) or votes (binding) on network governance decisions?
a. If a voting or signaling scheme is used: How is the information about a vote or signal communicated, are explanations given, consequences and impacts of the different proposals explained, in which languages? How long is this information available? How are network participants able to respond to potential changes, if otherwise?
The answer in item 27 above holds here. There are informal off-chain mechanisms for explaining proposals via Telegram chats, Medium posts, tweets, etc. When explanations are given, the most common languages are English, Chinese, and Korean.
b. If there is voting, how is the voting system structured/conveyed? Who has the right to vote, and for what?
The only binding ‘vote’ on the system today is when a multisig transaction is proposed onto the chain with an expiration date, and the Top 21 BPs have that length of time to sign it (or not). If it collects 15 cryptographic signatures before the expiration date, then the ‘prods’ threshold of 15/21 is met and the transaction (if valid) will occur.
The Top 21 are selected as described above. Anyone with an account and a few tokens is eligible to propose a multisig transaction, but BPs are free to ignore them.
The precise mechanism by which any transaction can be proposed for multisig (by any signers, not just the BPs described above) is explained in this article: https://www.eoscanada.com/en/gathering-signatures-for-an-msig
c. If there are signals, how is the signal system structured/conveyed? Who has the right to signal, for what?
The Referendum system is used as the primary on-chain signaling system. It was originally conceived as being a system for casting binding votes under the original Constitution, but no vote ever reached the 15% turnout needed to be binding. When that Constitution was replaced with the EUA as described above, the Referendum system was kept and is now used by BPs as a way to gauge token-holder sentiment.
Anyone can propose an item into the Referendum system. All token holders can vote via a one-token-one-vote method.
d. Is voting or signal history public or private? For how long? By wallet/network address or equivalent (see question 6) or by group?
All voting and signaling is immediately public and remains visible via history nodes indefinitely. The actual votes are removed from the chain state memory when an expiration period has elapsed; I believe it is 30 days.
35. Consider the system’s rules and norms encoded in “wet code” (informal/social, formal/legal) and/or “dry code” (coded/machine-executable), whether discussed or not in answers to the questionnaire thus far.
For each:
a. Are there aspects that can be changed by ordinary processes, for example: via majority votes, Bitcoin soft forks (“statutory rules and norms”)? If so, what are they?
There is no mere majority votes or ‘statutory’ type votes. All changes must be approved by a 15/21 supermajority of the Top 21 BPs as described in the next item.
b. Are there aspects that can be changed by extraordinary processes, for example: via supermajority votes, non-contentious Bitcoin hard forks (“constitutional rules and norms”)? If so, what are they?
I consider the 15/21 BP vote threshold to be ‘extraordinary’ because it (A) is a 2/3 + 1 supermajority requirement, and (B) is the same threshold needed to change the System contract and all major aspects of the chain’s functioning, from inflation rate to BP pay policy to vote policy and so on.
c. Are there intrinsic aspects that should never be changed, for example: only via revolution/coup/contentious Bitcoin hard fork (“core rules and norms”)? If so, what are they?
This question was inspired by the German constitution’s ‘immutable’ clauses. There is nothing that I can think of that would qualify — all aspects of the chain from the inflation rate to the one-token-one-vote policy to the 30 preference votes per token toward the Top 21 selection, have been discussed for possible amendment. I’ve seen nothing treated as sacrosanct in the way meant here.
36. Are there governance mechanisms, in either intention or effect, that make changing the network easier, or harder? As non-exhaustive examples:
a. How are potential future changes communicated to participants in the network?
When Block.one has an upgrade to propose, they post on social media and the token holder community discusses it. When BPs consider a change such as replacing the Constitution with the EUA, they put it into the Referendum system for a signaling vote from token holders, and they discuss the merits on social media.
b. Are there mandatory waiting or execution periods (for comment period, delay prior to voting or execution, time limit to vote or execute a proposed change, opportunity to exit the network, etc.)?
There are time limits on Referendum signal voting, which are up to the proposer to set. There is an execution time limit on multisig transaction BP proposals as described above, also set by the proposer of the multisig transaction.
37. What major revisions to the governance of the network have been made, or are under current consideration? Why were/are revisions made or considered? (not already discussed in question 24)
As described in answer #5 above, the Constitution that was in place at mainnet launch was replaced with the EUA. This had several effects including the dissolving of ECAF and the ending of the written prohibition on vote buying and vote selling.
Several other changes have also been voted in by the Top 21 BPs that are less about governance, such as approving upgrades, creating REX (which could be seen as an upgrade of sorts), etc. The history of these changes can be seen on chain via querying history nodes.
Block.one once proposed a new Constitution 2.0 before the EUA was voted in, but the Constitution 2.0 did not gather enough support to be adopted.
Glossary
● Network: all systems, not only protocol layer.
● Stakeholders: everyone who can participate or whose interests are affected.
● Wet/dry code: “Wet” code is code that is interpreted by the human brain (e.g. legal code), whereas “dry” code is code that is interpreted by machines (e.g. computer code), source: http://unenumerated.blogspot.com/2006/11/wet-code-and-dry.html
Acknowledgments
I’m grateful to the proof reading and suggestions of Kevin Rose, Aneta, Abesh G, and Boram.
The framework of questions used here are from the Wharton Cryptogovernance Project, ably led by Kevin Werbach and managed by André Geest.
