Current Signaling Process

The intention for this thread is to describe the current signaling process on these forums. It is meant to be descriptive and not prescriptive at this stage.

Thus far it’s mostly been me pushing this process and potential improvements that have been discussed in the past. I want to make it clear that anyone is welcome to start this process (or follow their own if they think they have a better process) on any issues of their choosing.

With all that said, this is the process that I plan to follow for the most recent signaling thread.

Stage 1

Action: Determine if there is a majority for change in some form by asking a general question: ‘Should we change from x’
Justification: The intention behind this is to determine immediately whether there is consensus for the status quo. If there is, the process can end here before lots of effort is expended trying to forge agreement on specifics.

Action: Call for discussion and suggestion on specific options that the community would like to see.
Justification: In the interest of efficiency, specific options can be proposed and discussed before the desire for change has been determined. In addition, opening up the proposal to the community gives everyone a voice on the specific implementation.

Action: Stage 1 lasts for one week.
Justification: This gives enough time for the initial signal to have some weight without unduly delaying the decision making process.

Action: The initial sentiment poll remains open for the duration of the process.
Justification: Some people will not be able to check the forums once a week, this allows them to signal for/against change at any point during the process.

Stage 2

We move to Stage 2 if the initial sentiment poll has a simple majority after 1 week.

Action: Create a multiple-choice poll allowing everyone to signal acceptance for each of the options proposed so far, this poll expires in two weeks.
Justification: A multiple-choice poll lets us most efficiently rank the proposals according to consensus.

Action: Stage 2 lasts for a minimum of 2 weeks.
Justification: Two weeks gives plenty of time for discussion and signalling on the specific options proposed within the first week.

Action: Additional specific proposals are welcomed and encouraged during step 2.
Justification: It’s possible that there will be no majority for any of the initially proposed changes. By allowing additional suggestions after this time we can parallelize the decision process.**

Action: If after the two weeks are over, there is no majority for any of the proposed options, Stage 2 repeats.
Justification: We should not adopt any proposal that does not have majority backing. By repeating stage 2 with a modified set of proposals, we have a better chance of reaching a majority.

Action: Throughout this process, the importance of compromise and building consensus should be emphasized.
Justification: The aim of this process is to find a solution that everyone can accept, rather than a solution that is everyone’s first choice. By emphasizing this, you help remind signallers of this aim.

Stage 3

We move to Stage 3 if a single specific proposal has majority backing.

Action: An on-chain poll is created in the form ‘Specific consensus option, yes or no?’
Justification: This lets MKR Token Holders to ratify the change, and confirm that the change is better for the system than the status quo. I don’t think we need to vote on what the on-chain poll looks like individually for each proposal, so I’m following the vote on the exponential rate stepping proposal.

Action: Currently we’re reliant on the Foundation to create on-chain polls, so Stage 3 involves convincing the Governance Facilitator to create this on-chain poll.
Justification: This is necessary to get the poll on-chain.

Action: The on-chain poll should last for a week.
Justification: By this point, active MKR Token Holders should be aware of the prior proceedings, one week should be sufficient for those who wish to vote to do so.

Misc Thoughts

  • In a ideal situation, the time from proposal to on-chain poll is three weeks, with one week on the on-chain poll, that means total time for a change to occur is one month.
  • With a controversial issue, the process to find consensus could take much longer.
  • If Stage 2 fails to find a consensus option after three iterations, the change should be abandoned for a period not shorter than three months.
  • If the initial sentiment poll drops below 50% and remains there by the time stage 2 ends, the change should be abandoned for a period of not shorter than one month.

As always, feedback is most welcome.


Thanks for this, @LongForWisdom! I’d like to get more involved here.

I understand that we want to approach this in “steps” However, can you share what the process is for creating an on-chain vote? Can anyone do it? Or is some sort of centralized permission required currently?

I am unsure of the entire process, I believe that in order to be included on the front-end @, something needs to happen that is controlled by the Foundation.

In terms of the on-chain part, anyone can call the appropriate smart contract function on the PollingEmitter:

Thus far, I don’t believe anyone outside the Foundation has setup a poll. @rich.brown might be able to elaborate on the process and the plans to open this up to those outside the Foundation.

Hello, I was one of the people who worked on the current signaling system so I thought I’d chime in with a few technical details in case they’re useful. currently only shows polls created by approved addresses. These addresses are, at the moment, associated with wallets controlled by members of the foundation. Specifically, we run an off-chain cache configured to only track information on polls where creator is in authorizedAddressList (eg [<0x1>, <0x2>, <0xabc>, ...]).

If someone were to fork our frontend and run their own instance of our backend cache, they could configure it differently. So, for example, they could pick their own set of addresses to filter by, or they could remove the filter completely — as @LongForWisdom says, there is nothing in the PollingEmitter contract that limits who can call createPoll. Really the signaling system was designed to be open in this way from the beginning and at some point i’d love to write more about how community members could create their own dashboards or cryptographically verify the foundation’s.

There’s more to say about how it all works, but i’ll leave it there for now unless there are specific questions :slight_smile:


Thanks for clarifying this @jparklev. I believe I’ve been told how this works before, but I can never remember the details :roll_eyes:.

I had a couple of questions.

  1. I assume that the authorizedAddressList is built to be modifiable, that addresses can be added and removed?
  2. Is the plan to relax the white-list at a later date? Or is the emphasis more on: ‘If you want open polling, build a third-party dashboard?’

I’d love to read anything you have time to write about it. It would be great to have a canonical topic about how the system works, basically the information here but in a new topic that we can link to. It could also include more detail about third-party dashboards and the options for expansion.

I think that would help to forestall future questions of this nature.