Page 3

Share this ASAP.

Before sharing:

Maybe its best to reach out to tadas and vlad just after proposing this. Not sure. Consider….

it’s definitely best to reach out to vlad and tadas first. they can help me find any flaws/improvements before posting to consortium and eden talk. I can also explain why we should approve this week (risks and opportunities with current ad hoc process). I can also mention eden talk if there’s time.

Then they’ll be more prepared for the post and ready to approve. I should definitely ask them if they’re ready to approve it with onchain transaction on Wednesday.

During our meeting i can/should ask them to write their approval in the chat to help it be approve

It will also look better for the community if in the post i say that i met with Tadas and Vlad about this this week and we agreed to advocate for this proposal. (We’re planning to submit at 13 UTC on Wednesday. Currently thats like 25% of votes with 100% approval).

I should submit my vote and encourage others to also submit their vote at 13 UTC. Don’t wait for 14 UTC or 15 UTC - submit it right away. That sends a better signal.

Also, next week i should open up the zoom room an hour early and state in advance. I’m opening the

Write in advance:

Please read the following proposal closely and be prepared to vote

I believe that approving this proposal during the week’s meeting is our top priority and will create immense benefits for all/everyone. If you have any questions or concerns about this proposal, then please reach out in advance with any questions.

Please take the time to carefully consider this proposal and ask any questions before this week’s meeting. I’d like to approve this proposal before 14:15 UTC in this week’s meeting so we can focus on other high priority proposals afterwards. See how Dan Larimer wrote the first interim consensus process

I’d be happy to meet before and my schedule is flexible

I’d be happy to meet as a group or on an individual basis to discuss and my schedule is flexible

I’ve cleared my schedule for most of the next few days and will be working on this proposal, roadmap, and next steps for Eden.

If you’re interested in

I believe that approving this proposal during the week’s meeting will create huge benefits for Eden ƒractal everyone in our community and the world. If you have any questions or concerns about this

• In order for a proposal to be approved, the following requirements must be met:

• In order for votes to be counted, the following requirements must be met:

• In order for a proposal to be approved, the following requirements must be met:

• Votes will only be counted if they are submitted between 13-16 UTC during the meeting

• In order for votes to be counted, the following requirements must be met:

• The proposal must be proposed before 16 UTC during the previous week’s meeting.

• The proposal must be submitted on Consortium before 16 UTC during the previous week’s meeting.

• A proposal can only be approved if over one third of all votes on the proposal.

• In order for a proposal to be approved, over two thirds of votes submitted must approve the proposal.

• For a proposal to be approved, over one third of all votes must vote on the proposal.

• For a proposal to be approved, over two thirds of votes submitted must approve the proposal.

• For a proposal to be eli, over one third of all votes must vote on the proposal.

• In order for a proposal to be approved, over two thirds of votes submitted must approve the proposal.

• The proposal and all votes must be submitted on Consortium.

In order for a proposal to be approved, it must meet the following requirements:

• Over one third of all votes must vote on the proposal.

• Over two thirds of votes submitted must approve the proposal.

• The proposal must be proposed o before 16 UTC during the previous week’s meeting.

• Votes will only count if submitted between 13-16 UTC during the weekly Eden ƒractal meeting.

Notes

• If Consortium is not working for any reason, then we will replicate the process with Hive and manually reference the spreadsheet until a different solution is approved.

• Proposals should be phrased with a binary ‘Yes’ or ‘No’ answer.

• To be eligible for approval, a proposal must receive greater than one third of all votes.

• To be eligible for approval, a proposal must receive greater than two thirds

• A proposal must receive greater than two thirds of votes submitted

• A proposal must receive over one third of all votes to be eligible for approval.

• Over two thirds of all votes

• Proposals shall be submitted on Consortium.

• A proposal must receive over one third of all VOTES to be eligible for approval.

• Proposals can only be passed between during the weekly Eden ƒractal meeting on Wednesday between 13:00 and 16:00 UTC

• A proposal must be submitted on Consortium before Wednesday at 16 UTC to qualify for approval in the following week’s meeting.

• In order for VOTES to be counted, the voter who submits VOTES must be present at the weekly Eden ƒractal meeting.
• VOTES only count for proposals in any given week if the voter attends that week’s meeting.

• Votes will only be counted if they are submitted by participants in the weekly

• Votes can only be submitted between by participants 13 UTC and 16 UTC during the weekly Eden ƒractal meeting

• Votes must be submitted on Consortium between 13 UTC and 16 UTC during the weekly Eden ƒractal meeting. Votes submitted at different times

• A proposal is only eligible 33.3% from “Total Circulation of VOTES” have to vote for a proposal for it to be eligible to pass.

• A proposal must receive over one third of all VOTES to be eligible for approval.

• Over one third of all VOTES must be submitted for a proposal for the proposal to be eligible for approval.

• A proposal must be receive at least

• Over one third of VOTES must

• A proposal can only pass if it receives greater than one third of all VOTES. minimum quorum

• A proposal must receive a minimum quorum of greater than one third

• At least one third of all VOTES must be submitted

• Votes will only count if submitted between 13 UTC and 16 UTC during the weekly Eden ƒractal meeting.

• Proposals must be proposed on Consortium before 16 UTC during the priori

• If Consortium is not working for any reason, then we will replicate the process with Hive and manually reference the spreadsheet until a different solution is approved.

Proposals must be phrased with a binary YES or NO answer.

This is an interim process can serve until modified using the same process or the automated workflow on fractally.com is ready.

Please share your thoughts in the comments below.

Proposals will expire after 2 weeks? Did Tadas say that he thinks it should expire? I think i should not include it. I don’t think it’s a big priority now. If others want to include it then that’s fine by me but i don’t want to add more resistance by adding to it.

Additional Resources

You can view this spreadsheet for reference about proposals

Original VOTES Proposal?

This interim consensus process will become nullified when the EDEN token becomes transferrable. A new VOTES token will be created before

Before making the EDEN token transferable, creating liquidity

VOTES can only be submitted

Permit voting only during the meeting on Wednesday (since what’s the point of voting before meeting if it is not being taken into account anyway?).

33.3% from “Total Circulation of VOTES” have to vote for a proposal for it to be eligible to pass.

By the end of the meeting either YES or NO option has to receive 66.6% from “Total VOTES used in the poll” in order to pass.

Proposal is eligible to be passed if it has been submitted at least 7 days ago.

better than 70% and 35% is greater than 2/3 and greater than 1/3. Yes I’m pretty sure about this. It is better not to change his number right now and this is a much simpler way of saying it rather than in percentages. So much better rather than 766.67% and 33.33%. It’s much easier to understand and simpler and agreed-upon and the path of least resistance that the current must follow. Attach the reply to Naval about this with the path of least resistance. And the idea of the schnelling point - . And this is the point of least resistance where it is the easiest for people to cooperate. And this is what we must do with this proposal for votes. We need to use the simplest language possible and make it very easy to understand and pass. Go with the path of least resistance. If we try to advocate for 70% and 35% at this point then it would create resistance and uncertainty and perhaps make people feel less willing to adopt an interim consensus process and thereby continue in the default state of relative anarchy and ad hoc hand raising. We can consider alternative designs in the future but right now we need to go with the path of least resistance and Dana Marie simply and so using the words 2/3 and 1/3 is much better here and avoid asking the question about changing it or asking additional questions to the community as a whole that aren’t designed to help get this proposal passed and approved now. It will fix so many issues and give so much more order and cooperation to the community and will be extremely helpful when we get this proposal passed. So my priority now is to simplify it as much as possible and explain as well as possible and presented as well as possible to approve the proposal. Find the specific words that provide the path of least resistance and don’t provide too much information that creates more resistance or friction or confusion. Just give people something that’s very easy to approve and wrap their heads around with a nice spreadsheet and very simply defined and clearly articulated and elegantly stated Proposal

Also with respect to call kolmogorov complexity and gall’s law and so forth. Make it very simple for people to approve and benefit from this new cooperative process

35 and 70 percent is easier to say than 33.33 and 66.67. It’s also a bit more difficult to pass proposals this way. I like it. I think it’s better as 35 and 70 rather than weird decimals.

This is also better because the size of group is small. Makes it a bit more difficult for just 4 or 5 people to pass a proposal.

I thought about more like 35/75 or 40/80, but I think that 35/70 is best for now. We’ve already been discussing this previously and this isn’t a big change. 40/80 would require too much thinking for now and be overly restrictive - Ie if Felix + 2 others than if it’s not agreeing then we don’t want to hold the whole group.

35% of “Total Circulation of VOTES” have to vote for a proposal for it to be eligible to pass.

By the end of the meeting either YES or NO option has to receive 70% from “Total VOTES used in the poll” in order to pass.

Would the 70% make it so that one person like Felix or I could hold up the entire process?

I don’t think so. But i should definitely play around with this on spreadsheet first to see how it looks.

The interim consensus process is comparing what we currently have:

Permit voting only during the meeting on Wednesday (since what’s the point of voting before meeting if it is not being taken into account anyway?).

33.3% from “Total Circulation of VOTES” have to vote for a proposal for it to be eligible to pass.

By the end of the meeting either YES or NO option has to receive 66.6% from “Total VOTES used in the poll” in order to pass.

Proposal is eligible to be passed if it has been submitted at least 7 days ago.

Proposals can be made on BBS or Consortium.

If the EDEN token becomes transferrable, It won’t work for votes

I do think that it makes More sense actually to have two separate proposals for builders and talk. Because they are really two different things and there might be a situation in which you want to approve somebody to be eligible to receive the respect rewards on Eden talk but they have not had the time to make a profile on the builder site. It makes sense for them to be different proposals so that people can just start posting on the Eden talk right away without needing to make a profile on the Eden Builders first. And that way the quality of profiles on edenbuilders gets increased because the council can be more selective about only approving great profiles, whileIt makes sense for them to be different proposals so that people can just start posting on the Eden talk right away without needing to make a profile on the Eden Builders first. And that way the quality of profiles on edenbuilders gets increased because the council can be more selective about only approving great profiles, while also separately being able to approve people being eligible for Eden rewards on Eden talk

Should we vote on BBS instead of consortium?

Does Consortium make it easy to see who voted on a proposal?

Hive is nice because it enables people to write proposal (without much character limit) and then shows exactly who agreed to the proposal below.

However, everyone is used to EOS accounts and i think it’s best to use EOS accounts here.

BBS requires another signup, but it looks simple and also want to encourage sign up for Eden Talk.

Does BBS provide a private key? Idts. However I don’t think it needs to because it’s being posted on-chain and the participant is also live on camera. But private key is better

If possible, BBS would make it similar to the hive interface, provides more clear delineation between VOTES and EDEN, and helps us learn how to use this tool

• By submitting their vote

I think all of the following isn’t necessary or helpful now. Better to just keep it simple and recommend that people post on consortium. Along with a note that the current process will become nullified if the EDEN token becomes transferable.

Technical Details

• The votes must be submitted with only 1 EDEN token on Consortium.
• If a voter submits more than 1 VOTES token, then their vote will be nullified on the current proposal.
• Prob not necessary or helpful to include this in the v2 proposal. Maybe in a suggestions section at the bottom that is clearly explained that this is a potential refinement in the future
• It also might be best to not write this so as to be clear that it is not the EDEN token that is voting
• Perhaps we should use the EOS consortium group and vote with eo instead of eden so it’s more clear that the EDEN is effective in VOTES?
• Idk, maybe its best to just leave this part undefined or without recommendation?
• If we do wind up using the EDEN token, then the vote would still be with VOTES. So it’s good to make the VOTES token sooner rather than later to protect the community from legal interpretations and courts that say EDEN=VOTES even though it does not

• By submitting their transaction on-chain,

Notes for Event Hosts and Video Creators

• While voting on proposals, it can sometimes be helpful to screenshare the spreadsheet to provide a visual overview of votes on proposals
• Video creators can resize the relative proportions of the screenshare and participants to approximately 50% each to provide a visually engaging video experience.

https://bloks.io/tokens/EDEN-eos-eden.fractal

Current process with only people who are there and ambiguity

https://bloks.io/tokens/EDEN-eos-eden.fractal

https://edencreators.com/edenfractal/interimconsensusprocess

https://edencreators.com/votes