Finally, after months of waiting and uncertainty, the referendum vehicle is now live, and EOS token holders can now vote on proposals, which can change the EOS government structure, be it system contracts, the constitution, reward systems, voting mechanics itself, you name it.
IMO that’s reason enough to get excited! This opens the door now for EOS to change and evolve and play out its Taoist nature, as one commentator has framed it. If this works out well, it will push EOS ahead of most other cryptos!
If you know me, you know i like to look behind curtains, ask inconvenient questions and put the finger in the wound…. Ready?
How does referendum work?
So let’s keep the obvious short. How does a referendum proposal pass?
– Anyone can put forth a referendum via the EOS discussions app. Current rankings follow voting participation, but actually the referendum form can easily spammed. (well there is a certain RAM restriction, which is required to put forth a proposal)
– 15% of tokens need to have participated in a referendum. This would be roughly 150 Mio tokens. (Note, that only staked tokens count. Since only 50% of EOS are staked this would require an effective 30% voter participation.
– There need to be 10% more yes than no votes to a proposal, which is generally interpreted as a 55% minimum lead of voted tokens. But actually it is not really clear, if this is a relative number or an absolute one, which e.g. would mean that the minimum level for a referendum to pass would be 15% for and no more than 5% against (or just 15% for and less than 5% nay), which effectively would mean a qualified (3/4) or more for referendums with low participation.
You will say this is an odd interpretation and I agree. Nevertheless this is crypto… anyone willing to bet against this becoming a topic of heated discussion in the upcoming year?
– The above majority needs to be held for at least 30 consecutive days in a 120 day period. That’s actually not so bad, since it gives some time to reflection and the opportunity of opponents to have their objections heard too. On the other hand, given the fact that a lock-in is quite hard to achieve, it makes a proposal pass even harder.
So how might a referendum proposal be deployed?
Now this is were the real fun starts!
Well of course if the referendum passes, there is no switch, that sets a proposal from unapproved to approved ( at least not on-chain), and changes need to be made, just as they are done now, by a 2/3d majority of 15 out of the 21 top bps. So actually this is a second instance upon the proposal and might decide to deal differently with this proposal. This is in fact a good thing as well, as an proposal will need to conform to an even broader range of stake holder, including the top level bps.
You might want to say, ok, if the bps don’t follow the will of the community, they will be swiftly voted out… well think again how often perceived bad behavious of bps has been punished by token holders in the past 7 months. Not really… and then it’s important to remember that current bps have been elected in based on 250Mio tokens voted, whereas a referendum would require 150, so you can simply imagine that you might – at a given quota of staked tokens – have elected bps and proposal votes on opposite ends. So remember the above set criteria of 15%/10%/30d?
Those are not the sufficient criteria a referendum to pass. We also need to add a majority vote of the top 21 bps as criteria!
But there is more fun ahead!
As said above, it’s the BPs responsibility to deploy a referendum, and what caught my attention was EOSgo’s reddit post, that put forward the following criteria for a complex (e.g. meaning a to be developped smart contract) proposal to be deployed:
- Must be coherent, legible and well documented
- Needs to have a GitHub Pull Request (includes Contract changes)
- System code changes must have already been tested and stable on a public Testnet (Jungle, Kylin, etc…)
- System code changes must have some form of a 3rd party security audit performed prior to submission
Yeah i now, providing a smart contract that has been finalised and is broadly accessible and testable by the community on testnets isn’t a big thing, but then this darn proposals also need to be coherent and well documented?
Well in the end those things are simply proposals (which make perfectly sense), so they are not binding, and if you look at the currently existing proposal hardly one does fulfill the criteria. And there is no real structure or other that only only opens a proposal for referendum with the above things established, so there will be lot of outcomes without any coding available.
Well one such referendum exists that has that, the one that calls for Rex to use Ram-fees and Name auction fees: Of course this is possible because B1 has done all the above steps, and the REX contract has been thoroughly tested and above all includes a switch for toggling between harvesting those funds and not.
Now imagine a scenario where EOS voters approve URI, but Dan has long left for Shower Coin, how will we ever get URI, even if the bps approve?
And does it make sense to first develop a smart-contract and have it approved only afterwards? But even if it was developped afterwards, can we expect bps to do this? From the measly 1% block rewards, which are actually meant to compensate them for running the chain? And who out of the 21 bps will cover a complex task? Actually such proposals will require some kind of worker proposal contract, you remember the structure to which only ECAF is more frowned upon?
Proposal consistency and depths of politics
This brings us to the first requirement set out in the EOS go post: coherence.
To illustrate let’s take a look at the currently most popular proposal with the imaginative title of DECAF that reads: Would EOS be better off if ECAF would not be able to issue key switching orders and we would rather rely on the code and block producers 15 out of 21 multisig?
Actually this proposal doesn’t call for any actually action, in the best sense of populism it addresses a gut feeling, so if this referendum was passed, ECAF could continue issueing its orders and BPs comply and all could join in sighing how EOS would just be better off without.
More so if bps would start try interpret this nonsense, what are they supposed to do? Collectively ignore ECAF orders? Remove the respective paragraphs from the constitution? But in what way? Should they scrap base layer arbitration as well? All of arbitration? Is that all? I don’t know…..
Then there is also the point of overlapping or opposing goals of proposals, e.g. there are currently a proposal calling for 1 token 1 vote as hinted by Bredan Blumer and then one asking for reverse weighted votes, which are pretty much diametrical in their outcome. Now what if they both passed? Will bps choose the one proposal they like better?
What to expect?
Referendums on EOS in fact do open brand new perspectives in crypto, but as you see, the contracts alone won’t deliver us with automated joy, no they might even not be able to bring the much needed clarity about voter will? What it will open us will be the unsteady and dirty world of politics, just like the one we frown upon so dearly in off-chain life.
And in the long run, those issues describe above will be sorted out and integrated in a broader framework, and eventually will make EOS a much stronger chain. Certainly it won’t be a straight path…
Overview of some proposal voting platforms
EOS Authority <– My preferred option since they offer the max indepth info.
What do you expect of the referendum system?
Will it be the game changer in crypto?
Have you voted? Why or why not? What for?