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

Governance
21

@olanod Good to see alignment on direction. Your phased plan looks well thought out — and you’ve got the WFC 573 context that makes the validator reduction make sense.

Thinking about how these fit together: your proposal handles the cost side (fewer validators, fewer cores, lower security spend). This one handles the supply side (burns to manage what’s left after costs drop). They’re complementary rather than competing.

Question is how to coordinate. Do you see these as separate referenda that reinforce each other, or would it make sense to combine them? Happy to defer to your timeline on the validator/core reduction since you’ve got that mapped out — this proposal can focus on the burn infrastructure that becomes more important as those costs drop.

What’s the best way to move forward without duplicating effort?

22

It is very refreshing that adjustments are finally being discussed. They say there are three ways to learn. Unfortunately, the people at Kusama have decided to learn through bad decisions and pain instead of taking the more pleasant routes.

Incidentally, it is ironic that Florentina and Saxemberg are advocating for change here, even though they consistently voted against such adjustments in my proposals at OpenGov and she talked against it in the corresponding episode of AAG Kusama. It is starting to hit your wallet, isn’t it? But enough of the schadenfreude, let’s move on to the solutions.

Number one is global developments since the founding of Kusama and its all-time high. The people of this world faced unprecedented inflation, which hit particularly hard during the Covid years. Everything related to inflation is highly unpopular and will remain so for decades to come, which is why it makes no sense to abandon the idea of fixing the maximum supply.

No one will spend money on something that has a higher inflation rate than their country’s currency, and since the wealthiest countries want to keep their currencies below an inflation rate of 2%, anything above that is a bad deal. I therefore advocate a maximum supply of 21 million.

Secondly, and logically derived from this, a lower inflation rate is needed. Reducing the number of validators and cores is a sensible step, but it is not enough, because without a minimum self-stake and a reduced token issuance, far too many tokens will continue to be sold. Halvings are the most elegant solution, because people are already very familiar with it and know that it works.

Thirdly, this means that the minimum commission rate for validators must be reduced to 0, as these subsidies (and that is what they are) will no longer be necessary. Validators should not be financed by inferior tokens, but by higher-value ones. This will allow us to reverse the downward death spiral and move towards a healthy upward growth curve. The incentive must be to hold Kusamas, not to sell them immediately at the first opportunity, as is currently the case.

In summary, this means:

  • A maximum supply of 21 million Kusama
  • Drastic reduction in cores
  • Drastic reduction in validators
  • A minimum self-stake for validators (approx. USD 10k)
  • Drastic halving of 50% every four years
  • Reduction of the minimum commission rate to 0%

And all this as quickly as possible! We have already wasted years of potential doing the wrong thing!

Finally, I would like to note that it is not surrender or resignation to adopt certain elements from other tokens that have proven beneficial to their ecosystems.

The dumbest arguments against this so far: “But Kusama is special, so we don’t want to imitate Bitcoin and Polkdadot…” Or: “Kusama’s economy works very differently from all previously observed systems, which is why there is no need for inflation reduction…” Yeah, right…

23

@Criptoe4u We agree on more than we disagree: validator reduction, core reduction, urgency. The divergence is hard cap vs burns.

The case for burns: a cap is a fixed assumption about what the “right” supply is. Burns tie scarcity to demand — when the network is valuable and used, it becomes scarcer. When it’s not, moderate inflation continues funding security. Ethereum proved this works at scale. It’s not about imitating Bitcoin or avoiding it — it’s about choosing a mechanism that responds to reality rather than hardcoding a guess.

On inflation psychology: fair point, but burns can get you below 2% net inflation if activity is high enough. The difference is you earn it through usage rather than declaring it upfront.

Either way, good to have the debate on the table.

24

Yes, that’s right. We agree on more things than we disagree on.

I simply think that a maximum supply offers visible security. Let’s assume that we would limit the supply to 21 million. On the one hand, this would evoke positive associations with Bitcoin, and on the other hand, it would evoke associations with scarcity, which we associate with something valuable. Both would be exploitable marketing slogans. Furthermore, with halvings of 50% every four years, it would take decades to reach the maximum supply (21 million).

Burns are certainly also positive, just think of BNB for example, but I would only recommend them as a supplement. A very small percentage of unspent treasury income, for example.

The most important thing right now is to restore confidence and security and to establish incentives to promote positive developments.

Allowing unchecked inflation was the biggest mistake, because it destroys any economic system. I really hope that everyone has learned this lesson by now.

25

@Criptoe4u Fair points on the psychology — I just don’t find “exploitable marketing slogans” compelling as a design principle. I’m not here to pump a number. I’m here because I want Kusama to be a vibrant ecosystem for privacy and cypherpunk projects.

Honestly, if KSM just kept pace with inflation I’d be fine. The goal isn’t moon math — it’s stopping the bleeding so builders have a stable foundation to work on. Burns tied to activity feel more aligned with that than picking a number because it sounds good.

But I hear you on confidence. Maybe we get there different ways.

26

I think you are making the same mistake in thinking as the architects of the current system.

Your focus is on the developers, ideological ideas (without making any value judgments), and the lie that it’s not about making money. However, the focus should be on customers, products for customers, and those who are betting their money in Kusama’s development and future.

That’s why it’s not enough to offset inflation, because why would anyone buy Kusama and not stocks, for example? Kusama needs to be made more valuable, especially after approximately 70% more tokens were created in less than 6 years to finance developers who have no monetizable results to show for Kusama. Without new foreign currency from outside, the outlook is very bleak, which is why incentives are needed.

27

Note: posting this on behalf of Rich-Decent Partners.

People assume there is only the Bitcoin way (21m hardcap) or the Ethereum way (burns).

There is a third way and that has been proposed here and is how we will make Kusama first “self financing” and then extremely profitable.

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

Anyone interested in contributing to Kusama governance can join this today:

Chaos Sessions - A Kusama Coordination Initiative
Monday, January 12, 2026 • 3:00 – 5:00 pm (Europe/London)
15:00 – 17:00 UTC • 2 hours

The second age of Kusama begins! Join us for this exciting coordination session. Please come prepared with ideas and energy.

Google Meet: https://meet.google.com/sth-ffwi-nbt
(Dial-in: +44 20 3873 3170 PIN: 494 544 560 3932)

Add to your Google Calendar: https://bit.ly/chaossessions
(Works perfectly on mobile & desktop — tap and save!)

28

[Update] v1.2 — Burn-Focused

TL;DR: Based on community feedback, v1.2 refocuses this proposal on burns only. Validator/core reduction is deferred to @olanod’s phased plan. Two complementary proposals > one overloaded proposal. This may be ready for a vote soon.

What Changed in v1.2

Component v1.1 v1.2
Burn mechanisms Yes Yes
Base inflation 7.82% → 5% Yes Yes
Validator reduction 1000 → 500 Yes Removed (deferred to @olanod)

Why the change: @olanod has proposed a detailed, phased validator/core reduction aligned with WFC 573. Rather than duplicate his work, this proposal now focuses purely on the supply side. His handles the cost side. They reinforce each other.

What v1.2 Delivers

  • 46% inflation reduction (7.82% → ~4.25%)
  • Multi-source burns: fees (50%), treasury inflows (10%), treasury balance (1%/period with 100K floor), coretime (25%)
  • Infrastructure for the future: burns scale automatically as activity grows

Note: Burns have the most impact when paired with spending discipline. That’s an important but separate conversation.

[Full proposal v1.2]

Community Feedback That Shaped This

This version exists because of the discussion here:

  • @olanod — Your phased validator/core reduction plan is more detailed than what I had. Makes sense to split the work: you take cost side, I take supply side.
  • @florentina57 — WFC 573 context was crucial. Understanding that ~96 validators is a natural floor (based on 32-core JAM) — with room to scale up as activity grows — reframes the validator discussion entirely.
  • @Rom1.io — “A hard cap encodes an assumption. A burn encodes a feedback loop.” This is now in the proposal. Better articulation than I had.
  • @ThomasR — Ref 543 history helped understand why validator reduction failed before and how to frame it differently.
  • @Criptoe4u — The hard cap debate is on the record. We disagree on mechanism, but agree on urgency.

The proposal is stronger because of this thread.

Next Steps

This feels close to ready. The core questions have been debated:

  • Burns vs hard cap → Burns (activity-responsive, no cliff problem)
  • Validator reduction → Deferred to @olanod’s complementary proposal
  • Implementation → Immediate for burns, phased for validators (per @olanod)

What’s left:

  1. Final review of v1.2 text
  2. Coordination with @olanod on timing
  3. Put it to a vote

If there are remaining concerns, now’s the time. Otherwise, let’s move forward.

Bottom Line

“A hard cap encodes an assumption. A burn encodes a feedback loop.”
— @Rom1.io

This proposal builds the burn infrastructure. @olanod’s proposal handles validator economics. Together, they give Kusama sustainable, activity-responsive tokenomics.

Ready when you are.

2 Likes
29

Thx for sharing (even it’s a bit late).
I shared it Le Nexus DAO and X

I won’t be able to attend unfortunately.
It would be nice if this is recorded.

30

@hantoniu-codeberg Thank you for your work!

Assuming that both proposals (yours and @olanod ) are accepted, what is the expected overall inflation rate?

32

Good question. Here’s how the proposals interact:

If both pass:

Proposal Effect Timeline
This proposal (burns) Net inflation: ~4.25% Immediate
@olanod’s proposal (validator reduction) Reduces security costs Phased over 6 months

Combined effect: Still ~4.25% net inflation initially — the proposals work on different axes:

  • This proposal changes the inflation rate and adds burns (supply side)
  • @olanod’s proposal changes how much we need to spend on security (cost side)

But here’s the key: Once validator costs drop (per @olanod’s plan), we need less inflation to fund security. That opens the door to further base inflation reductions in future versions:

Stage Base Inflation Est. Net Inflation
v1.2 + @olanod (near-term) 5% ~4.25%
v2.0 (12+ months) 4% ~3.5%
Post-JAM transition (~96 validators) 2-3% ~2-2.5%

WFC 573 mentioned a ~2.4% target for the 32-core config. @olanod’s reduction gets us there on the cost side; this proposal builds the burn infrastructure for the supply side. Together, they make that target achievable.

(Apologies to @olanod for the ping storm — your proposal is just that central to the answer.)

33

The proposal is now live on-chain:

Referendum 627

This is a Wish For Change referendum. If passed, it signals community support for implementing burn-based tokenomics as described in v1.2.

Thanks to everyone who contributed to shaping this — @olanod, @florentina57, @Rom1.io, @ThomasR, @Criptoe4u, @SAXEMBERG, and others.

1 Like