I’ve held RSR since 2019 and have watched every phase of the project. Its great to see the community coming together and proactively look for solutions to an admittedly long outstanding issue. The Bitcoin-style emission model never made sense. Bitcoin’s supply was earned through mining at the protocol level; RSR as a pre-minted ERC20 was issued at inception. Using that logic to justify a massive treasury has only postponed transparency.
Like many here, I’d welcome a burn to restore momentum. At the same time, as the core team has mentioned, a full burn could potentially starve the protocol of funds as it’s gaining traction, whether in the near or long term - especially when major integrations, operations and strategic partnerships require cash flow and confidentiality under NDA. With that said, we need a structure that gives us verifiable scarcity while keeping the project alive and fundable.
I’d like to put forward a few alternative ideas to whats already been discussed besides an outright 30b burn (which I am not against for the record) but could also potentially keep some flexibility for the team in future. The aim is to also lay ideas for the groundwork to more (overdue) community-level governance and team transparency.
1.) Deferred Burn Vault (DBV)
A smart-contract vault holding the ~30B (or whatever amount) of RSR from the existing supply and/or treasury. This will create a visible commitment to deflation without locking the team out of critical funding.
How it works:
-
Tokens sit in the vault and cannot be spent or sold.
-
When measurable KPIs are reached (for example: sustained RToken TVL above a threshold, protocol fees above X USD/month, or governance participation above Y %…etc), a set tranche is automatically burned.
-
The option to burn on failure of hitting certain KPI’s could also be something to consider, rewarding performance discipline both ways.
-
The contract includes a time-locked emergency clause - the team can propose to release a limited % (say ≤ 5 %) for urgent operational needs, but it executes only after a public waiting period (e.g. 7 days) unless vetoed by veRSR holders.
The result of this is on-chain accountability, transparent performance based burns, and preserved runway flexibility for the team in case of future need.
2.) Dynamic Burn Corridor (DBC)
This is the governance layer that dictates how the DBV behaves, or RSR’s “burn roadmap” as defined by the governors.
Initial structure
-
The corridor is set at a minimum and maximum total burn commitment, e.g. 10B - 30B RSR.
-
The lower bound (10B) is guaranteed - it signals seriousness and in this case we get the first, albeit smaller, major burn we’ve all been discussing immediately.
-
The upper bound (30B) defines the maximum that can ever be burned from the vault without community approval of a new corridor.
-
Adaptive Mechanism: The rate of burns inside this range changes automatically with performance. If adoption grows quickly (fees, TVL, or active RTokens rising), burns accelerate toward the upper end.
-
If growth slows, burns pause or remain near the lower bound to conserve runway.
This gives market predictability - holders know there’s at least a 10B burn coming (in this example) which would happen immediately but no depletion would occur that could potentially hamstring the team and project in future. It also gives the team flexibility - burns scale with real results, not emotion or hype. The DBV would be the engine that actually executes burns; the DBC is the governance level that decides the rate, size, caps and metrics for those burns.
3.) veRSR Pilot
veRSR is a great idea that I fully support and though already put forward by James and many others above; I’d like to insert a few additions in the context of this alternative approach to burning.
Mechanics: Lock RSR for fixed periods (e.g. 3 months - 4 years) to receive veRSR voting power and yield from protocol fees or emissions.
veRSR voters help:
Locked tokens shrink circulating supply (a “soft burn”) while rewarding loyalty, enhancing community involvement at the governance level and introducing gradual decentralisation.
When protocol-level burning was reintroduced, it became clear that the problem is not with the idea of burning itself, but with how and when it is done. The market reacts positively when burns are transparent, metric-driven, and clearly linked to performance. This model expands on that principle - the Deferred Burn Vault and Dynamic Burn Corridor add another avenue of performance-based burning alongside the existing index-protocol burn mechanisms. Together, they create a coordinated system where burns reflect genuine growth rather than arbitrary decisions.
4.) Transparency Charter
Transparency as also thoroughly discussed above has clearly been a major issue. Plenty of good ideas put forward and a few contributions from my side aiming at accountability without compromising institutional confidentiality.
-
Quarterly attested reports showing inflows/outflows and spending categories for all team treasury wallets.
-
Public dashboards for the DBV and DBC - everyone can verify burn progress and balances.
-
A confidential lane for the team to use for sensitive partnerships or regulatory work, with disclosures released after a fixed delay (e.g. 90 days). This is done with the understanding that as much as we as a community would love to be involved in every step of the core teams progress, the nature of institutional discussions may preclude them from giving out information at all times.
Working Together on the Details
The precise KPIs, corridor parameters, and veRSR rules all need to be shaped collaboratively - by the team, community, and external advisors. The frameworks here are simply general ideas to expand on whats already been discussed, while keeping it straightforward enough to be implemented by both team and community without excess delays. Consider them as a ‘phase 1’ list of options to stabilise confidence now while paving the road to a fully self-regulating, revenue-backed burn mechanism later.