MSIG

Welcome

This article documents details, proposals and discussions about the MSIG (multi-signatory) configuration for the eden.fractal account that helps facilitate Eden Fractal meetings. This article covers basics of Antelope permissions, previous configurations, design considerations, FAQ, community feedback, and ten proposals to update the MSIG created by community members in early 2023.

In the future this article can help guide other communities who are configuring MSIGs for mutual benefit, though for now it is mostly focused on helping the Eden Fractal community decide how to better configure an MSIG in the near future. Please note that this article is a work in progress and will be updated soon. Enjoy!

Table of Contents:

• Welcome
• What is an MSIG?
• What’s the difference between active and owner permissions?
• Eden Fractal Meetings about MSIG
• EF 66: Permission Possible
• EF 65: Crafting Keys
• EF 64: Changing Community Keys
• EF 44: Automated MSIG Proposal
• EF 35: MSIG Updates and Fractalgram!
• EF 34: Updating the MSIG!
• Eden Fractal 32
• Proposals
• New MSIG Configuration
• What is the eden.fractal MSIG?
• What is the first configuration of the eden.fractal MSIG?
• Proposals to Update the MSIG
• EF 27: Patrick’s Immediate Proposal
• Vlad’s Third Proposal
• Dan’s Counter-Proposal
• Vlad and Tadas’ Suggestion
• Vlad’s First Proposal during EFBS 4 (Withdrawn)
• Dan’s Proposal to Include Chuck (Withdrawn)
• MSIG Proposals and Suggestions Spreadsheet
• Recommendations from Early 2023
• Summary and Next Steps
• Increase the Weight of eden.fractal@EOSIO.CODE and Remove it from Active/Owner Permissions
• Change the weights for the time delay?
• Configure Owner Permission with Threshold Weight of 8
• Configure Active Permission with Threshold Weight of 7
• Configure ‘submitranks’ Custom Permission with Weight of 5
• Explore Automated MSIG Solutions
• Design Considerations
• How should MSIGs be designed?
• Worst Case Scenarios
• Game Theory, Incentives, and Stability
• Moral Hazards
• Supermajority Consensus and Maintaining the Status Quo
• Forking: Eden Smart Proxy Analogy
• Reputational Costs of Forking and Responsibility to Lead
• Potential for Collusion, Moral Hazard, and Liquidity Example
• Collusion to Veto
• FAQ
• How have the Eden.Fractal account permissions been used so far?
• How was the Eden.Fractal MSIG created?
• What are the responsibilities of a signatory?
• What is the time commitment of being a signatory?
• Community Feedback
• Marco’s Thoughts
• Pascal’s Thoughts
• Perry’s Thoughts
• Tadas’ Thoughts
• More Feedback
• Related Resources
• Eden Fractal Meeting 32
• Eden Fractal Meeting 34
• Eden Fractal Brainstorming Session 4
• Consensus Results Channel
• Permissions Article
• Admin Documentation

What is an MSIG?

MSIGs, or multi-signatory arrangements, are a vitally important and profoundly helpful tool that enable communities to flexibly share permissions for actions on community computers (such as EOS or Ethereum).

In the future this article will be expanded to provide a better introduction and overview of MSIGs, but for now the scope of this article will be directed to people who are already familiar with EOS MSIGs. For more details about MSIGs, you can explore the Gnosis Safe website or EOSIO developer documentation. You can also watch videos here or here for a quick overview about MSIGs:

What’s the difference between active and owner permissions?

The owner permission can change anything on the account, including the owner permission. Excepting EOS BPs, the owner permission has ultimate root access to all actions on the account.

The active permission can change anything on the account except the owner permission. This includes an infinite variety of actions, such as executing any existing action, transaction, or coding a new action in the software. For example, actions on the account could change the Eden+Fractal game rules, the scorecard and attributes of EDEN points, or add entirely new functionalities to the account. You can see the actions installed on the account here.

You can hear a description about the differences between the active and owner permissions on the eden.fractal account here. You can also watch the following video for a more general introduction to the EOS permission system.

Eden Fractal Meetings about MSIG

The Eden Fractal community has engaged in many thoughtful discussions to pioneer community permissions for everyone’s benefit. You can watch full episodes and explore show notes about these Eden Fractal meetings in the links below:

EF 66: Permission Possible

Hip hip hooray! Our mythical heroes approved three proposals to update the eden.fractal permissions and explored an introduction to the Optimism Collective, a new type of community designed to reward public goods and build a sustainable future for all 🌞 🔴

EF 65: Crafting Keys

How can a community securely express consensus? Our band of heroes discuss account permissions to create an abundant realm for growing digital public goods 🪴 🧑🏽‍🌾

EF 64: Changing Community Keys

How can communities create order while increasing independence? We endeavor through the wild to determine the configuration and key holders for the eden.fractal msig account 🔐 🐵

EF 44: Automated MSIG Proposal

New tools! Vlad proposed to update the community account with software he built to automatically change the MSIG based upon weekly rankings! 💫

EF 35: MSIG Updates and Fractalgram!

Tadas releases the new Fractalgram app and the delegates approve two proposals to reconfigure the eden.fractal MSIG! The new configuration includes six new signatories, smart time delays, and a custom permission! 🔑

EF 34: Updating the MSIG!

Eden Fractal MSIG, Part 2! After playing Eden+Fractal, the group engages in the second comprehensive MSIG conversation with three proposals to update the eden.fractal account permissions 🔐

Eden Fractal 32

We discuss the MSIG. Vlad & Tadas release app updates. Patrick funds Eden builders. Eric launches an art fractal. Perry announces dNews plans. Go Eden! ⚽️

Proposals

New MSIG Configuration

The following MSIG configuration was approved by Eden+Fractal delegates. Patrick introduced a proposal focused on the signatories at 1:07:52 and it was approved at 1:24:35. Tadas introduced a proposal for the full configuration at 1:31:01 and it was approved at 1:59:02. You can see an IPFS document with the proposal here.

The new configuration includes six new signatories, smart time delays, and a custom permission. The new signatories are Andrew, CAC, Gavriel, Marco, Perry, Sebastian, and Tadas. The time delays provide counterbalances between the various permissions to optimize both convenience and efficiency. The custom permission enables the ‘submitranks’ action to distribute respect each week. You can see the sections below to learn more about the design of this configuration.

Between Week 27 and Week 34, there were six or seven proposals to update the eden.fractal MSIG. Some of the most notable proposals are shown and summarized below.

What is the eden.fractal MSIG?

The Eden.Fractal MSIG is the arrangement of keys and people who have permission to change the eden.fractal EOS account. You can see this account and current arrangement here.

What is the first configuration of the eden.fractal MSIG?

The current MSIG includes 6 people and a 48 hour delay, with different thresholds for active and owner permissions. You can learn more about this configuration in the sections below and in the FAQ at the bottom of the page.

Proposals to Update the MSIG

EF 27: Patrick’s Immediate Proposal

In the 27th Eden Fractal meeting, the Eden Fractal council approved an immediate proposal from Patrick to improve the eden.fractal MSIG configuration. The proposal simply asked whether delegates wanted to update the MSIG and did not specify details about how it would be configured.

You can watch Patrick introduce this proposal at 1:04:48 in the following video and see the timestamps in the video description for an overview of community discussions about the proposal.

Vlad’s Third Proposal

In the 34th Eden Fractal meeting, Vlad made a proposal to configure the MSIG in the following way:

You can watch Vlad introduce this proposal at 1:17:27 in the following video and refer to the timestamps here to see community discussion about the proposal.

You can see Vlad’s message announce this proposal about here:

Dan’s Counter-Proposal

In the 34th Eden Fractal meeting, Dan made a proposal to configure the MSIG in the following way:

According to Dan’s telegram post, the most important differences from Vlad’s proposal are:

1. increasing the threshold for the active permission
2. increasing the threshold for the owner permission
3. creating a custom permission for ‘submitranks’ action

You can watch Dan introduce this proposal and provide a comparison with Vlad’s proposal at 1:33:02 in the following video.

You can also see messages from Dan with feedback about Vlad’s proposal and reasoning for his proposal here:

Vlad and Tadas’ Suggestion

Towards the end of the 34th Eden Fractal Meeting, Tadas suggested a different configuration with threshold of custom permission at 5, active permission at 6, and owner permission at 7. Vlad agreed amd suggested voting on this as a proposal at the end of the meeting, but the group decided to save the voting for the following week after another brainstorming session. You can see some discussion about this at 2:03:50 in the video below.

Vlad’s First Proposal during EFBS 4 (Withdrawn)

Vlad made the first two proposals to specify the MSIG configuration in mid-January, 2023. Vlad, Patrick, Tadas, Dan, and CAC discussed Vlad’s first proposal in detail during the fourth Eden Fractal Brainstorming Session. Vlad withdrew the proposal after hearing feedback in the discussion, then he also proposed and withdrew another iteration of the proposal in the following days. You can watch the full video and navigate timestamps for discussions about the first proposal in the video description.

Dan’s Proposal to Include Chuck (Withdrawn)

During Eden Fractal meeting 34, Dan advocated for including Chuck in the MSIG and this telegram post. This proposal did not receive much support and several community members expressed that they thought Chuck should not be on the MSIG because he hadn’t participated in the community in a long time. Dan withdrew this proposal after hearing community feedback.

MSIG Proposals and Suggestions Spreadsheet

The most recently created proposals and suggestions are curated on this spreadsheet in a visual table view. For your convenience, screenshots of the three most recent proposals and suggestions are shown below:

Recommendations from Early 2023

We wrote this section of the article in preparation for the 5th EFBS and 35th Eden Fractal meeting where the delegates voted to change the MSIG. It provided the following recommendations for the eden.fractal MSIG, as well as design considerations to provide additional reasoning in the next section.

Summary and Next Steps

Going into the fourth brainstorming session, it appears that the most important decision remaining for the configure the eden.fractal MSIG is how to threshold weight of active and owner permissions.

To summarize developments so far:

• Everyone seems to be in agreement about who will be signatories on the MSIG. The latest proposals include five new signatories: Andrew, CAC, Gavriel, Marco, Perry, and Sebastian. The proposals remove Chuck and the edenmsig1111 account from the MSIG. The group queried for objections about who will be on the MSIG at the end of meeting 34 and no objections were raised, which you can see here.

• Vlad supported Tadas’ suggestion to create a custom permission with a threshold of 5 and configure the active and owner permissions to a threshold of 6 and 7, respectively.

• Several communities members, such as Perry, Marco, and Dan, have voiced opinions to increase security with higher thresholds. Several community members, such as Vlad, Pascal, and Tadas have voiced opinions to increase agility with lower thresholds. You can see community members share these opinions in the preceding hyperlinks or community feedback section below.

• You can see a summary of these configurations with summary below:

• We shared many reasons to use a higher threshold below, but we also see value in the agility of a lower threshold that can prevent collusion to veto or getting stuck with inattentive signatories.

• Ultimately there may not be a significant difference between either threshold configuration. Both solutions have potential failure modes and could be at least partially remedied via forking.

• As the MSIG plays an important in community cooperation, we see value in exploring the design space and increasing understanding. This can be helpful for both our current community and many other communities in the future.

• As a general sidenote, this discussion exemplifies the community’s growing ability to reach consensus about more detail proposals. This discussion has many more variables than our original proposals.

• We’re looking forward to further discussions help Eden and all communities thrive with helpful permission structures!

Increase the Weight of eden.fractal@EOSIO.CODE and Remove it from Active/Owner Permissions

In order for the eden.fractal account to operate, I think that we need to increase the weight of EOSIO.code from 3 to 5. I just thought about this and am not sure.

I’m also thinking that we should probably remove the eden.fractal@EOSIO.CODE account from the active and owner permissions to provide additional security. If there are any code malfunctions, could this compromise the security of the account by having this on the active and owner permissions?

What do you think?

Change the weights for the time delay?

Configure Owner Permission with Threshold Weight of 8

Dan shared the following messages suggesting a higher threshold for owner permission in response to Vlad’s proposal:

Configure Active Permission with Threshold Weight of 7

Dan shared the following messages to express benefits of configuring the active and custom permissions in the following ways:

Configure ‘submitranks’ Custom Permission with Weight of 5

During the fourth Eden Fractal Brainstorming Session, community leaders discussed creating a custom permission that only has capability to execute the ‘submitranks’ action. This action is executed each week to distribute respect. You can watch this discussion here and see a message from Dan about this below:

Explore Automated MSIG Solutions

The Eden Fractal community has often discussed the idea automating the MSIG to change as new delegates are elected to councils each week. This could be implemented with the Eden Election software developed by Edenia. You can watch a discussion from meeting 34 about the potential for automated MSIG solutions with the Eden+Fractal delegates here. You can also watch an earlier discussion about this topic from week 27 here.

We recommend that the community explores this option in the near future, but warn that there could be significant risk in trying to change too quickly without sufficient deliberation. We encourage the community to exercise care to make sure that any change to theMSIG is considered thoroughly with a deep analysis of potential implications to make the best experiences possible.

Design Considerations

How should MSIGs be designed?

There are many important design decisions to consider while configuring an MSIG. MSIGs for account permissions play an important role in community cooperation and should be carefully considered from many perspectives to make the best experiences possible.

For example, MSIGs should be designed with an appropriate balance of security and convenience. If a threshold is too high, then it may be too difficult to make a helpful change to the account. If the threshold is too low, then the game theory could incentivize behavior or ‘attacks’ that are detrimental for community members. You can watch a recent discussion about this from meeting 34 here.

The following sections aim to provide an overview of some design considerations and recommendations for the eden.fractal MSIG. As with the rest of the article, these considerations and recommendations will evolve and may also be helpful for other communities in the future.

Worst Case Scenarios

Vlad and Dan shared the following messages analyzing the worst case scenarios for the eden.fractal account if the keys were compromised. You can see the Vlad’s message about this and Dan’s response below:

Game Theory, Incentives, and Stability

Dan shared the following message in a private conversation with Patrick to express the importance of increasing the threshold of the owner permission.

Moral Hazards

You can read an excellent overview of moral hazards in More Equal Animals, the seminal book from Daniel Larimer that inspired Eden. You can read the chapter about Moral Hazards here. For your convenient preview, the first page of the chapter is included below:

Supermajority Consensus and Maintaining the Status Quo

Dan wrote the folllowing message in a PM to Vlad.

You can also watch Pascal and Dan discuss pros and cons of the status quo, stability, and agility here:

Forking: Eden Smart Proxy Analogy

In a private conversation with Vlad, Dan wrote the following:

Yes it makes the community more vulnerable to forking, which generally 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.

Reputational Costs of Forking and Responsibility to Lead

In a private conversation with Vlad, Dan wrote the following:

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.

Potential for Collusion, Moral Hazard, and Liquidity Example

In a private conversation with Vlad, Dan wrote the following:

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?

Collusion to Veto

Dan and Vlad shared the following private messages about how high thresholds cause incentivize collusion to veto changes:

Vlad’s message:

Dan’s Message:

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?

FAQ

How have the Eden.Fractal account permissions been used so far?

So far the active permissions has been used on a weekly basis to execute the submitranks action and distribute respect to participants. Other than that, the active and owner permissions have only been used a few times in the beginning of Eden Fractal to set initial software configurations.

How was the Eden.Fractal MSIG created?

The eden.fractal account was originally created by Eden Creators to help start Eden Fractal. Within the first few weeks of Eden Fractal meetings the MSIG was decentralized to several community leaders. Soon we’ll add videos where you can watch discussions about this. Here are some messages where this is briefly explained:

What are the responsibilities of a signatory?

There are no formal responsibilities or obligations, but there are expectations from the community to keep the account keys safe to provide a stable environment for the community to grow and sign weekly transactions as needed. You can hear an explanation of the role of a signatory here.

What is the time commitment of being a signatory?

You can watch a discussion about the expectations for time and responsibilities of signatories here.

Community Feedback

Marco’s Thoughts

Pascal’s Thoughts

During week 34, Pascal voiced an opinion to increase security with higher thresholds. You can watch this here.

Perry’s Thoughts

During week 34, Perry voiced an opinion to increase security with higher thresholds. You can watch this here.

Tadas’ Thoughts

During week 34, Tadas voiced an opinion to increase security with lower thresholds. You can watch this here also see discussions about his alternate suggestion above.

More Feedback

Many community members shared thoughts about the eden.fractal MSIG throughout Eden Fractal meetings #32 and #34. In the future we will curate more thoughts from community members here. For now you can explore the show notes of each episode to see more feedback from community members. More coming soon!

Related Resources

In addition to the other resources shown above, the community engaged in detailed discussions about the eden.fractal MSIG during the second hour of meetings #32 and #34. You can watch the videos and see show notes about each conversation, as well as other helpful resources, below:

Eden Fractal Meeting 32

We discuss the MSIG. Vlad & Tadas release app updates. Patrick funds Eden builders. Eric launches an art fractal. Perry announces dNews plans. Go Eden! ⚽️

Eden Fractal Meeting 34

Eden Fractal MSIG, Part 2! After playing Eden+Fractal, the group engages in the second comprehensive MSIG conversation with three proposals to update the eden.fractal account permissions 🔐

Eden Fractal Brainstorming Session 4

January 17th, 2022- We were focused on MSIG Proposal, what is it? Find that and more in this session. Here is the link to the MindWeb MindMap.

Consensus Results Channel

Consensus results are posted each week in the Consensus Results channel of the Eden Discord. If there are discrepancies in the data, an analysis is also provided along with recommendations for proceeding. You can reach out in the discord and telegram group with any questions or comments.

Permissions Article

You can see a draft article about permissions here. Much more coming soon!

Admin Documentation

You can see documentation to help signatories operate Eden Fractal software here. More coming soon!

This page is a work in progress and will be updated soon. Thank you for reading!