Kusama Treasury Analysis & Reconfiguration

Nice work Adam, its great this topic is finally being actively debated.

Summary from your points:

  • Current spending is unsustainable
  • Therefore slow spending through hardcoded limits rather than social
  • Shift into stable assets (how this might be done is an interesting secondary question)
  • Stop / Repatriate KSM from Society per @RTTI-5220

Then @CoinStudio goes further:

  • projects pursue smaller, milestone and delivery based proposals

And finally @tom.stakeplus presses on a different aspect of the treasury

  • Revenue, aka how does the network grow its existing pot via staking and spend the proceeds.

There is a final point which hasn’t been discussed enough but plays to all of the above points which are all really sticking plasters on a deeper set of problems:

  • What kind of ROI should the treasury be looking for with its funding?
  • How should we value treasury spending?
  • How do we attribute that value - e.g. how do we make the subjective, more objective?

This then leads onto a much bigger question - what is the treasury for?

It will really help to pause and consider this - it should be fairly uncontentious to say that the treasury exists to ensure the survival of the network.

Ultimately the largest demand drivers of KSM(or DOT) are parachains - it was their crowdloan campaigns that were the marketing of the network, and therefore the mechanism that drove the token price and created the treasury in the first place.

With parachains mostly now purchasing slots for 97%+ less than peak, this same demand driver doesn’t exist. Ultimately the security-as-a-service proposition and economic model is bound to the demand for slots and therefore the demand for KSM that is locked up.

All treasury funded marketing to date has been focused on driving general awareness, without a potent mechanism such as crowdloan behind the media. The hope has been that this ultimately translates into new and successful parachains. That’s the end goal of it all if you strip it all back.

Either this model needs reigniting - by the treasury, or there needs to be an entirely new investment model that backfills the gap and provides some new narrative for why KSM has value.


Hi Adam, nice to see the proposal formalized :slight_smile: I think it makes total sense to introduce some form of budgeting to our treasury spending, no government or enterprise would last long without any control over how their finite resources are used. Limiting the bandwidth of our spends as your proposal suggests is crucial and needs to happen, but something I would consider adding already that is more important when budgeting is to accompany the spending with goals/purpose/direction/vision, with some mechanism to allocate resources where they are needed the most. Imagine you are planning a trip to Europe and decide to limit it to 5K, the limit would be pointless if you use most of your budget going in first class and don’t leave anything to even afford the cheapest hostels or go to any restaurant.

One way I would suggest we can adjust the proposal that would enable this goals based spending is by defining treasury spend tracks not based on amounts but on the category of the spend(e.g. media, events, marketing, wallets, core tech, r&d, etc.), the limits on each track should add up to match the bandwidth you proposed, we can start with a balanced division or discuss a bit more to have a general sense of what topics could have more priority based on our short term needs(e.g. do we focus on positive revenue?), it doesn’t have to be perfect but just a starting point that would be adjusted over time.
As side note, I know bounties serve a similar purpose but it’s just my personal opinion that OpenGov and its delegation system should deprecate them or we should evolve them to overcome the centralization around curators(e.g. with curated payments). Another advantage of separating tracks by domain is that delegation per track starts to actually make sense as domain experts can finally campaign for specific tracks making the most use of their expertise, a marketing expert can ask for delegations to the marketing related track(s) instead of pretending to understand a complex big spender proposal about a core technology.

If people like the idea, a couple of minor non very functional additions I would introduce with this change that builds on this notion of having goals and clear objectives similar to how companies define OKRs is to first include a scheduled remark, say in 2500000 blocks(~6months), that states our main goal for the semester and also acts as reminder to review our governance parameters and adjust them(with a new objective remark). The second change would be to add a new goal property to the TrackInfo struct that shortly describes the track but most importantly states the track’s current focus or priority, e.g. a BigEventSpender with goal: "Only sunny places with canaries", suggests voters to reject igloo parties organized by penguins :stuck_out_tongue_winking_eye:

If any of this make sense I’d be happy to formalize the changes and help in any way necessary to bring this referendum on-chain, perhaps with the help of other non-parity/non-big-funded-team fellowship members whom also live off OpenGov and the treasury(@sam?). I simply think a long due milestone we need to overcome in the spirit of decentralization is for the community to propose its first runtime upgrade independent of Parity’s usual workflow. This proposal with low technical complexity and with very little risk to brick the chain can be the perfect test case.

P.S. Out of curiosity, would the linear regression look the same if counting not from block 16,000,000 but around 15,500,000 which is about the time OpenGov was introduced?


Great idea – if possible, I would suggest tying this idea to @joepetrowski 's advice in setting up collectives with their own budgets:

  1. create 4-10 collectives that map onto categories of existing proposals (e.g. “ux”, “events”, “indexing”, “bridges”, “tools”, “education” …). I also recommend a “r&d” one to allow diverse innovation that doesn’t quite fit into an existing TrackInfo
  2. have the community approve quarterly (semesterly?) budgets each collective responsibly, cognizant of the revenue + income.
  3. each collective spends their budget on their charter (e.g. events), and should be expected to aggregate reports to have budgets either stay the same, increase or decrease each quarter (semester).
  4. collectives should devise mechanisms for spend recipients to be competitive with each other for some % of the collective’s spend (see how Moonbeam does it here). I believe around 30% should be reserved for newcomers, otherwise you end up with a stagnant military-industrial complex funding the same 3-5 beneficiaries and this community is supposed to be about innovation.

This ‘indirect democracy’ type solution has the community voting for budgets on tracks rather than proposals. In my country, I would like it to spend less on the military track and more on the education track, but I myself have little idea on how new military/education dollars should be spent on specific proposals – I’d like to leave it up to the military collective and education collective, who work with the budget that they are given.

In the same way, I may believe that the UX Tracks + Bridges Tracks should get more DOT or KSM at the expense of the Indexing Track. If the UX Collective rationally allocates their funds to Dotswap UIs at the expense of Wallet teams, and the Bridge Collective makes rational decisions about how to allocate between Snowfork, Centrifuge/Axelar, Darwinia, T3rn proposals (say) – but always within a certain budget, then you win sustainability in the aggregate (with budget controls) with rational decision making shifted to the individual collectives. You would expect the Bridge Collective members to be smart enough to know how evaluate bridge security solutions, the UX Collective to know how important different UIs are and seeing how they fit together, similarly for other collectives. Then, both the community and the N Collectives switch from lots of “yeah, this seems (un)reasonable, I guess… Aye! (nay)” one-off decisions to a smaller number of “ok, we have to allocate more here and less there because ___” both at the community level and within the collectives.

The expectation is that people would be making smaller numbers of more important decisions with this change. At the community level, people would be expected to have intuitions about how to shift budgets between tracks rather than proposals; At the collective level, people would be expected to to have super informed judgements about how to allocate finite budgets to specific proposals.


Question re your points @olanod @sourabhniyogi related to the ‘domains / collectives’ question.

If we begin with outcomes, rather than activity, do we not push towards more meritocratic and objective ways to value spend - ultimately we want to get to a place where anyone can arrive - without rep, or history and prove some effective new approach, and not have to jump through hoops pleasing the incumbents (whoever they are at that time).

imo this is what R&D funding is for per the above note - it’s for kickstarting this journey to impact.

This is what true decentralisation looks like - else we’re always pushing the can down the road.

New ideas necessarily look stupid, weird or don’t make sense to the incumbents - or they would be doing them. The exciting thing about Kusama’s potential innovation cycles is we can design for this cycle to keep turning, without creating the sort of military/media industrial complex you note Sourabh.

It makes most sense from a network scaling perspective for voters to back directions that they believe will have the most impact over time.

There can be reputational and even economic upside for those who back the directions that prove objectively to be the most successful over time (this is how we get to prediction markets/futurarchy)

Ultimately this is then driving the collective intelligence of voters towards a more educated investment mindset.

There are still many sacred cows we need to slay - if we continue to coordinate groups based on delivery of an ‘event’, or ‘a podcast’, or a ‘wallet’ (infrastructure), and those initiatives are all delivered successfully via milestones, but end up having no practical impact on the network, then is it not more wasted spend?

There is clearly a continuum here, but we should aim for collectives to be assessed directly on their network impact over time, with associated reputational upside and remuneration.

There are naturally people/projects who have benefitted from existing spending processes - there will inevitably be tensions as the impact of that work is reviewed, but this also needs to be seen as course correction - talent should be retained, ideas that don’t serve, should be thrown out.

This is not an easy process to push through - it will be delicate, people will take things personally, but there is wisdom in the adage, cut once, cut deep when it comes to organisational change.

This all roots back to a very simple question: what is the treasury for?

1 Like

This forum post is awesome @asteeber. Thanks for putting it together.

There have been a lot of separate discussions regarding treasury improvements lately and it is nice to see it all come together here and concrete solutions being put forward.

The last 2 comments above this one by @sourabhniyogi and @rich absolutely hit the nail on the head imo.

What do technical solution for the collective-based approach as well as meritocratic spends look like and how do we implement them (along with other changes proposed here)?

As @olanod mentioned it would be amazing for the community to come together to propose its first runtime update independent of Parity’s usual workflow!

Exciting times! :fire:

You’re speaking my language ser…

from last week:

1 Like

I would love to see both the community and the collectives both using the same mechanism that solves a lot of the problems identified – for me a great candidate is Gitcoin’s Quadratic Funding, where QF does seem to address the committee+innovation stagnation/whale domination/hoop pleasing/… problems. But, we need to combine QF with collectives.

My test case for Quadratic Funding (QF, or anything else) is this:

  • an actual proposal P that 80% of the community would not understand (e.g. literally, a Quadratic Funding pallet) requesting 3K-10K KSM
  • however, P would be considered in one or more track collectives who each have 10K KSM quarterly budgets
  • each of Collectives (plural) is composed of two different kinds of people: Brahmin Whales and Untouchable Shrimps – where the Brahmin Whales put N% of their voting power behind the existing Governance Tools but Untouchable Shrimps put 100% of their voting power behind P.

Question: How is it possible with QF that a 20% minority of Untouchable Shrimps in the collectives could put 100% their voting power behind P and get P funded @ 1K-10K KSM out of the 10K KSM budget?

Claim: Someone can generate a precise answer to this question this using past Kusama governance data, using actual participation numbers from Brahmin Whales (defined in terms of KSM) and Untouchable Shrimps inside different kinds of collective make ups, and use this to guide a QF pallet design (or something else that is better) that ensures P gets funded at 1K-10K KSM for some realistic value of N.

In my country, we have a Green Party and Libertarian Party that can never make a real impact against the dominant parties (Democrats and Republicans) – literally every proposal is suffocated well before or at the 50/50 mark. QF seems to be able to be able to give the Green Party’s climate change agenda (or the Libertarian Party’s military funding reduction agenda) through collectives, but if you have only ONE collective, that collective would be stuffed by Brahmin Whales with the equivalent of Big Oil / … defeating the Green Party agenda (or the equivalent of the warmongers of the military industrial complex defeating the Libertarian agenda). And if you have multiple collectives, maybe those same entities would stuff multiple collectives – where QF doesn’t work if Brahmin Whales outmaneuver the agenda of the Untouchable Shrimps by increasing N to 100, right? But it works if those same whales have to split their vote into lots of different places. Thus, my test case + question.

The community’s default behavior will be to stuff every collective with Brahmin Whales (with PhDs, experience) – they got us here, after all, right? But the same community needs to support new ideas, and recognize that new ideas/pallets/… have to replace the old ideas/pallets/… Next generation QFs needs to bring in the concept of competing collectives and have a hedge against the excessive power of Brahmin Whales that historically dominate democracies. Then, potentially, the equivalent of the Green+Libertarian Party can actually get somewhere by having their own collectives maybe composed of Untouchable Shrimps. Then the community who actually sees the excessive power of Brahmin Whales as getting in the way of Untouchable Shrimp agenda would taking their QF voting power and reassign it to these “fringe” parties.

Having multiple collectives seems overly complicated, but we can be amazed that a bunch of young people in the late 1700s already thought about these exact “how to represent the minority” problems pretty deeply, from multi party systems right down to a disgusting number “3/5” to model the Untouchable Shrimps, super cognizant of the power of Brahmin Whales. While I use the caste system metaphor pejoratively, some Whales will support the Shrimp agenda often enough that it can work. If any blockchain community can do it, its gotta to be this one –

If real governments can put Ranked-choice voting in front of people, I believe QF could as well, to innovate past the 50/50 mark, and show the world how the Green + Libertarian Parties of the world can actually make progress despite being in the minority. The Kusama treasury can go to 0, but for whoever is building this, if it can contribute to future democracy well outside here (for Polkadot but really, any governance system), its a great ROI.

1 Like

This is an outstanding post here Adam. I caught wind of this from your twitter post today and decided to see what was going on in the forum it appears that we are discussing a few different topics here:

  1. Avenues of increasing revenue
  2. How to effectively disperse treasury funds
  3. On Chain Treasury Management

Avenues of increasing revenue

I think staking society funds is an outstanding idea and if 120K KSM is indeed there, then that makes a ton of sense to force transfer and begin making some revenue for the treasury. Staking a portion of the KSM currently in the pot is also another good consideration. I have a few thoughts on the current treasury revenue that will also bridge into the last point on broader treasury management

  • Purely staking a certain percentage of the current treasury and choosing nodes as Adam has selected above
  • Reserving this percentage of network KSM for new nodes onboarding into the network. Much like the 1K validator program rotates funds between new validators - however it will be more KSM and could also be a source to increase decentralization and stake for a longer period of time than the current program
  • Open to other ideas on selecting nodes or onboarding new nodes to increase decentralization and inclusion of community nodes

How to effectively disperse funds

This is actively being worked on by multiple teams in multiple different ways. No doubt there will be growing pains, but things we can build from as we all see this as a significant problem. I also suggest that for many of the infrastructure plays or even some of the largest spends could be retroactively rewarded based on end delivery; we should consider a RPGF model much like Optimism has done within its ecosystem. Please read this post here to learn more. This is different from a milestone based approach. Incentives are not expected, but possible. Imo this can drive higher quality than setting your own milestones

On Chain Treasury Managment

I think for this, HydraDX/Basilisk is an outstanding option to trustlessly provide liquidity and recieve trading fees that can be transferred right back into the treasury. With their DCA options and OTC trader features going live soon, it can be a full suite for on-chain treasury management and uniquely DotSama (yes I said the D word).

Again, great post and I like the idea of focusing on increasing revenue as well

I’m curious how the Kusama treasury drain will be affected once Polkadot gets gov2. There’s exponentially more funds in there and I would think many people would start submitting proposals on Polkadot once gov2 is added to the runtime.

Lots of great discussion going around this topic! I think we’re all leaning toward restricting the bandwidth of the spending tracks in a runtime upgrade.

One thing @RTTI-5220 asked me in the Polkassembly post on the Kusama Treasury Staking Configuration is if I’m in contact with the runtime devs to see if these changes can be merged without breaking the runtime. To answer that, I really don’t have a foot-in with Parity or the Fellowship and nearly every PR I make on Github receives no technical feedback on whether it will work or not.

I don’t think we can rely on Parity to make any such changes. Rather, we should try to piggyback on a Parity runtime release. For example, once the Fellowship whitelists the runtime upgrade to 9410 we fork that release, include the track reconfiguration, prepare the runtime using srtools, then test the runtime upgrade with Chopsticks or something else. Then we can submit a system.setCode referendum in the root track and provide the receipts in the Polkassembly post.

It’s going to be a lot like jumping onto a moving train - Parity and the Fellowship will likely not accommodate these “trivial” changes in the spending tracks and will not wait for us to prepare a runtime before they release 9420. Since the Fellowship will likely prepare the next runtime upgrade very soon, we either do this ASAP or wait until 9420.

Track Change Recommendations

I’ve noticed a few ideas around how we change the tracks, ranging from drastic changes to modest changes. I’ll try to capture them all here (in order from less drastic to more):

Do nothing (most likely scenerio IMO)

Honestly, I don’t think the ecosystem will ever agree on how to restrict spending, so the Treasury will be drained within a year. Oh well!

Not to say we shouldn’t try! But this is how we should set our expectations to avoid giving ourselves false hope.

Coinstudio - restrict existing tracks

name: "small_tipper",
	max_deciding: 20,

name: "big_tipper",
	max_deciding: 10,

name: "small_spender",
	max_deciding: 10,

name: "medium_spender",
	max_deciding: 2,

name: "big_spender",
	max_deciding: 1,

This option simply decreases the existing tracks’ max_deciding numbers and changes nothing else. I think this would be the easiest to sell the ecosystem on.

ChrawnnaCorp - add event_spender track

name: "event_spender",
	max_deciding: 50,
	decision_deposit: 400 * QUID,
	prepare_period: 4 * HOURS,
	decision_period: 14 * DAYS,
	confirm_period: 48 * HOURS,
	min_enactment_period: 24 * HOURS,
	spend_limit: 7_777 * UNITS

This is a babystep into the domain-specific track configuration by adding an event spender track.

My recommendation - deprecate current tracks and create far more restrictive general spending tracks and stop Treasury burning

pub const Burn: Permill = Permill::from_perthousand(0);

name: "budgeted_tipper",
	max_deciding: 10,
	decision_deposit: 400 * QUID,
	prepare_period: 4 * HOURS,
	decision_period: 14 * DAYS,
	confirm_period: 24 * HOURS,
	min_enactment_period: 24 * HOURS,
	min_approval: 50%
	max_spend: 100 * UNITS
name: "budgeted_spender",
	max_deciding: 2,
	decision_deposit: 400 * QUID,
	prepare_period: 4 * HOURS,
	decision_period: 14 * DAYS,
	confirm_period: 24 * HOURS,
	min_enactment_period: 24 * HOURS,
	min_approval: 66%
	max_spend: 2_500 * UNITS
name: "treasurer",
	max_deciding: 1,
	decision_deposit: 1 * GRAND,
	prepare_period: 2 * HOURS,
	decision_period: 28 * DAYS,
	confirm_period: 48 * HOURS,
	min_enactment_period: 24 * HOURS,
	min_approval: 66%

These are some pretty drastic changes and will restrict spending more than anything else. However, I don’t think this would pass a vote.

Include a robust selection of domain-specific spending tracks

I can’t really provide the exact details of what this would look like, but essentially we work out how to configure tracks for Media, Events, Hackathons, UI, Infrastructure, Governance, Philanthropy, Business Development, R&D, Marketing, Bridge, Education, Indexing, Tools, etc. To me, this will be very difficult to deliberate on. What topics do we need? How specific/ broad do they need to be? What should the spending limits for each one be? How can we back up these decisions?

I think it would make sense to copy something like the big_spender track for each domain and essentially have no spending limit - sort of like the current configuration. However, this wouldn’t put a hard cap on spending and we’d likely see the same spending trajectory despite some points made on how recent spending isn’t reflective of our actual trajectory.

So folks, how shall we proceed? Any other ideas we should consider? How can we act now?

P.S. Who’s going to place the 3,333 KSM decision deposit in the root track to get these track changes actually voted on?

1 Like

One thing to take into account is this “special calls” that were included on Treasurer track in the OpenGov model: they should be accommodated somehow on one of the new tracks if we want to use this mechanism - I am talking specifically about bounty approval and curator approval calls.


Hi everyone, just to add some context to the great analysis @asteeber shared.

We’re tracking Treasury expenditure, amongst other data points at Parity (Data team) and have also some numbers and dashboards on this exact topic. I’m sharing these to add some context to the discussion - not to change the topic.

As far as the linear regression goes, if you only account for the last 3 months of treasury expenditure, we come to the exact same conclusion (mid November 2023).

However, when running the linear regression on a longer time interval (roughly 1 year), things look a little bit different which might hint to some seasonality in the data.

This gives us a “Zero date” of roughly March 2025, when looking in a yearly cycle.

In terms of data points to help support this discussion, we’re happy to help if you tell us what data you need to have a full picture of things. We’ll share more of these dashboards & data with the community going forward. :hugs:


Hey Adam,

I appreciate the details you provided in your post. Given the importance of these discussions, I encourage you to take this work further through a treasury proposal. This would allow you to fully focus on research and experiments, ultimately enabling you to propose concrete options along with their associated risks.

I am interested to see a smaller-scale experiment with your approach. I also beleive that further research and evaluation of the option I proposed to restrict existing tracks is necessary, as it doesn’t take into account potential issues such as people spamming tracks with false proposals, which could lead to a need for changing deposit requirements. I am also quite interested to see the actual numbers regarding real ideal staking calculations and the percentages of inflation split between staking and treasuries in various scenarios.

For the reasons mentioned above, and to ensure this initiative doesnt get lost in the discussion, I am in favor of supporting this initiative in the form of a treasury proposal that will provide concrete answers.

Below is my reply to your proposal on Polkassembly:

As I already mentioned, I truly appreciate your dedication to moving beyond mere discussions and presenting a practical solution. It’s always refreshing to see a proactive approach in action.

I believe it would be beneficial to conduct a smaller-scale experiment on this case before fully committing to the proposal. This would allow us to gain valuable insights, assess potential risks, and make any necessary adjustments to the approach. Please have a look at the proposed steps (sent you .doc on Element):

Milestone 1: Proposal Preparation and Community Feedback

Task 1.1: Present a new proposal during the discussion phase.
Task 1.2:  Present the working budget, incorporate the research hours spent into the proposal.
Task 1.3: Request a smaller test amount of 100? KSM.
Task 1.4: Align the proposal with feedback from experienced community members like Joe, Kian and Raul.

Milestone 2: Research Expansion and Scenario Analysis

Task 2.1: Expand existing research on staking Kusama Treasury funds.
Task 2.2: Present projected trajectories under different scenarios.
Task 2.3: Go deeper into ideal staking calculations.
Task 2.4: Cross-check findings with developers and confirm the proposed calls
Deliverable 2.1: Comprehensive research report with scenario analysis and calculation validation.
Deliverable 2.2: Completed and revised proposal document, incorporating all tasks.

Milestone 3: Test Case Execution and Evaluation

Task 3.1: Stake the allocated 100 KSM from the Treasury.
Task 3.2: Monitor the staking process and document any issues or observations.
Task 3.3: Analyze the impact of staking on rewards for the rest of the ecosystem.
Task 3.4: Evaluate the success of the test case based on the project's objectives.
Deliverable 3.1: Test case execution report, including findings and recommendations for future implementation.

Milestone 4: Community Engagement and Final Reporting

Task 4.1: Share the research report and test case findings with the Kusama community.
Task 4.2: Gather feedback and address any concerns or questions.
Task 4.3: Prepare a final report summarizing the project's outcomes and recommendations.
Deliverable 4.1: Final project report, incorporating community feedback and suggested next steps.

Hi ThomasR,
Is there a breakdown of the treasure spending of the last years. Like which percentage is used for what?

You should read this

So after reading and most important LEARNING what’s going on with the Treasury, there is one fundamental issue:

A- We reward the whole requested amount in a single tx !!!
This should definitely STOP now.

1/ If people are known and have already proved themselves they can deliver milestones, then i’m good.
2/ If they are new/unknown from anyone, then this should not happen.
Let’s say some say:
I want to do this for 10k KSM, provide this tool with these features, in 6 months.
→ I would recommend to have a review process and deliver KSM only after each milestone is assessed/evaluated.

We have now to many examples of people delivering nothing, or being proved to be unused/useless.

Treasury request should now all include a boolean:
Do i want full payment or progressive payment ?

Full payment should be evaluated veeeeeerrryyyy carefully.
Porgressive payment after each milestone (could be in time -after x weeks-, or in feature -after delivering this or that)

How is it possible to implement such a simple thing ?

B- I think we definitely also need to stop funding content creators for specific language content.
It proved to be completely useless.

Several thousands of KSM for Hindhi content ? For Spanish videos ?

Wagmedia can do the same in a better efficient way, involving the community, and requiring way less KSM than these KSM grifters.
Zeitgesit made a bounty so that they can get subtitles into different languages

Result ?
In 1 week everything was done for 4 videos in at least 6 or 7 languages for a few hundreds dollars.

C- Karura’s 20k KSM for aUSD collateral ?
It was a pure gift, with no ROI. 0 return. It’s like we just gave them 20k KSM for nothing. I hope everyone feels rekt for this move.
Borrowing should be the only accepted request (like Bifrost did) to build liquidity.

My personal conclusion
If we ALL start thinking differently, then we’ll definitely change the wrong path the Treasury spending is going.
We all need to be much more reluctant to spend funds.

1/ Better to spend smaller amounts several times (if someone proves to deliver), than a big one-shot/gift of thousands KSM for someone that proved nothing before.
2/ Stop funding useless translation contents or even educational contents, not Treasury’s goal. It can be done indirectly with team like Wagmedia that proved to be efficient for this specific purpose.


I completely agree with @ThomasR’s point of view that the delivery of projects within the community should be milestone-based, which ensures that the community can receive high-quality products that match their contributions. At the same time, if there are malicious project teams, the risk borne by the community will be minimized.

In addition, I strongly recommend introducing a bidding mechanism that allows other teams within the community to bid on the products and prices proposed by a project team. When a project team sets a budget for its product, other teams within the community can challenge it in a timely manner, competing with better products or lower prices. A benign competitive environment is conducive to market regulation, which ensures that the community can obtain better products or lower expenditures. This competition is economically beneficial for the community. At the same time, this is also a constraint for the bidding team. If a team has no problem with the product but lost to other teams due to insufficient consideration or greed in pricing, then it will be a loss for them. This approach can encourage more thoughtful and rational pricing decisions.

1 Like

This is a very good analysis. Many project parties applied for a large amount of KSM and DOT, but unfortunately they did not make real valuable contributions to Polkadot, such as Acala Network. Support for such projects should be reduced.



I also completely agree with what you said. Malicious project parties should be punished, vote to reject their parachains, and post “malicious project” tags to them. Some projects claim to be Polkadot projects to scam.

Only a few projects(acala network…) will affect the impression of external users on the entire Polkadot.

WagMedia and its affiliates have received $2m across Kusama and Polkadot treasuries.

Please share any useful information you have for WagMedia’s onchain impact?

If we assume that the spending led to the creation of 100 new addresses for writers, and then those writers articles led to 10 new and active addresses each through the articles they wrote, we get 1100 new addresses and a CPA (cost per acquisition of $1818 per user.

The fact is there is no data to support even that basic ROI, so I’m interested to learn how the team assess the effectiveness of the spending to date?


The irony that this organisation are the ones attempting to defend the treasury from grifters is ironic to say the least