Participating Projects

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.

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)

• 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.

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).

The dry code identifies only these groups:

• Token holders (who have/have not 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.

To become a token holder: buy tokens and create an account (or pay someone to create an account for you)

How to access:

• 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.

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.

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.

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.

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.”

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.

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.

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.

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.

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.

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.

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.

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.

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.

The top 21 BPs carry out proposals via the ‘prods’ power which is used to enact system changes, upgrades to the System Contract, etc.

A given BP gains ‘prods’ power by joining the top 21 by getting votes as described above in that section.

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.

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.

There is not currently any process, mechanism or institution for conflict resolution. An earlier institution, ECAF, was disbanded.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.