Steward Election - voting open now

Public goods is still displaying inaccurate for me even with an empty cache.

1 Like

I may be wrong but I think once a certain tipping point is passed in the total possible votes, all votes go to the top choices. Because it’s ranked preference and no amount of votes could put you in the running. Not positive though.

Hat tip to the design and forethought of the ENS team for waiting to have the steward elections after hype and happy to see many quality candidates.

I am still trying to get confirmation that this is how this type of election works.

If this is the way the election will work then I think the snapshot numbers are not reflecting it.

1 Like

As we’ve discovered, Snapshot isn’t using anything like this; it’s only attempting to discover the one winner, which does lead to inaccurate results for runners-up.

We’re talking to the snapshot team about changing their calculation for runners-up so we get an accurate view of the 3 top candidates, but we may just have to drop back to downloading a dump of all the votes and calculating it ourselves. Either way we will make sure we have an accurate result from the election, even if it’s not showing in the snapshot interface.


On further inspection, the voting method we selected - instant runoff STV - isn’t best suited to electing multiple candidates. We can adapt the rules to get good counts for second and third candidates (my suggestion was to rerun the election without the winner in order to find second and third place winners), but I’d like to suggest we instead use a different STV counting method.

Meek STV, described here and implemented in this python library is used in various local body elections, as well as on Stack Overflow and by the London Hackspace. It’s well understood, already implemented, and explicitly designed for electing multiple candidates. It’s still a ranked choice voting method, so all the ballots cast for this election are still valid.

I would like to propose that we use Meek STV for determining the outcome of this election, and prior to the next election pass an amendment to EP4 either specifying that future elections will use it if Snapshot can add support for it before then, or changing to another method already supported by Snapshot, such as approval voting, if they can’t implement it in time.

In the interests of not holding up the steward election process for a DAO-wide snapshot vote, I’d like to propose we adopt this by acclaimation (eg, please state an objection if you have one).

Finally, I need to apologise - the choice of voting system was mine, and I didn’t look closely enough into how it worked with electing multiple candidates before putting it forward.


For Meek STV calculations, I’ve quickly created a small script that uses Caritat and directly pulls the snapshot data. The GitHub repo for the script is available here, feel free to generate the results yourself or inspect the code.

With two days still left to vote on the elections, the current results calculated with Meek STV would be as follows:

  • Public Goods
    • sumedha.eth
    • ceresstation.eth
    • avsa.eth
  • Community
    • spencecoin.eth
    • limes.eth
    • coltron.eth
  • Ecosystem
    • ginge.eth
    • slobo.eth
    • avsa.eth
  • Meta-Governance
    • james.eth
    • jmj.eth
    • simona.eth

man you’re a beast :clap: :clap: :clap:

1 Like

Nice work. Script shells out empty result files though without errors :thinking:

Could someone ask Coinbase to chime in? Have they voted?

Did you setup the config?

1 Like

Just checked. config.json is a template :grimacing:

This isn’t necessarily an objection. It’s more a perspective I will share. The fact that we can calculate final results by querying the snapshot and declare it good, presupposes that as being the only problem/issue we have.

The bigger issue is not being able to see accurate results while voting is still underway.

Here is what the public sees as current voting results for Stewards of the Public Goods Working Group:

@taytems calculated the top 3 are:

Public Goods

  • sumedha.eth
  • ceresstation.eth
  • avsa.eth

Now, the results known the the public are skewed, yet pretty important for the public to know the standings in real-time, on the voting UI of snapshot. Why? There’s a lot of reasons, one is maybe voters wouldn’t want the same Steward in two categories. It’s not evident on snapshot that avsa.eth is in top 3 for two Working Groups (Public Goods & Ecosystem). As an example, maybe I really want to see avsa.eth become a Steward of a Working Group, but not of a second. (I am not saying he wouldn’t do a bang up job on both) Maybe instead I would like to diversify Stewards, and if I saw avsa.eth was definitely going to clinch Ecosystem, I would then change my vote to push up another Steward in Public Goods.

This is the real issue with how the voting has gone imho. I am not saying delay the nominations and start over. I just am not sure the public understood the voting method, and the bugs in snapshot have had some effects on who received votes.

Anyone else have thoughts on this?


I agree that having an inaccurate tally could alter voter decision-making. If providing a real-time tally it should be accurate, otherwise, I’d prefer a blind election.

This likely wasn’t foreseeable, but the bugs in Snapshot should be worked out before the next major election. I can imagine some unrest if this were a tightly contested election.


This is definitely a reasonable point and the script is just a temporary solution. I don’t have time right now to implement a solution for a PR, but I (or someone else if they’re willing) will be able to implement one in the future.

Assuming a PR for Meek STV gets accepted and merged by Snapshot, and if we choose to continue using this method at the next steward election, there will be an accurate result in the UI.

1 Like

We could also have high profile ENS core team members tweet the current standings 1x a day.


Set the config.json to the following:

  "strategies": [
      "name": "erc20-votes",
      "params": {
        "symbol": "ENS",
        "address": "0xC18360217D8F7Ab5e7c516566761Ea12Ce7F9D72",
        "decimals": 18
  "spaceId": "ens.eth",
  "seatsToFill": 3

This is a fair point - but unfortunately one we can’t do much about. I also would argue that ranked choice voting is a system in which strategic voting is much less beneficial, and thus less likely, so it should have less effect here.


Awesome! Thank you so much!

1 Like

I like this. I’ve been a bit confused by the snapshot atm.