RFC: Create a Standardized Guideline for Non-Security Council Elections

[Bob-Rossi]

Abstract
This post looks to start a discussion regarding a possible Constitutional AIP that seeks to set a standardized guideline for non-security council elections ran by the DAO. The end goal is to get community input on how we can create a more consistent and fair election experience moving forward.

Motivation
Since inception, the DAO has held seven different Snapshot elections across three difference projects. Due to a lack of direction in the Arbitrum DAO Constitution, all three projects varied their Snapshot voting approach as noted below:

A basic standardized guideline for handling elections will be beneficial to the community. We are nearing the one-year anniversary of the DAO. Now is the perfect time to evaluate the elections held thus far and to think about how to handle elections in the future.

Rationale
The Arbitrum Community should strive to create an election process that is as fair as possible - ultimately the community wants to make sure in the event of an election the winner(s) represent the will of the voters. A consistent voting process is one of the keys to a fair election. It ensures all participants in the process can perform their duties to the best of their abilities, as well as helps prevent candidates from gaining an unfair advantage against each other. As the process stands today with no guidelines, the following issues can occur:

Issue #1:

Snapshot has multiple ‘Voting Types’, some of which are less effective than others.

Proposed Solution #1:

The DAO should provide a clear guideline on which voting type to use based on the number of winners to be elected. Due to the nature of Snapshot voting this should be broken into two categories:

1. In instances where only one candidate will win the election this would likely be done by either “Single Choice Voting”, “Weighted Voting”, or “Ranked Choice Voting”. Ranked Choice Voting would be recommended. This will prevent ‘wasted’ votes that can occur with the other two methods. Voters who chose the least popular candidates do not lose their votes, but instead can have their votes upcycled to remaining candidates until the 50% mark is reached. I have added a poll to this topic to get a community feel for which of the options for a single winner election would be most popular.

• Ranked Choice Voting
• Single Choice Voting
• Weighted Voting
• Abstain

2. In instances where two or more candidates will win the election this would likely be done by the “Weighted Voting” method. The Weighted Voting will maintains consistency in our elections by mirroring how the Security Council elections are ran. Approval Voting does not have safeguards in place to prevent voters from choose more candidates then electable. This was seen in the LTIPP vote where some delegates had to have their vote manually removed since they chose more candidates than the council allowed for. Other voting methods will not allow for multiple winners to be chosen.

Issue #2

Elections ran without the “Shutter” feature allow for voters to see election results before the election is over. Without hiding results until completion, delegates are incentivized to delay and / or change their votes up to the final minutes of voting. This unfairly benefits candidates who gain early support, as delegate voting behavior may change based on who is winning at that moment and this can materially winner / loser results. It will also not give true indication of support for lesser candidates who then may not feel it’s viable to run for future positions.

Proposed Solution #2

Mandate all elections must be run with the “Shutter” feature if on Snapshot (or equivalent if we ever more to another platform)

Issue #3

Variability in the application window can lead to a substandard application process. Applicants may feel rushed to apply, or miss the window all together due to scheduling conflicts.

Proposed Solution #3

Mandate a minimum application window period to ensure all possible candidates have a fair chance to apply. This can be combined with a minimum applicant count to ensure elections of varying sizes have a diverse pool to choose from. A discussion should be had on what a viable minimum application window looks like. Some factors to consider are:

• Length of Time: The period should be long enough to allow ample time to put together a quality application, but not so long it unnecessarily delays voting.

• Minimum Applicant Count: If a proposal does not garner enough interest to have more applicants than winning spots, the question becomes if the proposal was properly crafted.

• Flexibility: The design should keep in mind that all projects have varying goals and skill sets, as well as varying levels of urgency. Some flexibility should be built in with that in mind.

A possible application window could look as follows, where “N” stands for the number of candidates who can win the election. Please note — this is an example formula to give starting point for discussion, other formulas / ideas are welcome. Language can be added to note that this is the minimum voting window period and if proposals wish to extend the timeline or require more applicants that is acceptable.

1. Week 1: The number of applicants needs to be greater than or equal to the larger of [N+2] or [Nx1.70] (Rounded Down). If after 1 week neither threshold has been met, the application window can be extended for another 7 days.
2. Week 2: The number of applicants needs to be greater than or equal to the larger of [N+2] or [Nx1.70] (Rounded Down). If after the second week neither threshold has been met, the election does not go to vote.

Some reasoning behind the above proposed formula… If enough interest is showing within a 7-day window to meet the minimum, it can be concluded that ample time has been given for applicants to apply and an election can more forward at that time. However, an extension period is offered to give proposers some flexibility if the initial minimum is not met, as history has shown extensions often result in additional qualified applicants. The extension period includes a reduction in the candidate criteria. The logic is that a total of 14 days should be more than enough for any possible applicant who missed the initial 7 day window to apply. The lowered threshold can be an acceptable tradeoff to give leniency to projects who are willing to extend their application window to gather additional candidates.

The formula is broken into a larger of A or B methodology due to the formula not working well with 1 or 2 winner elections. Once 3+ winners are met, you will see the formula has a fairly consistent “winning percent” (percentage of applicants who will be elected to council) regardless of size. In the initial 7-day window, most elections will see roughly 3/5ths of applicants going on to win. With the additional 7-day extension, roughly 4/5ths of applicants now can win. However, at no point is an election 100% guaranteed victory.

Key Terms
More information on the specific voting terms in Snapshot’s FAQs. For definitions of voting types, visit https://docs.snapshot.org/user-guides/proposals/voting-types. For more information on “Shielded” voting, visit Settings - snapshot.

Specifications & Steps to Implement
If enough interest is shown, I will put together an AIP that aims to update the Arbitrum Constitution to include language that defines a basic guidance for all Non-Security Council elections held by the DAO. The goal is to strike a balance between creating a consistent election process while maintaining some flexibility for proposers to fine-tune voting to fit their specific needs. The discussion above was based on current Snapshot voting, but Constitutional language will be done in a way that is platform agnostic in the case we ever move away from Snapshot voting. At a high-level, the language will highlight the following items, although all is open to changes as the RFC process goes along.

1. Define which voting type must be used for the scenarios defined in Issue # / Solution #1 above
2. Mandate that the election results are not visible until after the election is over
3. Mandate the minimum application window for a proposal based on size

Timeline

• RFC Period - 2 Weeks
• Take Feedback and Draft a Snapshot Vote - 1 to 2 Weeks
• Snapshot Vote - 1 Week
• On Chain Vote, if passing Snapshot - 2 Weeks

Timeline may change as need arises. I will also note that the Constitution has additional Governance Document mandated procedures, but I’m not 100% sure if those apply in this scenario since this does not affect contract information. If needed, additional time will be needed for:

• Phase 4 - L2 Waiting Period - 3 Days
• Phase 5 - Initiate and Finalize an L2 to L1 Message
• Phase 6 - L1 Waiting Period - 3 Days
• Phase 7 - Implementation

Overall Cost to Implement

There will be no cost to the DAO to implement.

And on a final note, thank you so much to @JoJo for his help with theory-crafting this discussion topic!

[Pepperoni_Jo3]

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 or provide an indication of final voting decision.

Thank you for sharing this post, @Bob-Rossi. Your thoughts on this topic are greatly appreciated. As the DAO evolves, establishing clear guidelines regarding voting mechanisms is going to become increasingly important.

I’ve provided my perspective and recommended actions for each of the major issues listed. One material change could be to break down the proposed adjustments into individual snapshot votes rather than grouping them together as one holistic set of governance changes. This would allow the DAO to assess, deliberate and ultimately decide on each option independently.

Topic #1 - Voting Mechanism

In my mind there is a tradeoff to the introduction of a standardised voting system. A standardised system could DAO through greater clarity and consistency, but also reduces the autonomy of individual proposal writers to experiment with and select a voting mechanism they feel is most suited to the particular election they are undertaking.

For this reason, and to avoid the issues of “how do we decide how to decide” (a common pitfall when approving multi-option governance and voting changes) I would propose the following action.

Action:

• Run a snapshot proposal where the DAO can provide it’s feedback on whether it would like a standardised approach for election (1) OR leave the election process up to the discretion of the individual proposal writer (2)
• If the DAO is in favour of a standardised process (option 2), we can then run a follow up Snapshot detailing the different voting mechanisms the DAO could choose to select.

Regardless, learning from the LTIPP “self voting” issues, going forward I think it is important for proposals to clearly articulate their election mechanism prior to starting the election process.

Topic #2 - Shutter Voting

I am strongly in support of the introduction of the “Shutter” feature for the reasons articulated above. It would also have the added benefit of reducing the frequency of last minute tactical voting.

Actions

• Run a Snapshot proposal to test the sentiment of the DAO for running elections in future as: “shutter” (1) “non-shutter” (2) or “let the proposal author decide” (3)

Topic #3 - Application Window & Minimum Application Count

I would support the DAO’s initiative to recommend guidelines regarding the optimal length of time for individuals to apply (1) and establish a minimum application count (2).

I’ll need to reflect further on the specific mechanism. If the problem statement is “seven days may not give high quality applications enough time to apply for council positions” , reaching the minimum application threshold within seven days may still leave high quality applications without insufficient time to apply. For that reason we could propose an increased application window of 10 days. This could be combined with a minimum application count (N+2) with the voting rolling over by an additional week if the minimum application count is not reached within the initial 10 day period.

Actions

• Before taking further action I’d love their to be more decision on the Application Window timeline and Minimum Application count

Keen to see what further discussion to bring out, both for topic 3 and the broader proposal.

[JoJo]

ehy chiming in cause as posted by @Bob-Rossi we had this discussion together and I helped him with some oversight on what was needed.

I think there is a merit in breaking down in snapshot point by point (assuming, snapshot can’t handle a case like this which seems like the case). Totally fine with that.

In general tho, topic 1, 2, 3 are all part in my opinion of the same basket of “good habits” on how the dao should vote. I would even dare to say, this discussion is complementary to the one currently live about self voting. So yes, let’s discuss. And eventually let’s make separate votes. But, let’s keep in mind the big picture: it’s all about make election smoother, fairier and more standardised.

That said

• topic 1 (voting mechanism): there could be a different approach maybe. Something like: standard way of voting should be X. But, if a proposal writer thinks there should be another mechanism of voting, it should be well articulated in the proposal. We leave the liberty to move into something else, but also, we should be aware that it would be more of an exception than anything. This all stands on the fact that we hope proposers, and also commentators, will be mature enough to understand that 99 out of 100 respecting the rules is +ve for the dao
• topic 2: nothing to add. It should be consistent. Again tho, would personally lean toward “shutter”, with exception possibilty as per the above if any.
• topic 3: is a numerical question more than a mechanism one. Bob studied previous elections, in the end we need to guarantee that for every election there is at least a certain amount of people, more than the spots available. So, numbers are up for discussion.

[Bob-Rossi]

Thank you @Pepperoni_Jo3 for responding and providing some thoughts.

One material change could be to break down the proposed adjustments into individual snapshot votes rather than grouping them together as one holistic set of governance changes. This would allow the DAO to assess, deliberate and ultimately decide on each option independently.

In my initial drafting of this, my goal was to discuss the voting process on the whole and getting to a standardized guideline. As I added issues to illustrate why I think the overhaul was needed, it has sort of morphed into these three key issues. I do believe all three are worth addressing at once for simplicity and effectiveness, but I also don’t want one controversial piece stop another popular item from passing. I’m no way opposed to splitting this up (and upon further reflection this may be the way to go anyway). Maybe the process looks like 3 Snapshot temp checks, where then the passing items go to Tally all as 1 item however.

I’ll add, there may be other best practices that can benefit the election process that I may not have addressed. So if other issues are present I have no issues expanding this out into a 4+ item discussion either.

For this reason, and to avoid the issues of “how do we decide how to decide” (a common pitfall when approving multi-option governance and voting changes) I would propose the following action.

Action:

• Run a snapshot proposal where the DAO can provide it’s feedback on whether it would like a standardised approach for election (1) OR leave the election process up to the discretion of the individual proposal writer (2)
• If the DAO is in favour of a standardised process (option 2), we can then run a follow up Snapshot detailing the different voting mechanisms the DAO could choose to select.

Regardless, learning from the LTIPP “self voting” issues, going forward I think it is important for proposals to clearly articulate their election mechanism prior to starting the election process.

I think this is fair and I like the idea, and to your point earlier there are a lot of variables between the issues that may need multiple temp-check elections. The more I think about it the more I think this may be the cleaner option.

A question back to you - I was struggling with this in terms of how to set a guideline without affecting flexibility proposal to proposal. However, I couldn’t really see a scenario where say 95% of elections would be perfect for Weighted Voting, but there then is a specific use-case that is for Single Choice. Or the same with say Weighed vs Approval in a 2+ winning candidate election. Do you have thoughts on what I may be missing? I am all for allowing flexibility for situations we can’t foresee, but I also don’t want to create openness just for the sake of it… as the balancing act with this is always going to be that if we loosen the rails too much it opens us back up to the gamification issue.

Maybe the play here is we define a specific voting type, but proposers can use a different voting type if and only if they clearly state that in the initial proposal discussion. Snaphot vote 1 is for the proposal, then in tandem a Snapshot vote 2 is up for approval for the ability to use a different voting method. That way delegates have a chance to block that voting style before the election occurs. I know it creates extra steps and I admittedly don’t like how ‘ugly’ that is, but I’d also rather have that option there in that edge use case where it really does make a difference… and in theory it would be only happening once in a blue moon anyway. Food for thought - @JoJo tagging you as I saw you had a similar thought about allowing proposal writers to ask for another mechanism. I would agree it really should be a ‘99 out of 100’ type thing.

I am strongly in support of the introduction of the “Shutter” feature for the reasons articulated above. It would also have the added benefit of reducing the frequency of last minute tactical voting.

From discussions had in the Security Council Election Thread as well, it seems this will be the least controversial item. To your point above I’d hate to see this specific item lost because one of the other issues can’t be agreed upon. FWIW, I think this is the both the easiest thing to fix and conveniently probably causing the biggest issues regarding gamification of votes.

I’ll need to reflect further on the specific mechanism. If the problem statement is “seven days may not give high quality applications enough time to apply for council positions” , reaching the minimum application threshold within seven days may still leave high quality applications without insufficient time to apply. For that reason we could propose an increased application window of 10 days. This could be combined with a minimum application count (N+2) with the voting rolling over by an additional week if the minimum application count is not reached within the initial 10 day period.

Thank you for adding your thoughts on this one, as this one I spend the most thinking time on. I don’t know if there really is a perfect answer here, so I too welcome anyone who is willing to input their thoughts into this. It’s all about flexibility while still setting a ‘floor’ of minimum viable action. I personally have no issues with 10 days instead of 7. Again this is probably where your point of breaking up the votes shines as we can propose a few popular methodologies.

[Pepperoni_Jo3]

I think this an excellent idea!

@Bob-Rossi

Maybe the process looks like 3 Snapshot temp checks, where then the passing items go to Tally all as 1 item.

Part of my rational for this approach is that if pushed to vote now, I would opt for:

• FOR shutting voting (no brainer IMO)
• AGAINST fixed voting mechanism (as I think some optional flexibility in any system is good)
• ABSTAIN on Application Window and Application Count (though FOR on a 10 day application window increase)

Breaking it up feels important to me as if other delegates hold the same sentiment, it could lead to a rejection of shutter voting due to token holders disagreeing with a fixed voting mechanism.

@Bob-Rossi

Maybe the play here is we define a specific voting type, but proposers can use a different voting type if and only if they clearly state that in the initial proposal discussion.

I support this proposal, but I suggest removing the parallel second snapshot vote. Doing so would establish the best practice for voting within the DAO, while still permitting others to adopt alternative voting mechanisms if explicitly stated in their proposals. This approach would resolve the issue of proposals initiating elections without clearly defining the election mechanism.

[JoJo]

I am a fan of having a standard vote with the optionality for the proposer saying “for this instance, let’s instead use this mechanism”.
Not sure, tho, if this could be gamed (it probably can). In the sense: if i am the proposer, and i support a non standard voting mechanism, beside delegates commenting, what prevents me from going with a non standard voting system? Should then delegates just vote against me not cause of the content of my proposal but cause I published on snapshot with a non standard mechanism?

But, probably, just keeping it simple, forcing a standard to constitution, is already better than not having it.

[pfedprog]

@JoJo

I am a fan of having a standard vote with the optionality for the proposer saying “for this instance, let’s instead use this mechanism”.
Not sure, tho, if this could be gamed (it probably can). In the sense: if i am the proposer, and i support a non standard voting mechanism, beside delegates commenting, what prevents me from going with a non standard voting system? Should then delegates just vote against me not cause of the content of my proposal but cause I published on snapshot with a non standard mechanism?

Well, what if the proposer has a bias towards the outcome of the vote. I think this is where the standard should be a deciding factor.

[JoJo]

yes, exactly why i would lean toward imposing the standard vote with no optionality. But maybe I am missing something semantic wise from your answer and we are maybe saying the same thing?

[pfedprog]

Depends on the perspective, I am not sure that shutter voting is always good, i think voters will be colluding in other ways or means, for example, in private messaging and subsequently hold more power over non colluders

[pfedprog]

One solution could be a transparent and timely voting from top holders.

Another solution is to make everybody not share any details regarding their vote.

However, both are impossible to enforce.

So → Collusion will still be possible

Hence, i think we need to go back to the question of what exactly are we trying to solve here for.

[pfedprog]

@Bob-Rossi

Elections ran without the “Shutter” feature allow for voters to see election results before the election is over. Without hiding results until completion, delegates are incentivized to delay and / or change their votes up to the final minutes of voting. This unfairly benefits candidates who gain early support, as delegate voting behavior may change based on who is winning at that moment and this can materially winner / loser results. It will also not give true indication of support for lesser candidates who then may not feel it’s viable to run for future positions.

I think that the current feature benefits the promt response to the election

With shutter feature it will benefit mostly the decision makers → largest token holders / delegates

Should we allow for delegates collusion ?

• Yes
• No

[Bob-Rossi]

@pfedprog A few posts, so responding to all in one.

I am not sure that shutter voting is always good, i think voters will be colluding in other ways or means, for example, in private messaging and subsequently hold more power over non colluders

Can you expand on in what way shutter voting creates a new and specific negative action that otherwise wouldn’t exist in a non-shutter vote? Voters colluding in private messaging is independent of the shutter / non-shutter decision, so in my opinion it’s not fair to say shutter shouldn’t be implemented because it only solves 1 problem and not all of them.

So → Collusion will still be possible
Hence, i think we need to go back to the question of what exactly are we trying to solve here for.

For context, while I would love to stop collusion where possible, the goal of this RFC would be to create a more standard election process that should hopefully create a better experience for all parties involved. As well as take away some of the ‘gamification’ pitfalls that can occur from certain voting mechanisms. If there are ideas to stop collusion present I’d love to explore them, but unfortunately there isn’t really much that can be done to prevent delegates from establishing private channel discussions.

I think that the current feature benefits the promt response to the election

With shutter feature it will benefit mostly the decision makers → largest token holders / delegates

Should we allow for delegates collusion ?

Can you expand on this? Especially the shutter feature benefiting mostly the decision makers? I’m honestly confused where shutter benefits the largest token holders / delegates over non-shutter. And I’ll add I’m not sure what the shutter feature has to do with delegate collusion in this context.

A side question / clarification — for the Shutter feature the votes are hidden ONLY for window the voting is live. All votes would be publicly known, by delegate, once the election is complete. So delegates would still be held accountable at the end of the vote as their votes would be public knowledge. I wanted to check if you knew that was part of the shutter feature, or if you thought they were hidden permanently? As you had noted “Transparent and Timely voting” above, and wasn’t sure if you thought shutter would ruin the transparency aspect. As shutter still has public results posted by delegate, and voting still has to occur timely as shtuter does not affect the time the voting period is live.

[Bob-Rossi]

Thank you all for the feedback! From the discussion, it seems the best course of action would be to break up the three issues into three separate Snapshot votes. I will spend the next week or so preparing myself for that. In the meantime, please feel free to continue the discussion here!

[pfedprog]

Thank you so much for responding

@Bob-Rossi

Can you expand on in what way shutter voting creates a new and specific negative action that otherwise wouldn’t exist in a non-shutter vote?

In short, it amplifies the benefits from colluding between delegates with sufficient amount of votes to swing the results of the proposal.

With non shutter votes there is a bug / feature that a promt response to a given election might lead to a gamification. Sure. This promotes social media posting.

But with shutter voting we absolutely move the communication channels to private messaging and mafia style games.

[pfedprog]

Found some interesting academic papers available online

Strategies in the Game of Mafia

In Mafia, two groups of two alignments, the mafia, and the vanilla townies, attempt to eliminate the opposing party to become the ending majority. The mafia, being a knowledgeable minority, can eliminate anyone they choose during private night discussions. The townies, being the unknowledgeable majority, can only exile through voting during public day discussions.

A mathematical model of the Mafia game

The main questions we address are:
• What is the probability that the mafia wins w(n, m)?
• How does the dynamics of the game look like? That is, what is the chance that after a given time
there is exactly a certain number of mafia members?

[JoJo]

I have played mafia/werewolf/other names for years, yes is for sure an interesting game, yes this dynamic applies here cause this is an election.

At the current maturity state of the dao, where maturity = consciousness of delegates about their power, alignment to collude and so on, I personally think we are not there, yet.

We will probably be, one day, but that day is far away, and in my opinion for now creating elections with a framework for which results are not known till the end of the vote is a +ve thing.

And we can also change it again, when we feel like is not +ve anymore.

Also remember, compared to mafia here is there is a key difference: at the end of any election, the results, including voting, is on chain. So you can see who voted for whom.