# Incentivising Participation in Liquid Democracy with Breadth First Delegation

Liquid democracy allows an agent to either vote directly over the available alternatives (candidates) of an election, or to delegate her voting rights to another agent (her guru) who can then vote on her behalf. In the academic literature and industrial applications of liquid democracy, each agent is usually allowed to nominate only one guru per election. However, if the nominated guru does not participate in the election, then the votes delegated to this guru will be wasted. To minimise the possibility of wasted votes, each agent can declare a personal ranking over her most desirable gurus, e.g, as in GoogleVotes. In this paper, we show that even if personal rankings over gurus are declared, the common delegation method of liquid democracy (which we call Depth First Delegation) remains problematic. More specifically, we show that if personal rankings over gurus are declared under the Depth First Delegation rule, there can be gurus who become worst off by receiving a delegated vote. To solve this issue, firstly we introduce a general framework for voting systems that allow delegation of voting rights. The key feature of this framework is the delegation rule function, which when instantiated details who receives each delegated vote. Secondly, we propose a delegation rule function instantiation that we call Breadth First Delegation. Given that personal rankings over gurus are declared, this is the first rule where every agent weakly prefers receiving a delegated vote.

## Authors

• 2 publications
• 2 publications
• ### Approval-Based Elections and Distortion of Voting Rules

We consider elections where both voters and candidates can be associated...
01/20/2019 ∙ by Grzegorz Pierczyński, et al. ∙ 0

• ### Trustworthy Preference Completion in Social Choice

As from time to time it is impractical to ask agents to provide linear o...
12/14/2020 ∙ by Lei Li, et al. ∙ 4

• ### Common Voting Rules as Maximum Likelihood Estimators

Voting is a very general method of preference aggregation. A voting rule...
07/04/2012 ∙ by Vincent Conitzer, et al. ∙ 0

• ### Weighted Voting Via No-Regret Learning

Voting systems typically treat all voters equally. We argue that perhaps...
03/14/2017 ∙ by Nika Haghtalab, et al. ∙ 0

• ### Persuading Voters: It's Easy to Whisper, It's Hard to Speak Loud

We focus on the following natural question: is it possible to influence ...
08/28/2019 ∙ by Matteo Castiglioni, et al. ∙ 0

• ### Voting with Random Classifiers (VORACE)

In many machine learning scenarios, looking for the best classifier that...
09/18/2019 ∙ by Cristina Cornelio, et al. ∙ 12

• ### Sequential Voting with Confirmation Network

We discuss voting scenarios in which the set of voters (agents) and the ...
07/11/2018 ∙ by Yakov Babichenko, et al. ∙ 0

##### This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

## 1 Introduction

Liquid democracy is a middle ground between direct and representative democracy, as it allows each member of the electorate to vote directly on a topic or temporarily delegate their vote to someone else. If a vote is delegated, the agent who casts the delegated vote becomes known as a guru (ChristoffG17 ChristoffG17). Therefore individuals who are apathetic for an election, or who trust in the knowledge of another member of the electorate more than their own, can still have an impact on an election through their guru. Note that proxy voting (see Miller1969 Miller1969) also allows vote delegation but, unlike liquid democracy, proxy voting only allows a vote to be delegated a single time before reaching a guru.

Liquid democracy has been gaining popularity in a few domains recently, which we will now discuss to give the reader a general overview of the non theoretical developments. In the political domain, local parties have been experimenting with it, such as the Partenpartei in Germany, Demoex in Sweden and the Net Party in Argentina. Additionally, the councils of London Southwark, Turino, and San Dona di Piave are also working towards the integration of liquid democracy for some of their community engagement processes, through the Horizon 2020 project: WeGovNow (BoellaFGKNNSSST18 BoellaFGKNNSSST18).

Liquid democracy has also been gaining increased attention within the blockchain domain. Blockchain is a technology where data transactions are grouped into blocks and the blocks are cryptographically linked into a chain. This blockchain is replicated in each node of the network, where a consensus protocol makes sure that every node (eventually) has the same copy of the data in the same order. It is due to this data replication that gives blockchain a significant advantage over traditional client-server architecture models for running an online liquid democracy system. With a centralised server, you have to trust that the server will delegate your vote to the correct guru, but if you are running a node of the blockchain network you will be able to check yourself that your vote has been given to the correct guru. Blockchain organisations who are providing liquid democracy based tools, include: the Ethereum Foundation for decentralised autonomous organisations (see the liquid democracy section of EthereumDAO EthereumDAO); Swarm Fund for democratic investments (see Section 2.1 of SwarmFund SwarmFund); and Democracy Earth for decentralised governance (see Section 2 of DemocracyEarth DemocracyEarth).

Regardless of the increasing interest in liquid democracy, there remains outstanding theoretical issues. Firstly, there is currently no general liquid democracy formalism (i.e. see the multiple different formal definitions of liquid democracy in: BrillT18 BrillT18; ChristoffG17 ChristoffG17; KahngMP18 KahngMP18;…). This is unlike non-liquid democracy voting systems that share the voting rule function formalisation. Secondly, there is no consensus on how to handle liquid democracy systems with multiple nominated gurus (Brill18 Brill18). Therefore the contribution of this paper seeks to tackle both of these issues by:

1. Detailing a general formal framework for delegation rules that can take as input information on the abstaining, delegating and vote casting agents, and outputs which guru receives each delegated vote.

2. Showing that the classical liquid democracy delegation rule, which we name as Depth First Delegation (DFD), cannot guarantee that gurus weakly prefer receiving a delegated vote (when agents can declare a preference order over gurus).

3. Introducing the Breadth First Delegation (BFD) rule, which we prove guarantees that gurus weakly prefer receiving delegated votes.

Contribution (a) provides a general liquid democracy formalism that can operate with any delegation rule combined with any voting rule. Contributions (b) and (c) focus on the incentive of gurus to receive delegated votes. Incentivising gurus to receive delegated votes is a basic requirement of liquid democracy, as without gurus accepting votes we effectively move to a direct democracy model. Note that BFD and DFD place the same requirements on each agent, to either: (i) declare a preference order over the election alternatives (cast your vote); (ii) declare a preference order over the potential gurus (delegate your vote); or (iii) declare neither (abstain).

Our paper is outlined as follows: Section 2 introduces the formal model of our liquid democracy system. Section 3 defines two instantiations of delegation rule functions and gives associated examples. Section 4 details our proofs, while Section 5 outlines related work and concludes.

## 2 Preliminaries

Consider a set of voters and a set of alternatives or outcomes . We detail the set of electorates using , i.e. non-empty subsets of . In our model, for every election there are three sets of electorates such that and , where set consists of the agents who abstain, set consists of the agents who directly cast a vote, and set consists of agents who are willing to delegate their vote to members of .

A preference relation over alternatives for agent is denoted and is a binary relation on , where we write to mean agent strictly prefers alternative over alternative . A preference relation over alternatives is:

• Complete - i.e. for all , either or holds;

• Antisymmetric - i.e. for all , if holds then this implies does not hold; and

• Transitive - i.e. for all , then if and hold, this implies also holds.

The set of all preference relations over alternatives is denoted by . As our model also allows votes to be delegated to gurus, we introduce a strict preference relation over gurus that is an incomplete, antisymmetric and transitive binary relation on . The preference order over gurus needs is strict so that cycles can be resolved, and incomplete as for many election settings it is unrealistic to assume that all the agents are aware of who every potential voter is. The preference relation over gurus for agent is denoted by , and must not include herself (to avoid cycles), i.e. if or equals , then does not hold. In a slight abuse of notation, we allow the rank of the gurus of to be accessed by indexing, so the most preferred guru of will be , while the least preferred guru of will be . Lastly, the set of all preference relations over gurus is denoted by .

Now building on the formalism detailed in BrandtGP16 (BrandtGP16), we can define related functions. A preference profile over alternatives is a function from a non empty electorate to the set of preference relations over alternatives . Whereas, a preference profile over gurus is a function from a non electorate to the set of preference relations over gurus . The set of all preference profiles over alternatives is given by , while the set of all preference profiles over gurus is given by .

When adding or removing preference relations over alternatives, we will use the following notation. For an preference profile over alternatives with , and :

Additionally, when adding or deleting preference relations over gurus, we will use the following notation. For a preference profile over gurus with , and :

We will conclude this section by discussing how the agents are assigned to the , and electorates given the preference profiles and . If , then it is inferred that agent will cast a vote according to and will therefore be a member of the casting electorate . If , then will be a member of the delegating electorate333There are multiple possible reasons why an agent would want to delegate. For instance: the voter may be indifferent between the alternatives; the voter may not be confident in her own ranking capability; and/or the voter does not want to invest the resources required to generate an accurate preference relation over alternatives. (i.e. ) if . Otherwise, will be a member of the abstaining electorate444There are multiple possible reasons why an agent would want to abstain. For instance: the voter may not trust anyone else to vote in her best interest; or the voter may not want to invest the resources required to generate an accurate preference relation over gurus. (i.e. ). Note that the vote of an agent in the delegating electorate may not be used in the election, as an appropriate guru may not be found for according to the delegation rule function being used, formally described later in Definition 3.

### Preliminary Delegation Definitions

To model the delegation connections between the voters, we will organise them into a graph:

###### Definition 1.

A Delegation Graph is a weighted directed graph where:

• is the set of nodes representing the agents registered as voters;

• is the set of directed edges representing the delegation connections between voters; and

• is the weight function that assigns a value to an edge equal to ’s preference ranking of .

###### Example 1.

See Figure 1 and Figure 2 for delegation graph examples, which will be discussed in more detail later.

To generate a delegation graph, we use the following:

###### Definition 2.

A Delegation Graph Function takes as input a preference profile over gurus () and returns the related delegation graph , where the following properties hold:

• , if: (a) and (b) that has ; then where .

Now to see which gurus delegated votes are assigned to, we use the following:

###### Definition 3.

A Delegation Rule Function takes as input a preference profile over alternatives () as well as a delegation graph (), and returns another preference profile over alternatives that incorporates delegations. Function states that:

• if , then will be casting her vote.

• if and , then will be delegating her vote to ( becomes ’s guru).

• if then will be abstaining.

A delegation rule effectively analyses, for each agent , the sub tree of the delegation graph rooted at and decides whether will cast, delegate or abstain. If is found to delegate, the delegation rule function will traverse ’s sub tree (according to the rules of this specific instantiated delegation rule) to find ’s guru. Later in the paper, we will discuss delegation rule function examples after we have explicitly defined two in Defn. 8 and Defn. 9.

Now to get the outcome of an election, as in the social choice theory literature we will use a voting rule function . In our model, will take as input the modified preference profile over alternatives (which incorporates delegations) and will return a single alternative winner or a ranking over the alternatives (depending on which voting rule was used). In Section 3, we show how the result of the voting rule is dependant on the delegation rule chosen. I.e. it may be the case that , when only the delegation rule function is different (i.e. only ).

Putting our discussion of this section together, we can introduce our model:

###### Definition 4.

A Liquid Democracy Tuple is a defined as , which contains a set of possible voters , a set of possible alternatives , a preference profile over alternatives , a preference profile over gurus , a delegation rule and a voting rule .

For this paper, the key property that we are investigating is participation. The participation property holds if a voter will not lose out by joining an electorate. Social choice theory defines participation in the context of vote casting only (Fishburn Fishburn; Moulin Moulin) and does not consider the issue of delegation. Because this paper’s model also uses delegation, we now establish two separate definitions of participation (inspired by the participation definition of BrandtGP16 BrandtGP16).

The first definition, Cast Participation, holds for a voting rule if each agent weakly prefers joining any possible voting electorate (given any possible non conflicting delegating electorate ), compared to abstaining555Note that this definition is defined only in the context of agent moving from the abstaining to casting electorate. This is to align the definition with the classical participation definition of social choice theory.. Therefore by voting, agent will always either: have no affect on the election result; or will change the result for ’s benefit.

###### Definition 5.

The Cast Participation property holds for a voting rule iff:

For all , and , where and .

The next definition, Guru Participation, holds for a voting rule if each vote casting agent (potential guru) weakly prefers receiving a delegated vote from agent compared to not receiving the delegated vote, given any possible voting electorate and any possible non conflicting delegating electorate . Therefore when receives ’s delegated vote, the election result will either: not change; or will change to ’s benefit.

###### Definition 6.

The Guru Participation property holds for a voting rule iff:

For all , and , where , , and .

We note here that there are other interesting participation properties to be defined and analysed for liquid democracy, such as when an agent moves from the abstain to delegating electorates, or from the delegating to casting electorates. But these are out of scope for this paper, which focuses on finding a delegation rule that incentivises agents to participate as gurus.

Now given the set of all possible voting rules , it is known from the social choice theory literature that only a subset satisfy (cast) participation. For example, in (Fishburn Fishburn), it was shown that the single transferable vote rule does not satisfy (cast) participation, while in (Moulin Moulin) it was shown that no Condorcet-consistent voting rule satisfies (cast) participation when there are 25 or more voters.

In this paper we focus our guru participation proofs only on the voting rules in . We build on the following observation that shows that given a voting rule in , if an agent joins the delegating electorate and only guru gains delegated votes, then guru participation is satisfied:

###### Observation 1.

Consider a tuple that contains a voting rule satisfying cast participation (i.e. ) and this tuple gives a preference profile over alternatives, that incorporates delegations, of . Now consider another tuple that is identical to apart from: agent has joined the delegating electorate from the abstaining electorate, giving ; and has been selected as ’s guru, i.e. . If either of the following hold:

1. ’s vote is delegated to the same guru in both and (i.e. ); or

2. ’s vote is delegated to guru in
(i.e. ).

then the only alternative(s) that can improve their position in the ranking returned by the voting rule in , compared to the ranking returned by the voting rule in , are the preferred alternative(s) of . In this case, it is weakly preferable for guru when agent joins the delegating electorate.

## 3 Delegation Rules

The delegation graph provides a way to visualise the connections between each agent according to the preference profile over gurus. Recall that liquid democracy is a form of proxy voting that allows the nominated gurus to also delegate their vote. Therefore if an agent delegates () then ’s vote may be set according to any in the sub tree of the delegation graph that begins from . This occurs even if guru is not actually in ’s preference relation over gurus , i.e. it is possible that to make hold true. In this case, it must hold that there has been at least one intermediator agent between the original delegator and the nominated guru . The possible intermediator agents can be found by inspecting the delegation graph.

To find out exactly which intermediator agents are used between the delegator and the guru, we introduce delegation chains. A delegation chain for an agent starts with , ends with (who would receive ’s vote through intermediators), and in-between lists all of the intermediator agents, who have further delegated ’s vote. A delegation chain (see Definition 7) must satisfy the following conditions: (i) agent delegates her vote while guru casts her vote; (ii) no agent occurs more than once in the chain (to avoid infinite delegation cycles that could otherwise occur); (iii) the intermediator agents must not have cast a vote (as otherwise they would claim ’s vote); and (iv) each agent in the delegation chain must be linked to the next agent in the delegation chain through an edge in the delegation graph.

###### Definition 7.

Given a Liquid Democracy tuple with electorates and , a Delegation Chain (DC) for an agent , is an ordered tuple denoted , where , , …, , and:

1. , ;

2. where ;

3. where and ;

4. where and , then where .

We refer to as being depth of the delegation chain. Also, given a delegation chain , we allow the weights of each edge of the delegation chain to be accessible using the function over the delegation chain itself: , where . Therefore we can refer to as the weight to move from depth to depth of the delegation chain. If there is an attempt to return the weight at where , then .

We can use delegation chains to help us understand which guru will be assigned ’s vote should decide to delegate her vote. It is fair to assume that if ’s most preferred guru abstains, then ’s vote is assigned to her second preferred guru . A complication arises when agent ’s most preferred guru also delegates. In this case where should ’s vote be assigned? The literature on liquid democracy suggests that vote delegation is transitive (BrillT18 BrillT18; ChristoffG17 ChristoffG17; KahngMP18 KahngMP18). Therefore in this case, agent effectively gains control of ’s vote and can give it to whoever chooses. We define this delegation rule as Depth First Delegation (DFD) (see Definition 8), which says that ’s vote should be assigned to guru iff: (i) delegates her vote and casts her vote; (ii) there is a delegation chain that can be formed from to ; and (iii) there is not another voter and delegation chain where (iii,a) delegates ’s vote to , and (iii,b) uses a smaller weight delegation than , before uses a smaller weight delegation than .

###### Definition 8.

Given a Liquid Democracy Tuple with electorates and , the Depth First Delegation rule includes iff:

1. , ;

2. where ; and

3. and that has:

1. ; and

2. for some where then .

###### Example 2.

Consider the Delegation Graph displayed in Figure 1. Using the Depth First Delegation rule, ’s vote will be set by guru (i.e. ) because agent acts as an intermediator for guru in the delegation chain that has a weight of . There is one other delegation chain available, with a weight of . Delegation chain is prioritised because , which means satisfies (i), (ii) and (iii) of the DFD rule.

In Example 2, agent ’s vote is given to guru , but why should (who is the second preference of ) outrank agent ’s explicit second preference ? This question gains even more importance the longer the depth first delegation chain is. Given this issue, we define here a different delegation rule that prioritises an agent’s explicit preferences. We define this rule as Breadth First Delegation (BFD), which says that ’s vote should be assigned to guru iff: (i) delegates her vote and casts her vote; (ii) there is a delegation chain that can be formed from to ; (iii) there is not another voter and delegation chain where (iii, a) delegates ’s vote to , and either (iii,b1) is shorter than or (iii,b2) is equal in size to but uses a smaller weight delegation than before uses a smaller weight delegation than .

###### Definition 9.

Given a Liquid Democracy Tuple with electorates and , the Breadth First Delegation rule includes iff:

1. , ;

2. where ; and

3. and that has:

1. ;

2. and either:

1. ; or

2. and   for some where then .

###### Example 3.

Consider the Delegation Graph displayed in Figure 1. Using the Breadth First Delegation rule, ’s vote will be set by guru (i.e. ) through the delegation chain . There is one other delegation chain available, , but is prioritised because , which satisfies (i), (ii), (iii, a) and (iii, b1) of the BFD rule.

### Delegation Rules Main Examples

Like voting rules, different delegation rules can have different properties. We will show through the next two examples, using Figure 1 and Figure 2 that the Depth First Delegation rule cannot guarantee guru participation. Note that the numeric election results for both examples are displayed in Table 1.

The first example shows that by only changing the delegation rule function, the result of a liquid democracy game can change:

###### Example 4.

Consider the Delegation Graph displayed in Figure 1. There are two delegation chains available to agent , and , while there is one delegation chain available to agent , .

Given the depth first delegation rule and Example 2 we know that agent is assigned , meaning returns the preference profile over alternatives: .

If instead we use the breadth first delegation rule , we know from Example 3 that agent is assigned , meaning returns the preference profile over alternatives: .

The second example shows that if joins the delegating electorate and the Depth First Delegation rule is chosen, the result can be inversed:

###### Example 5.

Consider the Delegation Graph displayed in Figure 2 where the only difference to Figure 1 is that agent has joined the delegating electorate (i.e. now ), with a preference relation over delegates of . There are now three delegation chains666Recall that delegation chains with a cycle (e.g. ) are not valid because of part (ii) of Definition. 7. available for agent , , and , with weights , and . Whereas agent has three options, , and , with weights , and . Lastly, agent also has three options , and , with weights , and .

Given the depth first delegation rule , we can see that: agent prioritises because and ; agent prioritises because and ; and agent prioritises because and . This means returns the preference profile over alternatives:
.

Given the breadth first delegation rule , we can see that: agent prioritises because ; agent prioritises because ; and agent prioritises because . So returns the preference profile over alternatives: .

## 4 Delegation Rule Properties

Before continuing, recall that Observation 1 showed how guru participation can be satisfied. Briefly, Observation 1 showed that when a new agent joins the election, if only one guru receives delegated votes (that have possibly been reassigned from other gurus), then the receiving guru will be weakly better off.

The previous examples shows that guru participation may not hold for DFD when there is a cycle in the delegation graph. Because of this cycle, when joins the election, both gurus and receive reassigned delegated votes and so Observation 1 does not occur. We summarise this with the following:

###### Theorem 1.

Given a Liquid Democracy tuple with a Depth First Delegation rule , then guru participation is not guaranteed to hold.

###### Proof.

By example. Take the preference profile over alternatives and the preference profile over gurus from Figure 2: and , where No Yes, Yes No, , , . Now see from Example 4, Example 5 and Table 1 that the following does not hold: . It does not hold, as when agent joins the delegating electorate, the result changes from No to Yes when the Depth First Delegation rule function was used, even though delegates her vote to guru (i.e. ) and votes for No. Therefore, ’s guru became worst off when receiving ’s vote, violating the guru participation definition and proving this Theorem. ∎

We also highlight that if the delegation graph has no cycle, then guru participation is guaranteed to hold for Liquid Democracy tuples that contain the Depth First Delegation rule. We show this through the following Theorem, which details that if Observation 1 does not hold, there must be a cycle in the graph.

###### Theorem 2.

Given a Liquid Democracy tuple with a Depth First Delegation rule and no cycle in the delegation graph, then guru participation is guaranteed to hold.

###### Proof.

Assume there is no cycle in the delegation graph and guru participation does not hold. Due to Observation 1, we know that whenever an agent joins the delegating electorate, if only one guru receives delegated votes then guru participation is satisfied. Therefore, for Observation 1 not to hold, when the last agent joined the delegating electorate to give her vote to guru , another agent must have changed its guru to another agent (). But either: (i) delegation chain existed before joined, in which case guru should have been chosen previously if she really was the best guru (and so Observation 1 would hold in this case); or (ii) delegation chain is now preferred for , even though the preferred chain of is . This can only occur if there is an agent between & and & , because Definition 7 states a delegation chain cannot use the same agent twice. But in this case, the assumption will be violated as there would now be a cycle in the graph, i.e. the cycle . ∎

For the next proof we introduce the notation , to stand for the delegation chain used to give agent ’s vote to its guru in the liquid democracy tuple . That is, there is no more preferred delegation chain for agent , given the delegation rule .

We have already shown from Theorem 1 that Depth First Delegation does not guarantee guru participation when a cycle is in the delegation graph. We will now prove that Breadth First Delegation does guarantee the guru participation property (with or without a cycle in the delegation graph).

Both our lemmas will be based on and , where .

The first Lemma considers a situation where an agent is currently delegating her vote to guru in . Now if another agent joins the delegating electorate and is not included in ’s preferred delegation chain of the newly created tuple , then still delegates to guru using the same delegation chain.

###### Lemma 1.

Given where due to . If given , , then and .

###### Proof.

Assume and . In this case, we show that can also be formed in . We show this by discussing each property of the delegation chain definition for in :

1. Agent , in the delegating electorate of , and guru , in the casting electorate of , are also in these electorates in as only agent has changed electorates.

2. If there is not a repeating agent in for there will still not be a repeating agent in this chain in .

3. If the only agent casting a vote in was then this holds true in , as there was no change in the casting electorate between and .

4. All of the edges to create delegation chain that were available in are still available in , as the only delegations that have been added are associated with agent , and is not in the chain .

As we have satisfied all of Definition 7 for in and we know that , then we can conclude must hold (as the most desirable delegation chain for exists in both and ), which contradicts the assumption.

The next Lemma shows that when agent joins the delegating electorate in and finds her guru to be , any agent who uses in her preferred delegation chain must also delegate her vote to guru . This is because: (1) agent cannot use a shorter chain (or same length chain with less weight) from to a guru , otherwise would have chosen as her guru; and (2) if did not use the same chain from to due to agent being an intermediator between & , as well as between & , then in this situation does not need in because it would be a shorter delegation chain to go directly from to to the guru .

###### Lemma 2.

Given tuple with where due to . Then where , ’s vote is also assigned to guru , i.e. .

###### Proof.

Assume and where due to and . This would mean either:

1. That satisfies Definition 9 and so should be ’s most preferred delegation chain, which contradicts the assumption that is ’s most preferred delegation chain; or

2. That delegates to guru because of a shared intermediary agent, i.e.: and where . In this case, should actually be (so ) because holds (thus contradicting (iii) of Defn. 9 for ). We know the preceding holds because (due to and (iii, b) of Definition 9), therefore .

We can build on the previous two Lemma’s to create our main Theorem:

###### Theorem 3.

Given a Liquid Democracy tuple with a Breadth First Delegation rule and a voting rule that satisfies cast participation, then guru participation is guaranteed to hold.

###### Proof.

Lemma 1 shows that when an agent joins the delegating electorate, if another agent updates her preferred delegation chain, then ’s new preferred delegation chain must include . Lemma 2 shows that if an agent includes in its updated preferred delegation chain, then must delegate her vote to the same guru that delegated to. This means that if joins the delegating electorate to delegate her vote to guru , then is the only guru that can gain more delegated votes. As satisfies cast participation, we can see through Observation 1 that a Breadth First Delegation rule satisfies guru participation. ∎

## 5 Related Work and Conclusions

How to handle preference relations over gurus has been an ongoing issue in the literature, as outlined by Brill18 (Brill18). Our paper, through the delegation rule function, details a formalism to describe all types of ways delegations can occur. We have provided two delegation rule function instantiations, Depth First Delegation and Breadth First Delegation, the latter of which has the desirable property that every guru weakly prefers receiving a delegated vote. But there can exist many other possible delegation rules with potentially interesting properties, from the Markov chain delegation rule hinted at by Brill18 (Brill18) to a

-limited depth delegation rule (where an agent’s vote is only allowed to travel a depth away from it). A Breadth First Delegation rule as well as -limited depth delegation rule could counteract the fact that current liquid democracy implementations can suffer from a small subset of gurus possessing a large number of delegated votes (outlined by KlingKHSS15 KlingKHSS15), as both rules favour keeping a delegated vote close to it’s origin. This hypothesis should be followed up on.

Regarding other related work, there currently exists a lack of theoretical analysis on liquid democracy, but we will summarise this papers differences to the main undertaking so far. Firstly the work of KahngMP18 (KahngMP18) finds that there is no decentralised liquid democracy delegation mechanism that is guaranteed to outperform direct democracy, when there are two alternatives and a ground truth on what is the correct alternative. Their delegation mechanism uses a graph of connected agents as input where each agent is labelled with the probability of knowing the ground truth and two agents are connected by an edge if they know each other. In comparison, our work only links an agent to another in a graph if they make the decision to nominate the other agent in their preference relation over gurus. This means that our graph is also applicable in domains where there is no ground truth (in these situations an agent would not want to delegate to a guru she knows just because that guru knows a lot about the subject - but instead the vote delegation could be motivated by shared values). Additionally our delegation rules can be used in a central or decentralised manner and so the negative result of direct democracy outperforming decentralised delegation mechanisms does not apply to this paper.

Another work is by ChristoffG17 (ChristoffG17) that positions liquid democracy within the theory of binary aggregation, focusing on two problems: (1) the existence of delegation cycles; and (2) inconsistencies that can occur when there are several binary issues to be voted on and a different delegate can be used for each issue. This paper resolves delegation cycles through in part (ii) of Definition. 7 which states that an agent cannot occur twice in a delegation chain. Additionally, individual rationality issues between multiple elections is out of scope for this paper. Finally, a special case of the model of ChristoffG17 (ChristoffG17) is introduced by BrillT18 (BrillT18), which allows a single agent to nominate several gurus to help define her preference relation over alternatives but our paper only focuses on one nominated guru per agent.

Finally, other interesting future work could include: (a) investigating guru participation with voting rules that do not satisfy cast participation; (b) relaxing the assumption that there must be strict preference orders over gurus; (c) defining and analysing other participation properties for liquid democracy.

## References

• [Behrens et al.2014] Behrens, J.; Kistner, A.; Nitsche, A.; and Swierczek, B. 2014. The Principles of LiquidFeedback. Interaktive Demokratie.
• [Boella et al.2018] Boella, G.; Francis, L.; Grassi, E.; Kistner, A.; Nitsche, A.; Noskov, A.; Sanasi, L.; Savoca, A.; Schifanella, C.; and Tsampoulatidis, I. 2018. Wegovnow: A map based platform to engage the local civic society. In Companion Proceedings of the The Web Conference, WWW 2018, Lyon , France, April 23-27, 2018, 1215–1219.
• [Brandt, Geist, and Peters2016] Brandt, F.; Geist, C.; and Peters, D. 2016. Optimal bounds for the no-show paradox via SAT solving. In Proceedings of the 2016 International Conference on Autonomous Agents & Multiagent Systems, Singapore, May 9-13, 2016, 314–322.
• [Brill and Talmon2018] Brill, M., and Talmon, N. 2018. Pairwise liquid democracy. In

Proceedings of the Twenty-Seventh International Joint Conference on Artificial Intelligence, IJCAI 2018, July 13-19, 2018, Stockholm, Sweden.

, 137–143.
• [Brill2018] Brill, M. 2018. Interactive democracy. In Proceedings of the 17th International Conference on Autonomous Agents and MultiAgent Systems, AAMAS 2018, Stockholm, Sweden, July 10-15, 2018, 1183–1187.
• [Christoff and Grossi2017] Christoff, Z., and Grossi, D. 2017. Binary voting with delegable proxy: An analysis of liquid democracy. In Proceedings of the Sixteenth Conference on Theoretical Aspects of Rationality and Knowledge, TARK 2017, Liverpool, UK, 24-26 July 2017., 134–150.
• [DemocracyEarth2017] DemocracyEarth. 2017. The social smart contract. Accessed: 2018-08-28.
• [EthereumFoundation2018] EthereumFoundation. 2018. How to build a democracy on the blockchain. Accessed: 2018-08-28.
• [Fishburn and Brams1983] Fishburn, P. C., and Brams, S. J. 1983. Paradoxes of preferential voting. Mathematics Magazine 56(4):207–214.
• [Hardt and Lopes2015] Hardt, S., and Lopes, L. C. R. 2015. Google votes: A liquid democracy experiment on a corporate social network. Technical report, Technical Disclosure Commons, Google.
• [Hardt2014] Hardt, S. 2014. Liquid democracy with google votes. Accessed: 2018-07-17.
• [Kahng, Mackenzie, and Procaccia2018] Kahng, A.; Mackenzie, S.; and Procaccia, A. D. 2018. Liquid democracy: An algorithmic perspective. In Proceedings of the Thirty-Second AAAI Conference on Artificial Intelligence, New Orleans, Louisiana, USA, February 2-7, 2018.
• [Kling et al.2015] Kling, C. C.; Kunegis, J.; Hartmann, H.; Strohmaier, M.; and Staab, S. 2015. Voting behaviour and power in online democracy: A study of liquidfeedback in germany’s pirate party. In Proceedings of the Ninth International Conference on Web and Social Media, ICWSM 2015, University of Oxford, Oxford, UK, May 26-29, 2015, 208–217.
• [Miller1969] Miller, J. C. 1969. A program for direct and proxy voting in the legislative process. Public Choice 7(1):107–113.
• [Moulin1988] Moulin, H. 1988. Condorcet’s principle implies the no show paradox. Journal of Economic Theory 45:53–64.
• [SwarmFund2018] SwarmFund. 2018. Whitepaper: The blockchain for private equity. Accessed: 2018-08-28.