Welcome

This page features Dan’s feedback for OREC. These notes are in an early draft state and will be refined and organized better soon.

Table of Contents

Plan: Optimistic Respect Polls

• [x] Try copying and pasting Tadas writing and changing only the necessary parts to fit in with this new idea of ‘Optimistic Respect Polls’.

It’s not a contract any more and it doesn’t have any executive power. OREC provides a potential way to transfer the control of an executive contract in the future, but it does not provide the current solution that we need. It provides much of the design for what we currently need, so i should copy paste it and change for Optimism Fractal’s current needs.

I don’t know if I agree with my previous feedback about stage and cycles. So I’m not sure if I need to change it. Tadas article for OREC was coming from a perspective of building a contract, so there’s a lot of assumptions there that I’ll need to change for this proposal

Related: Orpolls

Changes to Variables?

Variables

• vote_cycle = 1 week;
• veto_cycle = 1 week;
• cycle_start_time = 17:20 UTC on Mondays;
• min_vote_threshold = 128 Respect;
• respect_period = 26 weeks;

I suggest that we:

1. Add an additional variable called ‘cycle start time’?
2. Change the name of period to cycle to make it simpler
3. Change ‘stage1_period’ and ‘stage2_period’ to ‘vote_cycle’ and ‘veto_cycle’
4. Consider whether it’s best to have two variables for a ‘cycle end time’ and a ‘cycle start time’.
   • This adds some complexity and potential for confusion, but it could resolve the issue identified where someone who makes a last minute proposal can have an unfair advantage in having their proposal approved. We want to keep it as simple as possible, but a bit of extra complexity might be warranted here to make the system work well.
   • For example, if we set a cycle end time to 17:10 UTC and a cycle start time to 17:20 UTC, then perhaps it could solve this issue and make it so there’s at least 10 minutes where everyone is on the call together and can vote yes or no on a proposal before it moves into the veto cycle.
   • I’d have to think about this more closely to determine if this solution would work well or if it should be designed differently. Is it better to have a separate start/end time for the proposals and voting, and different start/end time for the veto period? Or do they have the same schedule?

Accommodating for Vote Changes

Can someone change their vote during the veto cycle? I think they should be able to change it from yes to no if they change their mind…. But this would introduce technical challenges. There are two separate polls and Tadas’ original design of OREC doesn’t allow for no votes during the second week. Maybe it’s best to only allow ‘Abstain’ in the second week since an Abstain is like a lite version of a no. Another issue with the current design that I have in mind- if we use snapshot and allow people to vote no in both polls, then that no could be double counted. How would we resolve that?

I suppose the way to resolve it is to go moreso with Tada’s original intention but put a wider time period during our meeting for the voting cycle. For example, if all proposals needed to be submitted by 18 UTC and the voting cycle doesn’t end until 18:20 UTC, then this would allow at least 20 minutes for the community to vote ‘yes’ or ‘no’ for a proposal. This would mitigate the issue where someone can gain an unfair advantage by posting a proposal in the last minute, because it wouldn’t be possible to

If someone votes yes in the first 20 minutes and then changes their mind during the veto week, then do they have any way to express this change of mind? Currently I’m stumped about this because it seems that they wouldn’t have any way to change their mind in the votes while keeping the system technically feasible without bespoke development, but it seems that this is a feature that we would want.

If someone votes no in the first 20 minutes, then could they reiterate this vote?

Another Solution? Two Week

Maybe the solution is to have the same exact poll repeated over two weeks. This would re-orient the system a bit but i think it might work well and allow more expressive, intuitive, and fair experience. Imagine this:

• In order for a proposal to be approved, it must meet achieve a sufficient quorum and minimum threshold of votes in to successive weeks. People can vote yes, no, or abstain in both polls.
• In order for a proposal to move to the second stage, it needs to have at least 66% of votes and the minimum threshold of respect.
• If a proposal passes the initial filter and moves to stage two, then the exact same proposal will be put up for vote in the second stage. The text in the proposal cannot be changed between the stages or else it would count as a new proposal.
• In order for a proposal to be fully approved, it needs to have at least 66% of votes and the minimum threshold of respect in the second week as well.
• If a proposal is moved to the second stage, it needs to have at least 66% of votes and the minimum threshold of respect in the second week

Benefits of Two Week Voting Cycle

I think this two week system generally works well and naturally with our meeting schedule. It always gives the group at least two meetings (and at least 40-60 minutes) to discuss changes in a planning session. Otherwise you’d either have a lot of pressure to decide something at one meeting, a high voting threshold that’s difficult to attain, or decisions would be made outside of our meeting with only the chance to discuss it once.

Benefits of 26-52 week Respect cycle

• This provides more stability and defensibility for the community. Especially With this optimistic design.

  • Imagine if we get 25 or 100 people attending within the next few months. It’s certainly possible and seems very likely to happen in 2024. The total amount of respect earned each week will be far far higher than today. People could join with friends and achieve a minimum respect threshold quickly, perhaps within a week, which would force longer time contributors to react in the proposals

• If anything it should ere to be more conservative for people who earned respect earlier in the fractal. If new people want, they can always fork it. If someone works alot to build it for a year and then takes a 3 month break, should someone who just joined for a week have more formal power than them? No

• It provides more security into your investment of time. If you invest many many hours, then you want to be sure that your investment will be worth it. Investing in a community that has a very short lifespan for utility of respect is a bit like investing in a currency with hyperinflation. Even if you work to earn alot of respect, it might not do you any good anymore in a few months.

  • Also that it’s not committing you to be controlled by the fractal community in that you have to keep attending and helping and earning respect to see it go the way that you want. That might be an unhealthy kind of relationship if you feel like you need to do it to protect it
  • Ie will each person be as motivated to join when the functional utility of respect . Or might it seem more like an obligaton to attach your reputation to the fractal but need to be there each week to guide it correctly
  • Maybe that’s also a good thing that it’s shorter because it motivates people to care more in the short term. That can be an argument for 26 weeks instead of 52. Overall I feel like 26 week cycle is best.

• We can make it shorter in the future if we want and start with a longer period

• This is easier technically now

Manual Proposal Creation

We don’t need to do any additional coding in order to make this system work. If we set the cycle time to start and end sometime between 18-18:30 UTC, then

1. This means that proposals could take up to 3 weeks can be approved. If we can change the design of the smart contract so that there isn’t a universal cycle for all proposals but rather each proposal goes through this 2 week cycle then it might work better. This would provide consistency, shorter 2 week proposal start-to-finish times, and seems like it would be simpler to understand.
2. It also means that some proposals will take just over a week to approve. Which can be advantageous for quicker proposals but adds some complexity. What would be the day/time of the cycle ending? Would there be strategies that people do to try to game the system and propose at certain times? If so, what would these look like?
3. If the OREC contract is set to change states at 18:15 or 18:25 UTC, then that could be interesting. This kind of stable time for cycles that is not dependent on when proposals are created could align with the dates of our events. If we set the OREC to a time on Monday during the event, then when would proposals need to be submitted in order to be only a week from approval?

Voting No in the second week

Why can’t people vote no on a proposal in the blocking stages? If they want to block a proposal, why can’t they vote no? It’s a bit strange and counterintuitive.

It seems like it might make the system more vulnerable to being gamed as well. Suppose someone puts in a proposal a minute before the end of a voting period and they have over 128 respect. It’s not a good proposal at all but there isn’t anyone to vote no in the last minute. It looks like this proposal has 100% yes votes on snapshot or whatever UI that people see, which would stay up for a whole week. This can be misleading to people looking at the poll.

Additionally, would this strategy make the proposal more likely to get approved? Yes, I think this is a flaw in the current design. A ‘no’ vote is more powerful than an abstain or a registration to block the proposal, but the system doesn’t allow no votes in the second week for some reason. A proposal requires both the minimum threshold and a 66% of total votes, and a last minute proposer could essentially skip the requirement of 66% of total votes needed by just making the proposal at the last minute. This makes it easier to approve proposals- even if people don’t want to approve the proposal and would normally vote no, they are not allowed to vote no in the second week.

It seems that disallowing ‘no’ votes in the blocking period both makes it more confusing and easier to game to approve bad proposals, but it doesn’t offer any benefits. I’m curious to know if there’s something I’m missing. I suggest to allow voting in the blocking period to improve this. That would make it simpler to explain, more intuitive, and more fair.

This could be essentially achieved on Snapshot by including an Abstain option.

Snapshot integrations

How do you envision the two week cycle for OREC happening on snapshot? Would there be two polls for each proposal and the second poll in the second week would only have a veto option?

If there are two polls, then how would we ensure that the second poll starts right after the first? Would it just be manual and in which case it will take longer than 2 weeks? Or would it be feasible to program another veto poll to automatically start after the two weeks?

If it is one poll on snapshot, then how would the the diference between the first and second week be calculated? Ie if people can only veto in the second week, then how would we count that if the poll still allows yes votes? Snapshot does have modules/___, so would we need to make a module / recipe for this?

Could people change their votes? Could people vote no or veto again during both weeks?

I could see this system working well if it’s easy enough

1 week

1 week

128 respect? or?

respect_period = 26 weeks