MultiversX Governance is a bad lie

Governance
1

Hello everyone.

For reference: This post is, as the proposal MIP-18, backed by the same group of people and not solely by the owner of this agora account.

About delays, lies and “governance”

We want to talk about something, that was revealed to us today and in the past days by Robert Sasu on Twitter (nothing against Robert in particular) that has deeply shaken our trust in the team regarding it’s promises around governance.

Let’s examine a quick and short timeline of Agora and MultiversX, for reference, before we start:

Historical Timeline

September 23, 2023: MultiversX Agora goes live.

“Every wallet account with a minimum of 1 EGLD staked is now able to login on the Agora, participate in discussions around protocol development, ecosystem growth and essentially all things MultiversX, and create drafts with improvement proposals that can later be submitted for on-chain governance vote - recommendable only if they gain sufficient interest from the community.”

"Pending an imminent mainnet upgrade, the on-chain part of the governance process will impose the following structure and requirements:

[…]

1. Mandatory deposit of 1000 EGLD for any voting proposal: this has been introduced to prevent spam, and also to encourage proposers to properly take the time that’s needed to communicate […]
2. Potential penalty on deposit: if a submitted proposal is rejected with veto, the proposer will lose a part of the deposit
3. Voting period is 10 epochs: it takes approximately 10 days from the time a proposal is published and put to a vote to when it is concluded
4. Liquid staking eligibility: projects can enable user votes from their smart contracts by implementing the new functions from the Governance SC with the activation of the next release candidate Sirius (v1.6.0)"

24th November 2023: MultiversX Protocol 1.6 Sirius goes live for voting on the governance portal

Among other things, Mainnet Sirius 1.6 promises to implement:

“Governance v3: Implements a new voting smart contract with features like MinQuorum, MinPassThreshold, and MaxDuration for proposals.”

Additionally, this entire full-page agora post was provided in the to-be-voted governance proposal that fully describes the entire governance mechanism in great detail, from the quorum, to required EGLD, to the duration and voting process.

We will not quote any particular segments of this post, as it would be excessive, but you can go ahead and reas the post. It clearly defines the guidelines of governance and enables the community to propose their own proposals, given enough EGLD is provided by the proposer(s).

Enough prerequisities, let’s get to the issue

So as we can see, the governance portal and agora launched (now) more than a year ago.

We can also see that almost a year ago, sirius 1.6 has been successfully voted on by the community. The community approved the governance implementation designed and proposed by the MultiversX Foundation and expected it to be shipped with sirius 1.6.

Today, we have recently voted on mainnet 1.8, which is expected to come on mainnet any time now. Yet, this aspect of governance, which is part of mainnet 1.6 was never implemented live on mainnet. Or maybe it is, either way it is not accessible and not even properly documented how to use it (if building a UI for it posed a too difficult challange).

But this is not the core issue we want to get to.
This goes deeper.

On 18th September 2024, Robert Sasu posted this on X.
“It is live actually” in response to the question when we would get “permissionless governance and proposal creation”. Further questions were not asked, but unfortunately, further details were also not provided by Robert. So, is it live? Where? We do not see a way to propose anything anywhere.

Let’s go deeper.

On August 5th 2024: We asked on the agora, when the proposal creation would go live. We received this response.
This was one month before Robert’s claim that permissionless proposal creation is live.
So either it actually did go live now, … or not, because the response we received by schimih, was that governance would go live with the first patch of the interim release.
Assuming mainnet 1.8 is the interim release, the first patch would be the first update immediatelly followed by the mainnet 1.8 release.
But since we still do not even have 1.8 live on mainnet - and neither the first patch, it couldn’t be live yet. Unless something changed that was not communicated to the community.

So,… one of the two is wrong. Either schimih or robert.

Okay, but let’s go ahead and add insult to injury - oh…? Oh! We do not even need to do that, the team did it themselves.

On September 25th, 2024 Robert tweeted an interesting tweet that spiked our attention, as he mentioned MIP-18 and … an ongoing implementation?
Let’s check out his tweet and analyze.

“But development in the delegation system never stops. Started implementing a new interesting feature which allows users to switch from staking provider to another staking provider without unbonding period, once per 30 days.”

Someinteresting aspects here:

  1. Robert says the implementation of MIP-18 (which he also linked in the comments) has officially begun. Good news? Not quite. Let’s get back to this in a bit.
  2. The unbonding period will be set to 30 days.

Now, in principle, great to hear the team is finally listening to the agora. After all MIP-18 was first proposed back May 2024 by us.

However many issues arise.

Issue one

MIP-18 was never voted and approved by the community in a governance vote before. We, the authors of MIP-18 expressed clear interest time and time again to want to propose it to be voted on by the community but it was never technically possible. The issue is now: the team has started to implement something, that they think will pass governance. However with zero facts backing this thought. Robert himself wrote in his comment underneath the MIP-18 proposal “this will need a validator call”.

Issue two

While we do not necessarily agree with the necessity of the validator call, we do acknowledge that it can help in forming the propsoal. In the end, validators that are active on MultiversX and have even just the slightest of basic interest in the protocol should participate in the agora and discuss posts and proposals. If they didn’t and do not like a new proposal on the governance portal, they can still vote against it. That is why you do on-chain proposals, to get everyone’s final opinion and seal of approval. Even of those that are not active on agora (even though their stakeholder category should be!). But even this validator call about MIP-18 did not happen until today, to our knowledge, yet, implementation of MIP-18 has begun.

Issue three

Robert also stated in the comments:
"We said a few times that we want to do governance on a finalised code. Like voting on the final proposal of the law. This is the way for true voting and decentralisation.
Good features will be voted. If not, that’s it. Moving forward with the next things."

Unfortunately, we cannot remember or find any articles/posts/docs where this [we want to do governance on a finalised code] is stated. Even in the official documentation for the governance process, this is not stated.

So this is clearly either a communication issue, but either way an efficiency issue. If the proposal ends up not being accepted due to lack of support by validators and/or community, all the hard work was in vain.

Issue four

Connecting to issue three:

This is not how governance works.
You do not take ideas by the community, implement them and then do the proposal. You first create a well thought through and laid out plan, mock-implementation with perhaps pseudo code if you want to go as far as that, or at the very least, which is what we did: properly and deeply and in great detail, explain the idea.

It is very important to note that MIP-18 as written in the agora is NOT AT ALL the final text which we would have used in the governance portal as it was only 90% done and left 10% room for changes and discussions and slightly alternative versions, which we extensively proposed and discussed in the comments.

Furthermore, Robert (or rather the core team) took MIP-18, changed some aspects of it (most notably, lengthened the unbonding duration from 10 to 30 days - we proposed 10 originally!) and is now implementing it this way according to Robert’s tweet.

This is, again, not how governance works.
You cannot simply change aspects of community proposals without them ever having had the chance to vote on them. Even less so the validators to discuss it in a “this will require a validators call” call.

Let’s summarize

  1. Robert claimed that “we want to do governance on a finalised code” in the comments on the tweet about MIP-18 - at the same time, sirius 1.6 was voted on, clearly with unfinished code as Governance is still not live
  2. Governance or better defined as permissionless proposal creation by the community (basically the most important aspect of governance) is still not live a year after the governance portal first launched
    2.1 Governance is still not live, almost a year after sirius 1.6 got voted on, which defined the entire governance process.
  3. Core developers claiming “it is live actually” when it isn’t
  4. Core developers/Team members contradiciting themselves (communication issue?)
  5. The development of a community written MIP has begun without the approval by the community
  6. Parts of MIP-18 were changed by the core team without the community’s approval, and are now being implemented as such
  7. Robert said that the team wants to propose only finished implementations/finished code. This was not stated anywhere, at least not that we could find it.
  8. By implementing first and asking later, you are risking waste of resources and spend time on the proposal. Besides the issue that this was never stated anywhere nor approved by the community (this quite crucial part of the governance process).
  9. A validator call was never held, yet implementation has begun, even with changed aspects compared to the original proposal
  10. Supposedly the team only wants to propose things when they are ready and the code is fully implemented and ready - yet Governance is not live despite the sirius 1.6 vote having happened almost a year ago now.

This. Is NOT. How Governance Works, MultiversX.

“B-B-B-ut EGLD holders are not shareholders” :nerd_face: :point_up:

Then why introduce governance, with an extensive governance process, involving the community and supposedly giving them the power to propose proposals according to the laid out, designed, allegedly implemented and by-the-community-approved governance process according to sirius 1.6?

MultiversX Governance in it’s current state is a joke.
Delays (which is expected, and not the major issue!), communication issues, lies, contradictions, unkept promises, not involving the community or validators or other stakeholders and just making decision on-the-get-go and more.

We think the final summary which outlies all issues 1-10 should properly showcase the issues with governance.

Until all of these are fixed, MultiversX has no governance.
The current state of governance is nothing but approval-seeking by the foundation for decisions it has already made long ago and implemented to their own liking.
It is not governance.

There is no point in agora, there is no point in being active here (which might actually also explain why the validators didn’t discuss MIP-18 here), when there is no governance anyways.

Until these issues are fixed, at least the vast majority, there is also no reason for us to continue on Agora. We had a few more ideas which we wanted to propose after we would have officially proposed MIP-18 on-chain, … but we have changed our mind in the light of the current state of MultiversX governance.

Good evening.

PS: Not saying we are not okay with the 30 days transition period instead of 10 days, although we do not welcome the change necessarily, but simply changing it, as thoroughly discussed and explained here, goes against all governance principles.

1 Like
2

@drmelone 100% agree with everything posted above. Verry well written. Nothing against the team or Robert (who does a fantastic job) but they really need to realize how important a REAL and FUNCTIONNING governance system (and U.I.) really is.

For transparancy purposes first - the community wants to have a clearer view of what is ACTUALLY being worked on and whether requests from Agora are ACTUALLY considered. I know that the team has unveiled https://multiversx.com/roadmap but we have no idea what the priorities among all these workstreams really are. Also the length of implementation (delay?) between a governance vote and its implementation can really get frustrating. We have voted for Spica realease v1.8 over 40 days ago and no communication has been done on the timing of arrival to mainet (even testnet). If everything has already been coded (this is the current philosophy of the team), why does the implementation take so much time then?
Moreover, should this release really be the one enabling governance on MultiversX, a better communication accross the team’s members need to be done because no one in the community has a clue on the overall situation yet.

Second, for efficiency purposes - as mentionned above, I’m not sure how one can agree with Robert’s vision on this (having a finalised code before submitting it to a governance vote) - The potential wasted time could really be detrimental!!!

Just having a functionning governance process (and UI) could really help the community and the team achieve reconciliation

1 Like
3

Yes it doesn’t make sense
“We only want to vote on finished code”

Then why has there been absolute silence for over a month since the vote if the code is allegedly done? Zeeeerrrroooo communication. Lack of communication is the issue.

4

We have been focused on solving all the issues with the Spica release. That is why there was no communication regarding the delegation improvements. We added MIP-18 to the backlog, analysed it, we said it is a great idea and let’s see what the implementation would look like.

Technically speaking Governance have been enabled since epoch 1265.

You can check it on the github. Practically we did not create a frontend for it and we found an issue with the delegateVote system for liquid staking contracts. That issue was found after auditing on the already released code, as we do multiple audits in a continuous way.

I have responded to the MIP-18 post with a suggestive step by step explanation on the code.

Why don’t we make governance proposals to some ideas, which do not have finalised code/specs?

  1. During implementation a lot can be changed, it happened countless times that the final implementation and the initial specs differed greatly. When that happens, everyone is pointing fingers.
  2. During implementation, even after the most sophisticated Technical Document of Analysis we have discovered discrepancies between that, the specs and what will be delivered.
  3. Code is law (in some sense in the decentralised public ledger). And the best democracy form would be to vote on the final LAW, which is getting released/activated at a set date.
  4. In case we want to vote on ideas - there would be actually 2 votes, just to be correct. One is on the idea, the 2nd one is on the final code.
  5. We take the risk of implementing the feature completely and having a governance call after that, on the final version of it. In the meantime we have discussions with all the actors who are affected by that feature.

“Furthermore, Robert (or rather the core team) took MIP-18, changed some aspects of it (most notably, lengthened the unbonding duration from 10 to 30 days - we proposed 10 originally!) and is now implementing it this way according to Robert’s tweet.”
30 days is only a config, which can be discussed and agreed with the community before the activation. Everyone can present their views. If you have delegation to multiple providers, one such migration does not affect all your assets, thus it is only for user moving from SP A to SP B, he cannot move again from SP B in the next 30 days. He can always unStake and withdraw.

“Staking Providers can only change their service fee once every xy epochs (e.g. 30 epochs). This way, delegators have a certain guarantee the service fee will stay as-is for at least a good amount of time. Furthermore it even more so eliminates the “hunt for higher APYs” as staking providers will need to provide stability before anything else, since they could no longer compete based on changing the service fee dynamically and advertising higher APYs than their competitors.”
This is in implementation as well, also with a config. So it can be decided at any time.

1 Like
5

And why not communicate that?

Why wasn’t this communicated?
Why are there no docs for this?

I know these reasons and issues. Henceforth you would vote for the idea and a final time for the final implementation

And before starting implementation you would at least thoroughly ask the community and affected stakeholders (validators). Both didnt happen

Then why wasn’t it done? Nobody was asked, not even on the agora, if the 30 days is accepted. It was just decided by the team. But most importantly, no public validator session was held about this.

6

We still have a few weeks/months before this feature is activated.

Before any activation/any decision we will discuss with all the actors.

1 Like
7

We will have all the calls with validators, users, AMA if needed in Telegram.

1 Like
8

One challenge with governance of this sort is that many involved have never coded, created, or birthed software that impacts the lives of ordinary people. The burden of responsibility runs DEEP in the veins of those who do. With so many vectors of energy that all those responsible for creating resonance in the machinery of this amazing manifestation of incredible ideas (otherwise known as multiversX), with so many outside energies vying for attention in what is effectively an egocentric world, … well… it boggles my mind how well the machinery runs.
Many here do not know me, but trust that i have been a thorn in the side of many, for many years, but one commonality to my energy: i criticize where appropriate, and do try to applaud as often as i criticize, and always try to offer solutions.
Has the path to governance been perfect? No, as is the same with EVERY path in such machinations, but is it “a bad lie”? FFS, no.

Frankly, and bluntly, the efforts of an undoxed group has little of import in my world. When you speak with personal accountability, I will listen more.

As a validator, i read the original submission with interest. I recognize the validity of the idea, despite how it could KILL small validators like me. I do not ever take positions based on my own need to self-protect, but … i valued the energy, and would value it more from identifiable people.

1 Like
9

Not really an issue. As we see from the xExchange Agora, people with little knowledge about how things work, but still want to participate, can post their ideas (without actually proposing an xEIP). After they have done so, they and others can discuss the idea and later on someone can take it into their own hands and make a proper xEIP out of it.

This is how governance is supposed to be.

Not many people know how to run a country and how taxes work and whatnot, yet everyone is entitled to an opinion and can freely discuss it with others, and eventually, if it is a good idea and many people agree with it, it can be turned into a full change for the entire society.

What do you mean here? You are surprised how well the machinery [MultiversX Network?] runs? Right now, only the Foundation writes the protocol code, and validators simply download and run it. I don’t see how opinions and an egocentric world directly affect the reliability of the software code.

And why not? It would be way easier to understand your position, when you would additionally articulate why the reasons presented in the original post are invalid, or rather, do not justify calling it a bad lie. There are various double standards, missed deadlines, zero communication, broken promises and more.

So, what is a lie?

A lie is a deliberate false statement or action intended to deceive or mislead others. It involves knowingly communicating information that is not true, often with the purpose of gaining an advantage, or avoiding consequences, or protecting oneself or others.

  • Core developers claiming “it is live actually” when it isn’t

Again, is it live? It isn’t usable anywhere, no docs, and even robert did not properly comment here. He only did so, while avoiding actually answering the question. He answered, to answer, not to actually provide an answer. In other words, his response was merely a formality, lacking any real substance or genuine attempt to address the question at hand.

One could say: he was knowingly communicating information that is not true while trying to avoid consequences or protecting oneself or others.
And Robert definitely knew what was being asked by whether it is live or not.
Yet he replied here, once again, saying “the smart contract is technically live on mainnet”.

Great, but it is not usable, not documented, not even an address is provided by him or by any docs, no UI, no information on how to use it to propose something, nothing.

  • Robert said that, in the past the team communicated that they want to propose only finished implementations/finished code.

This was not stated anywhere, ever. After talking to several other validators and devs, they also cannot remember the team ever having said that. Also it is not present in the original governance proposal for sirius 1.6, which is the one and only document that outlines the governance mechanism.

One could say: he was knowingly communicating information that is not true while trying to avoid consequences or protecting oneself or others.

So, is it a ‘bad lie’?

Yes.

Lies are clearly present. And they are bad as well. As the author of the lies could have spent a bit more time to actually reason their PoV before posting something that looks as the first-best argument they managed to come up with.

Furthermore these falsehoods are easy to uncover - so they are bad in the sense of quality as well. Usually you want a lie to not be uncovered, when you state one.

And the overall Governance so far has also been a lie, as visible in the original post, multiple issues, stretching from (minor) delay issues ranging well over a year, to (major) communication issues and broken promises.

Nothing against robert in particular. And don’t take it personally robert. If anyone or anything, the entire Foundation should be blamed for how this was handled.

Finally

You are entitled to your opinion. If you think all of this isn’t a lie, then okay, sure.
But factually speaking, there are so many delays, broken promises, poor communication and even gaslighting (“we have always said we only want to vote on finalized code” - which was never written or said anywhere, not even on the original Sirius 1.6 governance proposal document which “introduced” governance) that you cannot say this is not a lie.

Splendid! What an amazing argument! It really destroys all major points and takes away any and all credibility! (/s)

Bitcoin was written by an anonymous group or person.
Ethereum is being improved partly by anonymous beings.
Monero is run and being improved by practically only anonymous beings.
The original Crypto ethos literally IS anonymity.

Sure, we could DOX ourselves. We decide not to.
We actually want MultiversX to thrive, to grow, to improve.
That is why we write MIP’s. That is why we wrote this blog post so the Foundation finally, after more than a year, get’s (semi) pressured into fixing their wrongdoings.

Furthermore, being anonymous or not, the quality of our proposal and the quality of our post here does not change.
It is not one bit less valuable just because of being anonymous. And it does not become more valuable when doxxed people post it.

We have a ton of other ideas for MIPs, but we collectively decided to not release them until we have proper Governance. Some of them could pose to be major improvements to the network, other ideas we have could make MultiversX Governance the best in all of crypto.

But again, without proper governance, we will not release them, as the chances of them ever being implemented by the Foundation themselves UNLESS being approved upon by the community (let alone in a timely manner, but that is less of our issues) are close to zero.

And just as a hint: we are one of the major Community Leaders for MultiversX, validatstrong textors and EGLD whales.

Thanks

Nope. Not going to happen.
Accept the original crypto ethos, or you shouldn’t be in crypto.
It is confusing how you can be so devoted, even being a validator, but not respecting the original crypto ethos of anonymity.

Furthermore, being anonymous or not, the quality of our proposal and the quality of our post here does not change.
It is not one bit less valuable just because of being anonymous. And it does not become more valuable when doxxed people post it.

Even Robert acknowledges it, by his tweets and saying that they are working on confidential/anonymous transactions and that anonymity should be the gold standard as this is the crypto ethos.

Interesting that some MultiversX validators like you seemingly do not care about that though. Just as much as having a proper governance mechanism.

Even Bitcoin has a proper governance mechanism, even though its nearly impossible to get a change approved, they at least have a fair, open, transparent governance mechanism with no lies, delays, communication problems and gaslighting going on.

Looking forward to hearing more often from you.
Because of a severe lack of activity (probably due to the non-existence of the governance mechanism and the team only rarely using the agora) not many people are interested in writing posts let alone reading the posts here.

The xExchange Agora has 100x more activity than this one, with new posts and questions and discussions being created almost daily. Probably because people’s suggestions get taken more seriously there and the head of xexchange frequently answering people’s questions.

But in the core it also has the same issue as this agora: no live governance mechanism.