Guide to the Signaling Process


This is an informal guide on how to participate in the signaling process at MakerDAO by starting a signal request. Signal requests and their role in the governance process are described here.

This post covers the considerations before starting a signal request, how to construct a signal request, what the author is expected to do during the signal request and steps to follow after a signal request is concluded.

Before the signal request

Consider starting a discussion on the forum and/or use an informal poll to gauge the community’s sentiment before starting a signal request. This step is not necessary for all issues and should always be skipped for urgent issues.

Ensure that you have sufficient time for signalling. The signal request should last at least two weeks after going live. Anything less than two weeks does not give governance participants a decent chance to signal on the issue. Many participants do not frequent the forum every day, or even every week. In some situations however, the issue is urgent and some signal is better than no signal at all. In these cases, this two week length should be ignored with appropriate justification and subsequent approval from GovAlpha.

Constructing a signal request

Limit the signal request to a single issue

This keeps the topic from becoming a confused mess of different conversations. This is not to say that there must be only one poll, only that all the polls should seek signals on the same issue.

Begin with a summary of the essential information

This should take the form of a advantages/disadvantages, pros/cons, positives/negatives to the area being discussed and should be kept up-to-date as the thread progresses. In order to signal, the community should not need to read through the entire discussion, only the initial post. It is the thread owners responsibility to keep this summary as balanced and succinct as possible.

Aim to create consensus

When you create a signaling thread, you are trying to gather consensus around a specific proposal, be aware that the proposal may need to compromise to suit as much of the community as possible. The aim is consensus rather than majority-rule, if there is irreconcilable disagreement, the proposal needs to change.

Use neutral phrasing

The title, post content and poll options must all be framed in neutral language. Emotional or rhetorical language should not be used. Neutral framing is to ensure that you do not prejudice other community members into voting a particular way. This is vitally important no matter how strongly the author feels about the topic. For example, the poll option “No, we should not change the PPG process” is good. On the other hand, “No, the PPG process is perfect the way that it is.” is bad.

Use the correct category

The governance:signal-requests category should be used for all signal requests. Using the same category for signal requests allows them to be accessed separately from the rest of the governance threads and helps keep everything organised. It also allows a custom post template which can help point people in the direction of the Signal Request resources.

Have the correct tags

Using the same tag across the forum makes it easy to find all the signaling topics, it helps keep everything organised, it helps the community see if there are things to signal on, etc etc. The two tags that should be attached to a new signal are sig-status-active and signaling. Note that you need to add the sig-status-active tag first or else the signaling tag will not work

Link to appropriate resources

If your signal request is related to an existing discussion or to a previous signal request, add a link for readers to give them context. If your signal request is related to frequently adjusted governance parameters, then you must add a link to the Governance Parameter Documentation here (look for the appropriate parameter on the left panel).

Have clear lines of progress

The next steps of a signal thread should be communicated by the thread owner whenever anything changes. This can be as simple as a one-line comment explaining what will next happen, and when it will next happen.

Poll settings

Creating a poll in the forum requires you to follow these steps. It is quite easy to create a poll that does not conform to the signal request guidelines so please follow these steps carefully.

Insert a poll using the grey gear icon highlighted in the red box in the screenshot

Next, you will see the image below. Click on the gear icon again as highlighted

You can now create a poll. The following settings are required for any signal request poll:

  • Set up a Multiple Choice poll unless your poll only has Yes, No and Abstain as options.
  • Add a neutral Poll title that does not contradict with the thread title.
  • Add the polling options and include an Abstain option.
  • Ensure that each poll option says a single thing and is phrased neutrally.
  • Ensure that the Min Choices is set to 1 and the Max Choices is set to the number of polling options (excluding the Abstain option).
  • Set Limit voting to these groups to trust_level_2
  • Ensure that Show Results... is set to Only after voting.
  • Enable the Show who voted checkbox.
  • Disable the option to Automatically close poll.

These choices are made for the following reasons:

  • There are several advantages to including an Abstain option in a signal request. Firstly, it allows voters to signal ambivalence or protest in a active way. It also allows the Governance Facilitators to check the results of the vote in-progress while remaining neutral.
  • Multiple choices allow voters to back more than one option that they would be happy to support in an on-chain poll.
  • Restricting voting to trust_level_2 users ensures that the signal request is not brigaded and manipulated with new accounts.
  • Showing results only after voting ensures that confirmation bias is avoided. People are susceptible to voting with the majority and hiding the results until after someone votes provides an extra incentive for voters to think critically about the issue for themselves.
  • Making votes public after a vote has been cast allows the thread owner to prod dissenting signals to provide reasons for disagreement.
  • Polls should not be automatically closed as it reduces flexibility.

Before inserting your poll, check to see if all the highlighted red boxes in the screenshot below are as shown.

The markdown you see in your thread should be as below

[poll type=multiple results=on_vote min=1 max=2 public=true chartType=bar groups=trust_level_2]
# Poll Title
* Polling Option 1
* Polling Option 2
* Abstain


  1. (Optional) Has there been an informal poll and/or discussion about the issue on the forum?
  2. Is the signal requested limited to a single issue?
  3. Is the question phrased in neutral language?
  4. Is there a summary of essential information?
  5. Are you using the governance:signal-requests category?
  6. Have you added the sig-status-active and signaling tags in that order?
  7. Have you added appropriate links including to governance parameter documentation, if applicable?
  8. Have the lines of progress been included at the end of the signal request post?
  9. Poll settings
    1. Is the type of poll (Single Choice vs Multiple Choice) chosen correctly?
    2. Is the poll title neutral and not in contradiction with the thread title?
    3. Are the poll options neutrally phrased and refering to only one thing?
    4. Is there an Abstain option that voters can select?
    5. Is Min Choices set to 1?
    6. Is Max Choices set to the total number of polling options (excluding Abstain)?
    7. Is Limit voting to these groups set to trust_level_2?
    8. Is Automatically close poll: X selected and no date/time given?
    9. Is Show Results... set toOnly after voting?
    10. Is the checkbox forShow who voted checked?

If you’ve answered yes to all the questions in the checklist, congratulations! Your signal request is ready to go live.

During the signal request

  • Facilitating discussion and engagement in good faith: It is important to encourage people to participate in the signaling process and seek out opinions from both sides. Keeping the discussion going and engaging with all who participate is essential and this responsibility belongs to the thread starter. The thread starter does not have to remain neutral on the issue, but does need to run the signaling process in good faith to its conclusion.

  • Moving on-chain: A signal request cannot move on-chain until there is a majority for a polling option. The aim of the signaling process is to gather consensus and if it fails to do so then it has not achieved its aim. That said, it is difficult to argue against the poll moving on-chain if a polling option has a majority voting for it. Garnering significantly greater than a 50% majority should always be an aim for the thread owner. The closer the thread is to consensus in the polling stage, the more likely it will pass on-chain. In rare cases a plurality may be sufficient for a poll to move on-chain, however this should only be done if there is a clear reason of urgency.

Note that thread starters cannot close an active signal request thread once it has gone live.

After the signal request

If a signal request moves on-chain, it should be summarized after all the off-chain and on-chain polls are complete. At this point the thread should be considered finished. The sig-status-active tag should be removed, and a member of GovAlpha should be pinged to set the thread to close 7 days after the last reply.

If a signal request fails to achieve consensus after two weeks, the thread will be closed by GovAlpha.

Whom do I ask for help?

Name GitHub Forum
LongForWisdom LongForWisdom @LongForWisdom
Payton Rose prose11 @prose11
Tim Schuppener ultraschuppi @ultraschuppi

Consider also posting your question on RocketChat where any community member can help.


I find this summary very excellent, the truth that there is this guide, for my part I do not think I use it because I do not work in a UC or something of vital importance in the protocol but to make community.

But I will keep it just in case

Thank you for publishing this guide, I find it useful, I really did not know these tools, maybe in the future in the Latin America section I will use it, but it is good to have the knowledge.