AGP discussion: Support Locked Voting

The thing is that people would commit to locking at the time of the vote, not have had their tokens locked for the prior year.

You are right, now that I keep thinking about, it make sense to be that way.

Yes, ANT holders would lock their ANT for a period of one year or more to be eligible to vote. They will not be able to vote if their ANT is not locked for at least one year at the start of the vote.

Thanks for the clarification.

With 1Hive team we are starting to work on a first implementation of a lock voting kind of app:

1 Like

Yes I see the use of this now! Thanks for the clarification.

I think the AGP you propose here makes sense.

But based on the feedback, I wonder if it would be better for the lock length to be specified in the later AGP that brings it to life?

@luis idea here about the lock length increasing your voting weight can be another dynamic to exlore.

1 Like

I support this! It sidesteps the ‘buying voting power’ problem, but 1 year seems like a sledgehammer.

I am cognizant of the low voter turnout which would most probably decrease. Another approach could be some kind of time-weighted voting, although this would increase the complexity



I’m very glad to see the plutocracy problem in Aragon being acknowledged and to realize there are already initiatives/ideas that are willing to tackle it, but I have to say I’m not personally sure about this being a good solution, as this could end in having votes only from the usual suspects as it is basically a counter-incentive for new people to come to the Aragon ecosystem, understanding and adding diversity by their participation.

This proposal has nothing to do with addressing plutocracy. It’s a measure to stop someone buying voting power and using it without having exposure to the results. But I do agree with the need to look closely at how various lock times change the incentives of all participants


Plutocracy is a tricky theme last days, and I have realized lately that people tend to handle different concepts (just like it happens with terms such as capitalism).

Anyway, in my own perception, as long as people can acquire voting power with economic wealth we’ll be in the presence of plutocracy. Like it or not, governance by ANT holding is precisely that, for the time being I think it’s ok until we discover and validate better mechanisms.

Anyhow, @light I’d be curious about your view in implementing something like conviction voting instead of locking tokens to tackle this very same issue.

1 Like

The 1Hive Lock app as its currently intended would not help address this issue (Since the current voting app does not have a role for cast vote, and I believe the intention is for voting to be limited to Locked ANT). It more intended as a way to minimize spam by requiring some cost associated with taking an action (in this case its an opportunity cost of locking the asset).

Perhaps a seperate thread on conviction voting would make sense? Its one of the most interesting voting mechanisms I’ve seen proposed but feels a bit off-topic for this thread…

This is my main concern with this proposal as well, I talked about this in the other thread that this came up in: Whale watching on ANV-2 🐳

A question that comes up for me is how this would interact with delegation? Presumably it means that in order to delegate your vote you would also be subject to the 1 year lock requirement.

Another challenge would be for organizations that use Fundraising using the default template which includes an ANT reserve requirement. One of the benefits of this is that the organization can choose to participate in the AGP process, but it would not be possible for them to lock ANT held in the bonding curve reserve, as it would break the bonding curve sell function.

I think time-locking mechanics are an interesting and would be supportive of similar proposals, but would not support an implementation of locked voting as currently described for the AGP process.

One approach that I think could be interesting would be to add a bonus weight for locking ANT (perhaps also have this bonus be quadratic and tied to some sort of identified user registry). That way people can still participate without locking, but those that do lock have a greater say.


I think the only effect this would have is to stop people from voting with their ANT until they are comfortable exposing themselves to the consequences of a vote for at least one year, which is precisely the goal of the proposal. If you aren’t comfortable exposing yourself to the consequences of a vote for at least a year after the vote, then you probably shouldn’t be participating in Aragon governance. We want long-term participants.

I’m not sure what is possible from a technical standpoint but the way I would do it is that everyone who wants their tokens counted in a vote has to have them locked for at least one year, whether the tokens are delegated or not. So the UX would be: lock for one year -> delegate. Then the weight of the delegate’s vote is measured by the number of correctly locked tokens that have been delegated to them (and the number of their own correctly locked tokens).

Would it be possible to have something like once someone sells their org tokens back to the curve, if the ANT they are trying to buy from the curve are locked then they will receive the ANT once it unlocks?

I had considered adding a “weighted” mechanic to the proposal i.e. the longer the lock, the more weight the vote gets. But as people are already sensitive to the economic weighting of ANT votes I figured it would be best to not increase the voting-weight disparity between larger and smaller holders. I’d prefer to keep voters on an “even footing” so to speak.

1 Like

Its not just that you are exposing yourself to the results of the votes you choose to participate in but also the results of all votes within the next year. (presumably it also means that in order to eventually divest you have to have not participated in any votes for a year).

Its very reasonable (especially for a smaller holder) to prefer liquidity over participation because they have relatively little say in the outcome anyways.

The importance of exit is why in Moloch for example, votes are done on a regular basis but in sequence, if you vote yes you are not able to exit (the shares are non-transferrable and the ragequit option is not available) until after that decision has been executed. Because votes are in sequence, you will always have the option to exit if you choose to vote no on a subsequent proposal.

Perhaps if we do go down the locking route it would make sense for us to lock only for 2.5 months, that way if you are voting you forfeit your ability to sell before the next ANV, but you are not exposing yourself to future proposals that you have never reviewed, and possibly only if you vote to approve proposals are you subject to the restriction.

Agreed it seems like it would make sense for those delegating to also be subject to the lock requirement…

Though it makes me think about the tradeoff space for delegation implementation (and one of the reasons we decided to implement delegation as an upgrade to the voting app rather than as a seperate proxy voting contract) is that delegation should be possible without having to transfer tokens out of cold storage. Presumably the locking requirement would mean that users would need to send their tokens to a contract, which can deter certain groups (like funds which have policies on asset storage) from participating.

I’m not sure, it seems like it would be quite complex though, especially if locking requires moving a token into a separate contract.

I updated this AGP draft to remove the one-year requirement so we can focus on the general concept of Locked Voting:

This may be the better option, if we decide to go down this path. Though I think 2.5 months is not really a long time for the negative consequences of a vote to be realized, the same could be said for a one-year lock time too. I had originally considered four years, inspired by the typical 48 months vesting in startup equities :wink:

That’s fine, they just wouldn’t be eligible to vote then. This is the explicit trade-off this AGP is asking people to make. Trade liquidity for commitment and voting rights.

If this Locked Voting contract becomes a standard then I don’t see why they couldn’t add it to their storage policy, then they can still vote in orgs that required tokens to be locked to vote.

That does sound complex!

Based on all of this feedback it sounds like the options are:

  • Implement Locked Voting and exclude a bunch of ANT holders for various technical (hard) or policy (soft) reasons, and maybe mitigate the Bad Voter attack vector (what I’m calling the attack where someone buys a bunch of ANT, makes a bad decision in a vote, then dumps the ANT before the market has time to react), or
  • Don’t implement Locked Voting, remain fully exposed to the Bad Voter attack vector

ANT holders then have to weigh whether excluding a bunch of ANT holders from voting is worth the risk of being exposed to the Bad Voter attack vector.

Agreed. I’m just pointing out that this tradeoff is worse for you the less of a whale you are. Which is I think important to identify since the other main concern I’ve seen vocalized is that small holders feel disenfranchised by straight token voting.

And while I’m very much of the opinion that stake weighted voting is the right choice for the Aragon Network right now, I also recognize the importance of individual contributors to the ecosystem and I would hate for them to feel even more marginalized by the project’s governance.

This is a false dichotomy, there are other ways to potentially approach the “Bad Voter” attack vector, that may have completely different tradeoffs.

1 Like

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.

1 Like

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.

1 Like

Fair enough – it does seem like we need some sort of detailed analysis with each possible model, impact, development cost and UX cost.

1 Like

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.

1 Like

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.

1 Like