[Feedback Requested] Voting Extension Mechanism

TL;DR: In response to feedback from contributors, the Governance Committee wants to initiate discussions around possible ways to introduce flexibility into the monthly proposal cycles. The mechanism described below aim to provide flexibility for authors who may need extra time to make minor changes in later stages of the cycle, or who may need to resubmit their proposals outside of the regular cycle schedule.


The introduction of monthly proposal cycles in April 2023 has proven to be a helpful format for our community to better follow proposals moving through governance. It helps both proposal authors and governance participants better plan their time and attention to support the proposal process.

Feedback shared by contributors in the Governance Feedback Survey confirmed that these cycles have been working well for them, and that they are generally serving their intended purpose. However, there have been a few suggestions for improvement:

  • There is a desire for more time to share and incorporate feedback before a proposal is voted on in a given cycle.
  • There is a desire for more flexibility in the cycles in certain cases where slightly more time is needed to sort out minor issues.
  • Proposal authors have expressed frustration in the past of having to wait until the next cycle (next month) to resubmit their proposals due to the time constraints in the cycle phases.

To start addressing these issues, the Governance Committee proposed RGP-24, which the community passed. RGP-24 suggested changes to the proposal cycle that allow more time for review, discussion and feedback implementation of proposals in the first two weeks of each cycle. These adjustments to the cycle schedule aim to mitigate instances of late feedback submission in cycles and offers authors more time to integrate feedback during the initial phase of the cycle.

In addition, we wanted to start a discussion around formalizing the “emergency” voting process that could be adopted by the community to provide additional flexibility in the cycle as needed. Below is an example of what this process could look like and how the community could decide when it can be used. It is inspired by the process the RGP-23 proposal authors used to get the community’s permission to re-submit their proposal onchain a second time after it was unable to not meeting quorum. The model below is just a prototype - feedback is needed to validate and formalize it!

New Mechanism: “Voting Extension”

The following Voting Extension mechanism would enable proposal authors to request additional time to finalize or for permission to resubmit their proposals outside of the regular proposal cycle schedule from the community.

This mechanism aims to:

  • Formalize a process to allow for flexibility in the proposal cycles for special cases
  • Provide a lightweight process with little overhead
  • Leave power to determine what qualifies a proposal for an extension up to the community

How it Works:

  • Proposal author posts a (public) Discourse poll on the corresponding proposal post on the forum asking for community approval for an extension or permission to resubmit a proposal - providing context & reasoning
  • The poll should:
    • Be open for at least two days to allow time for the community to respond
    • The participants list should be publicly viewable to prevent manipulation
  • The Governance Committee will help communicating the poll on community channels (e.g. Discord)
  • The poll will pass if it has at least 10 participants and a 2/3rds majority voting in support of the extension.
  • If the poll passes, the proposal author can delay or resubmit their proposal (the Governance Committee will help facilitate this process)
  • If the poll does not pass, the proposal author will have to wait for the next cycle

Qualifying Circumstances:

Instead of deciding upon a set of qualifying circumstances in which a voting extension is warranted, the Governance Committee believes that proposal authors and the Radworks community should be able to use the Discourse poll to determine when a voting extension is appropriate case-by-case. This framework formalizes the process to ensure alignment on expectations around this flexible process.

A few examples of situations where we can imagine this mechanism being helpful:

  • More time is needed: Proposal authors need more time to clarify details of the proposal such as last minute budget negotiations or better definition of scope / focus of work based on feedback
  • Personal reasons: Proposal author or major stakeholders are unable to be present during part of the cycle/participate in voting windows
  • Can’t wait for funding: If the team applying for treasury funding is unable to delay funding by another month/wait for the next proposal cycle


This process is meant to allow for some flexibility within the monthly proposal cycles, however, we hope this mechanism would not need to be used often given the additional time for sharing and incorporating feedback during proposal cycles that was introduced in RGP-24.

This process is generally intended for smaller or minor changes or issues around a proposal that come up late in the cycle. If the changes require more time than the extension allows, this signals that the proposal would most likely benefit from waiting until the next cycle to allow for ample feedback and discussion time to find consensus.

Using a Discourse poll to gain consensus allows for a simpler and quicker way to gather feedback quickly and allows proposal authors to coordinate their next steps more efficiently.

Feedback Questions:

  • Do you believe we need to formalize this process? Why or why not?
  • Do the proposed process & tooling present a fair way to gain consensus around when to use the Voting Extension mechanism? Is there anything you would change about the process or the tooling?
  • Are the passing requirements for the Discourse poll sufficient? Anything you would change? Why or why not?
  • Should there be limitations to when this process could be used? If yes, when?

If there seems to be support for formalizing this process, the Governance Committe can create a Social Proposal in the next proposal cycle to officially ratify this mechanism.

Would love your feedback on this @yorgos since it was inspired by your process used to resubmit your Org proposal!

1 Like

Thank you for capturing and describing this mechanism @shelb_ee !

I think this post does a great job summarizing how the voting period can be extended in cases where the community feels like an exception can be made.

To answer your questions, specifically:

I am torn here. :thinking:
On the one hand, it was vital to come up with a way to handle the exception in our case, so having this option definitely seems useful.
On the other hand, I think the value was in the exception itself, allowing us to overcome some previously unforeseen circumstances, so I am wondering whether a new process (whatever that may be) is the solution… Perhaps we just need to be able to raise exception requests?

For the time being, I think they are. We have to keep in mind that regardless of the forum support, we still need a major token holder ( >1M $RAD) to submit an on-chain proposal, so we have two mechanisms in place to prevent abuse.


Thanks of the resonse @yorgos - this is really helpful feedback! I think you also raise a lot of good points.

Perhaps for now we can reference this post if a similar situation comes up again. If we find folks are needing an extension outside of the existing cycles we can revisit the discusssion to formalize this process if it feels appropriate/needed. How does that sound?

This is correct!