Early work in progress….

Marco

Gavriel

Eric

Perry

Sebastian

CAC

Combine current proposals

I made two proposals to change the MSIG.

One includes Chuck in the MSIG and has a higher threshold. The other proposal does not include Chuck in the MSIG and has a lower threshold. I think that we should include Chuck in the MSIG and configure a higher threshold, but I know several people have expressed interest in removing him from the MSIG since he hasn’t participated lately so I’m proposing it both ways.

You can see a table view of the two proposals displayed in this spreadsheet.

The most important aspects of these new proposals are:

TP34- Do you agree to configuring the eden.fractal account MSIG as follows? (Including Chuck)

TP34- Do you agree to configuring the eden.fractal account MSIG as follows? (Not including Chuck)

Hey Vlad, thank you for making these proposals!

Here are some related thoughts, reasons why I think we should configure the MSIG differently, and an alternate proposal:

I think the threshold for the owner permission should definitely be increased.

With the 48 hour time delay, this proposal would mean that only 5 of 11 people would need to collude to change ownership of the account. That is quite a low quorum for a change that could have huge detrimental effects on the community and greatly limit our ability to create value for everyone.

The eden.fractal account is valuable and it’s very important to build a stable environment for growth without disruption. I don’t expect that anyone would attempt to collude any time soon, but can imagine it happening if/when a contentious issue arises in Eden Fractal and ‘political parties’ form in the future (like we saw with the ESPx, for example).

We’ve only used the owner permission once before and probably won’t change it again for a while, so it’s best to ‘future proof’ it and make a more secure owner permission to provide a stable foundation for growth. This will enable us to cooperate more effectively with better game theory that reduces potential for disruptions or unhelpful drama. By increasing the threshold for the owner permission, we’ll also be in a better position to set a great example for all communities who’ll cooperate with the fractal consensus processes that we’re pioneering.

I think we should increase the owner permission to 8, 9, or 10. A threshold of 8 would require 7 of 11 (~64%) signatories to make a change. A threshold of 9 would require 8 of 11 (~73%) signatories to make a change. I’m thinking that 9 is probably the best balance of convenience and security, which I’ll explain further below. This would be more aligned with a 2/3+1 or 3/4 quorum like we use the Eden+Fractal consensus game. It’s also more aligned with the threshold ratio of the current owner permission and the 15/21 permission structure of EOS BPs.

Thoughts?

There are worse things that can happen to the eden.fractal account, such as directly creating new EDEN tokens or making an undesired code change without community consensus. It would also be bad if the community to lost access to the eden.fractal account and incurred a loss of reputation. We can raise a few thousand more EOS more easily than we can foster a great reputation that inspires confidence and excitement for the future of Eden Fractal.

I agree that we should secure the submitranks action and am considering whether we should increase the threshold of this action to 6, though I think it would be impractical and highly unlikely for anyone to try to drain the funds with the submitranks action in the near future. It makes sense for the active permission to have a higher threshold than the submitranks action because the active permission has more power than the submitranks action.

I also think we should keep Chuck on the MSIG. Chuck hasn’t been very active in the EOS community for the past six months… but he is a long-time, well-respected, talented, and trusted community member who played an important role in the foundation of Eden Fractal.

I don’t expect him to sign transactions in the near future, but I would think he would sign a transaction if we really needed it and at some point I imagine he’ll become more active in the community again. His presence on the MSIG doesn’t really negatively affect the community as I highly doubt that he’d act maliciously and we can easily adjust the threshold to account for his inactivity. On the positive side, his presence on the MSIG can provide some additional decentralization, security, and respect for the community.

Additionally, I think we should do the following:

These changes can provide several benefits:

To summarize:

I think we should add the six people above, remove only edenmsig1111, and set the following threshold weights:

Owner: 9

Active: 8

Custom Permission for submitranks: 5 (or 6)

When factoring in the 48 hour time delay, this would mean that the owner permission would require 8/12 signatories (67%), the active permission would require 7/12 signatories (~58%), and the submitranks actions would require 4/12 signatories (~33%).

I can make a proposal later today, perhaps after seeing some initial feedback. Thoughts?

No, it should be done at the same time. I am not comfortable with Vlad’s proposal and we did not agree to having a low threshold like that. There’s no reason to risk using such a low threshold.

I agree that the people in the MSIG have good intentions to contribution and collaborate, but the game theory is bad.

Imagine if the EOS MSIG only required 9/21 BPs to make any changes on EOS. It would be much less secure and trusted than the current arrangement of 15/21. EOS wouldn't be here if it only required 9/21 BPs.

That's similar to having only 5/11 MSIG participants with owner permission in Eden Fractal. It's a very risky arrangement for the community and we should absolutely not do that.

Bad system design incentivizes good people to do bad things.

I voted no on this proposal and highly advise increasing the threshold of the active and owner permission.

I think it would be very unwise for the community to approve Vlad’s current proposal with the active permission only requiring 4/11 signatories and the owner permission only requiring 5/11 participants. This would put the community in an unstable game theoretical position whereby small groups can exercise too much power over everyone else.

You can imagine the hazards that would arise if only 9/21 BPs could make any change on EOS and consider the similarities of this situation. We need greater security to provide a stable foundation for growth.

I agree that the people in the MSIG have god intentions to contribution and collaborate, but the game theory is bad.

Imagine if the EOS MSIG only required 9/21 BPs to make any changes on EOS. It would be much less secure and trusted than the current arrangement of 15/21. EOS wouldn't be here if it only required 9/21 BPs.

That's similar to having only 5/11 MSIG participants with owner permission in Eden Fractal. It's a very risky arrangement for the community and we should absolutely not do that.

Bad system design incentivizes good people to do bad things and reduces the community's ability to collaborate for mutual benefit.

Hey Vlad,

I think that changing the owner permission threshold to 6/12 would be a bad idea for the community.

After sending the messages about this in the Eden Fractal telegram chat earlier today, Patrick reached out to me and we had a long text chat. He wanted to approve your proposal and I sent him the following messages to reiterate why I think the threshold for the owner permission is too low. His messages are not included for privacy reasons so it might look strange but I think you can get the point.

Maybe I sound over concerned about it below but I started gaming out potential scenarios and I think that such a lower threshold does introduce a lot of unnecessary risk and it’s much, much better to use a higher threshold.

What do you think?

The status quo should be difficulty to change unless there is wide consensus. If only 5 people can change the account, then the system becomes less stable and easier for a small group to make big changes without community consent.

It’s the same reason why we require a supermajority of 15/21 BPs, 3/4 councils, or 2/3+1 agreement during fractally sessions. There should be a supermajority, not a minority, of consensus to make changes for the community.

Yes it makes the community more vulnerable to forking, which isn’t a good thing. What would have happened with EOS if we only required 9/21 consensus to make major changes last month when people were discussing the ESPx?

I imagine it could have caused a much larger riff in the community and may have split the community apart because each side could reach the 9/21 threshold. Because the 15/21 threshold is a supermajority, it provides incentive for the community to work together, collaborate, and find consensus in some mutually beneficial and cohesive manner.

If the owner permission is controlled by a minority, then it provides incentive for the community to split apart when there are disputes.

Forking can incur significant reputational cost. If a minority of community members decides to change the owner permission of the eden.fractal account, then they can change it however they want. They could remove me and you from the account, but continue to use the eden.fractal name.

For example, I invest a huge amount of time in building a helpful brand identity and promoting Eden Fractal with prosocial values. If the eden fractal brand gets damaged by a misaligned minority, then that can confuse all the work that I’ve done and disorient it into something else. That can look bad for our audiences and limit our ability create cohesive messaging to help everyone understand the benefits of these fractal consensus processes.

We’re the largest community cooperating with fractal cooperation. As such, we have a huge responsibility to set a good example and steward these consensus process in a way that inspires more communities.

I agree that it’s not necessarily bad and can be a good option in some situations, but it can also be bad in many situations

Btw perhaps the word collusion sounds too strong. It doesn’t need to have any malicious intent, just a result of different interests. A low threshold creates a moral hazard where a minority of people can make important decisions that affect everyone without much community consent.

An example that comes to mind is token liquidity. Many people in the community want the EDEN token to be liquid and many others do not want the token to be liquid. The stakes are high because it could potentially create a lot of value for people or put people in legal risk.

What if 5 people on the msig want to make the token liquid because they think that they can make a lot of money quickly, even if the majority of community members and delegates do not agree?

This is true and a good point. But the status quo should be more stable. Your proposal would require a minority to make any changes and a majority to veto.

The majority would have no recourse other than forking if 5 people decided to make a change against the will of the community.

Do you think that having a threshold for owner permission of 5/11 people is the optimal configuration for the community? Or do you think we should increase it to something like 6, 7, or 8?

I’d much rather not risk the delegates approving a proposal that could create big detriment for the community. Sometimes people want to make a quick change without thinking everything through clearly and I won’t necessarily be able to convey to everyone why I think it’s such a bad idea in a few minutes of speaking time during the meeting.

If we had another week then I could share the thoughts in a document that people could read and deliberate, but as it is delegates might just want to make a quick decision without fully considering the implications and I see that as a risk for the community.

It wouldn’t take much energy to agree on increasing the thresholds. What is the benefit of having such agility where 5/11 can control the owner permission without community consent?

. We can approve a proposal that was not previously proposed on Consortium and you can use your speaking time to introduce an alternative proposal

I initially supported it too because the beginning part is great, but saw flaws after thinking about the thresholds more deeply

I think the initial support did not think very deeply about the implications because other people aren’t as invested in the community

Yes it makes the community more vulnerable to forking, which isn’t a good thing. What would have happened with EOS if we only required 9/21 consensus to make major changes last month when people were discussing the ESPx?

I imagine it could have caused a much larger riff in the community and may have split the community apart because each side could reach the 9/21 threshold. Because the 15/21 threshold is a supermajority, it provides incentive for the community to work together, collaborate, and find consensus in some mutually beneficial and cohesive manner.

What would have happened with EOS if there were ESPx

One example that I can foresee is token liquidity. Many people in the community want the token to be liquid and many others do not want the token to be liquid. The stakes are high because it could create a lot of value for people or put people in more legal risk. If 5 people on the msig need money

Add here

Add discussions from previous meetings

TP34- Do you agree to configuring the eden.fractal account MSIG as follows?

1. Create custom permission for submitranks action. 2. Add accounts to all permissions: 2luminaries1 (Sebastian), machwireeden (Marco), grahappaaaaa (Perry), crypt.gm (Gavriel), cacedenoneos (Chris), gm3dgobzgage (Andrew). 3. Remove the following accounts from all permissions: chuckcd.gm (Chuck), edenmsig1111. 4. Set owner permission threshold=8, Active permission threshold=7, Custom permission threshold=5. Details in spreadsheet: https://docs.google.com/spreadsheets/d/16HY618Jkv3Uzu9xjgmRy_Gli6cIlq8hUHp0BU_AbSEM/edit#gid=0

TP34- Do you agree to configuring the eden.fractal account MSIG as follows?

1. Create custom permission for submitranks action. 2. Add accounts to all permissions: 2luminaries1 (Sebastian), machwireeden (Marco), grahappaaaaa (Perry), crypt.gm (Gavriel), cacedenoneos (Chris), gm3dgobzgage (Andrew). 3. Remove the following account from all permissions: edenmsig1111. 4. Set owner permission threshold=9, Active permission threshold=8, Custom permission threshold=5

Details in spreadsheet: