Voting v1 single delegation

Started this post as a Github issue on aragon-apps, but decided to post it here first because there are some open questions we should discuss before jumping into implementation.

Given that our naĂŻve liquid democracy implementation has been tabled due to scalability and technical concerns we should start considering implementing one-level delegation directly into the Voting app. Adding this feature should be possible through an on-chain upgrade of the current Voting implementation.

Requirements

  • A token holder (A) should be able to express to the Voting app that they wish to allow another account (B) to vote on their behalf.
  • B can have more than one token holder delegating to them.
  • If B delegates their voting power to someone else (C), C will only be delegated whatever voting power B has on their own (their own tokens) and not everything that has been delegated to B.
  • At any time A can overrule whatever B voted. If B changes their vote later, they wouldn’t be overruling A's overrule.
  • If A votes on a proposal before their delegate B does, whenever B votes they won’t be casting a vote on behalf of A since they already voted.
  • B shouldn’t have to incur on an extra gas cost because they are voting on behalf of someone else (voting cost should be constant regardless of delegate count).
  • B should be able to signal that they are an active delegate for passive token holders to discover and delegate to them.
  • A should be able to see what B voted (or whether B abstained) on their behalf for on-going votes and all past votes since the delegation happened.
  • A should be able to revoke their delegation at any time, removing any on-going casted votes by B on A's behalf.

Open questions

Constant voting cost for delegates

In order to achieve constant cost for the delegate, we need to have precomputed the total amount of delegated tokens a delegate has at any given time. In order to do this, we would need to execute a hook from the Token Manager’s onTransfer function (or potentially implement an intermediate Delegation management app that all the Voting apps in the DAO can use) to the Voting app to notify on every balance change so we can update the delegate’s total voting power.

In the context of using simple delegation for AGP voting we would need to transfer the controller of ANT to a contract that provides the Voting apps with this balance change notification (this will come at the expense of making ANT transfers even more expensive, ~3-7k gas more).

If used just for AN voting, the Staking app would need to implement the discussed stake change hook functionality that we decided to not implement for now.

Late delegate vote

There is a potential attack in which a delegate waits until the very last moment to vote on their delegate’s behalf for something that they think their delegates won’t agree with, but making it impossible for their delegates to notice and overrule.

This could be solved by adding a deadline for delegates to vote on behalf of others. After this only direct votes and overrules can be submitted, the deadline should be enough time for people to notice what their delegate voted and overrule it if needed. This should be a parameter configurable in every DAO, but I consider that a minimum of 24 hours are needed for this attack to be neutralized.

Checkpointing account delegates

In order to prevent an array of interesting problems I believe we should checkpoint an account’s delegates by block number. We can use the checkpointing library that both Staking and the LD implementations use.

5 Likes

Hey Jorge, really interesting post – I have a few questions:

  1. Does token holder always equal an individual’s account or could it also equal an organization or a group of organization’s members?

  2. How is voting power delegated and revoked? Will it be metadata associated to the voting account/token holder? Will this be stored on-chain? How do you imagine this process happening? Within the voting app itself? Through permissions or another authorized app?

  3. In the current voting app voting power is non transferable, so what are the implications for deployed orgs (and other applications) of adding this new functionality to it VS creating another vote delegation app?

  4. Should be there a max or min nÂș of votes that can be delegated to a single token holder that acts as delegate?

  5. What’s the difference between delegating voting power (in general) and delegating the action of casting 1 vote for a specific domain? For example, could you delegate your voting power for all the votes on ‘x’ domain?

  6. My assumption is that we’ll need a way to show the history of voting power delegation from specific (verified?) accounts. And possibly, a history of past votes per account too. We cannot rely on people remembering all their past actions. Where and how will this data be stored and fetched?

  7. We’ll also need a way to signal power delegation changes, for example, make B aware that A has overruled their vote. How do you think this info should be communicated?

  1. Does the above mean that delegation of voting power is not effective until the delegate casts the vote? And shouldn’t we try to prevent this in the first place? Meaning, communicating to B that can’t casts the vote on behalf of A before B spends time deciding on the issue and trying to do it.

  2. Discovery of active delegates – I feels this has a lot of unfolded complexity and also might be related to contextual identity. Must a delegate belong to the same org that the token holder that acts on behalf of? Could this delegates belong to the same pool of domain expertise?

  1. Does the above imply having some sort of filtering functionality added to the voting app, for example, to view only votes (ongoing, past and abstained) by B? It’d be great to explore this further and understand what additional filters/faceted search would be useful here.
3 Likes

I will read it again and think more about it. The requirements make a lot of sense to me, I want to think a little bit about the implementation details.

About this:

I also think we should consider the idea of creating a new app. For already deployed orgs, but also because some DAOs might want not to allow delegation. And well, you know, for that Unix principle too
 :wink:

It would be an address, which may be an individuals externally owned account (key) or a contract address controlled by one or more users (e.g. the actor app).

I think it is reasonable for delegative voting to be a separate app, but could see an argument for including it in the existing voting app under the pre-text that it is important for users to be able to participate in voting from cold storage.

There are interesting things that could be done here (you could apply a quadratic dampening function to vote balances from a single source for example, this is what Status is currently doing with their signaling app). However, I would consider that a completely different voting process with different objectives and outside the scope of delegation.

I believe that this proposes that delegation happens in the voting app, and therefore you could have a different delegate for each voting app instance installed in the organization. So if you have a voting app instance for finance and a voting app instance for contract upgrades you could have different delegates for each.

This feels like a nice to have, as opposed to a strict requirement initially in my opinion. I think we just need to be able to display in the voting interface how your voting authority was used on a given vote.

In the long run offering more visibility into delegation history would be good: how delegates have voted, how many people, how much voting authority is delegated to specific addresses is helpful information.

I’m not sure this is necessary, as I don’t think that information has any bearing on A or B’s actions. I think the more important notification is if A delegates to B, and then B delegates to C, A needs to know that unless they re-delegate to someone else who plans to vote directly their vote will not get cast.

Again I think this is important in the long run, but less so in the short-run. In the short-run we can probably assume that most people will delegate to active/public members of the community or to organizations like the community cooperative and likely those members will publicly state their positions and commitments to vote.

I don’t think this is something to prevent it is the expected behavior, If A votes it should always take precedence over what B does.

Also don’t think it is necessary for B to be aware or care about who is delegating to them, they vote as they normally would, and if someone has delegated to them then their vote just carries additional weight.

Agree lots of complexity here, but I think addressing that complexity can be out of scope for this. We can assume that people will communicate out of band whether they plan on voting directly, users may campaign based on their overall positions on the forum etc to attract delegates, we do not need to facilitate discovery imo.

Agree, I think this along with the comments above having additional information about voting behaviors available and well organized should be explored (though I think it can largely be deferred for now).

3 Likes

Good point!
(I’m adding void here because: “Post must be at least 20 characters”??)

Thinking more about it, I also think that some use cases could rather use a simple voting app, like a Multisig for instance.

1 Like

I think this is a compelling reason to have two versions of the Voting app.

It also brings attention to a relatively small but important issue–when an organization installs apps they probably need a way to rename them in the sidebar. EG the name of the voting app might be “Delegative Voting” or “Simple Voting” but the side bar should say “Member Voting” or “Board Voting”. The technical application name is not necessarily important to the users of a DAO, but the context in which it is used is important!

edit: cc @stellarmagnet @Paty

3 Likes

If minting new tokens is allowed, a hook from the mint function (or whatever calls token.generateTokens) should be added too, right?

1 Like

Hello everyone,

While I was working on some implementation for this I had an idea that I would like to bring to the table.

The two current approaches for tackling delegating cost are:

  1. The delegates themselves pay the extra gas for casting votes on behalf of other, which seems unfair.
  2. The ANT contract notifies every transaction to keep delegate total stake updated, which is a way of diluting the delegation cost amongst all holders.

A third alternative though is for the cost incur on holders that are delegating their vote, making all voters responsible for their own voting cost. This is how I imagine it could work:

When selecting a delegate, a holder also escrows a specif amount which will be available for delegates to withdraw after voting as a way to be refunded for the extra gas cost. This amount can be in ETH or any other token(ANT, GasToken).

This mechanism might also be useful in other scenarios. For example, it could be used to refund the voter that executes the voting script.

DThat’s interesting. The only thing to keep in mind with these sort of approaches is how a miner would be able to take advantage of such system and basically ‘steal’ the gas money (even if it is little money or only the delegate could do this).

There is another alternative that @sohkai was proposing offline that would be for delegates to optimistically self-report how many tokens they have been delegated to them.

I like the optimistic approach but I guess it needs careful implementation, as I feel that it will be susceptible to front running, by a malicious holder inserting transactions that change a delegate’s stake. I think it’s solvable though.

Can you elaborate on this? You mean by artificially increasing gas costs of a transaction?

Hey guys,
I made a stage 3 AGP for AA to prioritise the R&D efforts around DV. It was pointed out to me that it is on the road map and maybe engaging in the forum may be a better avenue to achieve this. With that in mind:

When should we expect to see DV on mainnet for AGP voting?
I see it listed in the Aragon Network road map as current. I’m not sure what that means exactly, it doesn’t appear to be scoped for 0.8

What is the current approach?
Is there going to be a new voting app, an upgrade to the existing one or some other solution

Also, one of the main reasons i feel DV should be prioritised is the fact that low quorum is dangerous and opens up potential attack vectors. What other plans do A1 and other flock teams have to incentivise people to use their vote or delegate? Is this something being researched and what is the current thinking around this?

4 Likes

Hey Aaron! @facuspagnuolo has been working on the smart contracts and they are ready https://github.com/aragon/aragon-apps/pull/881. The tricky part is the frontend, and we do not currently have bandwidth to do it for 0.8. It may be something we can do for further releases, like 0.9 for example.

4 Likes