Author: @hantoniu-codeberg
Date: January 2026
Track: Wish For Change / Root
Version: 1.2 — Burn-Focused (Complementary to @olanod's Validator Reduction Proposal)
This revision refocuses the proposal on burn mechanisms only, removing the validator set reduction component.
Why the change:
- @olanod has proposed a detailed, phased validator/core reduction plan aligned with WFC 573 (Kusama's approved JAM upgrade)
- Rather than duplicate effort, this proposal now focuses on the supply side (burns)
- @olanod's proposal handles the cost side (validators, cores, security spend)
- Two complementary proposals are stronger than one overloaded proposal
What v1.2 covers:
- Burn mechanisms (fees, treasury, coretime)
- Base inflation reduction (7.82% → 5%)
What v1.2 defers to @olanod:
- Validator set reduction
- Core count reduction
- Phased implementation timeline for those changes
"A hard cap encodes an assumption. A burn encodes a feedback loop." — @Rom1.io
This proposal introduces an Ethereum-inspired economic model for Kusama: reduced base inflation combined with multi-source burn mechanisms. Unlike Polkadot's 2.1B hard cap, we propose Kusama take a different path — proving that demand-responsive tokenomics through burns is a viable alternative.
Key changes:
- Reduce base inflation: 7.82% → 5%
- Implement multi-source burns: fees (50%), treasury inflows (10%), treasury balance (1%/period with 100K floor), coretime (25%)
- No hard cap — inflation adjusts with network activity
- Net inflation reduced from 7.82% to ~4.25% (a 46% reduction at current treasury balance)
This proposal is complementary to:
- @olanod's validator/core reduction proposal — handles the cost side
- Other treasury reform proposals — different approaches to sustainability aren't mutually exclusive
Honest expectation: This proposal cuts inflation nearly in half. It does not guarantee deflation. Deflationary periods become possible only with significantly higher network activity.
Polkadot adopted a 2.1B DOT hard cap in September 2025. Some argue Kusama should follow. We disagree.
A hard cap is a fixed assumption about what the "right" supply is — it's hardcoding a guess. Burns tie scarcity to demand: when the network is valuable and used, inflation decreases. When activity is low, moderate inflation continues funding security.
| Network | Hard Cap | Mechanism | Outcome |
|---|---|---|---|
| Ethereum | No | EIP-1559 burns (protocol-level) | Fluctuates with usage, $400B+ market cap |
| Bitcoin | Yes (21M) | Halvings | Successful, but unproven post-subsidy |
| Polkadot | Yes (2.1B) | Stepped decline | New, untested |
Note: BNB also uses burns but these are company-controlled (Binance decides burn amounts), not protocol-level. We cite Ethereum as the comparable decentralized model.
Ethereum proves you don't need a cap. What you need is a mechanism that ties tokenomics to network activity.
-
Arbitrary Numbers — Why 21M KSM? Why not 20M or 25M? These numbers are marketing, not economics.
-
Inflexibility — Once set, you're locked in. What if conditions change?
-
The Cliff Problem — What happens as you approach the cap? Bitcoin assumes fees will replace block rewards. That's unproven.
-
False Precision — A cap implies we know the "right" final supply. We don't.
| Condition | Hard Cap | Burns |
|---|---|---|
| High network usage | Same supply trajectory | More burns → lower inflation |
| Low network usage | Same supply trajectory | Fewer burns → moderate inflation |
| Need to adjust | Governance fight | Adjust burn rates |
Burns create activity-responsive tokenomics. When Kusama is valuable and used, inflation decreases. When activity is low, moderate inflation continues funding security.
Kusama's current economic model is unsustainable:
| Issue | Current State | Impact |
|---|---|---|
| Inflation | 7.82% annually | Continuous dilution regardless of activity |
| Burns | Disabled (0%) | No deflationary pressure whatsoever |
| Treasury | Spends ~7x revenue | ~0.0968 KSM/block net loss |
| Supply | 10M → 17.4M in 6 years | 74% increase, unlimited trajectory |
Meanwhile, Polkadot has capped supply and declining inflation. Kusama is falling behind.
| Metric | Value | Source |
|---|---|---|
| Total Supply | 17.4M KSM | CoinMarketCap |
| Current Inflation | 7.82% | Subscan |
| Total Staked | 8.085M KSM (~46%) | Subscan |
| Active Validators | 1,000 | Subscan |
| Treasury Balance | ~283K KSM | Forum Analysis |
| Daily Transaction Fees | ~3.5 KSM | On-chain data (2025 avg) |
| Daily Treasury Inflows | ~239 KSM | Forum Analysis |
| Treasury Burn Rate | 0% | Chain State |
Rationale: Lower base inflation reduces dilution. Unlike a cap, this is adjustable via governance if conditions change.
| Scenario | Inflation | Annual Issuance |
|---|---|---|
| Current | 7.82% | 1.36M KSM |
| Proposed | 5% | 870K KSM |
Implementation:
const TARGET_INFLATION: Perquintill = Perquintill::from_percent(5);Note: The impact on per-validator rewards depends on the validator count. See @olanod's complementary proposal for the validator/core reduction plan that maintains validator profitability.
Rather than a cap, we reduce inflation through burns across protocol revenue streams.
| Source | Current | Proposed | Annual Impact (est.) |
|---|---|---|---|
| Transaction Fees | 0% burned | 50% burned | ~640 KSM* |
| Treasury Inflows | 0% burned | 10% burned | ~8,700 KSM |
| Treasury Balance | 0% burned | 1% per period (100K floor) | ~110,000 KSM** |
| Coretime Revenue | 0% burned | 25% burned | ~5,000-20,000 KSM*** |
| Slashing | 0% burned | 50% burned | ~0-2,000 KSM |
*Fee burns are small at current activity but scale with network growth. **Treasury burn estimate based on current ~283K balance; burns only apply to balance above 100K floor. ***Coretime is new; estimate based on expected growth, not historical data.
Combined estimated burns: 125,000-140,000 KSM/year (at current treasury balance)
Where the burns come from:
- Treasury burns do the heavy lifting (~85% of total burns)
- Fee burns scale with growth (small now, significant if activity grows 10-50x)
- Coretime burns grow with adoption (infrastructure for the future)
Net inflation calculation (current treasury balance):
Gross Inflation: 5% × 17.4M = 870,000 KSM/year
Estimated Burns: ~130,000 KSM/year
Net Inflation: ~740,000 KSM/year = ~4.25%How treasury burns work:
- Each 6-day spend period, 1% of treasury balance above 100K KSM is burned
- Current treasury: 283K → Burnable: 183K → Per-period burn: 1,830 KSM
- 61 periods/year → ~112K KSM/year from treasury burns alone
- Floor protects treasury from depletion; burns decrease as treasury approaches 100K
Implementation:
// Fee distribution
const FEE_BURN_PERCENT: u8 = 50;
const FEE_TREASURY_PERCENT: u8 = 30;
const FEE_VALIDATOR_PERCENT: u8 = 20;
// Treasury burns
const TREASURY_INFLOW_BURN_PERCENT: u8 = 10;
const TREASURY_BURN_PERCENT: u8 = 1; // Per 6-day spend period
const TREASURY_BURN_FLOOR: Balance = 100_000 * KSM; // No burns below this
// Revenue burns
const CORETIME_BURN_PERCENT: u8 = 25;
const SLASH_BURN_PERCENT: u8 = 50;Burns have the most impact when paired with spending discipline. If the treasury spends faster than burns can offset, the mechanism is weakened.
This proposal focuses on the on-chain burn parameters. Treasury spending culture — how voters evaluate proposals, milestone-based funding, retroactive grants — is an important but separate conversation that deserves its own discussion.
This proposal focuses on the supply side of Kusama's economics. Other proposals address different aspects:
@olanod has proposed a phased reduction of validators and cores aligned with WFC 573 (Kusama's approved 32-core JAM upgrade). This addresses the cost side — reducing security spend while maintaining network integrity.
How the proposals fit together:
- This proposal: Reduces inflation through burns (supply side)
- @olanod's proposal: Reduces validator/core costs (cost side)
- Combined effect: Lower inflation + lower costs = sustainable economics
We explicitly support coordination with @olanod's work rather than duplicating it.
The community is exploring various approaches to treasury sustainability (e.g., loan-based models, self-financing mechanisms). These are not mutually exclusive with burn-based tokenomics — they solve different problems and can stack.
This proposal takes no position on those alternatives. If the community pursues them alongside burns, that's compatible.
Annual Supply Change = ~7-8% (varies with staking ratio, currently 7.82%)
Burns = 0
Net Result: Perpetual dilution, unlimited supply growthAnnual Supply Change = Base Inflation (5%) - Burns
Burns = Fee Burns + Treasury Burns + Coretime Burns + Slash Burns
Where burns scale with network activity:
- High usage → More fees/coretime → More burns → Lower net inflation
- Low usage → Fewer fees → Fewer burns → Moderate net inflation (~4.25%)| Scenario | Gross Inflation | Est. Burns | Net Inflation |
|---|---|---|---|
| Current treasury (283K) | 5% | ~130K KSM | ~4.25% |
| Treasury at 200K | 5% | ~70K KSM | ~4.6% |
| Treasury at floor (100K) | 5% | ~20K KSM | ~4.9% |
| High activity (10x fees + 400K treasury) | 5% | ~200K KSM | ~3.8% |
Key insight: At current treasury balance, this proposal reduces inflation from 7.82% to ~4.25% — a 46% reduction. Burns are self-adjusting: they decrease as treasury approaches the 100K floor, preventing depletion.
WFC 573 commits Kusama to a 32-core JAM configuration, which will eventually require far fewer validators (~96) than today's 1,000. As validator costs drop, the base inflation needed for security decreases.
In that future:
- Security costs could drop to ~2.4% (per WFC 573 estimates)
- The burn infrastructure built now becomes the primary lever for fine-tuning supply
- Burns allow governance to target whatever net inflation rate makes sense
This proposal builds the burn infrastructure now so it's ready when validator costs drop.
| Aspect | Kusama (Proposed) | Polkadot (Current) | Ethereum |
|---|---|---|---|
| Supply Cap | None | 2.1B DOT | None |
| Scarcity Mechanism | Burns | Cap + stepped decline | Burns (EIP-1559) |
| Flexibility | High | Low (cap is fixed) | High |
| Activity-Responsive | Yes | No | Yes |
| Cliff Problem | None | Yes (approaching cap) | None |
| Current Net Inflation | ~4.25% (proposed) | Declining to 0% | ~0.74% (fluctuates) |
Ethereum currently runs ~0.74% net inflation — significantly lower than our proposed ~4.25%. We're not claiming parity with Ethereum. The differences:
- Ethereum's base issuance is lower (~0.5-1% for staking vs our 5%)
- Ethereum has massive transaction volume — fee burns are substantial
- Our fee burns are minimal today (~640 KSM/year at current activity)
What we share with Ethereum is the mechanism: burns that scale with activity, no hard cap, governance-adjustable parameters. We're adopting their framework, not matching their current numbers.
This proposal is a starting point. If successful, future versions can reduce base inflation further.
All burn-related changes take effect upon passing:
| Change | Parameter |
|---|---|
| Base inflation | 7.82% → 5% |
| Fee burn | 0% → 50% |
| Treasury inflow burn | 0% → 10% |
| Treasury balance burn | 0% → 1% per period (100K floor) |
| Coretime burn | 0% → 25% |
Note: Validator set changes are handled by @olanod's complementary proposal, not this one.
All parameter changes in this proposal are governance-reversible. If something doesn't work, we can fix it.
| Parameter | Can Be Reversed? | How |
|---|---|---|
| Base inflation (5%) | Yes | Governance vote to adjust inflation rate |
| Fee burn (50%) | Yes | Governance vote to adjust fee distribution |
| Treasury burns | Yes | Governance vote to modify or disable |
| Coretime burn (25%) | Yes | Governance vote to adjust |
Unlike a hard cap, which creates political pressure against any future change, burn mechanisms can be tuned up or down based on real-world results. If 5% inflation proves too low for validator security, we can increase it. If burns are too aggressive, we can reduce them.
This is experimentation, not permanence. Kusama's purpose is to test things.
| Risk | Likelihood | Mitigation |
|---|---|---|
| Burns insufficient for major impact | Medium | Treasury burns provide baseline; fee burns scale with growth |
| Treasury underfunded | Low | 100K floor protects minimum balance; burns decrease as treasury approaches floor |
| Community prefers hard cap | Medium | Present honest data; let community decide |
| Divergence from Polkadot | Low risk | Kusama's purpose is experimentation |
| Coordination with @olanod's proposal fails | Low | Proposals are independently valuable; both passing is better, but either alone still helps |
After 12 months, this proposal succeeds if:
| Metric | Target | Measurement |
|---|---|---|
| Net inflation | < 5% | (Issuance - burns) / supply |
| Burn rate | > 100K KSM/year | On-chain tracking |
| Treasury balance | Stable above 100K floor | Treasury account |
| Mechanism functioning | Burns scaling with activity | On-chain monitoring |
Long-term success: If network usage grows significantly, net inflation should decrease proportionally — demonstrating the activity-responsive model works.
This proposal is conservative by design. If v1.2 succeeds, the framework enables further optimization.
| Version | Base Inflation | Est. Net Inflation | Trigger |
|---|---|---|---|
| Current | 7.82% | 7.82% | — |
| v1.2 (this proposal) | 5% | ~4.25% | Pass referendum |
| v2.0 | 4% | ~3.5% | 12-month success metrics met |
| v3.0 | 3% | ~2-2.5% | Sustained treasury health + JAM transition |
| Long-term | 2-3% | ~1-2% | High activity + mature coretime market |
Even if fee burns are negligible today (~640 KSM/year), the mechanism will be in place. If Kusama activity grows 10-50x, we don't need a new referendum — burns automatically increase.
v1.2 builds the rails. Future growth rides them.
This proposal doesn't promise deflation. It promises sustainable, activity-responsive tokenomics.
What we deliver:
- 46% reduction in net inflation (7.82% → ~4.25%)
- Burns that scale with growth (small now, significant if Kusama thrives)
- Treasury protection (100K floor prevents depletion)
- Flexibility (adjustable via governance, unlike a hard cap)
- Complementary design (works alongside @olanod's validator reduction proposal)
Polkadot went with a hard cap. Kusama should prove there's another way — not through hype, but through honest, adaptive economics.
- Discuss — Share feedback on the forum thread
- Coordinate — Support both this proposal and @olanod's complementary work
- Verify — Check our numbers. We've been wrong before; we'd rather be corrected than wrong.
Kusama has always been about experimentation. This proposal experiments with honest tokenomics.
- Ethereum EIP-1559
- Polkadot 2.1B Cap Announcement
- Kusama Subscan Staking Dashboard
- Kusama Treasury Analysis
- Kusama Fee Data — On-chain transaction fees (Subscan)
- WFC 573 — Kusama JAM Upgrade — Approved 32-core configuration
Version 1.2 — Burn-focused, complementary to @olanod's validator reduction proposal. Building the supply-side infrastructure for sustainable Kusama economics.
Thanks for taking the initiative and the structure (ie this gist), good to have other people thinking on this stuff and prompting discussion.
I caveat the following with the understanding that 'change is the only constant' and that Kusama is itself a coordination experiment.
The open question: can a distributed network of agents (human and machine) iterate successfully towards intellectual, economic and narrative coherence?
The output of increasing coherence will naturally first be sustainability, then profitability in a regenerative, rather than extractive form.
A simple rubric - does a decision likely increase or decrease the network's aggregate collective intelligence.
Prior context
Assumptions
treasury balance not ~283K KSM is ≈ 679K KSM on Asset Hub
Annual impact estimations of burning are not rooted in a basic (network) financial model, this would be useful to do.
Success metrics are also not rooted in any underlying data / model.
The major problem isn't inflation, it is unproductive inflation.
Thoughts
Yes Polkadot imitating Bitcoin's hard cap hardcodes a 'guess'. It is also nothing new.
Following an Ethereum model iterates the design on from Bitcoin, but again doesn't bring anything new.
Ethereum's burn model came after demand - post revenue, when blocks were full, fees were high and this decision made sense.
Kusama is in a definitively different position - pre-revenue.
Fees are so low that the volume of transactions needed to make a dent in the supply is vast.
Blockspace is a commodity good - if the cost is ~0, then burning will have little to no impact.
We are not failing for tools, or talent or resources but for imagination of what may exist beyond the horizon.
This is a key statement that is worth unpacking - how is Kusama unsustainable?
There is little to no treasury spending, so that is right now, sustainable.
Validators however are underwater and have been for a while.
Validator reduction solves this directly per ref#573.
With 32/24 cores we can then calcuate the direct costs of validating the network in USD terms.
Provocation
Assume you cannot use Bitcoin's model.
Assume you cannot use Ethereum's model.
They are context dependent designs, you cannot just clone the parameters and expect to improve issues within a different context.
Keep it simple stupid (KISS)
Work within the context we have, not the one we would like.
Step 1. Assume network sustainability should be the initial focus that aligns all stakeholders.
Step 2: Work out what is the cost base of the network - this is then the demand problem we have.
Step 3: Calulate the leanest version of Kusama - what is actually essential to maintain? (the rule - cut once, cut deep).
Step 4: Derive a baseline network budget denominated in USD.
Step 5: Develop a coordinated strategy to drive USD revenue to cover costs.
Step 7: Coordinate network resources to activate this strategy in the most cost-effective way possible.
Step 8: Ensure there are objective and ungameable metrics to assess progress towards the revenue targets.
First do what's necessary, then do what's possible - then you can achieve the impossible.
Addendum
Kusama has 10m DOT coming in to fuel innovation.
This is basically free money from a network sustainability perspective - ie we're spending down DOT but any value accrues to KSM.
There are then two budgets:
This is a pretty good starting point.