Do you have examples? (Probably worth a new thread to discuss ways of mitigating this attack vector)
Agree that a separate thread is probably better to dive into details, but off the top of my head some possibilities are:
- Focus on increasing the participation rate in votes (delegation may help with this, though a voting incentive could also be used to target a participation rate), which would increase the cost and ability to perform the “bad voter attack” given market depth/liquidity
- Implement a dynamic quorum requirement based on a futarchy signaling market, so its easier to pass proposals which are predicted to positively impact the price of ANT but difficult to pass proposals that are predicted to decrease value
- Implement something like conviction voting, where votes increase in magnitude over time, making it impossible to swing a vote quickly and then sell (without giving others the opportunity to sell before you can pass the vote).
- Implement some sort of identity layer to provide sybil resistance and add non-linearity to voting weights (something like QV), this would make it harder for a bad voter to swing votes without also compromising the identity layer.
These all have varying degrees of complexity and tradeoff spaces, but the point is that we should not think that lock voting is the only way to approach the “Bad Voter” attack. And choosing to not focus on lock voting, doesn’t imply that ANT holders are comfortable with how vulnerable to “bad voters” the system is currently.
I would also add that the status quo is not that we are “fully vulnerable to bad voters” as the Association Review process filters out proposals that would be truly damaging to the project if they were to pass.
If the intent is to limit what we’re calling the ‘Bad Voter’ attack, then locking tokens between voting cycles is clearly long enough.
As it stands, the attacker only has volatility risk of a few blocks and thus can effectively buy voting power at marginal risk to their equity. Locking between voting cycles exponentially increases this risk making it totally infeasible as well as allowing safe exit for ‘legitimate’ voters who disagree with subsequent votes
I would argue that if there were no negative consequences after 2.5 months, It could hardly be classed as an attack. A Bad Voter attack will be noisy and controversial. When coupled with the inherent liquidity risk, it effectively stops this vector dead in the water.
+1. Although we are not ‘fully vulnerable’ it is a very important topic that deserves a deep dive and some attention from the community at large
All of these do sound great, but are at least an order of magnitude harder than just implementing locking. The only exception is delegation, which we have already done work on, and I think we can increase participation that way, but there is still a lot of communication work that would need to be done in that direction.
That’s why I really like locked voting – it’s a solution that we could implement extremely easily.
I’m not sure this is true. Both because I don’t think we have really examined what the implementation requirements are for locked voting, and because it may also not be as difficult as we think to implement some of these other suggestions.
As a short term solution I would much rather see us first implement quiet ending period + delegation and possibly a reward pool to incentivize participation to try and increase the participation rate (and therefore the cost/feasibility of buying ANT to influence vote outcomes and then selling afterwords). This doesn’t seem to be an order of magnitude more difficult to implement, it may actually be easier.
Im excited to see how ANT holders vote on this topic, but I think it’s also important that we don’t bias the results by positioning this as something that is “easy” or something without reasonable alternatives.
Fair enough – it does seem like we need some sort of detailed analysis with each possible model, impact, development cost and UX cost.
I wonder if it would be possible to come up with a way to do locked voting using the token controller and the dissent oracle mechanism that is being discussed as part of the 1Hive Dandelion Org grant, rather than by transferring tokens to a separate contract.
The idea here would be that if a holder votes to approve a proposal, they forfeit their ability to transfer tokens for some duration of time. The token controller would validate that the wallet is able to transfer based on checking when the last time they voted yes was. There is already some active work being done by @Quazia to implement a transferability oracle mechanism into the token manager, and this feels like it could follow a similar pattern.
This would be more complicated for ANT than for other Aragon organization tokens because the ANT doesn’t use the Token Manager as its token controller, but it seems like it is atleast worth exploring.
The advantages of this route is would be that we could avoid excluding organizations from participating in the AGP process if ANT is held in the fundraising apps reserve pool, and it wouldn’t require users to move their tokens into a separate contract (making voting more accessible to people who prefer to keep their assets in cold storage).
Thanks everyone for the great discussion around this AGP. Given the many open questions, I am going to withdraw this AGP draft until we have better information about the implications and alternatives for locked voting. And as was pointed out up-thread, the Aragon Network is somewhat protected from a “Bad Voter” attack by the AA’s curation role built into the AGP process, so this is not an urgent issue. I will pick up the discussion about Bad Voter attack mitigations on another thread.
Was going to post this as part of a larger response to AGP Discussion: ANV Reward Policy but wanted to keep all the locked voting (and risks of locked voting) mostly contained to one thread.
Locked voting creates a disincentive to vote by introducing an opportunity cost to voting. It’s not clear how dramatically this will impact participation rates, but if participation rates are reduced the cost of influencing a vote may also decrease. So if the goal is to increase the cost the (currently hypothetical) scenario of a Bad Voter buying ANT to vote, then dumping ANT and not being exposed to the results of the vote. It may solve that problem but do so in a way that makes it profitable to buy enough ANT to swing a vote and treat the ANT investment as a write-off. If the value of swinging a vote is > the expected downside of devaluing ANT then this is not an effective deterrent.
Passing a vote may have a high expected value for an individual, but negative expected value for Aragon as a whole, if a vote like this passes the individual gains, and the loss is spread across every ANT holder. The lower the participation rate the more profitable these types of proposals are…
Furthermore, If the time lock requirement doesn’t span multiple voting sessions, then the market may not actually react to reflect the impact of bad decisions. For example funding a flock proposal might turn out to be a bad decision, but it may not be clear to the market that it was a bad decisions for longer than the 3 month the period.
If the lock requirement is longer than a single voting period, the market will have longer time to react to the passage of bad proposals, but participants will face a greater risk as they forfeit their ability to exit in response to bad proposals being let through the association review process and must put even more trust in the association to curate proposals.
It’s not clear how the overall impact that introducing a locking requirement or how the duration of the locking period would effect the quality of decision making, I can imagine this proposal being net positive or net negative, but even on the positive side it probably means that we end up relying on a small subset of ANT holders (likely well connected insiders and whales who have additional insight into which proposals will be allowed through the Association review step…) which are probably not very representative of the wider community to call the shots.
In summary… Im not sure I see a huge upside to requiring locking over short periods of time (probably not enough to outweigh the many potential downsides) and I worry that long lock up periods would have all the disadvantages of a centralized voting authority with very little of the advantages of broad community-centric governance.