[Discussion] Defining the IOTA Governace proposal proccess and lifecycle

[Phylo]

Lifecycle of a Governance proposal

As we as a community and a project move forward into a new era of token utility, smart contracts, and possibilities, I hope we can start to define our processes to enable community participation and decision making in IOTA, Shimmer, and the upcoming Assembly network. In my opinion, we need such structures and processes to find common ground on governance and establish an efficient method for everyone to propose changes to the project’s current state.

I have spent the last 12 months mainly researching governance and DAO models of dozens of projects in the DLT space. Some have established good models. Others have dramatically failed. Some have created an environment that welcomes participation and makes it easy to access. Others have created “governance monsters” without practical use for their communities. I want to start introducing my ideas based on the finding and observations of other projects and propose guidelines and structures that I believe will allow us to make effective governance decisions in the future.

This proposal aims to define a structure of what community governance proposals in the Shimmer network should look like. Giving everyone the option to propose ideas and every stakeholder in the network to participate in the decision-making process is the primary goal of this proposal.

Learning from other projects that have implemented community-driven governance processes in different stages and with different outcomes and successes is essential. I believe that a staged process of defining an idea around changes, giving the community a chance to suggest changes and additions to the concept, the ability to signal support, and finally reaching consensus via voting is crucial, in my opinion. Governance should not be rushed, but it should also not slow down or hinder needed changes in a protocol.

Some parts of this post rely on things that may change in the future, especially around the voting functionalities and metrics defined here. We must design a process that allows adjustments on the way if we see that certain aspects do not play out as intended. The beauty of the upcoming Shimmer network is that we as a community can also try out these things around governance before we would implement similar systems in the IOTA protocol.
I also do not intend to use this governance process to implement technical changes in IOTA’s core protocols or frameworks. For this, the research and engineering Team of the IOTA Foundation has implemented the TIP Proccess to suggest changes on a technical level.

My post and this process is aimed to be implemented in the Shimmer network first. Later, we can then use our learnings to develop the governance structures around Assembly and IOTA.

Please see this all as suggestions, ready to be adjusted. I welcome everyone to work together on this process.
So following the idea laid out further below, I tag this post as a phase - 1 discussion, which will hopefully receive some good input and evolve into the final structure we aim to use for our governance process.

Proposal Process

This forum here should serve as the main host of our governance process and be used to move a proposal through Discussion phase - 1 and Temperature check phase - 2 to a potential implementation Voting phase - 3, finally conducted with on-Tangle votes based token ownership. Leveraging the functionalities of the already developed Firefly Governance feature used in the upcoming Build vs. Burn vote.

For a governance proposal to be accepted and implemented, it must successfully pass through these three phases:

Phase 1 - Discussion

Initiates the start of a proposal’s lifecycle. Anyone should be able to step forward and propose a change. Getting feedback on an idea, adapting it, and including input from others is the primary goal of a phase - 1 post. The outcome of this process should be a defined and specified proposal ready to be put up for a community vote.

Requirements:

• Discussion post created in the governance forum under the respective category tagged with phase - 1
• Proposal Duration: open-ended
• Adding a polling option is not a requirement in this initial phase
• There is no formal requirement for proposals to pass from phase - 1 to phase - 2. However, if a phase - 1 proposal discussion fails to pick up momentum from the community, it is unlikely to become a successful proposal. The initiator may use this phase to gather interested followers and define details and comments to help the proposal in phase - 2 gain the required majority in polling conducted in phase - 2 of the proposal lifecycle.

Phase 2 - Temperature check

A solid and specified proposal has been developed, considering suggestions that have been raised in phase - 1. The initiator feels confident that it includes everything needed to be implemented in the project. A successful poll conducted by the members of the governance forum signals support and confidence that the community will accept it in an upcoming public vote in phase - 3.

Requirements:

• Governance Proposal post created in the governance forum under the respective category and tagged with phase - 2. The proposal contains a Poll including the option “Make no changes”
• The proposal uses the provided proposal template for governance proposals (see below). The proposal template requires all submissions to speak to relevant fields, such as a Simple Summary, Abstract, Motivation, Specification, and Implementation.
• Duration: 7 days
• For proposals to successfully pass from phase - 2 to phase - 3, a relative majority of votes must be reached for one option on the forum poll. If the relative majority of votes on the forum poll indicates the result, “Make no changes”, the proposal will not pass to Phase 3.

Phase 3 - Voting

The final decision if a change shall be made is conducted in a Sybill protected and transparent vote. Currently, the only feasible option supported by the IOTA protocol is a vote based on token holdings (1000 IOTA tokens = one vote). This method can be adjusted in the future by governance decisions, should other secure voting methods be developed and implemented in the protocol. The current process created for the Build vs. Burn vote has already some functionalities implemented to protect the vote from the influence of short time speculators by using a time-based build-up of voting weight.
In this phase, all needed on-chain preparations must be in place before a phase - 3 proposal gets published. This includes explicitly creating a participation event by the initiators to be implemented into nodes making the vote possible. This is based on the specifications designed for the Treasury vote. The event needs to be merged into the respective Github branch reserved for participation events before Phase 3 can start so that node operators can implement it from there.

Requirements:

• Governance Proposal post created, tagged with phase - 3.
• The post contains the exact text that received the majority of votes in the proposal poll conducted in phase - 2. It also directly links the “on-tangle” vote execution. This execution might be directly performed via a deep link, opening a voter’s Firefly Wallet, or it may lead to a web interface that provides the voting functionality.
• (If used) A respective voting proposal is created in a voting application (web interface). The proposal in the application contains a direct link to the phase - 3 proposal in the Governance forum.
• A participation event created in Github (repo to be defined) containing the exactly defined binary for the vote following the specifications defined in the Treasury vote process
• The vote options must contain the option “Make no changes”
• Duration: The created participation event used in the vote must contain a three days announcement period to include the new event by the node operators, a maximum seven days pre-vote period to conduct the vote, and a 7 - 14 days counting period (variable choice by the proposal creator)
• For proposals to pass the vote successfully, there must be a result with a relative majority of votes counted, accompanied by reaching a yes-voting quorum of a minimum of 5% of maximum possible votes (based on the circulating supply of the used asset & defined counting period).
  If the relative vote majority achieved in the vote indicates the result, “Make no changes", the proposal will not be accepted and considered closed.

Governance proposals require a Forum admin to check if the requirements are met to move them through the different phases and publish a post under phase - 2 and phase - 3 tags.

Governance post template

This is a suggested template for proposals in the governance forum. It would be required for proposals in phase - 2 and phase - 3 of the process. The purpose is mainly to provide a unified structure so that proposals follow a defined form.

Simple Summary

• If you can’t explain it simply, you don’t understand it well enough. Provide a simplified and layman-accessible explanation of the suggested change

Abstract

• A short (~200 word) description of the issue being addressed.

Motivation

• The motivation is critical for proposals that want to allocate funding or change the Governance process. The admins may reject proposals without sufficient motivation outright.

Specification

• The specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow for it to be reasoned about by the community.

Rationale

• The rationale clarifies the specification by describing what motivated the design and why the proposer made particular design decisions. It can describe alternate procedures that were considered and related work. The rationale may also provide evidence of consensus within the community and discuss significant objections or concerns raised during the discussion.

Implementation

• The section should include or describe any dependencies of the implementation and potential timelines. What is needed to consider the process finalized and implemented?
• Needs to contain links to the respective resources for the on-chain vote, specifically a link to the participation event in Github (only required in phase - 3 proposals)

Proposal vote link

• Direct link to the vote execution via a deep link or link to the web interface for vote execution (only required in phase - 3 proposals)

The way forward:

I hope we can start working together here on this process. I would collect suggestions from the comments and adjust this post where it seems reasonable over the following days. Once we think the process is well designed, I’ll create a phase - 2 post and open it up for a community poll.

Thanks everyone for reading and I hope to hear some good comments on that topic here.

[HyperMindz]

This is an incredibly thoughtful and thorough proposal Phylo!

The amount of time and research that you’ve put in over the past year shines right thru. I was actively trying to find holes or deficiencies in it and came up empty handed.

But I do have one question, one that might not be of concern at this time and might already have an answer/solution which I’m not aware of, but it relates to the implementation of proposals once it’s been decided to move one to Phase 3.

With my limited knowledge of running a node, my understand is node operators are to implement each proposal once it has gotten to Phase 3. My questions is, when does the proposal get implanted to be voted on and is there a time frame that needs to clear so multiple proposals are added all at once?

For instance, would node operators be implementing multiple proposals that have passed to Phase 3 once every month, quarter, 6 months or year? Maybe if having predetermined votings dates the community as a whole knows when voting takes place and then can vote on multiples proposals at once. It seems it would be an efficient way to handle voting and to get more of the community to vote on proposals.

This might already be thought out or talked about / proposed but I wanted to add the only thoughts I had in regards to this proposal.

Great work and look forward to using this format.

[Phylo]

Thanks a lot for your reply, great question, and input!
So about the implementation of proposals in the nodes:

• it is not difficult to do it as a node operator. The hornet dashboard offers the ability to upload participation events to a node.
• Having proposals tracked by many nodes is, of course, a great addition to having checks in place when it comes to important decisions, so we would hope that many community members track the progress.
• to make a proposal “voteable” in Firefly for an average user, the participation event would need to be uploaded to the nodes Firefly connects to. These are currently the nodes run by the IOTA Foundation and the nodes run by Tanglebay. I think it is reasonable to say that the nodes run by the IF would implement important proposals of interest to the whole community. I assume that our Team would be able to do this in the defined 3 days timeframe before a vote will be accessible in Firefly.
• Thinking forward, it is also very likely that proposals are being voted by individual teams or projects that have created their own tokens once we have Tokenisation on Mainnet / Shimmer. This may then happen totally independent of IF nodes. Basically, users need only to know to which node they need to connect their Firefly Wallet in the network configuration to vote on such proposals. The Teams would need to provide these nodes by themselves and tell voters how to connect to those nodes. I also can imagine that projects like Soonaverse may offer an easily accessible set up for such occasions so that normal users won’t have to bother with the technicals.

The idea of having predefined voting dates/times:

• Absolutely like the idea. You are very right. If we had several proposals at the same time that would all start on different days, it might confuse users and will likely be bad for overall participation.
• The IOTA Content Creator DAO has implemented this concept already with their Voting weekends, and I really like the approach. So yes, I think it would make sense to have a predefined starting point for proposals (maybe every second weekend of a month) and collect them so that voters have then only the burden of taking the time to read up on the ideas and vote once a month.
• I think we should definitely include this idea in a future version of this proposal before moving it to phase - 2

[Saurabh]

Reject.

We don’t need governance.

I propose ungovernance which is eliminating the need for governance.

DLT pilot teams are expected to deliver a DLT, the ability to issue tokens and a wallet where assets can be stored. IOTA Foundation are the pilot team here, they should do that and not try to govern the ecosystem. It will evolve with community participation. People will create their own token economies and governance systems.

At a DLT level, foundations, governance etc. are not required. It should be open to all.

PoW is better suited for ungovernance. When tech is updated, miners test it and deploy it. If 51% update, network is upgraded. There is natural progress. There is no need at all for governance.

I have noticed some people like Charles Hoskinson like wealth and fame. He has bought a ranch and is proud of his Twitter and YouTube following. IOTA co-founder Dom has also publically admitted to admiring centralists like Michael Dell. He wants to be a hero. I don’t blame them for wanting to be successful and this is ok if you want to start a project but these desires will have to be sacrificed if you want to set up an open to all DLT.

There is a reason why Bitcoin founders chose to maintain a low profile.

If there is a governance mechanism, it will come with its set of problems. The first is the ability to influence and restrict participation. On platforms like Tezos you need minimum 600 XTZ to get a vote. Many people outside US and Europe cannot afford it. Some platforms like Algorand let you vote even if you have 2 Algos but it is meaningless. They pick which proposals should be voted on and indirectly tell you which option to choose. Who did they ask before buying Napster?

Why get into such complexities? Keep it simple. A decentralized platform, the ability to issue tokens and a mobile wallet. Do this and after that if you want to become a builder on IOTA, that’s fine.

[iota12345]

Thank you Holger-Phylo for this research!

I have a few observations:

1. We don’t want to make every single small issue something that needs to be voted on by everyone. That would make development grind to a halt and nothing would get done.

2. I like the suggestion by HyperMindz of having pre-determined voting dates. This will make people focus and make developers work to a deadline, pushing progress forward.

3. People who do not have expertise in coding/ IT development should not be voting on such issues. Perhaps a few representatives should be elected to make decisions about such things.

4. We should not all have to pander to a few noisy characters shouting loudly about something they disagree with. Some changes just need to be pushed through.

5. The things most people seem to get prickly about is how money is spent and how tokens are allocated. That is what will need the most oversight, transparency and audit. I certainly think that the more mana one holds, the more voting power one should get because that holder is taking more risk.

[Phylo]

Great input, thanks. I think I can agree with you on most of your topics.

• The governance process should be designed to avoid this “voting everyone on small issues”. So if someone proposes something in phase - 1 that no one else is interested in, it will very likely fail already in phase - 2 without making it to a vote. We could define a minimum requirement in participation in a poll or even a minimum amount of received likes in phase - 1, and of course, the admins can filter out obvious spam. Especially if we would see that obvious reasonings and motivations would not exist as defined in the proposal template, we should not forward this to an on-chain vote. But for sure, this can be better defined and made more clear.
• I excluded any proposal that requires coding/developer skills from the governance process. As I described in the introduction, these things are in the hand of the IOTA Foundation, and changes in these technical things would require passing the TIP proccess. One day, if the community and the Foundation agree on it, this may be eased and the scope of governance progressively widened into core protocol decisions, but we are currently not there.
• and as you also already mentioned, I see this process first implemented in a potential community Treasury and general decisions around Tokenomics/Strategy like the suggestions made by Dom and Kappy here in the forum already. We should not try to vote on specific implementations of Coordicie etc.
  So governance will need to grow together with the community. And it always needs a system of checks and balances in place. Pure rogue “decentralize everything” is not how I envision this process. A middle way seems reasonable, and we just need to define the boundaries within which we tend to operate it.

[DLTimes]

I can only agree with the previous speakers, thank you very much for this extensive proposal and your invested time!

I think your ideas are very good and I hope that they will also form the cornerstone of the governance structure.

However, I have a practical question.

In the last few days I have repeatedly dealt with the procedures of Terra/Luna governance.

The process from ideation/discussion to voting is very similar, however there was one situation today that I don’t think should have happened.

I’ll explain what happened with a short example:

Person A has an idea and it is discussed (phase 1).

This results in a formal proposal with a rough vote (phase 2).

The proposal makes it to the final stage and there is an official vote with a time of 7 days.
On Day 3 of the election, we will receive new information in the community.
Basically, the proposal from person A is good, but small things should be changed.

In the example given, Person A changed Luna’s proposal and the election continued.

Eligible voters can change the decision during the election period.

Advantages of this method:
The lengthy process from collecting ideas to voting is not completely ended.
The proposal remains flexible and a quick decision is still possible.

Disadvantages of this method:
Not every voter expects that the proposal can still be changed and does not deal with the topic on a daily basis throughout the election period.

The outcome of the election may be falsified.

In my opinion, any change to a proposal that is in phase 3 should lead to cancellation and be downgraded to phase 1, even if it makes the process more lengthy.

This would most likely make proposals more well thought out.

I’m still very curious how you think about it and I would be happy about your ideas.

[Phylo]

Thanks, these are very good questions. And nice to hear a case from a real-life issue.
I agree with you. An ongoing vote that has reached Phase 3 should not be possible to change during the voting period. Actually, as our votes will happen on the Tangle using Firefly and the nodes, it cannot be changed once it reaches this stage. Only if all node operators agree to the change (very unlikely). I believe that it definitely also needs a cooldown period of maybe 3 days after a vote has finished before anything gets executed. In this timeframe, the last effort to change/stop things can be made by the community if something is revealed that was not publicly known once the vote started.
In this case, a new proposal could be brought up (maybe directly in Phase 2 if it is urgent) to implement the needed changes.
Many projects have things like this in place. Either be it an emergency council that could stop buggy code from being implemented or an emergency motion from the community that could be started to counter the decisions in the vote. We should also define the process for such actions, and I will include ideas for this in an updated version of the proposal here.
It needs to be very well thought through. It is a fine line between legit emergency actions of a community and invalid influence in a democratic process. This needs to be well defined. Of course, introducing a rather centralized part of a committee or guardians has some issues also. Still, I think a strong community that takes care of governance can establish persons in place who would not use this power outside of emergency situations. We have seen many projects in Defi that have been drowned and destroyed due to not having such a cooldown period or emergency motion process in place. Smart contracts are a great way to define such fail-safe mechanisms. And if they are designed in a good manner (giving an actor the chance to stop a dangerous action, but not to execute anything that would access crucial security or treasury functions)
Very good input. Thanks for that.
I’ll work on an updated version of the proccess over the weekend.

[Deep_Sea]

Great work Phylo in initiating this discussion and creating some activity. A few things I want to clarify before giving my response.

1. I couldn’t pin point if this was governance framework for possible protocol issues (ie: changing the token supply) or strictly for something like a Treasury governance. Maybe changing the token supply isn’t necessarily a technical protocol change as in, “implement all Coordicide modules now before they are technically completed”. I wonder if there is some terminology that better fit’s a vote like, “change the token supply”, and doesn’t indicate “implement Coordicide early”. Saying the above, I think this is great! and see it working somehow with a Treasury.

2. Just a note to others in regards to this suggestion being a control mechanism that the IOTA Foundation is trying to govern the Shimmer ecosystem. I see Phylo’s suggestion as a suggestion from a community member. Something to be discussed by the community, built by the community, and approved by the community. Indeed, for now, the IF needs to control the technical implementation of Shimmer (ie: Coordicide module implementation), but outside of that, we the community should be building the governance structure that will make all the other decisions.

So, I really like the process based in steps and it seems very clear. One question I have is, “what is the majority” in phase 2? Such as, what would constitute a majority? My suggestion is that potentially an average active voters in previous 6 month of voting be used. Then some percentage of that number be a basis to be considered “a majority” and proceed to Phase 3. I have heard of other DAOs having issues where proposals are submitted on New Year’s Eve (or some holiday) when there is no active participation and the “majority”, essential becomes so low that they and a group of others can push a proposal forward with no friction.

I’m definitely a fan of a standard submission format for submitters. Maybe we can have different templates for different categories. For example, a proposal submission that seeks to have a vote on changing the total token supply easily can use the proposed format (ie: Summary, Abstract, Motivation, etc.); however, a Treasury Funding proposal may need something a bit more specific. Such as, Milestone completion deliverable, technical details, etc. Of course that can be developed at a later time.

Lastly, I think an Emergency Halt button to the process is a good idea. I know other protocols have this and requires some large amount of vote to initiate it. Where there is some parameter that if things look like they have gone askew, either with insider corruption or smart-contract execution, the community can easily vote and create an all-stop. Like a kill switch. Then, maybe some period of time in which the community can assess the situation, propose either to conduct a solution or leave things be. Upon which the community can have a vote. If a solution was voted for, then that solution is executed. If the vote concludes with, “let things be”, then things run on as normal.

Last last thing. I found it interesting what DLTimes mentioned. I wonder if, in the case of a funding proposal for example, that the Smart-Contract can issue a request to the grantee. It may be something like, “Your proposal and terms have been accepted by the community. Do you want to proceed with funding as proposed in the proposal?” So if in the off chance something changed, the receiver (grantee) can reject the proposal and go back to Phase 1. Or, for more protocol governance structure proposals, a certain amount of votes (being a large amount) can stop a vote in process. Like in the case of a scenario change and the proposer wanting to go back to Phase 1.

I hope to see more activity here because we as a community really need to get active in discussions and then start really building something.

[Phylo]

Amazing JD, thanks for the detailed reply.

[Deep_Sea]

Just one thing about Governance discussion as a community I think we should consider. In the example of Kappy’s 20% supply increase, he put a vote on Govern.Iota.Org website which shows 80% for the [20% increase] and 20% for [do nothing]. Yet, when I put a similar vote on Twitter, the response is very different. With 45.9% do nothing and combined, 54% do an increase.

I really enjoyed the different votes we did for the “Build vs. Burn”, polling in different social mediums. Generally all concluded with about a 75% to 85% for Build and 25% to 15% for Burn. Which the actual Firefly vote came in nearly what the polls were showing.

So given I’m seeing a difference in the Govern.Iota.Org with that of Twitter, it might be good think now, how the communications mediums best support a community wide consensus and reach. I think this website (govern.iot.org) is a great first step, I just wonder if there are other process implementations we can include which expand the discussions to include a broader audience. Or, can we even develop our own governance website with a sudo Discord type discussion medium integrated right into it. Another option could be automating poll bots that reach out to various mediums such as: Twitter, Discord, Telegram, Reddit, etc. So that when a proposal moves from Phase II to Phase III, a vote for a proposal advancement can be initiated autonomously to all of these communication mediums and some quantitative averaging to show the community consensus. Just a thought and something to think about while we develop this governance framework. Such as, how can we best reach majority of the IOTA, Shimmer, and Assembly community worldwide… not an easy task!