Thats what i was thinking too.
I think voting should be transparent, nobody is hiding something and has a clear stance on their votes.
Thats what i was thinking too.
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.
supportive of experimentation here at the snapshot phase
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.
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?
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.
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.
Thank you @lbsblockchain for incorporating the feedback. I support your suggested criteria
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!
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.
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:
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?
This is a risk in current models - and not sure how it changes with private voting.
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 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!
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.
As we’re working on addressing collusion in DAOs at Butter, we’re interested in this experiment.
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.
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.
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.
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.
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.
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.
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.
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! 🏻🏼