[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.
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:
- Final review of v1.2 text
- Coordination with @olanod on timing
- 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.