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.
- 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.
Bcan have more than one token holder delegating to them.
Bdelegates their voting power to someone else (
Cwill only be delegated whatever voting power
Bhas on their own (their own tokens) and not everything that has been delegated to
- At any time
Acan overrule whatever
Bchanges their vote later, they wouldn’t be overruling
Avotes on a proposal before their delegate
Bvotes they won’t be casting a vote on behalf of
Asince they already voted.
Bshouldn’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).
Bshould be able to signal that they are an active delegate for passive token holders to discover and delegate to them.
Ashould be able to see what
Bvoted (or whether
Babstained) on their behalf for on-going votes and all past votes since the delegation happened.
Ashould be able to revoke their delegation at any time, removing any on-going casted votes by
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.