[ARFC] Private Voting for Aave Governance [2-month Trial]

[0xkeyrock.eth]

From what i’m reading, there is no optionality if Shutter is enabled? Meaning that once enabled the voter does not have the option to choose between the Shutter private option or to be publicly seen before the “private reveal”.

I believe optionality is best for this but would be curious to see the Trial and welcome the experimentation.

As mentioned already by @MarcZeller, transparency on voting actions is essential for delegates and this would create a few obstacles if there no optionality on Private/Public voting view.

[TinkaB]

supportive of experimentation here at the snapshot phase

[stani]

Thank you @lbsblockchain @Michigan_Blockchain and @fig for coming forward with the idea. The Aave community and governance at the current state definitely has space for experimentations and shielded voting could enable results that might lead to less skew to high voters direction and we might see some exiting results from the experimentation. Highly supporting the initiative.

[jengajojo]

Thank you for this proposal. We have seen promising results with shield voting in many DAOs and I am confident that the AAVE community will benefit from this implementation. Since this proposal asks for a 2 month trial, what is the success criteria for this trial?

[lbsblockchain]

Just an update on this proposal: it has received support from the community and an indication that the community would be happy with a 2-month trial. We are going to take into account @jengajojo’s feedback and define success criteria for the trial, which we’ll then upload onto this forum and simultaneously publish the Snapshot.

[lbsblockchain]

As per @jengajojo’s feedback, we’ve come up with 3 criteria to assess the success of the trial. The time period the below criteria will be considered over will be 2 months prior to private voting being enabled vs. 2 months from when the time it is enabled.

• Average spread between YES to NO votes
• Number of unique voters voting
• Difference between outcomes of the votes, i.e., what % of votes result in YES

For each of these criteria, success is when the average spread between YES to NO votes reduces, the number of unique voters increases, and there is greater variety in the outcome of the votes. These outcomes would indicate increased and more thorough engagement across the community.

We will progress this proposal to Snapshot stage on Monday 24 April.

[jengajojo]

Thank you @lbsblockchain for incorporating the feedback. I support your suggested criteria

[lbsblockchain]

Hi all, we’ve uploaded this to Snapshot and voting is set to go live 24 hours from now (17.00 GMT on 25th April 2023).

Please find the link here and we’d love your participation!

[yohangglobal]

Although it might be too late of a response, I noticed this proposal on Snapshot and believe the reasoning provided by @lbsblockchain is too one-sided.

I agree that it’s a net positive to allow for this type of experimentation as @MarcZeller mentioned but there could be volatile precedents set in place with the widespread acceptance of shielded voting.

There are already multiple examples of highly contested proposals being swayed a certain way because of an entity’s increased voting power:
Sushi Kanpai | Uniswap BNB.

Their individual outcomes aside, the ability of the average voter to be fully aware of where deciding factors in a vote are coming from as well as align a voter’s actions with their public outlook is an important factor of governance that shouldn’t be restricted.

Take the below comment into consideration:

@Kene_StableLab

there is an overlooked psychological effect that being able to see the results of an ongoing governance vote might have on token holders

There is an undoubtedly strong impact on group voting when participants view larger entities engaging in governance. However, I feel as if protecting/shielding this engagement would advance the negative side of token voting compared to the positive benefits explained in the OP.

In one of the above-mentioned voting examples, there were instances where an entity became very outspoken about community support and its outlook on the protocol. During voting, this same entity voted against the general community even after stating otherwise.

From my viewpoint, this is where shielded voting would lead. This isn’t to say that protecting participants’ privacy is unimportant, I simply think that in a situation where parties could control a larger majority of voting power, transparency around their identity or standing within the community shouldn’t be hidden.

Another aspect of this that should be considered in greater depth is who determines the eventual success/failure of this shielded voting. The success criteria provided are reasonable, yet moving from an upgraded Snapshot space back to a disabled feature has not been clarified.

If it becomes clear that shielded voting would favor larger entities (and depending on the agreed upon method for including this change), who’s to say this would not become the status quo since these larger entities could vote this change into effect permanently?

[fig]

This is a risk in current models - and not sure how it changes with private voting.

@yohangglobal

I simply think that in a situation where parties could control a larger majority of voting power, transparency around their identity or standing within the community shouldn’t be hidden.

Nefarious actors may borrow or buy AAVE across multiple wallets - masking their identity, yet accumulating more power through this action.

As a reminder - the results are revealed after the vote concludes, allowing for a bit of accountability. If the community deems there is too much risk - they may shut it off at any time via a vote.

In my opinion, the risk of this trial is minimized as it exists in the TEMP CHECK / ARFC stage; budget requests, asset additions, and protocol upgrades still need to go on-chain to be executed

I agree it’s not a perfect solution yet - but looking at this community, it seems most competent to learn, experiment, and reflect on the outcomes from a trial.

[Luis]

Hey!

Luis here from Shutter (we worked with Snapshot to implement the shielded voting using threshold encryption).
It’s awesome to see this proposal and the active discussion around it!

To put it simply, shielded voting seems preferable (and that’s why real election voting works like this), due to higher information symmetry at the time of vote. We think this leads to less voter apathy and less manipulation/strategic voting.

It doesn’t prevent bribery or enhance individual voters privacy.

We also don’t think it negatively affects auditability/transparency, because all results will be public and auditable afterwards.

Ping us or the Snapshot team if you have more questions! We’d love to help and gather feedback during this trial, if the vote passes!

[NathanVDH]

Very happy to see this put into a test, in the end there’s no better way to see if it’s a fit for the Aave community! Happy to help in setting it up as well if needed.

[lajarre]

As we’re working on addressing collusion in DAOs at Butter, we’re interested in this experiment.

@lbsblockchain

Prevent early voters’ decisions from influencing the decisions of later voters, thus reduce herding behavior and encourage independent thinking.

One of the arguments for shielded voting is that it reduces tacit collusion (indirect cooperation via observing live Snapshot results), leading to more truthful votes, as @Luis points out.

However, certain groups, such as a small group of whales with shared interests, might still collude under shielded voting. Their small size enables them to coordinate directly with lower costs.
As @Figue rightly points out, shielded voting makes such collusion undetectable until after the vote concludes. This could be detrimental to the community in certain cases.
However, it might be possible to counterbalance this: for instance, what about running a second Snapshot proposal if the community determines the initial vote was heavily biased?

In summary, implementing it will lead to different voting dynamics, which will be worth monitoring.
Also, as a consequence, this change might also impact the way some Temp Checks are conducted.

[yohangglobal]

Hey fig! Yeah I think we’re on the same page, I could also be viewing this from a more biased standpoint due to past experience.

Re: malicious actors, methods like borrowing/buying AAVE indirectly are more or less trackable to a certain extent (depending on the amount of effort directed to searching) imo.

Has the method for shutting off via vote been discussed yet (might’ve missed a few of these points) or would this follow a similar process as other proposals?

I think there could be two sides to displaying this on Aave vs a smaller dao/protocol since a permanent inclusion would lead to a much more impactful precedent. Still agree though that a temp check in this sense is a better outcome.

[yohangglobal]

Hey Luis, appreciate the effort in building out these types of products. I’d push back on the following re: negative effects and election voting.

@Luis

We also don’t think it negatively affects auditability/transparency, because all results will be public and auditable afterwards.

Although results would be public, the benefit of having transparency would have no impact until after the vote and would lead to voters finding out any collusion only when it’s too late.

This same concept applies to your outlook on election voting, which is true when it comes to the “1 person = 1 vote” mentality.

@Luis

shielded voting seems preferable (and that’s why real election voting works like this)

However, this is not the case when it comes to token-gated governance where users can purchase their voting power. I’d assume that the same types of strategies would apply in this case with the added benefit of hidden addresses/tokens used.

Did your team discuss similar factors as this? Would love to know how parts of these discussions ended up and where improvements could be added.

[lbsblockchain]

The Snapshot proposal has passed. @MarcZeller, given that this was an ARFC and no code changes are required, would you be able to turn on the privacy option in Snapshot as an admin? We can then monitor performance according to the three criteria we highlighted here.

[MarcZeller]

@lbsblockchain

would you be able to turn on the privacy option in Snapshot as an admin?

taking care of this, let’s sync on telegram for implementation details

Update: this has been implemented, and will remain as such until the 5th of July 2023 unless community votes to extend private voting on snapshot.

[AHurwitz]

Good afternoon Aave community! I’m a Safe Guardian and would like to know what the takeaways are from the 2 month trial of shielded voting. The SafeDAO is considering a similar test.

• What worked well and improved with shielded voting?
• What did not improve with shielded voting?
• Will Aave governance continue using shielded voting? If so, will it be for specific types of votes, or sub groups within the DAO?

Much appreciated! 🫱🏻‍🫲🏼

[lbsblockchain]

Hi @AHurwitz thanks for asking!

It’s been 2 months since the trial has ended and @fig and I are planning on having a chat and running through the takeaways, including your questions here. We’ll post our takeaways here ASAP

[AHurwitz]

Excellent and thank you! It will be great for DAOs to learn from Aave’s insights here.

I came about 2 additional Snapshot add-on strategies I brainstormed today that could potentially be useful with existing voting strategies to reduce collusion of larger voters.