Research UX for delegating votes

[AlexJupiter]

Opening this up as a potential "epic" to streamline the work around creating a v2 for the delegation of votes.

This DropBox Paper file contains all research towards accomplishing this epic, however this GitHub issue will hopefully serve as a central point of discussion for moving the accomplishment of the epic forward.

[AlexJupiter]

@virgile-dev @santisiri in the white paper there is the concept of Transitive Delegation and the ability for a delegator to restrict the use of their vote by a third party.

I was wondering whether we should concern ourselves with this feature for this iteration, and whether it's it's even possible to implement this feature before we connect the Sovereign front end with a blockchain back end?

[santisiri]

The problem you can run into transitive delegation without any constraint is getting trapped into some circular events (infinite loops). The most simple example is

Alice delegates to Bob, Bob delegates to Charlie, Charlie delegates to Alice. 🤯

There are more complex ones. By treating votes as tokens we can approach it better from a blockchain perspective for accounting, and including functions (vote, delegate, revoke) that are simple for the user. Yet there are some limits:

If Alice allocated 100% of her votes, and 2% of those want to be revoked by Bob, Bob won't be able to get them back.

The interface now communicates this particular scenario when it happens. Now, there's a cost for Alice to keep her votes allocated (or delegated): she will not be able to sell them. Hence she has an incentive to keep moving them. If the revoke call remains active, the prioritiy will be given to Bob for those tokens.

That said: I'm always in favor on figuring out how to improve this key part of the UX.