Self-Voting Policy Discussion [ArbitrumDAO Constitution]

Governance
1

This discussion-piece is co-authored with Axis Advisory team member @ConsensusAnalyst .

TL;DR

  • The self-voting policy discussion aims to initiate an official forum discussion relating to the concept of self-voting so as to solicit delegate feedback re. whether we should aim to have a more streamlined approach to this phenomenon;

  • This self-voting policy discussion discusses cases that have arose in the past where delegates have self-abstained from voting with an aim to soliciting delegate feedback re. whether any of these potential scenarios (that may continue to arise from time to time), should have a more consistent approach to ensure harmonisation;

  • This discussion emanates from events that took place in the recent LTIPP elections and comments made by @SmolPhil in the election process itself. In light of the well-founded nature of these comments, we think it best to have an official forum discussion to agree on a way forward or rather, comparatively assess delegate-approaches towards self-voting.

  • Should this discussion lead to a general consensus re. when self-voting should be avoided, we are volunteering to create a Constitutional AIP to include this general consensus as a guidance of sorts in the ArbitrumDAO Constitution [Section 2].

ABSTRACT

This self-voting policy discussion aims to highlight the concerns surrounding self-voting within the ArbitrumDAO (hereinafter referred to as the ‘DAO’) and will apply to all voting activities i.e. Constitutional and Non-Constitutional AIPs. Its objective is to reduce ambiguity and facilitate more informed decision-making in subsequent proposals by creating a harmonised and consistent approach towards the self-voting phenomenon.

The self-voting policy discussion also addresses the challenges in determining what constitutes a ‘direct’ and ‘indirect’ conflict of interest and whether this should or should not be included within the self-voting amendment to the constitution.

Anchored in the principles of ethical conduct and community trust, the self-voting policy discussion focuses on the necessity of instituting checks over balances, harnessing a shared understanding among all token holders.

MOTIVATION & RATIONALE

During the recent LTIPP proposal for Council Elections held on Snapshot there was some confusion as to whether ‘applicants may or may not vote for themselves’. This was raised by SmolPhil on the ‘LTI Pilot Program Position Application Thread’ on Jan 21, 2024.

Although this was not mentioned in the LTIPP proposal and does not form part of the ArbitrumDAO Constitution, there was an informal understanding that “the community found no self-voting rule to be the fairest approach”.

The purpose of this self-voting policy discussion is to clear the air and identify whether the community truly is in favour or against such a measure. Within both democracies and DAOs, it is integral that the ‘rules of the game’ are clear to all participants, making the voting process as transparent as possible.

Feedback in reply to this self-voting policy discussion on the community forum, in a public space accessible to all, is strongly encouraged.

OVERVIEW

Self-voting refers to the practice where token holders use their voting power to vote on proposals that involve or benefit themselves.

While self-voting could incentivise participation by aligning the interests of participants with the DAO, who ultimately have their ‘skin in the game’, it could also raise potential conflicts of interest whereby people vote in accordance with their self-interests rather than for the long-term well-being of the DAO.

The focus is to avoid situations of self-enrichment arising, in particular, where delegates vote for themselves to get elected to a committee, in which they will be privy to direct financial gain.

For the purpose of this self-voting policy discussion, ‘self-enrichment’ refers to the act of increasing or enhancing one’s own personal financial wealth as a result of one’s own voting contribution.

[POTENTIAL] STEPS TO IMPLEMENT: SELF-VOTING POLICY

There are myriad of modes of implementation re. The self-voting provisions that could potentially be included in the ArbitrumDAO Constitution.

  • Apply self-voting policy for election-type votes on an individual level.

Example: If X is a delegate, X cannot vote for him or herself if X is an election applicant.

  • Apply self-voting policy for election-type votes on an individual & committee level.

Example: If X is part of a delegate committee, the delegate committee would not be able to vote for X if X is an election applicant.

  • Apply self-voting policy in relation to conflicts of interest.

Example: If X is a delegate and has a vested interest in Y’s proposal or will be voting for Y’s proposal due to a direct affiliation (such as employment).

  • Apply self-voting policy in relation to self-enrichment.

Example: If X is a delegate, or part of a delegate committee, X & the delegate committee cannot vote on proposals which would lead to X getting a corresponding financial gain from the proposal passing.

POTENTIAL GUIDELINES FOR A SELF-VOTING POLICY

Identification of conflicts

A conflict of interest will be determined to arise where a token-holder or their close associates stand to directly (and possibly indirectly ~ depending on which proposal passes) to benefit from the outcome of a proposal.

Therefore, before voting, token holders must reflect on the proposal in question and whether a conflict of interest, as explained above, is present.

One of the main points of contention relates to indirect conflicts of interest. To explain what is meant by ‘indirect’ in this context, reference will be made to the example raised by SmolPhil (referenced above).

In essence, will Treasure DAO members be able to vote for SmolPhil, when applying to the LTIPP Council as an individual, given that he is a member of the ARC?

The purpose of this self-voting policy discussion is to open the floor to discussion and to act as a form of guidance going forward, rather than to argue for or against the inclusion of such a measure.

Disclosure Requirements

When voting for a proposal whereby an actual or potential conflict of interest may be present, one should self-identify this, including the nature and extent of the interest.

This should include an explanation of this actual or potential conflict, included as a reply to the proposal itself on the forum, which is to then be linked to on Snapshot or Tally, including the nature and extent of the interest.

Abstention Form Voting

In the event that there is a direct (and possibly indirect ~ depending on which proposal passes) conflict of interest, the token holder should abstain from voting and participating in the voting process regarding the proposal in question.

By leaving a comment on platforms such as Snapshot or Tally, further clarity is provided to the community as to the reason why the token holder has opted to abstain from the vote.

This practice helps address potential issues of uncertainty and information asymmetry. Therefore, the focus is on providing the most valuable information to voters in the quickest amount of time possible, thereby reducing the likelihood of voter fatigue.

Consulting with the Community

On the other hand, circumstances may arise where a token holder faces uncertainty regarding the existence of a conflict of interest.

In such instances, it is incumbent upon them to actively seek the community’s input on such matters, gathering their feedback and proceeding to act accordingly in good faith.

This aligns with the DAO’s aim to encourage a culture of open and structured dialogue without having to rely on small groups of people to make decisions.

Consequences for Violation?

The purpose and scope of this prospective proposal is to serve as a form of guidance. Consequently, for the time being, there are no plans to introduce formal enforcement mechanisms.

Rather, the primary deterrent against self-voting rests on the potential for reputational damage and community backlash, which could have far-reaching negative impacts surpassing any immediate benefits.

This approach is designed to uphold fairness and transparency within the DAO, rather than resorting to a rigid prescriptive approach.

LOOKING FORWARD

We encourage all ArbitrumDAO participants to voice their thoughts in relation to the subject-matter discussed above. For consistency’s sake, the end goal for this discussion is for it to result in a Constitutional AIP drafted in light of community feedback.

8 Likes
2

Hello, thank you for bringing this discussion to the forum.

I believe there should be no policies or prohibitions that limit the way delegates vote.

Delegates do not own their voting power; rather, they represent a collective of people who have chosen to entrust them with decision-making authority. Therefore, delegates should vote in the way they believe best represents those who have placed their trust in them. If self-voting is the best option for delegates, they should vote accordingly. Ultimately, it will be the holders who judge whether a delegate continues to deserve their trust based on the outcomes of the proposals.

The same logic applies to token holders. In plutocratic systems where voting power depends on the acquisition of transferable tokens with economic value, those who own such tokens should be able to vote freely for the outcome they deem most appropriate, even for themselves. In this case, their skin in the game and the impact of poor decision-making on the value of their holdings are at stake.

It’s important to note that policies that cannot be enforced on-chain have numerous ways to be bypassed if they are approved. It’s as simple as transferring the voting power to anonymous accounts and voting for the desired candidate, or nominating an anonymous person for the election to conceal the fact that one is voting for oneself.

Transparency is crucial. It’s important for everyone to be aware of the identities behind actions and decisions (without compromising personal privacy or engaging in doxxing). Knowing who is voting and for what reasons, without any restrictions, is essential. This approach fosters the development of reputation within the ecosystem. Ultimately, it’s the reputation, built on transparent and accountable actions, that should be the deciding factor in our system.

Now, I acknowledge that the system is imperfect, with the assumption that all delegates will act in the best interest of ARB holders or that the delegates have a clear and consistent understanding of the collective interests they represent.

With that in consideration, is there something that can be done to prevent undesired concentrations of voting power? Rather than directing how someone should vote, mechanisms or incentives could be established to encourage the distribution of power.

An alternative for the past elections for LTIPP positions could have been to set a high quorum as a minimum number of votes that a candidate had to obtain to be elected. This way, no candidate could have elected themselves solely on their merit, but they could have voted for themselves and validated their position with the votes of others.

This is just a rough idea that needs to be developed further. However, the point I want to make is that I believe the DAO should not direct or establish policies on how voting should be conducted, but rather should set up mechanisms and incentives to prevent concentrations that could hinder efficient decision-making.

11 Likes
3

Hello,
I also believe there should be no policies or prohibitions that limit the way delegates vote.
Firstly, any restrictions can be easily circumvented, or the delegation can be transferred to another address temporarily.
Secondly, there is nothing wrong if a person votes for himself, if it benefits the DAO.
If he wants to receive feedback, then it is his right not to vote for himself, but not his obligation.

5 Likes
4

Delegates do not own their voting power. Instead they are representatives of many community members. There should be no limitation on how delegates vote. They should be able to utilize their voting power in the best interest of those who have delegated to them.

7 Likes
5

have been discussing with @Immutablelawyer and also the rest of the DAO about this for a while.

I think not being able to vote for him/herself basically kills the whole political and democratic process: if I delegate to X it means that as a user I think that X will do my own interest. Accordingly, if X is a candidate, it would be quite natural for me to vote for X or to let X for him/herself.

Without going around the bush too much, this is an issue only for big voters. Big voters can change sometimes in a single vote a whole election.

I don’t think is necessarily bad, I think is part of the process. What could be instead a target would be for big voters (what big means, can be discussed, or conversely can be generalized to everybody) vote in a “responsible” way. And again what responsible means would have to be discussed. But in general

  • provide written feedback on the why of the voting. This is something that would be fantastic to do for everybody, but for sure big delegates should do it
  • vote in the right way. So, if there is a 3 out of 5 elections, in which the big voter is also a candidate, voting for himself plus another 2 options seems “righter” than only voting for himself. This also forces on choosing at least another 2 candidates that might not be a fit, but if in general we are targeting a multiple voting, better to vote than not
  • disclose, when voting, in the written motivations, if one of the people who got voted had previous relationship with the voter (ex member of the team, ex part time member, seed for example)
  • in general, disclose any conflict of interest (ie: I am voting for X, but we have a partnership and I am going to be a service provider for X for this thing).

In general would say that

  • voters should do what they want
  • voters should vote in a way that favours who they see fit (including themself) without hindering others (ie only voting for yourself but not for others in a multi election)
  • voters should disclose why they are voting in a certain way
  • voters should disclose whaterver info can help clarify their position in relationship to the entity being voted so that people are aware of it.

And btw part of the above can be partially solved through enforcing certain settings on snapshot, something on which @Bob-Rossi is working on.

8 Likes
6

One policy we’ve seen elsewhere that has worked well – particularly for elections like the one that just occurred – is that candidates may vote for themselves, provided they also vote for the maximum number of open seats or choices. If you were running for an advisor position for LTIP pilot, for example, you could vote for yourself but only if you also voted for two other candidates.

This allows a candidate to vote for themselves, but not be incentivized to withhold votes from all other candidates, which is the natural incentive otherwise.

It also prevents the disenfranchisement of delegators to that candidate.

9 Likes
7

These comments and thoughts reflect my personal opinions on this proposal. Whilst I am a member of the Arbitrum Representative Council (ARC), they do not necessarily represent the overall views of the council.

As others have indicated I believe a preventing delegate self voting is philosophically and technically flawed.

Philosophical

Delegates are trusted to actively engage in voting in their communities and they should be empowered to support candidates who can effectively advocate for their delegate base. In many instances this may be the delegate themselves, or a member of their broader community. If self voting is prohibited, it would likely lead to large delegates abstaining from voting in many instances. This would hinder delegate’s ability to truly represent their delegate base’s interests and disconnect many token holders from Arbitrum’s governance process.

Technical

If self vote rules were implemented all elections would have to be manually audited to identify delegates and individuals who are self voting. This creates an operational overhead, and means final results produced through governance may not be adhered to and may require manually adjusted to address instances where delegates intentionally or mistakenly self voted. Even with active identification of delegates self voting, it may be infeasible to accurately identify all instances of self voting in a governance process. Moreover, the definition of “self voting” is still somewhat subjective, and fringe cases may need to be clarified by an adjudicator.

Rules around self voting make us less than decentralized and are less than ideal. Together I feel that this undermines the open, transparent and trustless approach to decision making DAO governance should provide.

Going forward…
I would be in support of non-binding (and non monitored) “delegate voting best practices” in a format similar to that suggested by GFX Labs:

We may also want to define further recommendations for delegate best practise for other voting mechanisms. For example the split vote mechanism used in the recent Procurement Committee election could have had delegates apply the following guidance:

Delegate can allocate no more than 50% of their vote to one of their own party.

It may be beneficial to tie this work in with @Bob-Rossi’s proposal on Standardised Guidelines for non security Council election.

These could be put forward to the DAO via snapshot votes for token holders to weigh in on with their perspective. I’ve provided my recommendations for non security Council election best practice adjustment here. Relating specifically to self voting, I’d recommend a rank order snapshot with the following options:

  1. Delegates can’t self vote
  2. Delegates can self vote, and are encouraged to vote aligned with best practice guidelines
  3. Delegates can self vote and should not be encouraged to vote aligned best practise guidelines

These options might be a little wordy, but I’m hopefully targeted use of snapshot can help the DAO come to a clear decision on how to conduct elections going forward.

3 Likes
8

Unfortunately, at the moment providing a well explained reason for voting is one of the ways to actually get attention because its not a common practice but an exception to the rule.

9

I agree. But with the current incentive program for delegates, providing reasoning for voting should be, well, incentivised, right @cattin ?

2 Likes
10

Great job to the folks who tackled the self-voting thing! Adding disclosure rules and the “no-vote” option makes things clearer. Pumped to see what the community brings to the table and how it spices up the DAO’s decision-making! :tada:

1 Like
11

I’d suggest that we keep the rules as close to what is enforceable onchain as is possible.

Unenforceable rules create situations where bad actors have an advantage over good actors. Said another way, when the only deterrent to cheating is your conscious - those without a conscious have an advantage.

We don’t want to create a governance system that systemically preferences corruption.

Delegates should be allowed to use their vote however they want to so long as it is possible to vote that way. If we really don’t want a certain type of voting, we should invest in upgrades to Tally, Snapshot, or the governor contract to ensure our governance resolves with math & cryptography rather than enforcement & policing.

7 Likes
12

yup it’s one of the main criteria

4 Likes
13

Thanks @Immutablelawyer for raising this issue on the forum. Glad to see various opinions on this matter.

We prefer this policy rather than no policy. We believe it’s doable to enforce on chain (or implementing a strategy to enforce them on Snapshot, possibly…)

4 Likes
14

Honestly, I would prefer a no self voting policy… but it doesn’t seem reasonable without having someone policing it… so unless that is part of the proposal, I have to agree with @JoJo & @GFXlabs’s comments.

I especially want to double down on these suggestions from JoJo:

These are important.

4 Likes
15

The idea is good, like many others.
But the most important point is how it will be checked. These restrictions can be easily circumvented simply by using a different nickname and address.
Of course, we would like honesty to play a crucial role, but while we cannot implement this in code, it is better not to use it.

1 Like