xGov VOTING - suggestion for preventing whale manipulation

Governance
1

The few of you who know me and pay attention will know i am and have always been very vocal about xgov (mostly discord and spaces) since its inception because i firmly believe it’s a crucial missing component in the Algo space to take place of the old grant system and in the future even general governance and decisions in it - so it’s imperative we start treating it as a fundamental product and not just a playground for the few interested and few that are exploiting it.

I have insights as a proposer that passed proposals, proposer that failed proposals and also as xgov voting in all 4 periods. I also have personally advocated and helped projects to appy or atelast to get familliar with xgov - i think its beneficial to understand all sides if you are suggesting changes or improvements.

I’ll start by saying, i am not a big believer in tearing everything down and building up from ground because that discards and negates most of what we’ve learned in past year (during the xgov pilot). However as this is literaly what higher ups decided for new xgov (rebuild from scratch, I understand its mostly due to governance rewards going away soon-ish and existing xgov system is based around those, i don’t see any good reason why we are changing voting mechanics this significantly yes/no/abstain votes - opening new can of worms if you ask me).

But since that is the direction the xgov is going i’ll try and highlight the glaring issue we had and will continue to have if not addressed. (many are aware of the issue, but suggestions how to go about it are all in my opinion too complicated - xgov needs to be easy to use and easy to understand and not some black box magic)

the problem:
Concentrated voting power & Whales

  • new xgov doesn’t address issue of whales sufficiently, larger stakes (on nodes farming node rewards) will still produce whales, and with introduction of pooling even more whales to be exact.

Here is the bar chart for 4th voting session in xgov from SilentRhetorics xgovguru page:

xgov_votes
xgov_votes2374×734 302 KB

It shows vote contribution by wallets towards passing proposals. I’ve marked the instances where single wallet contributed more than 30% neccessary votes towards passing in red, and instances where there was 20-30% in orange (These two ranges are important for later).

Looking at the chart we can clearly see that there are quite a few proposals that got passed with a significant contribution from whale accounts. Obviously if there is a small ask almost anyone is a whale but that is besides the point. The point is: whales make or break any larger ask. Which is a serious problem because it encourages backroom deals, self-interest, etc…

I have 0 against whales, they have large stake so they are invested in ecosystem, i am however against them running the show in xgov, atleast in the form that it was.

there is another extra element that is going to be introduced in next xgov interation and that is artificial whales e.g. pooled votes - which i had had lots to say about and why it’s a ridiculously bad thing to allow them into xgov, but i won’t steer too far from teh topic - all we need to know here is, that my proposed solution basically eliminates the issues of these new type of “artificial” whales as they get limited by the 25-30% cap the same and for them it’s most likely a lot harder to split the stake and pose as multiple people than it is for individual whales.

the proposed solution:
I won’t go into how voting power is acrued as this is afaik already decided(1 block produced = 1 vote). But here is a suggestion about modification to voting, that is easy to implement and is not unfairly penalizing anyone yet the benefits are significant.

Cap the max % a single wallet can contribute towards a single proposal. (I propose 25-30% max as it’s nicely identified on the chart above).

Pros:

  • easy to understand, no convoluted math and quorums and weightning done with votes or whatever
  • easy to implement regardless of other aspects of voting process, so its low effort and no obvious downside, no real reason to not implement it.
  • it has 0 impact on smaller xgovs as their individual voting power probably won’t reach 30% of total votes for single proposal (might still be the case with smaller proposals, however its even more imperative these get different wallets voting for them and not jsut a few - whales are the big issue; flying under the radar and collecting 10/20k algo each period is also an issue - albeit smaller one)
  • We are not taking away any voting power from whales, we are just making sure their power is not going against the general consensus amongs xgovs. E.g. single whale can’t pass proposal on their own. It would need atleast 2 more whale wallets backing it up at 30% max vote. (exploitable still by splittign stake, but no-less than any other suggested methods)
  • it eliminates/reduces potential exploits and abuses that artificial centers of power pose (e.g. financially incentivised pooling in exchange for forfeiting your voting rights to single entity)
  • i’m against “Against/NO” votes that are planned for the new xgov iteration. This imo needs a serious rethinking and an actual consensus within eco… Regardless my suggested cap also helps the new xgov iterration by also limiting the “harm” single entity can do with trying to “downvote/vote against” maliciously.

Cons: I don’t foresee any, since this is just “slightly” limiting the whales and their potential breaking impact on the xgov.

If you read till here, congrats you obviously care about xgov!
Thank you for attending my ted talk. Any feedback is welcome even harsh one and why what i’m proposing is bad, exploitable or great :slight_smile: - let’s make xgov better together.

disclosure: during the one year xgov pilot phase, xgov allocated a total of 2.99mil algo.
Cosmic champs got 3 total grants approved via xgov, totalling 100k algo (50k in period 2 for two proposals and 50k in period 4 for one retroactive proposal).

6 Likes
2

Hi Simon, thanks for engaging in our ongoing discussion about how to improve the next iteration of xGov.

How do you propose to prevent an account with large voting power from “Sybil attacking” this mechanism by splitting their power across 2 or more accounts which would be under the size threshold but otherwise be able to vote identically to achieve the same result?

6 Likes
3

I don’t propose anything towards that. I even state

We are not taking away any voting power from whales, we are just making sure their power is not going against the general consensus amongs xgovs. E.g. single whale can’t pass proposal on their own. It would need atleast 2 more whale wallets backing it up at 30% max vote. (exploitable still by splittign stake, but no-less than any other suggested methods)

slightly unrelated, but i think you misunderstood the threshold idea. To clarify 30% would be 30% of the ask of proposal, so threshold would be dynamic per individual proposal (if proposal A asks for 100k algo, threshold would be 30k algo support towards passing it per single wallet, if proposal would be 50k algo ask - then threshold would be 15k algo support towards passing per single wallet) - it has nothing to do with the size of the stake per-se. As you don’t know what that 30% will equal to untill the voting session when proposals state how much they are asking. splitting your stack to optimize towards any random number might be kinda in vain, so if anyone would go spliting their stack my guess is they will simply go with 30k chunks, to maximize their “different accounts” and still qualify for node rewards.

There are two reasons for that:

  1. i don’t believe there is any reliable non-easily exploitable method of preventing or mitigating sybil attacks in decentralised space without kyc or some sort of did (just to add, you can just as easily boot/fake your on-chain footprint…)

  2. The sybil prevention / check should imo happen at the step where voting power is acrued e.g. eligibility to enroll as xgov (and it’s not really addressed there at all, so i guess it’s not a concern or it’s too big of a hurdle to the designers of the system) and not at the voting stage. E.g. don’t give everyone a tickett for the game and then turn them away at the entrance to the stadium.

The original idea of deterrent for malicious actors in xgov is the cost. However by deciding to intersect xgov with node incentives, this deterrent is removed - thats on teh xgov design team to justify and correct if they identify it as issue.

What my proposal aims to do is, to prevents abuse if ones voting power is large. Again only a limitation on the voting and vote allocation itself.
(if they split their wallet to 10 different accounts and if all these accounts are deemed valid xgovs with allocated voting power, then who are we to say nope, you can’t vote - back to the point #2 above).

3 Likes
4

I like this idea in theory, but as pointed out, it does nothing to stop wallet splitting. Given that these votes will be derived from node-running, “bad actor” whale(s) would be further incentivized to break up their stake into multiple wallets and could then effect both consensus and xGov simultaneously. It was this reason that I arrived to the conclusion that VRF must be apart of the selection process for picking sub-divisions of xGov voters into committees (weighed against each other by stake, with no single wallet having more than 50% voting power per committee). X committees are blindly selected to vote on a proposal. Proposal results are obfuscated until voting has finished. The only downside of this system would be that some people would vote and not be selected as part of a particular committee that was chosen by VRF. On the face, that sounds bad, but I consider it a small price to pay for integrity.

6

i agree with you, however i’m suggesting this with an assumption the new iteration of xgov proceeds as planned/suggested e.g. without changing it drastically.

On the note of sybil resistant…whale who split their stake in multiple wallets has roughly same chances of being selected by VRF regardless if they split stake or not. Imo if we did the math it would probably be shown to be beneficial to split your stake into certain max algos/stake to gain more voting power in next comitee as you propose it, so i don’t believe vrf is really doing much towards sybil attack prevention. (the idea behind VRF is that you don’t gain advantage even if you split your stake, it doesn’t magically diminish whales chances of being selected - that’s my understanding of it)

Your 50% voting power max is basically what i proposed, just a lot more harsh, because it’s actually taking away and diminishing whales total voting power, accrued by their stake (e.g. skin in the game) - which i don’t think is fair nor healthy to do. That’s why i propose capping their impact per proposal instead - less harm, and they don’t lose their power - which for a “honest” whale will be totally fine and actual deterrent from splitting wallets.

On that note don’t see a why both suggestions couldn’t be implemented, as yours is aimed more towards how xgovs/comitee is selected and mine is about making sure no-one on that comitee has unfair power/is able to majorly abuse the actual voting process while keeping it easy to understand how much voting power you actually have.

4 Likes
7

I’m basing the following workflow on the assumption that the new xGov plans do NOT proceed, and instead offer an alternate path. I don’t think I’m explaining this correctly, so I’ll do my best to elaborate here.

Step 1
Potential xGov would soft-lock ALGO (potentially also in LP form, such as current Gen. Governance model). This stake would represent 1 ALGO = 1 Vote.

Step 2
Assuming xGov is still eligible, when a proposal is submitted and approved via ARC standards for formatting and content (possibly sorted by ARC additions/changes vs ‘other’), then X number of VRF committees would be created (an odd number to avoid a potential deadlock). These committees would comprise of N number of xGovs, where N = a number of xGov wallets needed so that no single wallet comprises more than 50% of the total voting power of any single committee.

Step 3
Assuming each xGov votes with all their voting power on ALL proposals (either Yes/No/Abstain), then the VRF-selected committees’ votes would be tallied for each proposal they were matched with, leaving all non-VRF selected committees votes uncounted.

Step 4
All passed proposals move on to be ratified by General Governance after a review period (to allow for proper vetting, especially in the case of changes to ARCs).

Step 5
At the end of the commitment period, soft-lock would be released and any unspent funding would roll-over into the next term. No extra rewards, but still allow DeFi participation.

If done in a double-blind manner, then no one would know whose votes counted and whose did not until the voting was over. This is how VRF allows ALGO to be Sybil resistant in node selection, and how it should be implemented into xGov.

1 Like
8

Looks solid to me. But in general though, only certain wallets are eligible for xGov. You can’t just create a ton of wallets to participate.

1 Like