OpenGov Adjustments - 2025

A Polkadot Ecosystem Agents™ Initiative

We are proposing adjustments to OpenGov in retrospect of the community’s engagement over the last 24 months of proposals, voting and dialog.
This proposal seeks to decrease noise for voters and increase accountability of proponents.

The adjustments are conceptually part of a broader framework and vision for the future of OpenGov - we see the long term vision of the treasury transforming by moving the majority of spending to bounties, or collectives which allow for better domain knowledge, scope, and cost negotiation. The long term vision also includes agreed-upon budgeting per domain area, greater transparency across bounty spending, and enhanced controls for managing and promoting competent talent within the ecosystem inside the bounty system.

Next week we will post this on-chain as a Wish For Change (WFC) to seek alignment from the community on this new vision.

The short term adjustments revolve around increasing the quality of submissions and reducing the noise and effort that is required from governance participants. We see this as a large time and brain drain from the ecosystem with a huge opportunity cost for those actively involved.

The short term adjustments involve, per track:

  1. Increasing the Submission Deposit from 1 DOT to 10 DOT

  2. Increasing Decision Deposits

  3. Increasing the minimum Support Turn-out

  4. Decreasing the Max Deciding referendum
    (number of active referendum allowed per track)

  5. Making the Referendum Canceller easier to submit.These adjustments have all been modeled against previous OpenGov proposals to ensure that high quality proposals will still pass with these new adjustments.

The Submission Deposit has been increased to help reduce spam proposals or “just vote nay” (submission errors). Any submission deposits on failed proposals result in this DOT being locked forever and unable to be claimed (effectively burnt). The aim of increasing this to 10 DOT should help prospective proponents to take more care when raising governance proposals.

Increasing the Decision Deposit should force proponents requesting funds to have a greater stake in the ecosystem and network or may require proponents to seek an aligned sponsor for large spends if they are coming from outside of the Polkadot ecosystem.

Increasing the minimum Support Turn-Out will help ensure that only well aligned proposals that really engage the community make it through and are funded / approved.

Decreasing the Max Deciding will increase efficiency of spending, help reduce noise for involved parties, and therefore decrease voting fatigue. This proposal decreases the maximum possible active governance proposals across four tracks from 160 down to 15. Similar to Gov 1, this can lead to a queue of waiting proposals and the proposal with the most support in the queue will become active (go into voting) next. This helps increase the quality of proposals and slows down OpenGov, allowing participants to focus on proposals and have a more robust discussion period before and during active voting.

Making Referendum Canceller cheaper to submit ensures that if there are active proposals which are very likely to fail - e.g. 90% NAY with a strong support, then these proposals can be cancelled to clear up the active spots, allowing another proposal to be voted on, without having to wait the full voting duration.

The following tracks are included in the proposed short term adjustments:

  1. Treasurer

  2. Small spender

  3. Medium spender

  4. Big spender

  5. Referendum canceller

These tracks account for 60% of all treasury proposals raised since OpenGov’s launch. These adjustments have been tracked in the following document and are as follows:

  1. Treasurer

    1. Max deciding, decreased from 10 to 2

    2. Decision Deposit, increased from 1,000 to 25,000 DOT

    3. Min Support Turn Out increased from 0% to 1.5%

  2. Small spender

    1. Max deciding decreased from 50 to 5

    2. Decision deposit increased from 100 to 500 DOT

    3. Min Support Turn Out increased from 0% to 0.5%

  3. Medium spender

    1. Max deciding decreased from 50 to 5

    2. Decision deposit increase from 200 to 1,000

    3. Min Support Turn Out increased from 0% to 1%

  4. Big Spender

    1. Max deciding decreased from 50 to 3

    2. Decision deposit increase from 400 to 5,000

    3. Min Support Turn Out increased from 0% to 1%

    4. Approval increased from 50% to 60%

  5. Referendum Canceller

    1. Max deciding decreased from 1,000 to 500

    2. Decision deposit decreased from 10,000 to 5,000

These proposed adjustments to OpenGov represent an evolution in how we use the Polkadot treasury.

By reducing the amount of incoming treasury proposals we will have more time to evaluate the proposals raised, increasing the quality of our decision making.

By raising deposits, tightening active proposal limits, and optimising cancellation mechanics, we seek to elevate the quality of governance activity and increase alignment within the network participants, while minimizing the time and energy drain on participants.

This WFC will mark a clear step toward a more focused, sustainable, and scalable OpenGov for all.

31 Likes

I fully support these proposed changes.

These were discussed with a whole bunch of people at the web3summit and I believe these will go a long way to:

1. Reducing overall noise + spam of low effort proposals

2. Reducing voter fatigue (which is a massive issue at the moment) – I’ve heard from a few people that it is too difficult to properly review every referendum as the volume is too high.

3. Ensuring only “heavily” aligned referendums get approved.

Great job championing this, getting all the suggestions together and helping to get this out there Birdo!

9 Likes

Great initiative.

“Increasing the Decision Deposit should force proponents requesting funds to have a greater stake in the ecosystem and network or may require proponents to seek an aligned sponsor for large spends if they are coming from outside of the Polkadot ecosystem.”

Could we incorporate the concept of collective decision deposits (e.g., DD crowdfunding) into this solution? This approach could help alleviate the trade-off between restricting submissions from smaller token holders - while still allowing larger holders to participate - by enabling organized collectives to actively contribute to submissions by crowdfunding DDs. Even if this comes later, I’d be very happy to see it as part of this roadmap.

7 Likes

Love seeing this land, Birdo!

Adding my voice here, we kicked these ideas around at Web3 Summit, and there was a clear consensus that we need less voter burnout, and way more signal.

Happy to have helped in this, and super excited to watch this WFC become a reality.

Big thanks for rallying the feedback and pushing it over the line…

3 Likes

4 Likes

Improving Governance is always a good initiative.

I have some questions:

Does this long-term vision include improvements to the process for rotating curators?

In what ways does the previous short-term implementation promote inclusivity and contribute to the ecosystem’s growth?

Thanks for pushing this out Birdo. I’m in favor of these changes. I think they will help tremendously with the three goals mentioned by Leemo.

4 Likes

There are already methods to change curators of bounties, you can see examples here:

  1. Proposing new curators for the Public RPC Bounty (31)
  2. Replacing curators for events bounty 17

Rotating curators for the sake of rotating them is not a good idea imo. Voters should only approve curators who have the necessary skill/competence, experience, and connections for that role. If the curators of a specific bounty are not up to scratch, then they should be proposed to either be removed or replaced via referendum.

Rotating them randomly to “give people a shot” will only decrease efficiency. I personally wouldn’t want Nico from Velocity to be removed as a curator of the DeFi bounty because someone else wants to give it a try.

From my experience, people who want to force-rotate curators are those who have had something rejected by a bounty in the past. It is always possible to then propose that idea via referendum.

In reply to Wario: I can understand where you are coming from on this, as someone who isn’t in the financial position to hold multiple tens of thousands of DOT. However, if your idea is good and you have proven that you are a good ecosystem agent, then it’s typically possible to find someone who resonates with your idea who can help to sponsor the decision deposit. It’s up to you and your own personal network to do that currently.

I do support the idea of collaborative decision deposits that @RTTI-5220 spoke about above, I’ve been talking about it for a while at this point on AAG and other places.

1 Like

I would suggest enforcing a standarised reporting and modus-operandi accross different bounties, including what is asked for petitioners to submit pre and post applications and how the different bounties report their activities. This can include objective success metrics - designed by the correspondent bounty - the grantees should include in their report.

I am aware of the different nature of the different bounties, but a more similar way to deal with the different bounties ( and to evaluate the performance of them) will help everyone. Bounties are sovereign - so clear scrutiny and fair checks and balances - it is also needed.

Day dreaming: Every bounty has a yearly strategy and budget to execute it, and start to empower the RFP way to execute the strategy, can also help to start to build bottom-up at least, that global strategy that is being elusive for us.

3 Likes

Just out of curiosity, what about the idea of having the parameters be time-based?

For example, for a period of 1 months per year, the deposits as they were before (encouraging maximum participation). For the rest of the 11 months, it is either the parameters you proposed here, or even more restrictive ones.

I believe this needs to go hand in hand with more focus from the OG UIs on bounties, as they will become the primary source of funding. Atm, a new joiner might have a harder time finding bounties than the default OG process.

All in all, in favor of this direction regradless of the above two points.

1 Like

These are much needed improvements to OpenGov :star_struck: . Thank you @Birdo for presenting this proposal. I am especially aligned with having less proposals simultaneously active to ensure a more in depth analysis can be done and better decisions can be taken.

I am hoping that by reducing voter fatigue this can also translate in more voting participation by tokenholders who have limited time yet valuable contributions.

This is a great idea and one that would not only be more inclusive but also legitimize the support a proposal has by other tokenholders willing to contribute to the DD.

I think that in addition to finding people who resonate with an idea privately, via networking, we should also encourage people who do not yet have a network within the ecosystem to find this support in advance via public forum or discussion posts, AAG, etc. Expressing clearly the idea they are proposing, how it benefits the ecosystem and the need for crowdsourcing the DD. One simple idea would be to have a tag on the forum, as a visual aid for DD crowdfunding.

I was not here during Gov1 but I was wondering if someone could kindly clarify how would the support of proposals in the queue be measured? Thanks.

2 Likes

This has been seen before in tracks like Root, which have a max deciding of 1.

Basically, if that track currently has the maximum number of referendums in the decision phase (say 5) then other referendums remain “queued” (assuming decision deposit has been placed). Once one of the deciding referendums finalizes (approved/rejected), then basically the referendum with the most support (raw DOT voting AYE/Abstain) is elevated to the decision period.

So if the big spender track had a max deciding of 3, and there were two referendums “queued”:

  • Ref 1900 - 500k DOT support
  • Ref 1950 - 1M DOT support

Then ref 1950 would be elevated to the decision period, as it has more support. Ref 1900, even though it was proposed earlier, will remain “queued”.

1 Like

Interesting proposal. I agree with all the points you’ve made. I just have one comment. Since the decision deposit increases significantly for the tracks mentioned, and considering that the deposit is denominated in DOT, a sharp rise in the threshold could discourage participation in governance, especially if the price of DOT were to increase. Conversely, if the price of DOT were to decrease, the effect would be the opposite.

I am wondering if it would be possible to implement a dynamic mechanism where the decision deposit is calculated in USD as a percentage of the requested funds, and then converted into DOT at the time of submission.

Here is a simple example:

  • Requested amount: $1,000,000

  • Decision deposit rate: 10%

  • Required deposit: $100,000 worth of DOT

  • The amount of DOT is calculated based on the DOT/USD exchange rate at the time the request is submitted

I’m not sure if something like this is technically feasible, but I thought it was worth sharing the idea.

2 Likes

Solid list,

Can we also have a drastic reduction in the timeout waiting time when the Decision Deposit has not been placed?

4 Likes

Great list! It is a very well due step to reduce the number of refs. Very hard for every one to take the time and evaluate all the proposals with the same level of scrutiny.

Positive even the increase of the minimum Support Turn-Out. It will be interesting to see how this will play out with the new DV model.

I love to see the long-term vision and the thought process behind an agreed budget per domain area. This will move us closer to an IRL company and will require a sort of clear prioritization and objectives to decide how to split the budget and cap expenses.

I fully agree with adding more transparency to the bounties. If possible, I would suggest implementing a system to increase alignment between multiple bounties, especially for mixed proposals like marketing and events (easiest example). Currently, proposers often have to go through OpenGov, which is a time-consuming and effort-intensive process for the team. Another situation is when one bounty partially approves a proposal and refers the proposer to a second bounty that then rejects it, resulting in a not complete approval affecting heavily the positive outcomes of the proposal (i.e. presence, speeches, other activities at an event but no one knows about it).

1 Like

Hello there,

Thank you for the opportunity to bring the community to reflect on OpenGov’s parameters.

I am not going to debate the overarching goals of this initiative. Instead, I will focus on some of its practical implications.

The Submission Deposit has been increased to help reduce spam proposals or “just vote nay” (submission errors). Any submission deposits on failed proposals result in this DOT being locked forever and unable to be claimed (effectively burnt). The aim of increasing this to 10 DOT should help prospective proponents to take more care when raising governance proposals.

I think that more clarity is needed here. For example, how would you categorise a proposal that was put up for vote (with or without a discussion post) but withdrawn after community feedback that requested it to be re-worked and re-submitted later?

A lot of proposals don’t even get looked at in the discussion phase and proponents struggle to get eyes on their initiatives; even when these proposals are shared on high-traffic governance platforms (including this forum). Often, it is only when these proposals are up for vote that some OpenGov participants will take the effort to review and leave feedback.

You can increase the SD to attach a higher cost to publicising a proposal, but wouldn’t it make sense to first address the underlying issue (i.e. the absence of a well-established and effective structure/department/team that can steward/mentor proponents)?

Increasing the Decision Deposit should force proponents requesting funds to have a greater stake in the ecosystem and network or may require proponents to seek an aligned sponsor for large spends if they are coming from outside of the Polkadot ecosystem.

The idea of establishing sponsorships is good in theory. In practice, sponsorships will come with huge responsibilities (and potential liabilities) for sponsors. For example, what happens if the sponsored project goes bust or if the project team vanishes? This has happened in the past and will keep happening; because Web3 is a startup industry based on experimental technologies and because the vast majority of startups wither before they turn 3. Sponsors will have an uphill battle undoing their loss of credibility and reputation.

And so, what we are likely to see is that the only proposals that will get sponsored are those submitted by people who are already well-established and deeply networked into the Polkadot ecosystem. This, to me, does not sound like an improvement, because we will end up with a new version of OpenGov that is even more inward-focused than the one we currently have.

Couldn’t a public-facing BD working group work with OpenGov proponents to facilitate alignment with ecosystem priorities, since this is an obvious requirement for getting funding approved? This kind of “Incubator-like” structure could be modelled on the Open Source Developer grant bounty. It would also help ensure that high-stake proposals approved on OpenGov serve public interests and common good, rather than private interests and other predatory backdoor deals.

Increasing the minimum Support Turn-Out will help ensure that only well aligned proposals that really engage the community make it through and are funded / approved.

In a decentralised slow-moving community like the one around OpenGov, there is no real consensus on what alignment looks like a priori. Instead, alignment is decided upon during voting by anybody who happens to be interested in participating. This is what makes OpenGov an “open-ended” system, and this is what appeals to a lot of proponents.

Increasing the support thresholds would introduce a subtle form of gatekeeping that will primarily in favour those who are already operating inside the Polkadot ecosystem. This seemingly simple change could also suffocate the dynamic nature of OpenGov by amplifying the hold that a few high-noise or high-signal people exert on the direction of Polkadot.

To get “well-aligned proposals” that “engage community to make it through” while keeping opportunistic actors at bay, a proper on-chain reputation system is needed. It has been close to 3 years since OpenGov went live, but nobody seems to be interested in delivering such a critical piece of decentralised governance infrastructure.

Thank you for reading until the end.

5 Likes

Full support overall, this could be a good path.

The most interesting thing is that these changes, along with initiatives like the recently proposed OpenSync, greater focus and transparency on bounties, etc. could all lead to more optimal mechanics and experience for all participants.

Keep the great stuff up.

(just started a photoshop course recently :smiling_face_with_sunglasses:)

Any time you are trying to set something in terms of USD amount, you are adding more complexity. Specifically, you’ll be adding a dependency on the oracle(s), which is yet another attack vector and means that you need to either trust a third-party oracle or put a price oracle in at the runtime level. Both of these possibilities have drawbacks that outweigh any benefits, IMO.

I agree that the lack of stewards/mentors is a problem, and in an ideal world we would have them. However, sadly, we do not live in an ideal world, and finding the resources for this does not seem feasible at this point. This seems like a way to move in the right direction with (IMO) minimal damage to those who want to participate in OpenGov. I’d even argue that it is a good thing that you have to start learning how OpenGov works a bit (including the offline parts) in order to participate, as a way of ensuring that people are really interested and not just spamming the chain.

It’s similar to how I will take a hand-written note more seriously than a ChatGPT-generated email, even though they may say the exact same thing. The note shows that the person was serious and put some time into it.

3 Likes

I see the issue with the long waiting time (i.e. something being posted and only the SD being submitted, since it’s so cheap, and the real purpose is just to advertise/spam), but sometimes it takes a while to get the DD from others, especially for high-DD tracks like Root.

I think the solution is that most apps (outside of developer apps like PJS App) should not show Referenda that don’t have a DD placed.

4 Likes