OpenGov on Polkadot: Reflecting on the Payment Issues from Kusama

1

OpenGov is now live on Polkadot, a milestone we’ve reached thanks to the concerted efforts of our community. As we embrace this new era of governance, it’s crucial that we take into account the experiences and learnings from our sister network, Kusama.

Lessons from Kusama’s OpenGov Experience

Kusama’s foray into OpenGov highlighted some important issues. Notably, proposals that requested substantial funds often faced difficulties in gaining approval. After extensive community discussions, a common conclusion emerged: Full funding amounts were allocated and spent completely upfront, without a clear mechanism for tracking the progress or milestones of the proposals.

That sounds insane right?

Inviting Solutions to Funding Challenges

I believe that we need to address these issues to ensure that transformative proposals requiring substantial funding can succeed on Polkadot. In light of this, I’m inviting all members of our community to put forth their ideas on how we might refine and improve this process.

A Potential Solution: Hybrid of Referendums and Bounties

To kickstart this conversation, I’d like to propose a potential solution: a modification of the treasury module to create a hybrid model that combines the elements of referendums and bounties. Here’s how it might work:

  • A referendum would be created for each spending proposal, similar to our current system.
  • Instead of allocating the entire funding upfront, funds would be released as project milestones get approved by a curator.
  • The curator would be also assigned as part of the proposal
  • Curators could be sought for example from the ever-growing Auditor community

This approach allows us to keep the democratic approval process of referendums, while introducing the structured, milestone-based delivery of bounties. By tying funding to project milestones, we can ensure ongoing progress before the full funding is disbursed.

Invitation for Community Input

I believe that this hybrid model could provide a more effective way of handling substantial funding proposals. However, this is just one potential solution among many. The strength of our community lies in the diversity of our ideas and perspectives. I’m eager to hear your thoughts, suggestions, and feedback.

Let’s engage in this important conversation. How can we enhance our funding process to increase the success rate of proposals and ensure the efficient utilization of treasury funds?

Looking forward to a constructive and inspiring discussion!

EDIT - this post was flagged by spam. Not sure what is happening?

4 Likes
2

Hey @JoakimEQ,

Thank you for pushing the discussion on this. What you propose sounds an awful lot like the payout bounties discussed previously.

This is the effort @ChrawnnaCorp is referring to when he talks about me trying to “centralize all payments through a single bounty”. It is still unknown whether this is deliberate ignorance to help Jay’s own motives or whether he actually didn’t bother to properly read up on the topic.

Either way, after being labeled an authority grifter on AAG and the host using the platform to spread misinformation on the effort, I received hate messages from anonymous users. With no support from the community, things naturally died down.

It is nice to see that people are independently coming up with the same solution to solve our spending issues and I hope the discussion around this picks up again. May we collectively find best practices to ensure sustainable treasury spending!

4

I want to ask again that you please stop randomly tagging me, gabe. It borders harassment. Probably if you had a strong idea you may have engaged in the early discourse instead of becoming upset (even 6 months later).

I am wary, Joakim, of suggestions to install new councils, even with limited powers. It seems to me like a reversion – a solution by centralization.

In line with your general idea here, however, it would be handy to have the option to bind funds in a bounty. This could be especially useful in situations where there isn’t a strong relationship between spenders and holders. The mechanism for electing these curators for each specific proposal would also be useful. A regular official curator council would be foolish in my opinion.

For now, though, with ample room on each track, this milestone based funding can be achieved by submitting regular proposals following the completion of promised work.

If we want to install gatekeepers of any sort they should be absolutely necessary, have extremely limited powers, defined term limits, and be held to a very high standard of transparency.

1 Like
5

You misunderstand the ebb and flow of “decentralisation and centralisation”.

The treasury is a centralising force.

Delegating funds out to teams decentralises again.

Those funds are effectively then centralised once again and then decentralised again in those teams.

It is fractal - imagine the way a tree forks. This is true pretty much everywhere we look.

Secondly, curators / administrators fulfil varying roles - right now the most urgent gap to fill is a legal one, without adding in some administrative entity adjacent to treasury spending and invoicing, the treasuries exist in a legal no man’s land.

This is true of the vast majority of DAO treasuries.

The worst case scenario given regulatory scenarios is they become effectively unspendable.

Given the right legal structure (such as a trust), administrators exist to enact the will of the DAO, nothing else, so you can call this centralising for compliance purposes but it would have no effective impact on the decentralising force of spending in the way I think you are concerned about.

6

The human urge to justify centralization (around oneself). What you read and what I wrote are not the same.

1 Like
7

Genuine question - do you see the fellowship, or a media collective receiving treasury spends as a centralising or a decentralising force?

How about KappaSigmaMu - and the burn?

8

For the collectives forming I’ve been encouraging anyone actually building them to be sure reputation can be lost as easily or easier than gained.

9

I understand your caution about leaning too much on centralization. But remember, history shows that pure direct democracy can hit roadblocks, especially when groups grow larger and tasks get complex. Some level of representative decision-making becomes a necessity - it’s not a step back, just a practical move.

Getting everyone involved in every decision sounds great in theory, but it can slow things down in reality. This isn’t a call to abandon decentralization. Quite the opposite. We just need to find a good balance, and focus on what’s practical and efficient.

Speaking of practical, your idea about milestone-based funding is spot on. It’s a great way to monitor progress and ensure our resources are put to good use. This isn’t about central control but about transparency and accountability. We reward good work and everyone can see where the funds are going.

However, we need to face the facts: Treasury proposals on Kusama show that opengov tends to move to an equilibrium state of nothing moving forward. We need to fix this. We have already seen the burden of having to do constant referendums on Kusama as well and now that is not the way forward.

So lets create a new OPTIONAL setting for treasuryspend referendums that allow for a bounty proposal and custom curator to be assigned.

1 Like
10

An option would be great for situations where tokenholders are wary of proposers but want to give them a shot. Do you have the means to submit a feature like this?

We actually already have safer forms of centralization built into the system that could be leveraged before leaning on top-down bounties… We are not one person one vote like some historical direct democracies; weight is proportional to tokens held. Power can be further concentrated from the bottom up (and most importantly quickly removed) through delegation – a system many are working on but could use more user friendly work!

These heavy voters (with the most to lose) may have temporarily halted progress for some spends on Kusama but this is an extremely new posture and hasn’t permanently broken anything that needs to be fixed through central councils. Spend proposers have been slow to adjust from the free flowing optimism of the Gov1 Council to reactive conservatism of tokenholders… But tools to organize builders around productivity to be paid later, systems for accounting, treasury brokers to help projects present work for retroactive funding… all this work can be done to reduce friction while keeping the market open and free from the rot of centralized institutions.

Using centralization only as a very last resort takes a lot of creativity but will ensure the longevity of the network. So far I appreciate your thoughts on this matter and would love to have you on the AAG panel any time you’re available.

But beware of anybody who spends all day on the forums pointing at problems and suggesting centralization as the solution!

1 Like
17
  1. It would need to be a PR on the substrate repo. You can see an example here for multiasset treasury spending: MultiAsset Treasury Spend Over XCM. Companion PR for Substrate #13607 by tonyalaribe · Pull Request #7058 · paritytech/polkadot · GitHub
  2. What are these safer forms of centralization than the ref → bounty hybrid I proposed?

In general you seem to point out centralization as some kind of pure evil - not sure why you think this is the case. This kind of logic can easily pointed out as false.

For example, if the chain halted and we needed to quickly perform some kind of upgrade that required a referendum - not moving as fast as possible with that would cause irrepairable damage. Suddenly the slowness of decentralization turns “evil”.

Be careful when thinking in absolutes. The overall thesis of decentralization is deep in all our hearts, but when we want to think about achieving things, we need to be ready to move on the scale of decentralization and centralization in an agile way where the net benefit to us is greatest.

1 Like
18

Indeed I wasn’t speaking in absolute terms when I covered some precautionary measures in situations that need a little more centralization…

The fellowship which is a more centralized structure covers the scenario you bring up, for example.

I personally believe individual organizations need central power to get rolling. More or less it seems to me that individuals push into the unknown while the crowd maintains it. Smaller orgs can go on happily as highly centralized without introducing risk into the system.

Centralization has the eventual risk, however, of corruption either by greed, death, insanity :stuck_out_tongue:

Decentralization removes single points of failure.

In a scenario like the one I was tagged in here for – centralizing all spends through a small bounty council for distribution by the very few – this is a prime example of lazy centralization to solve the drawbacks of early open participation.

Like I said though, an option would be great for specific scenarios.

Also, if you haven’t been following the SEC saga, centralization makes it easy for regulators to slap us with any rules they want. Decentralization makes that difficult.

19

Hi Everyone

Sam from Imbue here.

Thanks for raising this discussion @JoakimEQ, it’s one that’s dear to our heart

Imbue at its core is milestone-based vesting of funds. We have been built from the ground up with a focus on accountability

We actually built functionality to solve this problem that we hope to showcase on AAG over the next 2 weeks.

The way it works for a treasury is straightforward, we just call treasury proposals grants

1. Alice is applying for a grant/proposal, she start by defining how much she needs and her milestones 
2. Alice also defines approvers. These are people who are subject matter experts who can validate her milestones and verify that it meets the quality expected. 
3. Alice then applies for the treasury proposal and details what she will be using the money for and - crucially - who the approvers are
4. Once the proposal passes the funds are deposited into an escrow account
5. Alice submits milestones and the approves vote on them, Once the vote passes Alice can withdraw that milestone
6. Most importantly, if Alice seems to not be delivering on her promises any and all the approvers have a right to raise a `Vote Of No Confidence`. This opens up a vote for all approvers similar to a milestone vote however if this vote passes the remaining milestone funds (all unapproved milestones) get refunded back to the treasury

We think this is a cleaner approach than the centralised issue of curators because each treasury proposal can have different approvers and so it should be because each proposal could be trying to fix a different problem

For example, I might be qualified to look at a milestone tech delivery using standard well-defined metrics such as

* Is the code well written and maintainable
* Is it covered by tests
* Potential bugs and/or exploits

Conversely, I might not be qualified to look at the “quality” of content or designs that’s delivered because I do not have that creative eye

We are really keen to showcase this but for now, I can leave a screenshot of one of the screens for a grant that is being delivered

image
image1920×3417 247 KB

Finally, while this has been designed for a substrate native treasuries, we can see this technology being much needed in other ecosystems and would go a very long way to driving adoption by working alongside other ecosystems and most importantly answering the “Why Polkadot?” question which seems to be the biggest sticking point when it comes to new users

2 Likes
21

Why does it need to be a seperate chain rather than just a new treasury function extrinsic?

@sam

22

It doesn’t need to if we are talking about only kusama/dot treasuries, you can amend the current treasury pallet to do the very same thing

Although for now, our grants pallet is Kusama-specific - it can easily be ported over to any other chain including Polkadot when we win a slot. Everything remains the same except the Origin because thats how we issue refunds

Our goal here is for this to become general purposes so any treasury across web3 can use it, not only kusama and polkadot, that’s why you need a dedicated chain.

We are trying to move functionality away from the relay chain and into dedicated parachains. Hence why we never planned on amending the treasury pallet for this

I hope that answers your question