Eden Style Governance Milestone Ticket

[n13]

Overview

Eden is a governance style invented by Dan Larimer. It is suitable to democratically elect a leadership team from a group of people, giving everyone equal say in who will be the leadership.

It consists of multiple rounds of voting. Members are put in randomized groups each round, and each group needs to come to consensus on one winner. Each group winner advances to the next round, where the same process occurs

There's 3 rounds in Eden, which results in 4-6 winners so far - depending on the number of people who started.

Eden is suitable for selecting a leadership team for the DAO - it's not really suitable for other kinds of decisions so i Hypha we will simply give the winners a badge (North Star, or any badge they want to set), and HVOice - amount set in setup.

An Eden election takes place in real time on a set date.

Therefore there is opt in by members - announcing they will be there - and once it starts, it ends around 3 hours later if the time per round is 1 hour and there's 3 rounds for example.

Specification Eden in Hypha DAO

Eden in Hypha will work as outlined above, but within the DAO

Winners receive badge(s) and HVOICE

MVP implementation requires a manual trigger of the vote by any member, however, the votes are limited by the time interval set in the DAO setup, e.g. they can't happen more often than whatever the time interval set is.

Features

DAO Setup

When setting up a DAO, a user can add Eden style leadership elections (optional)

Frontend

• [ ] Checkbox to enable Eden governance
• [ ] Time interval for eden elections, e.g. "every 3 months".
• [ ] Election round timer. E.g. "1 hour" - this is the time interval for each round.
• [ ] Number of rounds. E.g., "3". We can hard-code this for now. EOE has hard coded it to 3
• [ ] Number of members per group: e.g. "4". This should be between 4 (minimum viable group) and 7 (after that it gets too hard to decide)
• [ ] Opt in period, e.g. "4 days" - members have 4 days to opt in, meaning once the election is called, there's 4 days to opt in and announce availability.

Backend

• Store Eden settings

Election Proposal Type

Task: User creates Eden proposal

Frontend

• New prop type "Eden Election".
• Enter HVOICE reward for winners, e.g. 10,000 HVOICE
• Enter Badge reward for winners, e.g. "North Star Badge"

Backend

• Eden Election Proposal Document
• gQL query for document so frontend can show it

Opt In Period

Task: Proposal is live and in opt in period

Frontend

• Show proposal
• Detail screen: Opt-in button

Backend

• Opt in action, collect members
• Add members to document
• gQL: Query members of document (who is in?)

Live vote

Task: Eden election is live - starts

Frontend

• Count down timer to start election
• Groups Screen - shows available groups
• Vote screen - opening a group leads to votes screen, shows votes
• Vote button - on vote screen if member is looking at their own group, vote button next to every member
• Vote display - show votes already currently cast
• Member contact information - telegram or discord - Each member can set in user settings their contact info, which is then displayed here.
• Profile service DAO: Add setting for contact info
• Tabs / Rounds screen - Each round has its own tab showing all the information

Backend

• Election Document - keeps track of rounds (id)
• Round document - keeps track of groups in round (by id)
• Group Document - keeps track of members, votes, winner
• Profile service: Add setting for contact info
• Randomize groups service - can't be on chain since chain can't do randomization
• Timer to keep track of the process.
• There's rounds, each round is 1 hour, but 10 min of that is for people to find each other.

Real World Problems

• How do people find the zoom rooms they are supposed to be in? Eden is working on a Telegram bot that would automate the video room link generation which would be very cool. As it is it's manual, and takes a long time to find the room, and in our case there was a password on the room too, so we couldn't get in, but we also didn't know who created the zoom so couldn't ask - it was a mess. It worked because one of our group members knew the guy who created the link, so we could contact him and get in.
• Timing - there's countdown timers active all the time, and the process moves on each time. That's almost like a video game. Very important to make this smooth - the timer part works pretty well on their existing site.
• Both backend and frontend need to be informed of timer events

Final Screen / Historic Screen

Task: Vote is ending, or user is looking at a historic vote

Frontend

• Winners
• Rounds history (tabs rounds screen)

Backend

• End vote
• Send rewards to winners

[sceenius]

Playing the above through in condensed form, this is similar to a role application without knowing yet who will be assigned to the role - a process decides that vs. a vote on an already known applicant.

1. Create Eden Proposal
2. Apply for Eden Proposal (optional - submit video or select time)
3. Launch Eden event round ED - set timer, group applicants (randomize) 3.1 For each group: watch/meet, then vote
4. Launch Eden event round CD - set timer, group applicants (randomize) 4.1 For each group: watch/meet, then vote
5. Launch Eden event round HD - set timer 5.1 Final group watches/meets, then votes
6. Close Eden event - announce HD, assign HD to proposal as winner (owner)

With ED = Eden Delegate, CD = Chief Delegate, HD = Head Delegate

Couple of notes:

This is another form of Liquid Democracy (LD), the diff here is that it happens for each and every proposal and there is only 1 delegate, LD makes the delegates permanent, but only if there are "domain experts". There is a question if Eden proposals really need real-time meetings or if this can be handled async (via video recordings) to save everyone's time. The most complex UI element (to me) is the vote button that needs to be shown on applicants from your current group only (you don't see any others where you are not part of the selected group, it's kind of a filter). Assigning voice and badges is a nice side benefit, but the main concern is to find the HD for the Eden proposal.

[n13]

Playing the above through in condensed form, this is similar to a role application without knowing yet who will be assigned to the role - a process decides that vs. a vote on an already known applicant.

1. Create Eden Proposal
2. Apply for Eden Proposal (optional - submit video or select time)
3. Launch Eden event round ED - set timer, group applicants (randomize) 3.1 For each group: watch/meet, then vote
4. Launch Eden event round CD - set timer, group applicants (randomize) 4.1 For each group: watch/meet, then vote
5. Launch Eden event round HD - set timer 5.1 Final group watches/meets, then votes
6. Close Eden event - announce HD, assign HD to proposal as winner (owner)

With ED = Eden Delegate, CD = Chief Delegate, HD = Head Delegate

Couple of notes:

This is another form of Liquid Democracy (LD), the diff here is that it happens for each and every proposal and there is only 1 delegate, LD makes the delegates permanent, but only if there are "domain experts". There is a question if Eden proposals really need real-time meetings or if this can be handled async (via video recordings) to save everyone's time. The most complex UI element (to me) is the vote button that needs to be shown on applicants from your current group only (you don't see any others where you are not part of the selected group, it's kind of a filter). Assigning voice and badges is a nice side benefit, but the main concern is to find the HD for the Eden proposal.

There is an existing process and we will need to recreate it.

There were several surprises, details, and unexpected problems in this process.

If we design a new process, then we will come across different details, surprises and unexpected problems

So I don't think it is feasible to deviate from the current process at all

In addition, we need to show the existing EOS on Eden process in our UI as part of one of the milestones, and that will have to be exactly like their process anyway.

So yeah - I have some screenshots of the existing process I can upload later.

[n13]

I actually think the existing Eden UI is good as far as function is concerned.

What makes it confusing is the visual layout which is not very good. We can improve on that.

For each round there's 2 viiews

• An overview - this shows all groups, all members, and all votes in real time
• A group view - for someone who is in a group, there's a detail view just for that group, where I can hit the vote button on any of the other members.

[sceenius]

The EDEN democratic process elects a new leadership team (delegates) that will vote on new proposals as long as that role or badge is active. So, I think it is not used as a voting method for each new proposal, but rather as a way to delegate the vote to the elected lead until that role/badge expires. So,

1. EDEN democratic process is launched and winners are recorded on chain (via UI/Dashboard or https://genesis.eden.eoscommunity.org/)
2. New proposals that are created in the DAO can select the DAO consensus model as a voting method (need to add the voting method as option)
3. The only person(s) allowed to vote on that proposal are the elected delegates (or only the Head Delegate, not sure).
4. Voting proceeds as usual and the proposal is either accepted or rejected (by the delegates).

[sceenius]

Further inquiry to the Eden folks (10/27)

Another question I have - once the Eden election is complete and you have new delegates, you want to bring their power into the DAO. My thinking is to design the DAO consensus model in a way that either limits votes to the delegates (fairly easy to do, can adjust to the elected level of HD, CD or L1) or gives delegates a voice boost (more involved, since we need to take that away once the delegate status has ended plus we'd have to calculate how much additional voice power is needed to effectively overwrite non-delegates).

My initial opinion is that limiting the Voting Power to the delegates ( with adjusted levels to their respective ranks ) is the preferred way. It means to me that being a delegate of any level comes with a “privilege” AND a responsibility (!) to vote/participate. The quarterly Eden elections would be a chance to achieve this “privilege”. Designing it this way would potentially drive more meaningful engagement and dedicated participation to both processes.

My reflection on this: Very good alignment on the idea to give delegates special status in the DAO. I am now thinking to assign them special privileges in the community doughnut, such as being able to create a proposal inside the nucleus (in addition to the full voting rights in the community space). That way we don't have to struggle with voice power.

More reflections on this: It does not have to be restricted to the community doughnut, but can be used inside the nucleus as well. Which is actually easier to implement since we don't have any community proposals yet to vote on (!)

[sceenius]

The one badge I see being valuable for Eden is that of a "delegate" which can work with the Eden election process for this milestone. Sketching some requirements for that smart badge -

(1) This badge is only active between two elections and is removed/inactive otherwise (2) Badge holders have the full voting power IF the Eden consensus method has been selected (under vote settings) (3) Possible voice multipliers can apply that give (former) delegates more voice after they step down from the role (4) Possible delegate levels are shown on the badge (0=inactive, 1=L1, 2=CD, 3=HD)

[sceenius]

Current summary of all requirements gathered so far:

1) Eden election process - no change in the protocol, results are mapped to the DAO, Eden bot guides participants 2) Eden consensus method - new voting method in the DAO, delegates "run the show" (in the community doughnut) 3) Eden delegate badges - new smart badges for delegates, different levels are accounted for (voice=2,4,16)

The primary purpose of the Eden Election is to bring stability and alignment to the community. Full stop.

[sceenius]

The corresponding features we can implement are

1. Eden election process ("import") - add new delegates to DAO ({Eden election} + {EOS account} + badge assignments)
2. Eden consensus method ("setting") - configure new voting method in DAO ({Eden election} + badge holders)
3. Eden delegate badges ( “privilege”) - add smart badges to DAO ({Eden election} + voice replacement)

with {Eden election} ::= ID, name, start date, end date, manual input or pull data in from API

[sceenius]

Stories:

• As an Eden community member, I can vote with voice =1 on any proposal
• As an L1 delegate, I am eligible for a L1 badge and can vote with voice = 2 on any proposal
• As a Chief Delegate, I am eligible for a CD badge and can vote with voice = 4 on any proposal
• As a Head Delegate, I am eligible for a HD badge and can vote with voice = 16 on any proposal
• As an administrator, I can switch the DAO to the "Eden Consensus" method; this will only be enabled if all required badges are active
• As a core member, I can create new proposals

[sceenius]

On Monday Dec 12 at 2pm ET the Eden folks are testing the new Eden Up Vote Bot, I will try to be there to learn more about it. This is just another indicator that we should NOT replace or rebuild what they are doing, instead just "import" the results into the DAO. They are making continuous updates to the election process.

[sceenius]

Selected Eden Bot screenshots from Telegram. The aim is to run the election through the Bot and with the video integration. To participate, you need to be a community member - https://genesis.eden.eoscommunity.org/members

[sceenius]

The Eden DAO could be an embedded view on the right menu bar -

https://genesis.eden.eoscommunity.org/election

[sceenius]

Update from Eden:

Chief delegates are stored on chain, others are only in the members table (not sure if we can distinguish) -

CDs: https://bloks.io/account/genesis.eden?loadContract=true&tab=Tables&table=elect.state&account=genesis.eden&scope=&limit=100

Members: https://bloks.io/account/genesis.eden?loadContract=true&tab=Tables&table=member&account=genesis.eden&scope=&limit=1000

[sceenius]

Full write-up of the recipe is here - https://notepad.hypha.earth/_CtQVhzbS-q5UD_UXtTNTw?view