A simple hybrid model: revenue-substitution + safety budget + staking guardrail (for discussion)
Hi all — thanks for the kickoff and for the emphasis on asking the right questions and defining trackable success metrics.
Based on the discussion here (inflation vs security, buybacks/burn, liquid staking effects, and the need for a clear flow model/dashboard), we’d like to share a hybrid monetary-policy sketch designed to be incremental, measurable, and compatible with the current “mint + staking” logic.
- Pillar 1 — Define a yearly security budget target: S_target
We frame security funding as a budget (in ATOM/year) rather than debating “a good inflation %” in isolation. Concretely, S_target is the minimum annual amount needed to keep validator economics viable and the chain secure.
2) Pillar 2 — Substitute real revenues for inflation: S_revenus → reduces S_inflation
We then treat inflation as a residual:
S_inflation = max(0, S_target – S_revenus)
Inflation_core = S_inflation / Supply
So when Hub revenues grow (Cosmos Stack / services / B2B), inflation mechanically declines without requiring repeated ad-hoc parameter cuts. This matches the “revenue-based constraint” direction of the research kickoff.
3) Pillar 3 — Keep the current inflation curve as a guardrail when staking is too low
We agree with concerns about staking ratio and security. So we propose preserving the existing inflation mechanism as Inflation_guardrail (the familiar curve tied to staking), but only as an emergency floor when:
bonded_ratio < stake_threshold
Final inflation becomes:
Inflation_eff = max(Inflation_core, Inflation_guardrail)
This means:
In normal conditions, revenue-substitution drives inflation down.
In stressed conditions (low staking / high uncertainty), the chain automatically falls back to the known guardrail to protect security.
Why this is useful vs “just burn / just buyback”
Buybacks/burn can reduce dilution, but they don’t automatically create a security-funding rule. This hybrid approach makes the link explicit: real revenues replace issuance while a staking guardrail remains to prevent under-staking.
What we’d like feedback on (aligning with the “right questions” theme)
1. How should we define and measure S_revenus in a way that’s auditable/on-chain? (i.e make off-chain revenue on-chain)
2. What should be governance inputs for S_target and stake_threshold?
3. What dashboard/diagram would best help the community track these flows and outcomes?
Happy to share a concrete numeric example and suggested metrics if helpful.