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 powerB
has on their own (their own tokens) and not everything that has been delegated toB
. - At any time
A
can overrule whateverB
voted. IfB
changes their vote later, they wouldnât be overrulingA
's overrule. - If
A
votes on a proposal before their delegateB
does, wheneverB
votes they wonât be casting a vote on behalf ofA
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 whatB
voted (or whetherB
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 byB
onA
'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.