In the current OpenGov design, once a referendum is submitted on-chain, its preimage (the proposal content) and origin cannot be changed. This creates several practical problems:
Preimage Errors: Technical errors in preimages (incorrect parameters, wrong origins, miscalculated amounts) currently require a complete resubmission rather than a simple correction.
Throwaway Referenda: Proposals that receive negative feedback early on cannot be adjusted. Instead, they must be resubmitted as new referenda, creating unnecessary on-chain clutter and fragmenting discussion over several referenda
Cross-Referencing Burden: When a proposal is resubmitted, stakeholders must cross-reference the old referendum to understand the proposal’s history, which creates an unnecessary mental burden.
I did a measurement in 2024-10 and at least 5%(!) of all referenda had been affected by this single UX issue:
Votes can be cast (but don’t trigger approval/confirmation logic)
The preimage and origin are locked
The proposer cannot make changes based on community feedback
Suggested Solution
This RFC proposes a new discussion period for OpenGov referenda that precedes the existing prepare period. During the discussion period, the original proposer can modify the referendum’s preimage and origin, enabling on-chain response to negotiation and refinement of proposals before voting outcomes become binding. Once the discussion period concludes, the referendum transitions to the prepare period (which can be skipped if decision conditions are already met) and the preimage and track become immutable.
Proposed Lifecycle
This RFC proposes adding a Discussion period before the prepare period:
the proposal creation flow will be always discussion, then it can be promoted to referenda after 14 days or somepriviledged approval with correct track. There is 0 changes required for this to work.
Hi @jak-pan, I suspect you have just skimmed the RFC before replying.
The core idea of the RFC is to make the preimage and origin editable, which is not a feature that can be implemented via just the UIs
We have seen the pattern of „wrong preimage please vote nay“ or resubmissions after a few days just with changed parameters again and again, especially in the last few days.
I think the problem here is that this “Discussion” period basically accommodates an off-chain process, whereas currently the Referenda pallet deals exclusively with what is relevant on-chain: Track timings, the respective deposits, the votes and the outcome.
From an on-chain perspective, what does it mean for something to be “in discussion”? Is it like a draft? That would be reasonable, but I’m not sure it justifies storing something on-chain purely so that off-chain processes can index it, process it, and come back with a “yes, that’s ready now” or “no, wait, I need to change it”.
In other words, isn’t this something that should be handled directly by Subsquare or Polkassembly? Encourage users to first create discussions (but including the origin + call data in it), have the community discuss those, and once it’s ready then do the submission on-chain.
Historically, it was often encouraged (but not required) to begin with a discussion period to gather community feedback prior to submitting a proposal. In practice, however, many discussions did not receive the level of engagement their authors hoped for - likely due to the sheer volume of proposals, as well as limited community bandwidth to review discussion drafts in addition to commenting and voting on active proposals. To my knowledge, it was also never a requirement for DVs to provide feedback on discussions. That dynamic has contributed, in part, to situations like the one we see today, where some proposal submissions pivot to “Please vote Nay” and are then subsequently resubmitted.
With the recent publication of the Web3 Foundation’s OpenGov Proposal Voting Guidelines, and their inclusion of a “public discussion lead-time” as part of the Minimum Standards for All Proposals, we are beginning to see more discussions appear in OpenGov.
Your idea seems to intentionally formalize - or “force” - that discussion period. If implemented effectively, it could increase the likelihood of meaningful community feedback during the discussion phase. Ideally, this would also encourage - or potentially require - greater engagement from DVs during that period.
Do you envision this approach applying across all tracks, or only to selected ones? Alternatively, might it make sense to vary the discussion period length depending on the track?
I’m interested in hearing broader community perspectives on this. In principle, this approach could lead to higher-quality proposal submissions, though it does introduce additional process overhead, so finding the right balance will be important.
The discussion period is defined in the RFC Summary as
This RFC proposes a new discussion period for OpenGov referenda that precedes the existing prepare period. During the discussion period, the original proposer can modify the referendum’s preimage and origin,
@jslusser laid out the reasons pretty well. During off-chain discussions, few pay attention because it is not neccessary and time consuming. Only when the clock starts ticking there is an incentive to pay attention. Once people do, negotiations begin and suggestions to change value/tracks etc come in. It is a pretty basic UX issue.
Currently in the RFC I make these suggestions for Polkadot:
Treasurer & Treasury spend (Big, Medium, Small Spender) origins should be discussed 14 days
Treasury tip (small and big tipper) origins are intended for low-risk spends on shorter cycles. 7 days are suggested here
Whitelisted Caller, Canceller and Killer tracks are time sensitive. Instant progression to the prepare stage is indicated.
All other (technical) origins are likely invoked by competent users that followed proper off-chain preparation procedures. We give 3 days discussion time to allow corrections, as sometimes a proposal gets accidentally submitted to the wrong track.
The prepare period follows the discussion period. I was looking into if we can get rid of it completely but it is designed to ensure that the DD is placed. In my current suggestion the prepare period stays, but can be skipped if all criteria for passing it are given.
Additionally, I was worried about lengthening the overall referendum lifecycle too, so in the discussion of the RFC I wrote that it can be considered to shorten the decision phase, since during the discussion phase voters are already considering the proposal. So it would be possible to have e.g. 2 weeks of discussion period but then cut the decision period from 4 weeks to 2 weeks, so no additional time is neccessary.
But this is definitely an open point where we should gather more feedback on.
Love this! I have put forth proposals a few times just for feedback, and community sentiment for funding before putting down a deposit. Here are some gray areas to solve/define….
If there is an additional problem to solve that the “Prepare” time exceeds, can you cancel/withdraw or pause ref? I am assuming that this is the proposer’s decision based on you saying, “A decision deposit MAY already be placed” ? So, if full deposit isn’t applied the ref will not commence past Discussion Period?
Some refs will seem like duplications of tech, however maybe regional needs that require regional applications.
I have been thinking deeply about this since BA presentation & am wondering if a ref list of other proposals could be listed while in discussion period (OG Tracker Update? )? Example- I put a strategy request out once with a reference to BD Marketing materials that was funded in a previous ref, however over a year later I don’t know if they ever got created, or are still being worked?
Yes. I didn’t look at it this way but the proposer could tactically not place the DD to prevent the ref from going forward.
To control for spam here we have the submission deposit separate from the decision deposit. The submission deposit is non-refundable.
That is a qualitative problem. Blockchains are math constructions and primarily good to solve quantitative problems. So qualitative duplication cannot really be our concern here.
So from on-chain perspective, the only effect it has is that it enforces every referendum to have a decision period for a specific amount of time based on the track.
That’s fine, but I’m not sure it’s justified. Again, it’s trying to mirror an off-chain process which will continue to happen off-chain anyway. So why not implement it on top of the existing governance UIs?
This brings some questions or adds some additional problems:
Possibly lengthening referendum cycles. I’ve read you’re considering shortening the decision period to make up for it, but that might have other implications - the decision duration was set to that amount for some reasons. Additionally, I don’t think you should shorten the decision period by the same amount as the discussion period takes, since you never know how if the proposal changes last minute.
Enforcing the same timeline regardless of whether a referendum needs more or less discussion: Each referendum requires a different amount of discussion and back-and-forth, even within the same track. Whatever discussion duration is picked for each track, you are probably making it longer than necessary for some referenda (which only adds unnecessary time), and too short for others (which would result in “Please vote NAY” anyway down the line)
Discussion incentive for voters: I’m not sure that having a specific “Discussion” period with a fixed deadline is incentive enough for voters to go there and evaluate proposals early. I really don’t know much about psychology, and I’m personally not that active as a voter in OpenGov either, but I feel like they would prioritise taking a deeper look at referenda that are already in a decision period (and even more if it’s decisive), rather than something that’s just been created and “let others handle it by now, I’ll take a look later”.
All in all, I personally think it would be better to avoid the complexity of having something on-chain for a process that is completely off-chain. With the current referenda pallet, it’s absolutely possible to provide the UI + UX described by this RFC, by having a discussion be opened beforehand, even enforcing some time length if that’s the case. The current discussion system in Polkassembly is just missing preparation of the track + call data, but once you have that, then you can have unlimited detail updates before submitting it on-chain once it’s ready with a one-click.
Things that I think would improve UX that are relevant on-chain:
The ability to withdraw a submitted proposal.
Having the referendum content on-chain, which would solve the mutability/accountability issues.
But a discussion period? I’m not sure I see the actual advantage of having that on-chain.
Ok, sorry I fixated on the “Discussion Phase” part of the “RFC-0161: Discussion Phase for OpenGov Referenda”, which apparently is out-of-scope.
My suggestion then is to change the on-chain process by introducing an extrinsic that allows the creator of a referendum to withdraw it (maybe only before it enters the decision period, if needed)
This way, you can cater both use cases: Someone who submitted a referendum by mistake and wants to withdraw it, or someone who wants to change a submitted referendum.
Because with that extrinsic in place, editing can be composed with batch(withdraw, submit), and even a UI can handle all of this behind the scenes while still giving the user a “You are just editing your referendum”.
I’m not that active as a voter in OpenGov as I said anyway, so that’s just my opinion, for what it’s worth.
I just don’t think it’s a good idea to do big on chain logic changes for 5!% improvement for people that can’t bother to discuss and make correct param setup instead of doing some simple ref simulation tool?
This circle jerking about small (and incorrect) stuff is why everything is so complex and overengineered and take 10 times longer than it should. We could have built spaceships with the amount of engineering power we have at this point.
hahaha, I am not even going to pretend I understood your reply to your second response on question 1. However, I will take your word for it, as it is over my head, right now. Appreciate 1st reply, totally understood that response!
Love this! I have put forth proposals a few times just for feedback, and community sentiment for funding before putting down a deposit. Here are some gray areas to solve/define….
)? Example- I put a strategy request out once with a reference to BD Marketing materials that was funded in a previous ref, however over a year later I don’t know if they ever got created, or are still being worked?
However, I will take your word for it, as it is over my head, right now. 
Appreciate 1st reply, totally understood that response!