Revenue-Linked Inflation: A Sustainable Security Budget for the Cosmos Hub
TL;DR
Two objectives:
-
Link inflation to revenues — inflation should compensate for missing revenues, not be an arbitrary parameter
-
Open a door for off-chain revenues — allow ecosystem partners to contribute revenues on-chain, transparently, to validators and delegators
The mechanism:
-
Define a target security budget (revenue per block needed to secure the network)
-
Fund this budget primarily through real revenues (tx fees, ecosystem contributions)
-
Use inflation only to fill the gap when revenues fall short
-
Result: inflation auto-adjusts based on actual ecosystem revenue
This creates a path to zero inflation as the Hub matures, without compromising security. And it gives ecosystem partners a transparent way to share revenues with those who secure the network.
The Problem with the Current Debate
The community is discussing lowering inflation. But the conversation is backwards.
Current approach:
-
“Inflation is too high, it dilutes holders”
-
“Let’s lower it to X%”
-
“Why X%? Why not Y%?”
-
No clear answer → political compromise → repeat in 6 months
The real question we should ask:
-
How much do we need to pay for security?
-
Where should this money come from?
-
How do we transition to sustainable funding?
Lowering inflation without answering these questions just means paying validators less, which leads to either reduced security or concentration toward large validators who can operate at lower margins.
Opening the Door to Off-Chain Revenues
Before explaining how to link inflation to revenues, we need a way for revenues to flow on-chain in the first place.
The Revenue Stream Module
A new module that allows ecosystem partners to contribute revenues on-chain in a transparent, verifiable way. Partner revenues are streamed block-by-block over a period determined by the partner, ensuring continuous and predictable fund distribution.
How it works:
// Anyone can create a revenue stream (permissionless)
// Spam prevention: only whitelisted denoms + minimum amount
type Stream struct {
Source string // "Cosmos Labs" / "Informal Systems" / etc.
TotalAmount sdk.Coins // Total to distribute
RemainingAmount sdk.Coins
StartBlock int64
EndBlock int64 // Distributed linearly over this period
}
Example flows:
| Source | Contribution | Distribution |
|---|---|---|
| Cosmos Labs | $500k from ecosystem services | Stream over 6 months |
| Informal Systems | $200k annual commitment | Stream over 12 months |
| Major dApps | Voluntary contribution | Stream as they choose |
| Protocol revenues | Ongoing fees from Hub services | Direct to revenue pool |
Transparency Dashboard
All streams are on-chain and queryable:
-
Total revenues this month: $X
-
Breakdown by source
-
Inflation rate this month vs last month
-
Projected inflation if current revenues continue
This creates accountability. Entities funded by the community pool have a transparent way to show they’re giving back. The community can see exactly how much real revenue the ecosystem generates.
The Proposal: Revenue-First, Inflation-Second
Now that we have a way for revenues to enter the system, we can link inflation to these revenues.
Core Mechanism
Every block:
1. Calculate REAL REVENUES
- Transaction fees
- Revenue streams from ecosystem partners
2. Compare to TARGET
- Target = governance parameter (revenue needed per block)
3. If revenues < target:
- Mint (target - revenues) as inflation
- This fills the gap
4. If revenues >= target:
- Inflation = 0
- All revenues go to stakers/validators
Visual Example
Scenario A - Early stage (today):
Target: $1000/block equivalent
Revenues: $100/block (fees only)
Gap: $900
Inflation: Mints $900 equivalent in ATOM
Stakers: Receive $1000/block total
Scenario B - Growing ecosystem:
Target: $1000/block
Revenues: $600/block (more activity, more partners)
Gap: $400
Inflation: Mints $400 equivalent
Stakers: Still receive $1000/block
→ But inflation dropped by 55%!
Scenario C - Mature ecosystem:
Target: $1000/block
Revenues: $1500/block
Gap: $0
Inflation: 0
Stakers: Receive $1500/block
→ Zero inflation, higher rewards
Inflation Cap: A Safety Bound
This mechanism doesn’t mean unlimited inflation. Governance sets a maximum inflation rate that cannot be exceeded, even if revenues fall short of the target.
Example with cap:
Target: $1000/block
Revenues: $100/block
Gap: $900
Max inflation: $500/block (governance cap)
Actual inflation: $500 (capped)
Stakers receive: $600 ($100 revenues + $500 inflation)
→ Target not reached, but inflation stays bounded
This protects against scenarios where revenues collapse temporarily (bear market, low activity). The network accepts a lower security budget rather than hyperinflating.
Governance controls both levers:
-
Target: the ideal security budget
-
Cap: the maximum acceptable inflation
Over time, as revenues grow, the cap becomes irrelevant — inflation naturally drops below it.
Compatibility with Fee Burn (Feemarket Module)
This proposal is fully compatible with the feemarket module that burns a portion of transaction fees. In fact, they complement each other well.
When target is NOT reached (early stage):
Fees collected: 100 ATOM
Burned (50%): 50 ATOM
To stakers: 50 ATOM
Gap to target: 200 ATOM
Inflation minted: 200 ATOM
Net supply change: -50 + 200 = +150 ATOM
The burn is effectively “cancelled” by compensating inflation. No harm, no benefit — the burn is neutral.
When target IS reached (mature ecosystem):
Fees collected: 100 ATOM
Burned (50%): 50 ATOM
To stakers: 50 ATOM (+ streams = target reached)
Inflation minted: 0
Net supply change: -50 ATOM (deflationary!)
The burn only becomes truly deflationary when the ecosystem generates enough revenue. Before that, it’s neutral. This is the best of both worlds: fee burn + revenue-linked inflation work together naturally.
Why This Works
For stakers: Guaranteed minimum yield (the target), with upside when ecosystem thrives.
For holders: Inflation decreases automatically as revenues grow. No more arbitrary votes.
For validators: Predictable security budget. Clear incentive to grow ecosystem revenues.
For the ecosystem: Direct link between Hub success and reduced inflation. Aligned incentives.
For staking incentives: Inflation rewards stakers — they receive all newly minted tokens, including the share that would have gone to non-stakers, so stakers grow their percentage of total supply while non-stakers get diluted. But this is an internal transfer: stakers gain what non-stakers lose. Real revenues are different — it’s fresh value entering the ecosystem. Stakers gain without anyone inside the ecosystem losing. This makes the Hub more attractive as a productive asset, not just an inflation hedge.
For the future: The revenue stream infrastructure can serve as a payment mechanism for potential future Hub services. As the ecosystem evolves and new use cases emerge, the primitives are already in place.
Governance Parameters
type Params struct {
// Target revenue per block (in ATOM or USD equivalent)
TargetPerBlock sdk.Coin
// Maximum inflation per block (safety cap)
MaxInflationPerBlock sdk.Coin
// Minimum inflation (optional, could be 0)
MinInflationPerBlock sdk.Coin
// Allowed denoms for revenue streams
AllowedDenoms []string
// Minimum amount to create a stream (anti-spam)
MinStreamAmount sdk.Coin
}
Governance controls the target, not the inflation directly. This is a crucial shift:
-
Old model: “Vote to set inflation at 7%”
-
New model: “Vote to set security budget at X ATOM/block, let revenues determine inflation”
Addressing Concerns
“What if no one contributes revenue streams?”
Then we’re exactly where we are today: inflation funds security. No worse off.
But we’ve created the infrastructure and incentive for contributions. Entities funded by community pool now have a clear, transparent way to give back. Social pressure and transparency do the rest.
“Isn’t this complicated?”
For users: Nothing changes. You stake, you earn rewards.
For governance: Instead of debating arbitrary percentages, you debate the security budget. More rational, less political.
For implementation: The core module is straightforward. I’ve implemented similar mechanisms on other Cosmos chains.
“What about price volatility of ATOM?”
Two options:
-
Target in ATOM terms: Simple, but security budget fluctuates with price
-
Target in USD terms: Requires price oracle, but stable security budget
I recommend starting with ATOM-denominated target for simplicity, with option to add USD-targeting later via oracle integration.
Implementation Notes
Core Module: x/revenue
// Keeper interface - internal only, no public messages
type RevenueKeeper interface {
// Called by other modules to create revenue streams
CreateStream(ctx sdk.Context, source sdk.AccAddress, amount sdk.Coins, durationBlocks int64) error
// Called in EndBlocker
DistributeRevenues(ctx sdk.Context) sdk.Coins
CalculateInflationGap(ctx sdk.Context) sdk.Coin
}
Key design decisions:
-
Public
MsgCreateStreamallows external partners to contribute revenues on-chain -
Spam prevention via whitelisted denoms + minimum amount (not via restricting who can send)
-
Streams distribute linearly over their duration → prevents gaming
-
Small amounts go directly to fee collector → no dust streams
-
All on-chain, all queryable → full transparency
Integration with Mint Module
The existing x/mint module would be modified to:
-
Query
x/revenuefor current gap -
Mint only the gap amount (instead of fixed inflation)
-
Respect max/min bounds from params
Call for Discussion
I’m posting this to start a conversation, not to push for immediate implementation.
Questions for the community:
-
Does linking inflation to revenues make sense as a direction?
-
What should the initial target be? (Current inflation equivalent? Lower? Higher?)
-
Who can create revenue streams? Two options:
-
Whitelisted addresses (governance approves each contributor)
-
Permissionless with constraints (anyone, but only whitelisted denoms + minimum amount to avoid spam)
-
-
How do we encourage ecosystem partners to contribute?
-
Should the target be ATOM-denominated or USD-denominated?
What I’m NOT proposing:
-
Forcing anyone to contribute
-
Removing inflation entirely tomorrow
-
Complex mechanisms that are hard to understand
What I AM proposing:
-
A rational framework for inflation
-
Infrastructure for transparent ecosystem contributions
-
A path toward sustainable security funding
Feedback welcome.
