[WFC] Burn-Based Tokenomics for Kusama: The Ethereum Model, Not a Hard Cap

Governance
1

TL;DR: Polkadot chose a 2.1B hard cap. I’m proposing Kusama take a different path: Ethereum-style burn mechanisms that create demand-responsive scarcity. No arbitrary cap — just burns that make KSM scarcer when the network is valuable. Let’s prove there’s a better way.

The Setup

Polkadot just passed Referendum 1710: a 2.1B DOT hard cap with stepped inflation decline. Many assume Kusama should follow.

I disagree.

Kusama is the experimental network. If we just copy everything Polkadot does, what’s the point? Let Polkadot prove the cap model. Let Kusama prove the burn model.

The Problem

Kusama’s current tokenomics are unsustainable:

Metric Value
Inflation 7.82% (perpetual)
Burns Disabled (0%)
Treasury Spends ~7x its revenue
Supply growth 10M → 17.4M in 6 years

Polkadot fixed their problem with a cap. But a cap isn’t the only solution — and arguably not the best one.

Hard Caps Have Problems

  1. Arbitrary numbers — Why 21M KSM? Why not 20M or 25M? It’s marketing, not economics.

  2. Inflexibility — Once set, you’re locked in forever. What if conditions change?

  3. The cliff problem — What happens when you approach the cap? Bitcoin assumes fees will replace block rewards. That’s unproven and risky.

  4. No demand response — A cap doesn’t care if the network is thriving or dying. Same supply trajectory either way.

Burns Are Smarter

Ethereum has no cap. Yet it’s often deflationary because of EIP-1559 burns.

Network Hard Cap Mechanism Result
Ethereum No Burns Often deflationary, $400B+ market cap
Bitcoin Yes Halvings Works, but cliff problem looms
Polkadot Yes Stepped decline New, untested

Burns create demand-responsive scarcity:

  • High usage → More fees → More burns → Deflation
  • Low usage → Fewer fees → Moderate inflation continues

The market decides scarcity, not a preset number.

The Proposal

1. Reduce Base Inflation: 7.82% → 5%

Phased over 9 months. Still pays validators, but less dilution.

2. Multi-Source Burns

Source Current Proposed
Transaction fees 0% burned 50% burned
Treasury inflows 0% burned 10% burned
Unspent treasury 0% burned 3% per period
Coretime revenue 0% burned 25% burned

Estimated annual burns: 150-250K KSM at current activity.

3. No Hard Cap

Scarcity emerges from burns, not decree. As usage grows, burns grow, and KSM becomes scarcer naturally.

4. Treasury Discipline

  • 15% quarterly spending caps
  • Milestone-based funding for large proposals
  • Retroactive grants for proven impact

5. Validator Consolidation

Increase minimum self-stake from 150 → 300 KSM. Let the market consolidate validators naturally.

The Math

Current:
  Gross inflation: 7.82%
  Burns: 0%
  Net inflation: 7.82%

Proposed (current usage):
  Gross inflation: 5%
  Burns: ~200K KSM/year
  Net inflation: ~3.8%

Proposed (high usage):
  Gross inflation: 5%
  Burns: ~600K+ KSM/year
  Net inflation: ~1.5% or deflationary

The more valuable Kusama becomes, the scarcer it gets.

Kusama vs. Polkadot: Different Paths

Kusama (Proposed) Polkadot
Cap None 2.1B
Scarcity Burns Cap + stepped decline
Flexibility High Low
Demand-responsive Yes No
Model Ethereum Bitcoin-inspired

In 5 years, we’ll know which model is better. Let’s run the experiment.

Why Not Just Copy Polkadot?

Because Kusama’s purpose is to be different. To experiment. To try things Polkadot won’t.

The hard cap is the conservative choice. Burns are the innovative choice.

If Kusama becomes “Polkadot but smaller,” it loses its reason to exist. Let’s give it a distinct economic identity.

Questions for Discussion

  1. Is 5% base inflation right? Too high? Too low?

  2. Are the burn rates aggressive enough? Should fees be 70% burned instead of 50%?

  3. What am I missing? Ethereum has way more transaction volume than Kusama. Can burns work at our scale?

  4. Should we add a “soft cap”? Maybe burns + a very high cap (50M?) as a backstop?

  5. How do you feel about Kusama diverging from Polkadot here?

Full Proposal

I’ve written a detailed proposal with:

  • Verified on-chain data
  • Economic modeling for different usage scenarios
  • Implementation timeline (4 phases, 9 months)
  • Technical specifications
  • Risk analysis

Full proposal document

My Take

Polkadot went conservative. They chose the “safe” path with a hard cap.

Kusama should go bold. Burn mechanisms are:

  • More flexible
  • More responsive to demand
  • Proven at scale (Ethereum)
  • True to Kusama’s experimental spirit

Let’s not just be “Polkadot’s testnet.” Let’s be the network that proves burns beat caps.

Next Steps

  1. Gather feedback — Poke holes in this. What breaks?
  2. Refine parameters — Maybe the numbers need adjustment
  3. Build support — If this resonates, help champion it
  4. Submit referendum — Phased implementation starting with treasury burns

This is an RFC. Nothing is final. Tell me why I’m wrong.

Proposal developed through analysis of Kusama on-chain data and comparison with Ethereum’s EIP-1559 model.

7 Likes
The Roadmap for the Dynamic Allocation Pool (DAP)
2

Despite the lack of love for burns on Polkadot, they remain a straightforward way to control inflation and incentivize use. It’s most effective on chains with activity but on Kusama pretty much any experimental changes in this direction are more than welcome specially now that no Polkadot changes will be tested first.

Go for it, launch it and see the impact on a live economic environment.

2 Likes
3

[Update] Burn-Based Tokenomics: Corrected Data & Revised Projections (v1.1)

TL;DR: I made a data error in my original proposal — the “239 KSM/day in fees” was actually treasury inflows. Real fees are ~3.5 KSM/day. The corrected proposal still delivers a 46% reduction in inflation (7.82% → ~4.25%), just with honest numbers. Full proposal linked below.

The Correction

Metric Original (wrong) Corrected
Daily transaction fees 239 KSM 3.5 KSM
Annual fee burns 44,000 KSM 640 KSM
Total annual burns 150-250K KSM ~130K KSM
Net inflation ~3.8% ~4.25%

Fee burns are negligible at current activity. Treasury burns do the heavy lifting (~85% of total burns).

What v1.1 Delivers

  • 46% inflation reduction (7.82% → ~4.25%)
  • Treasury burn with floor: 1% per period, but only above 100K KSM (prevents depletion)
  • Validator set: 1,000 → 500: Per-validator rewards increase 28% despite lower inflation
  • All parameters reversible via governance — this is experimentation, not permanence
  • Burns scale with growth: Infrastructure for the future, even if minimal today

Full proposal v1.1

What We Need From You

@SAXEMBERG — thank you for the early support. You said “launch it and see the impact.” I want to make sure we launch with accurate expectations, which is why I’m posting this correction.

But one voice isn’t enough to pass a referendum. We need:

  1. More scrutiny — I got the fee data wrong. What else am I missing? The proposal is stronger when the community stress-tests it before it goes on-chain.

  2. More voices — Agreement, disagreement, questions, concerns. Silent support doesn’t build consensus. If you think this direction makes sense (or doesn’t), say so.

  3. Better ideas — Should burn rates be higher? Is 500 validators right? Should we phase implementation instead of immediate? The proposal is a starting point, not a decree.

Key Questions

  1. Is 46% inflation reduction enough? Or should we push for more aggressive burns?

  2. Is 500 validators the right number? Maintains security, improves economics. Too few? Too many?

  3. Burns vs. hard cap — Does the corrected (less dramatic) burn model change your view? Is a hard cap more appealing now?

  4. What are we missing? Poke holes. Better to find problems now than after a referendum passes.

Bottom Line

This proposal delivers: 46% lower inflation, validator profitability preserved, treasury protected, everything adjustable.

This proposal doesn’t deliver: Deflation (not at current activity), fee burn impact (not yet), guarantees.

4

If Kusama does not address its infinite supply issue, the token price will continue to decline steadily, turning it into yet another failure within the ecosystem.

Ignoring basic tokenomics has consequences, and this is already reflected in the market. For these reasons, I support the proposal.

5

@Megadot — appreciate the support, and you’re right that ignoring tokenomics has consequences.

I notice The Kus AMA thread got 73 posts in the last 24 hours debating media spending. Meanwhile, a proposal to fundamentally change Kusama’s economic model has… 4 posts total.

Not complaining — just an observation that we’re apparently more passionate about video production than monetary policy. :sweat_smile:

If anyone else has thoughts (support, criticism, questions), now’s the time.

6 Likes
6

https://x.com/Zou_Block/status/1948918095927714043 This post presents our ultimate reflections on Polkadot’s tokenomics. It contains many ideas that align with yours and we hope it will be of some help to you.

7

@ZouYang — thank you for sharing this. Your thread covers a lot of ground that aligns with this proposal: burns over caps, percentage-based inflation, stable treasury funding, and the Ethereum model as precedent.

A few observations on the differences:

  1. Target inflation: You’re aiming for 2% net on Polkadot; we’re targeting ~4.25% on Kusama as a conservative starting point. Our v1.1 is intentionally modest
    if it works, future versions can push lower (see the roadmap in the full proposal).
  2. Deflation: You argue against it for DOT. We’re agnostic — our proposal doesn’t promise deflation, but the mechanism allows for it if activity grows dramatically. For Kusama as an experimental network, we’re comfortable letting the market decide.
  3. Validator economics: Your thread mentions timing inflation changes with Polkadot Hub to offset validator revenue loss via increased on-chain fees. On Kusama, we’re addressing this directly by reducing max_validators from 1,000 to 500 — per-validator rewards actually increase 28%.

Would be interested to hear your thoughts on the Kusama-specific approach. Given your research on Polkadot economics, your perspective on what would make this proposal stronger — or worth supporting — would be valuable.

Full proposal v1.1

8

I don’t think reducing the number of validators in Kusama from 1,000 to 500 is a good idea. Such a change would mainly benefit large validators while pushing smaller operators out of the network.

Likewise, I don’t agree with a minimum commission, neither on Kusama nor in the way it is being proposed for Polkadot by Jonas.

9

Great proposition.

Kusama tokemics are even more unsustainable compared to Polkadot, so yeah we definitely need to do something about it.

It’s time for the community to focus again on real topics (and forget the Kus noise for instance).

I’m also in favor of the changes.
1000 validators on Kusama, completely unnecessary by the way, let’s face reality, it’s validating empty blocks, there’s 0 need for such a number of validators in the current state of the network.
It’s fair to be decentralized, it’s not for the network to overpay security for empty blocks.

2 Likes
10

@Megadot — the tradeoff is real. 500 validators does favor better-capitalized operators. But the alternative is keeping 1,000 validators at 5% inflation, where everyone takes a ~36% pay cut — barely covering costs for most.

At least with 500, the remaining operators see their rewards increase by ~28% compared to today. Selection is by total stake, so smaller validators with strong nominations can still compete. And if 500 proves wrong, governance can adjust it.

If you see a configuration that fixes the economics without this tradeoff, I’m genuinely interested.

@ThomasR — exactly. 1,000 validators securing a low-activity network is a luxury we’re paying for with 7.82% inflation. We’re overpaying for security we don’t need. 500 right-sizes the cost to the current network state, and can scale back up if activity justifies it.

The proposal isn’t perfect, but “change nothing” isn’t viable. If specific parameters are wrong, let’s discuss — but the direction seems to have support.

1 Like
11

I’m less interested in the exact parameters than in the invariant we’re trying to encode. Kusama is meant to surface signals early. That means economic mechanisms should amplify reality, not smooth it.

A hard cap encodes an assumption. A burn encodes a feedback loop.

Same at the security layer, if the network can’t justify its validator set through usage, that cost should be visible, not hidden behind perpetual inflation.

If we weaken the mechanism to avoid uncomfortable outcomes, we reduce the information the experiment is meant to produce.

2 Likes
12

It’s 3 validators per core right? (Edit: it’s 5 validators/core)

So roughly 166 cores for 500 validators.

Currently 12/132 Cores (so I.m not sure about how Cores number are defined) are sold on the market, 9% of the total. And I don’t know if these 12 includes the ones from the Hub.

Let’s say we cut Cores number by 2, to 66 available Cores, 12/66 is only 18%. Enough Space for people to play with cores if needed at the moment.

I remember past refs where increasing validators numbers was justified by the fact to increase cores number for JAM etc…

But as Kusama doesn’t seem to be a canary network for JAM in the future, I don’t really see the point to keep that high level of over decentralization for nothing.

Let’s cut the inflation and reduce validators pool.

IMG_0920
IMG_0920928×351 75.5 KB

IMG_0919
IMG_0919434×567 48.4 KB

NB: nobody gives a shit about the nakamoto coef as long as your chain is efficient. The Nakamoto coef is not the alpha and omega of everything.

13
  • You can see this past ref about reducing validators to 500

https://kusama.subsquare.io/referenda/543

I’m not sure the rationale behind the comments are still valid.

  • This one was about the increase about 600 to 700 validators (140 cores)

https://kusama.subsquare.io/referenda/511

:backhand_index_pointing_right: So it’s 5 validators for 1 core if I get it right.

And IF we have activity, we scale up, not the contrary.

I never understood why we were increasing Cores without any data showing a boost in network activity…

  • this one was to increase to 100 Cores

https://kusama.subsquare.io/referenda/410

No explanations in the description why it’s needed, nor in comments.

  • Increase to 250 validators

https://kusama.subsquare.io/referenda/188

The « we need more » argument doesn’t seem to be valid anymore :sweat_smile:

I’d say that we really do need less now. :down_right_arrow:

Down and to the right.

14

Kusama played its role as an experiment network for asynchronous backing and elastic scaling, now it’s time to revert the network capacity to sustainability and realistic economic numbers.

15

@ThomasR Thanks for surfacing Ref 543 — I went back and read through the discussion. Useful context.

The main objections were capacity concerns (what if we need more parachains?) and timing (let’s wait for other WFCs to play out). The proposer actually had good data — but it didn’t land.

I think the difference here is framing. Ref 543 was pitched as “cut validators to save money.” This proposal frames validator consolidation as one piece of a larger economic redesign: burns, treasury discipline, demand-responsive scarcity. The validator change isn’t the point — it’s a supporting mechanism that makes the economics work for the validators who remain.

On the capacity concern from Ref 543: the numbers have only gotten clearer since then. Polkadot currently secures ~47 cores with 600 validators. Kusama has 12 cores with 1,000 validators. We’re paying for 4x the headroom we need. If demand changes, governance can adjust — that’s the whole point of making these parameters tunable rather than permanent.

@Rom1.io “A hard cap encodes an assumption. A burn encodes a feedback loop.” — I’m stealing this. It’s a better articulation of the core thesis than anything in the proposal.

1 Like
The Kus Public Review & AMA: 2022 - 2025
16

Honestly, lowering the number of validators on Kusama makes sense for now. The reality in the trenches is that these Kusama machines already left all sustainability a long time ago and best practices have been abandoned for a while by many validators. PoP and whatnot won’t save a low value reward token. Making the validator count numerous no longer makes sense anymore on Kusama (Even on Polkadot the count has been held at the current number without any intention of increasing it any further for obvious reasons). We already proved the validator limit on this tech and now that count is one of the things that is currently holding Kusama down. Consolidating machines into a lower count will certainly help improve validation quality without going into much details of what goes right now on Kusama.

As for large validators monopolizing all operations, Kusama’s capitalization is no longer attractive to large infra scheming so hopefully we can make it more attractive so that these schemes of monopolizing validation even exist :sweat_smile: .

2 Likes
17

Thank you for taking the time to make a proposal for Kusama’s tokenomics. I agree with others above that we cannot keep ignoring the fact that Kusama’s tokenomics are killing the network and that closing our eyes is not going to solve anything. I also agree that Kusama is NOT Polkadot and therefore the approach should not be to follow blindly the same approach as Polkadot.

I do feel that to implement such changes to the network it would be beneficial for this proposal to be vetted by researchers, for example with a background on economics, such as when Jonas wrote a report and analyzed the inflation reduction proposals for Polkadot and raised extremely important points about network security and risk of validators being bribed to attack the network.

As stated by others above:

  • 1000 validators for the current Kusama activity is overkill, we cannot keep such a big validator set with the hope that one day we will be able to test JAM, not at the expense of Kusama’s economy and not with an unknown timeline
  • Validator quality in Kusama has decreased considerably given the very limited rewards and the expensive minimum hardware requirements for validators, better to have a bit less decentralization with a reduced validator set but a set of validators who will actually secure the network properly

A few things to note that we are expecting in the future:

  • the new Kusama Bounties as part of the New Kusama Vision are coming very soon and hopefully this will bring some activity to out network
  • enactment of WFC 573 for a 32-core JAM on Kusama, which eventually means we will need to:
    • decrease from 140 → 32 cores
    • decrease from 1000 validators (700 paravalidators) → 96 validators (JAM will have 3 validators per core and today Kusama has 5 validators per core)

Kusama is a network where experimentation is expected, whether it is with this proposal or a different one, I agree that we need to try something. I am also curious to hear what the position of the W3F and parity is regarding this proposal and whether they consider it to be aligned with the new vision.

Lastly, just a note that there is currently no minimum self-stake for Kusama validators, you might be referring to the 150 KSM self-stake from the soon to be sunset DN program.

2 Likes
18

Reduce 1000 → 500-700 validator

Validator self stake at least ~$1000 value

Reduce inflation also is a must

All treasury spends should only focus on increase onchain activities and revenue back to itself

Thank you

19

@florentina57 Thanks for the detailed feedback — and for the correction on self-stake. You’re right, there’s no minimum currently. That language was in v1.0 but removed in v1.1 — the updated proposal relies purely on reducing max_validators from 1000→500 and letting the network select the top 500 by total stake. No artificial floor.

The WFC 573 context is really useful. I hadn’t fully connected the dots: if Kusama is already committed to 32-core JAM (which passed), then the long-term validator requirement is ~96, not 1000. That makes 500 a transitional step, not a radical cut. The capacity objection from Ref 543 becomes moot — we’re not reducing capacity, we’re aligning validator count with a future that’s already been approved.

500 keeps decentralization healthy while improving validator economics. Long-term, ~96 becomes a natural floor based on JAM’s 32-core design — and if capacity grows, we can always scale validators back up. The parameter is tunable in both directions.

On the economist review — I’d genuinely welcome that. If anyone knows an economist like Jonas, invite them to weigh in on this thread. Better to have the numbers stress-tested now than after a referendum passes.

One thought on JAM and inflation: WFC 573 mentions security costs could drop to ~2.4% with fewer validators. If that’s where we’re headed, the base inflation rate matters less over time — it’ll naturally shrink as validator count drops. Burns become the main lever for fine-tuning supply. Maybe this proposal is as much about building that infrastructure now as it is about the immediate 5% target.

@SAM Thanks for the support. Agreed on treasury discipline — burns mean nothing if spending outpaces them.

Full proposal v1.1

20

Like @florentina57 mentions let’s remember the community already voted for a future JAM configuration of 32 cores with 96 validators(maybe less initially), I’ve been cooking a proposal for a while checking with some of the affected parties if it makes sense to progressively reduce Kusama’s capacity not only to accommodate for “lightweight JAM” but also to arrive to a sweet spot that reflects better current demand and gives people room to adapt to the changes. I’ll soon make a root proposal with a batch to:

  • First set validators to match the 700 paravalidators(staking.set_validator_count?)
    Then following in the a batch with separate scheduler.schedule_named_after
  • 1 month later: set cores to 120, validators to 600
  • 2 months later: set cores to 100, validators to 500
  • 3 months later: set cores to 80, validators to 400
  • 4 months later: set cores to 60, validators to 300
  • 5 months later: set cores to 40, validators to 200
  • 6 months later: set cores to 24, validators to 120

I’m still not sure if it’s enough to do configuration.set_max_validators/configuration.set_coretime_cores in the relay or if broker.request_core_count in coretime chain and staking.set_validator_count in AH are need separately. I didn’t have much time to do the full research but expect something soonish.

Whether it passes or not I do think we need to do something similar to adapt to our current nonexistent demand, first let’s have a sustainable ecosystem with economics that make sense and scale back up once demand requires it.

1 Like