Quorum Delegation

Authors: BlockScience and SDF, July 2023

Summary

Quorum Delegation is a framework that allows users to passively vote, by delegating their voting choice to a group of other users. As opposed to most other delegation frameworks, this allows users to distribute their choice over several people, instead of only one. Quorums can be formed client-side, by choosing and ranking a set of other users. When a specified minimum of this set has actively voted themselves, their votes can be used to determine a Quorum Vote decision. The Quorum vote decision can be formed on various alternative choices - for the PoC, this will be a mix of absolute and relative consensus within the Quorum. Without having to reveal any information about their Quorum, a user can then automatically vote with the Quorum. Any vote casted through Quorum Delegation then follows the remaining path through Neural Governance. In this way, Quorum Delegation can be seen as a first layer of NG.

The rationale for this design is to enable delegation of votes - which can reduce attention cost for users - while allowing for higher flexibility for users than a 1:1 relation can. The Quorum can be built from any group of users - a user might choose people they trust personally or instead find a personal balance of domain-experts, as this flexibility allows for a high personalization of delegation. The name of this mechanism is inspired from the quorums formed in the Stellar Consensus Mechanism.

Quroum Delegation in a glance. In this case, the Quorum is formed of 10 anonymous users, of which 6 vote "yes", 2 vote "no", 1 abstains, and the last one did not participate in the round. Because there are 8 yes/no voting users and the participation threshold is 3/5 (or 6 users), the quorum is valid. Because the "Yes" vote is larger than a simple majority on the active quorum (½ of the votes or 4 votes), the Quorum Consensus is to vote "Yes", which will be automatically cast on behalf of the Delegating User.

Use Cases

• Trust-Set: Users can delegate to a group of users they personally trust. This allows any User to construct a set that represents their personal views, while reducing the risk for unintended decisions by an individual they delegate to.

• Domain-specific Bloc: Users can delegate to a group of experts on a given topic. As an example, the vote for a development heavy proposal on infrastructure might be delegated to a group of respected devs from different projects, to reduce risk of unknown personal incentives outweighing general interests.

• Balanced Bloc: Users can delegate to a group of experts from different fields. As an example, the vote for a project proposal targetting remittances might be delegated to different experts from different regions, such as one Quorum member representing development expertise, another representing remittances expertise, financial services expertise, social studies expertise and so on.

User Journey

From the user point of view, Quorum Delegation takes place first in the UI, which generates the relevant calls to signal the decision to Delegate and sets the Quorum Candidates. Then, QD follows the backend and/or smart contract logic through which Vote Tallying occurs, allowing the vote to be automatically cast depending on the outcomes from their Quorum.

1. On the UI: During the voting round, the user indicates whether they want to Delegate or actively Vote.

2. On the UI: If the user decides to Delegate, then they must select at most MAX_QUORUM_CANDIDATES users which are eligible to form their individual anonymized quorum. These are their Quorum Candidates.

3. On the backend: The User Quorum will be resolved after the votes from the Actively Voting users were tallied. It will be defined through the following procedure:

   1. First, quorum candidates that abstained or chose to delegate for the round vote are filtered out.

   2. If the number of remaining candidates is above or equal QUORUM_SIZE, then the first QUORUM_SIZE candidates will form the User Quorum. If it is below, then the missing candidates will be filled by Abstain votes towards all projects (eg. if N_QUORUM = 5 and there are only 3 candidates, then the other 2 missing spots will be filled by Abstain votes towards any Voting Option)

4. On the backend: The Delegating User vote will be defined through a mixture of Absolute and Relative Consensus of his Quorum towards all possible Voting Options. Failure to have both results in the Delegating User taking an Abstain action.

5. For vote tallying purposes, the Delegating User vote towards any Voting Option is defined as the consensus of his Quorum towards that Voting Option. This concludes the journey.

Module-specific Adjustments

Parametric Adjustments

• MAX_QUORUM_CANDIDATES

  • The maximum size of potential candidates a User can select for their Quorum.

• QUORUM_SIZE

  • The maximum amount of candidates taken into the decision for a Quorum Decision Vote.

• THRESHOLD_QUORUM_PARTICIPATION

  • The threshold of Quorum Candidates actively voting to render an effective decision (as opposed to the User "absenting"). As an example, one might require that 3 out of 5 (quorum_size) candidates have voted.

• THRESHOLD_RELATIVE_AGREEMENT

  • The threshold of agreement among active candidate votes. As an example, one might require that at least 75% of the Quorum votes yes for a User to also vote yes.

Logic Adjustments

• Allowing or disallowing Re-Delegation.

• Implementing publicly known pre-sets for Quorums

• Allowing Users to overrule Quorum votes (through e.g. a waiting period or notification)

• Allowing Users to set all parameters themselves.

Functional Adjustments

• Generalizing and/or modifying Quorum Delegation for other voting outcomes rather than Yes/No/Abstain

• Allowing for Quorum pre-selects (Dev Quorum, Social Quorum, Influencer Quorum etc)

• Adapting the internal Quorum Vote from 1-candidate-1-vote to Voting Power determination.

• Tracking Quorum Delegation as input to a Neuron, giving greater Voting Power to Users that are delegated to.

• Publicly broadcasting the Quorum candidates.