Term 4 Charter Updates/Voting Updates May 31, 2022

Governance Validator DAO
1

Hello All,

At the beginning of Term 4 the most daunting task was to ‘fix’ HIP voting, whereas we know it was incredibly difficult to reach quorum from the stake weight design. This was to only be exhausted by the uncertainties of wallet security leading to diminished validator voting. Furthermore, evaluating the Charter we have noticed a lot of out-of-date information that is not applicable to the VDAO. Such as: ‘5/5 members of the Validator DAO’, ‘proposal to a vote on Snapshot, ‘use of Validator DAO funds requires 6/9 members of the Validator DAO to agree’ and the list goes on with out-of-date information and inconsistency. Currently gov.harmony.one is not used any longer - leaving the VDAO in a deadlock on ratifying the Charter with a normal process. Same goes for the governance voting, we are in a deadlock on not being able to pass votes.

Noting the underlying text that gave the VDAO presence needed to be changed, public governance voting being at a standstill and wallet security needed to be addressed; we had to address these for ourselves, future terms and the community. We encourage feedback on the Charter, voting strategy and idea to maintain validator wallet security. Our hopes are to receive improvements and critique on these items so the VDAO may serve you better.

To gauge your support, we shall implement polls within this post as many validators do not wish to export their private key and vote on snapshot. Please vote here to show support.

The new VDAO Charter is linked here for your view and feedback. We have added more sections, roles, explanations, standard forms, processes, definitions and guidance that we found pertinent to serve as a reference for the VDAO in serving the community. All of us wanted to take the approach that this document, in the eyes of a new member, would serve as an all-in-one reference. This was not only applied to the VDAO but any member of the community who would like to put forth an HIP or a candidacy for the VDAO – we have standard layouts and recommendations. It is not meant to overwhelm but provide an all-encompassing view as to what we do. We have retained the verbiage of being ‘Governors’ but defined our role as to what we do – more than simply signing payment transactions. These are only a handful of changes and solicit your feedback on this document.

Poll to accept changes of the Charter

  • Yes
  • No

0 voters

Next, we would like to introduce Logarithmic Voting. We had the idea of Quadratic Voting only to be misinterpreted as this implies a ‘bank’ of votes that can only be used a finite number of times. Logarithmic is a more accurate representation and is as follows:

Looking at and evaluating logarithmic voting it is apparent that it poses a risk in gaining many voting tokens at minimal expense and effort to any party that wishes to act maliciously. However, a clever idea from @TrickLuhDaKidz is to combine logarithmic voting with traditional stake weight voting in 1 formula. This will require some steps to achieve but shows promising results. Keep in mind, the only visible token is ‘VDAOG’, being the chief governance token.

Firstly, stake weight will be mirrored and then run through a logarithmic function, giving us ‘lnVDAOG’ token. The formula is: ln(ValidatorStake/10000).

  • 10,000 comes from the 10,000 required in self stake for a validator node as the minimum for declaring on-chain. This was originally thought to be effective in limiting actors with 10,000 ONE from creating nodes and using them to acquire voting tokens. With a total stake of 10,000, the natural log of 1 is 0. However, alone, this is trivial to game as we have seen.

Second, the ‘lnVDAOG’ token is now the ‘logarithmic’ portion of the equation and will then be used within the following:

Screen Shot 2022-05-31 at 8.59.24 PM
Screen Shot 2022-05-31 at 8.59.24 PM1106×142 14.3 KB

Thirdly, there have been limits that are defined to prevent gaming/manipulation, sort of ‘caps’:

  • ‘Upper Cap’: Max Elected Keys * 1.35 * EMS
    • As of right now that cap is 6% per shard (225 slots), later to be 250 slots per shard. This gives us a max of 54 possible elected keys a validator may hold as of now.
      • EMS = Effective median stake
  • ‘Lower Cap’: EMS * 0.65
    • This lower cap will work to discourage malicious actors in creating dummy nodes just to gain voting tokens.
      • EMS = Effective median stake

The above equation will hold the following logic to avoid gaming and manipulation and yield us an updated token ‘VDAOG’:

  1. If ValidatorStake is greater than the ‘Upper Cap’, then a validator’s VDAOG = UpperCap
  2. If ValidatorStake is less than the ‘Lower Cap’, then a validator’s VDAOG = ValidatorStake/2
  3. All stakes amount of ONE in between the proposed caps will then follow the equation above.

The above equation uses (ValidatorStake/2), this is the traditional stake weight portion. Note, the ‘lnVDAOG’ mirrors a validator’s total stake which is why it is being used in the formula.

What this also allows is the voting of nodes that wish to participate. Nodes that wish to take part within governance voting may request to be supplied with ‘VDAOG’, their stake being mirrored with ‘lnVDAOG’. This also will help circumvent the event where it is very challenging in achieving a 51% quorum in traditional stake weight.

We can take KuCoin as an example:

ValidatorStake = 277,552,416 ONE

TotallnVDAOG = 1165.71 VDAOG

TotalStakedONE = 5,450,921,215 ONE

Looking at the original equation: ln(277552416/10000) = 10.23 lnVDAOG This was the original intended logarithmic equation but it had no limits on lower or upper bounds and was susceptible to manipulation.

  • Taking it further,= 0.00878 , this represents the decimal of the total tokens used in voting.
  • 0.00878*5450921215=47841535.21
  • 277552416/2 + 47841535.21=186617743.21 VDAOG
    • The addition of (ValidatorStake/2) to the ‘logarithmic’ portion allows the larger nodes to retain voting power and security with their stake.

In this case, KuCoin gets their voting power decreased by approximately 32.76%

If we run a node with a stake of 4000000 ONE through this, that is approximately a 750.4% increase in voting power, yielding 30016402.84 VDAOG.

It is important to not forget the relationship – the more lnVDAOG increases, the larger the decrease in voting power for larger nodes and the smaller the increase in voting power for smaller nodes. As more ONE is staked, the voting power relative to other nodes approaches an equilibrium, if you will. In essence, the voting power becomes more similar to most nodes.

Using stake data from 16 MAY 2022 (epoch 984) we can take a look at an example vote, being HIP-25. As we know HIP-25 was unable to pass due to inability to reach quorum. The following simulation will take all current voting nodes (collected from HIP-16, 17 & 25) with the addition of ‘large’ non-voting nodes (Binance Staking, KuCoin, 三潭映月 (HIGH STABILITY 99.7%, LOW FEE RATE 5%), Honest Mining, Guarda Wallet, SNZ Pool, Stake DAO, InfStones, HarmonyNews.one, DACM.io 1, Animoca Brands, CypherMines Nodeasy, Matrix Stake, Stake DAO [Retail], Хинкали and others.)

1430×202 42.8 KB

As we see, HIP-25 would have passed with a fairly high margin. We had 1 node abstain from the HIP-25 vote per the report that is made available. Note: every node that voted, voted in favor aside from the 1 that abstained.

As we do not have the stake data from the closing of HIP-25 we will have to work with the data obtained. If we run this vote again using traditional stake weight, we receive the following result:

1429×204 43.8 KB

As we see, quorum would be reached with this data but the agreement threshold of 2/3 in favor would not pass. We had 1 node abstain from the HIP-25 vote per the report that is made available.

What this tells us is that logarithmic voting brings the voting power of larger nodes down and the voting power of smaller nodes significantly increases. The ‘half stake weight, half logarithmic’ idea came about to formulate a voting strategy in which would keep the security of our larger nodes but give voting power to the smaller ones.

We have yet to see any defined equation/formula/logic on how logarithmic voting may work. We have also not seen data presented that includes mainnet node stakes. We hope this fosters discussion, feedback, comments and critique.

All data was acquired from smartstake.io based on epoch 984. All voting node data was compiled from HIP-16, 17 & 25. Data is included within the supplied Excel file.

‘VDAOG’ name was retained as this was voted to be the best name for the token without being too complex. ‘lnVDAOG’ is a token that is in the background and will not be expressly shown as it is used in the final calculation of ‘VDAOG’. For the purposes of demonstration and development it has been explicitly shown for transparency.

Supplied is a repository of all compiled data and simulations used in developing ‘VDAOG’ which is found here You may need to reconstruct the graph if you choose to download this file and view with Excel. Google Sheets has a different format. Feel free to reach out for the file directly if you so choose.

Poll to accept changes of Logarithmic Public Voting

  • Yes
  • No

0 voters

Third, an idea to maintain validator wallet security and minimize exposure of private keys while voting may be accomplished via an alias wallet to vote. The idea is a validator creates a brand-new wallet (ie MetaMask) to vote with. A contract can be built to establish a proof that said wallet is controlled by a certain validator. This can be achieved by the validator sending ONE (via CLI) to that wallet address and sending the ONE back to the validator. Taking this a step further, validators that wish to participate in public voting may request voting tokens from the contract to their alias voting wallet. The security may be improved further within the contract to establish proof of ownership by requiring a specific value of ONE during a given timeframe (when tokens are requested).

Note that the voting strategy and alias wallet voting above have not been built and deployed as we wish to garner feedback to finalize any changes and then begin designing the contracts to handle these functions.

Poll to accept changes of alias wallet voting

  • Yes
  • No

0 voters

We appreciate all of your time,

Validator DAO Term 4

12 Likes
2

I think the alias wallet is a terrific idea

9 Likes
3

Pay them out! Come on guys.

8 Likes
4

Updated the function to calculate max keys to round down to nearest whole integer, yielding 52 max keys vs the 54 that was there prior. Graphics within the post had a small change. Refer to excel file for up to date info :slightly_smiling_face:

Is to be 52 keys. Need to round down to full keys which is reflected within the excel file calculations.

8 Likes
5

Fantastic write up and it’s great to see the Term 4 governors (and @TrickLuhDaKidz ) take over and really flesh the logarithmic voting solution out. I support this motion and look forward to the feedback that others have to input. It may not be the perfect fool-proof solution but it’s a great leap towards the right direction. Bravo!

8 Likes
6

I will try to further lay out the math and logic to make things more apparent and understandable.

Let’s continue using KuCoin as an example with their large weight and show where the numbers go:

Screen Shot 2022-06-06 at 10.10.16 AM
Screen Shot 2022-06-06 at 10.10.16 AM2224×606 240 KB

The above will equate to the shown ‘VDAOG’ (far right column)
Effectively, there is a natural log calculation nested within the formula above, being ‘lnVDAOG’.
Now the interesting part of this math is the logic of how it operates to prevent a single node in taking over an immense amount of voting power and to prevent many small nodes ran by a nefarious actor aiming to amass voting tokens to sway public voting. We will have to define some limits here:

  • Upper Cap = Max Keys * (1.35 * Effective Median Stake)

    • Current Max Keys set by protocol is 52

  • Lower Cap = 0.65 * Effective Median Stake

  • Effective Median Stake = 5,238,400 ONE (epoch 984 data)

When the equation is calculated, a node’s stake is checked via this logic:

  • If Validator Stake is GREATER than Upper Cap THEN the node’s VDAOG = Upper Cap

    • Look at Binance Staking as an example with their VDAOG allotted

  • If Validator Stake is LESS than Upper Cap AND GREATER than Lower Cap THEN the node’s VDAOG = the above equation

  • If a Validator Stake is LESS than Lower Cap THEN a node’s VDAOG = (Validator Stake / 2)

    • This aims to prevent a user in spinning up nodes to amassing voting tokens as a stake above the defined Lower Cap will likely require an operational and signing validator node to keep that stake. The Lower Cap is in line with the network’s lower bound.

Please post your questions!

6 Likes
7

Great work here PiStake! I truly appreciate the breakdown you have provided for this. In theory it began to make sense but this mathematical visual really helped to solidify things form me! I really love what yall are doing now and look forward to what you will continue to do!

2 Likes
8

I realize this voting method may seem a bit complex. I’ll try to simplify things in a way that I would easily understand, and hopefully that will make it easier for others as well.

Last VDAO Term, @ben2k_stakeridoo and @coinchowder offered several new methods of voting with VDAO tokens. This was in large part due to the VDAO Bootstrap Initiative failing after Binance’s large, last-minute increase in stake size.

One of the suggestions Ben and Chowder had was a quadratic (logarithmic) voting method, where the smallest validator (10,000 ONE) would have ~.01 VDAO tokens. That equation would look like this: y=ln(x/10,000)+.01

And that equation would’ve allowed the Bootstrap HIP to pass. But there is an issue with voting integrity/security at the lower end of the spectrum (validator’s with smaller stake) that could allow for a malicious actor to spin up multiple nodes and affect voting.

So we have the standard voting method, which is secure but was unable to pass a HIP that had overwhelming support, and now we have a potential logarithmic voting option, which is able to pass the HIP but is less secure. Possible solution: combine the two methods. A split of 50/50 was chosen to avoid arbitrary weighting/bias towards either voting method.

Here is a breakdown of how the 2 methods are combined using @PiStake’s KuCoin example:

Standard voting 50%: Take each validator’s current stake and divide it in half.
KuCoin = 277,552,416 / 2 = 138,776,208 VDAO tokens

Logarithmic voting 50% (a 3-step process):

  1. Run each validator’s total stake through the logarithmic equation (cell C5), giving you their individual lnVDAO token total
    KuCoin = ln(277,552,416 / x) = 10.23117999

  2. Divide each validator’s logarithmic total by the sum of all validators’ logarithmic total (cell D2), giving you the % of lnVDAO tokens each validator holds
    KuCoin = 10.23117999 / 1165.71 = 0.0087767798

  3. Multiply this percentage by the total amount of staked ONE (cell E2), converting the % of lnVDAO tokens each validator holds back into ONE
    KuCoin = 0.0087767798 * 5,450,921,215 = 47,841,535.2112 VDAO tokens

Add Standard voting 50% and Logarithmic voting 50%:
KuCoin = 138,776,208 + 47,841,535.2112 = 186,617,564 VDAO tokens (cell F5)

[NOTE: The “+.01” in y=ln(x/10,000)+.01 was dropped to simplify the equation]

Upper and Lower “Caps” are also suggested for VDAOG:

The Upper Cap, as PiStake said, is set at 52 keys * 1.35EMS (e.g., 52 * 5,238,400 = 367,735,680 ONE). This cap reinforces HIP-16’s “6% Rule”. It prevents a validator (e.g., Binance) from having an over-sized voting share in comparison to the total number of BLS keys they’re allowed to have. Binance would have the voting power of ~128 keys at 1.35EMS (or ~265 at .65EMS), despite being limited to 52 keys per HIP-16.

The Lower Cap is set at .65EMS (.65 * 5,238,400 = 3,404,960 ONE). For validators with total stake below the Lower Cap, they do not receive the logarithmic voting 50%. They only receive the standard voting 50%. For them,
their VDAOG allotment = validator total stake / 2.

The lower cap is a somewhat arbitrary cut-off, but is intended to further reduce the risk of a malicious actor creating numerous low-stake validators in order to swing a vote. (Another possible option for the lower cap would be to reduce VDAOG for all unelected validators instead of using .65EMS.)

Per recommendation, here is a Glossary of Terms:

  • EMS (Effective Median Stake) - Median stake per BLS key, as calculated by Harmony’s Effective Proof of Stake protocol (EPoS)

  • HIP (Harmony Improvement Proposal) - Governance proposals voted on by Harmony validators

  • VDAOG (Validator DAO Governance token) - Token used by validators to vote on governance proposals

  • lnVDAOG (logarithmic VDAOG) - Logarithmic component of VDAOG

5 Likes
9

Great progress and awesome calculation, but two questions

About that alias voting, if I send out a compensation to delegator due to technical issues can he take over my alias by sending the one back to me? And is it just a alias or will the vdaog token transferred?

About the charter and smaller bounties I saw that governors need to vote and approve (6 of 9) and then it will be 14 days up to discuss before able to claim. should there not an easier way and include on approval direct the members?

10

Once proof is established of ownership of the wallet address, you cannot revoke it until you decide to. The proof to establish ownership will be a small denomination of ONE and must be sent in a certain timeframe and possibly a certain amount. Similar to fiat KYC bank binding. This is something that will be fleshed out with thr DevDAO.

This is in regards to using 10% or more of currrent treasury holdings. Small initiatives not needing 10% of funds just require governor supermajority vote that may be internal. These are then posted to Talk forum as an example for 7 days to gauge support.

2 Likes
11

But it’s still also possible to vote with the Validator wallet itself?

May I’m looking at the wrong document or don’t understand correctly but under 10% is required for 14 days On talk and over 10% is required for 7 days.

Screenshot_20220608-144715~2
Screenshot_20220608-144715~21440×2046 273 KB

But that would mean if wanna suggest today a bounty I forward it to VDAO governor and need to wait till 6 of 9 approve (what if 4 governors have a problem with my person but bounty would be good? How can I track the status? Is there a specific way to outreach? Through discord so it’s public? What if I reach out to a governor and he delete my message?) post it again on talk and then it will announced through pertinent channels or outlets at the VDAO Governor’s discretion. And what this means? Is there a specific channel or do I need to search for those announcements?

3 Likes
12

Going to address this here. Section B: Minor Initiatives, subsection b) states 7 days to post and gain support - should be 14 days. Needs to be addressed for consistency. @ben2k_Stakeridoo I thought with bounties you addressed this section. Either way it’s a good catch, the VDAO will address and update to make consistent.

Yes, here you are totally right, Under Section B, b), ii. states 7 days whereas all other sections (not just in bounties) state 14. This would not prevent the Charter from being functional. Again, thank you - good catch! The VDAO will update to make this consistent.

Yes, bounties are requiring the use of funds and thereby should have an agreement from the governors before funds are pledged to a bounty recipient in aims to ensure fund oversight. Right now, we did not specify any particular website for bounties as there is not ideal standard - people may use things like charmverse or github for bounties and their tracking. This part was vague and left so for the VDAO to use what method they are most comfortable with. Tracking and evaluating bounty progress and caliber of work is also up to the VDAO as each bounty is case-by-case.

It would be IF snapshot is integrated within the CLI and will hold that support. The alias wallet allows for a greater level of security by not having to constantly use the validator wallet for each action, thereby reducing security risks. IF snapshot voting is integrated in full then it would be best up to the community to voice their input if this feature is to be kept or not. As of now this solution addresses the possible security risks and the lack of any CLI support.

1 Like
13

99% of the entire community can agree on a bounty yet a few governors can override this.

99% of the entire community can disagree on a bounty yet a few governors can override this.

I know this is not your intentions but this is centralised and in the future could be used for corrupt activities and potentially poor implementations of said bounties.

Of course, it would also depend on the type of bounty but this will be especially relevant to protocol changes.

I also find "due to unforseen circumstances " a little vague but more you follow with "unable to function within the bounds of the charter "

I worry that they could be open to interpretation to benefit certain individuals or groups without any extra input from the community.

Maybe not list every circumstance but there should be some mechanism to counter / challenge if necessary.

3 Likes
14

@Maffaz Made a good point I’m talking about

About the Wallet I’m concrete asking if this feature will be implemented and I use my wallet (not with CLI) to vote. Is this afterwards still possible?? Or am I forced to use that feature?

1 Like
15

The Bounties section of the Charter is to address bounties made specifically by the VDAO for meeting their deliverables or for benefitting that Term. Were you referring to any bounty made by anyone on Harmony? The VDAO making bounties and sending payment for them should be managed by the VDAO as it will come from the treasury, as stated within the Charter.

This footnote within the Charter specifically and only points to the snapshot and Talk forum website. It states ‘the links listed must be deemed null and void, due only to unforeseen circumstances, which would prohibit the VDAO from being able to function within the bounds of its Charter. All other circumstances require their amendment through ratification.’ This is to address the possibility of Harmony moving from Talk forums in the future or migrating from snapshot so updating the Charter may be done more efficiently by only changing a few links.

1 Like
16

Using the alias wallet you will not be able to vote with either wallet at will. A validator will have to revoke the VDAOG tokens from any alias and then may vote with the validator address as normal - to prevent double voting. However, this will be up to the validator to decide what option they wish to choose - once snapshot is integrated into HMY CLI for gov voting in full. The alias wallet also opens up the possibility to gov vote on mobile without needing to possibly expose validator private keys.

Overall, the alias wallet voting mechanism provides a good utility and flexibility to nodes in voting while minimizing the risk of compromising their wallet on accident.

2 Likes
17

I am talking specifically about the VDAO bounties and agree wholeheartedly that they should be managed by the DAO.

In Section B-a-iii it is stated:

“After no less than fourteen (14) days on the official †VDAO Governance
Proposal Site the Bounty can be posted and its availability announced through
the pertinent channels or outlets at the VDAO Governor’s discretion.”

This is vague enough to be interpreted anyway and could be open to corruption of funds.

For <10% a snapshot vote is probably overkill but there should be some mechanism involved that allows the community to challenge . I doubt this will happen in general but if that possibility is removed it can be taken advantage of in the future when 10% could mean $10k for example.

I was referring to the Charter Ratification section. Maybe this was left in error… The footnotes are clear :slight_smile:

image
image817×630 183 KB

Other than those 2 nitpicks, it looks great and is well presented and written… Excellent job!

5 Likes
18

Thank you everyone for taking the time to look at our post, vote and leave comments. Thank you @Maffaz and @ben2k_Stakeridoo for all your comments and questions. We really appreciate you taking the time to thoroughly review the updated Charter that we have presented. You’ve helped to identify several areas where we can make the document more consistent and more complete.

As far as your latest comments I will address them the best I can.

I agree that the bold wording in section B-a-iii could be reworded something along the lines of:
“After no less than fourteen (14) days on the official †VDAO Governance
Proposal Site the Bounty may be posted and its availability must be announced through
all pertinent channels and outlets.”

Same with the wording in section B-b-iv:
“Once a vote has been approved through the official *VDAO Governance Voting
Site, the Bounty may be posted and its availability must be announced through
all pertinent channels and outlets.”

We left this section open in wording because the community sentiment alone if negative on the proposal site (talk forum) during the 14 days it is posted should be enough to deter a bounty from moving forward. However in the case that you believe this is not enough I am not opposed to the idea of challenging a bounty but it can work negatively in both ways. A balance would need to be found in order to add a challenge to a bounty without it being abused easily and causing a hold up with bounties that should be easy to pass. We would be happy to work with you on a solution to this that would work for both the proponents of the bounty as well as the community.

The following section was left as sort of a fail safe. The wording sounds complete in my opinion as far as how you could change the charter due to the complete wording, especially that which is specified as shown in bold. If you would like to suggest a different way of wording this section or want to suggest its deletion we would be happy to look at it.

“B. The creation of a new Charter would require that the current Charter be deemed null
and void, due only to unforeseen circumstances, which would prohibit the VDAO from
being able to amend the current Charter using established methods, prohibiting the
VDAO from functioning within the bounds of its Charter. All other circumstances require
the current Charter be amended through ratification.”

We would be open to discuss how you would consider countering or challenging the creation of a new Charter in an acceptable manner. My thought initially is to require the proposed charter to be posted to the VDAO Governance Proposal Site (Talk Forum) for 14 days to gauge community support, then require the proposed charter be posted for a vote on the VDAO Governance Voting Site, unless as a valid location and voting method are not available and working at the time of voting.

If you run into anything else you would like to go over with us, please bring it to our attention. Thanks again for everything, we look forward to working through these final details to make this charter as detailed and complete as possible.

5 Likes
19

@AffinityShard thanks for now understanding my concerns and addressing it (thanks @Maffaz for support) can I suggest to go but further:

the bounty will be posted and the availability must be announced through the pertinent channels like Discord (link) Telegram (link) and the bounty platform itself (link)

5 Likes
20

So the validator dao is just going to change the voting method without a vote from the validator community? It’s been stake weight since I’ve been a delegator around 2 years. I don’t see anyone confirming that it’s impossible to vote that way on snapshot. I’d like for someone to confirm this. What this looks like to me and others is that the current governors, half from harmoforce, along with small validators who’ve been complaining for months are taking advantage of the situation and changing the game to fit their agenda. I’m actually surprised to see some of the validators on here agreeing with this, because in the past they championed decentralization. I guess money always ends up being the motive. To summarize this it doesn’t appear right that a group of governors can have the power to change policy when the entire dao time on Harmony it’s been preached that dao governors don’t create policy. They assist the governance, they don’t dictate. @Jacksteroo @giv @lij

2 Likes