## Summary
The objective of this proposal is simple:
**Reduce unnecessary NEAR dilution as quickly as possible, but only as quickly as can be done safely without weakening validator incentives or network security.**
Rather than choosing a predetermined future inflation target such as 1%, 0.5%, or 0%, I propose allowing actual protocol revenue and observed network-security conditions to determine how much issuance can safely be removed over time.
The basic mechanism would be:
> **Protocol revenue supplements staking rewards → revenue is observed for 12 months → the weakest month determines how much issuance can safely be removed → emissions are reduced → the process repeats.**
The intention is to gradually replace **inflation-funded security** with **revenue-funded security**.
-–
## 1. Why change the current model?
NEAR currently compensates validators and stakers primarily through newly issued NEAR.
At the current stage of the network, the existing 2.5% issuance rate may still be reasonable. NEAR also recently reduced issuance from 5% to 2.5%, so another immediate large reduction without sufficient data would introduce unnecessary risk.
The longer-term problem is different.
A fixed percentage issuance rate automatically becomes increasingly valuable as NEAR’s market capitalization rises.
For example, 2.5% issuance at a $3 billion valuation represents approximately $75 million of annual token value.
At $20 billion, the same 2.5% represents approximately $500 million.
The network does not necessarily become proportionally more expensive to secure simply because the token price appreciates.
For that reason, I believe issuance should eventually be based increasingly on the **actual economic requirements of network security**, rather than remaining permanently fixed at a percentage of supply.
-–
# 2. Redirect protocol revenue toward staking rewards
During the transition period, net protocol revenue—particularly revenue currently used for NEAR buybacks—could instead be used to purchase NEAR and distribute it algorithmically as staking rewards.
This creates two sources of staking compensation:
$$
\boxed{
\text{Staking rewards}
=
\text{Emission-funded rewards}
\text{Revenue-funded rewards}
}
$$
The revenue-funded portion would not require new tokens to be minted.
Protocol revenue would purchase existing NEAR and redistribute it to those securing the network.
This has several advantages.
It increases the incentive to stake without increasing inflation.
It may increase the percentage of NEAR committed to network security.
It allows NEAR to measure how validator and delegator participation responds to revenue-funded rewards.
Most importantly, it begins transitioning staking compensation from:
> **newly created tokens**
toward:
> **real economic activity generated by the network.**
-–
# 3. Do not choose the emission reduction in advance
I initially considered predetermined reductions such as 0.25% or 0.5%.
I believe a better mechanism is to allow the data itself to determine the reduction.
The network should not say:
> “Next year we will reduce emissions by 0.25%.”
Instead it should ask:
> **“How much issuance has protocol revenue demonstrated that it can safely replace?”**
This also avoids problems caused by large changes in the NEAR token price.
-–
# 4. Measure revenue in NEAR, not only in USD
Because the purchasing power of protocol revenue changes with the NEAR price, the relevant measurement should be the amount of **NEAR actually purchasable with net protocol revenue**.
For each month:
$$
B_m=\text{NEAR purchased using that month’s net protocol revenue}
$$
Observe this for 12 consecutive months.
Then identify the weakest month:
$$
B_{\min}=\min(B_1,B_2,\ldots,B_{12})
$$
This weakest month represents the most conservative demonstrated revenue capacity during the observation period.
-–
# 5. Apply a 2× safety margin
I propose that only **half of the weakest month’s demonstrated revenue capacity** should be allowed to replace emissions.
Therefore:
$$
\boxed{
\text{Safe monthly emission reduction}
=
\frac{B_{\min}}{2}
}
$$
Annualized:
$$
\boxed{
\text{Annual emission reduction}
=
6B_{\min}
}
$$
This creates a **2× revenue coverage requirement**.
For example, if even the weakest month during the previous year generated enough net protocol revenue to purchase:
**1,000,000 NEAR**
then only:
**500,000 NEAR per month**
would be considered replaceable issuance.
Annual reduction:
$$
500,000\times12=6,000,000\ NEAR
$$
The emission rate would therefore be reduced by whatever percentage of total supply 6 million NEAR represents at that time.
The percentage is an **output**, not a predetermined target.
-–
# 6. Why use the weakest month?
Using average annual revenue would create unnecessary risk.
Imagine eleven months of very high revenue followed by one extremely weak month.
The annual average might still look excellent, even though the weaker month demonstrates that protocol revenue may not yet be dependable enough to replace validator subsidies during difficult market conditions.
Using the weakest month means that the system asks:
> **“What level of revenue has NEAR proven it can sustain even during the least favorable month of the year?”**
Then only half of that amount is used to justify reducing issuance.
This gives the network significant protection against:
* declining Intents activity,
* falling protocol revenue,
* rising NEAR prices,
* crypto bear markets,
* temporary decreases in fee generation.
-–
# 7. Start a new observation period after every cut
Once emissions are reduced, the previous 12 months should not immediately be reused to justify another reduction.
The system has entered a new economic equilibrium.
A fresh observation period should begin.
The cycle becomes:
**1. Revenue-funded staking rewards begin**
↓
**2. Observe 12 months**
↓
**3. Find the weakest month**
↓
**4. Divide its NEAR revenue capacity by two**
↓
**5. Reduce annual issuance by that amount**
↓
**6. Observe the new staking/security equilibrium**
↓
**7. Begin a new 12-month measurement period**
There is no requirement for emissions to fall every year.
If revenue stops growing, NEAR appreciates too quickly, validator economics deteriorate, or network security metrics weaken, emissions simply remain unchanged.
The process resumes only when conditions justify another reduction.
-–
# 8. Network security must override the formula
Revenue alone should never automatically determine monetary policy.
Before any reduction, NEAR should also examine:
* percentage of total supply staked,
* validator count,
* validator concentration,
* delegation concentration,
* validator profitability,
* geographic and infrastructure decentralization,
* staking participation,
* staking APY,
* network-security metrics.
The calculated reduction should represent the **maximum economically justified cut**, not an automatic mandatory reduction.
If security metrics suggest that the network still requires the existing reward level, the cut should be reduced or postponed.
In simple terms:
> **Revenue determines what NEAR can afford to remove.
> Security determines what NEAR should remove.**
-–
# 9. Why revenue-funded staking first?
Protocol revenue could instead continue being used solely for buybacks and permanent supply reduction.
That benefits all holders through scarcity.
However, during this transition period I believe using revenue for staking compensation may provide greater strategic value.
It can:
* increase staking incentives,
* potentially increase the percentage of supply securing the network,
* strengthen the holder/staker base,
* give validators additional compensation while emissions are still being studied,
* establish how much real revenue can replace inflation-funded rewards,
* provide direct empirical data before monetary policy is changed.
If protocol revenue grows rapidly, staking APY may temporarily rise.
That is not necessarily undesirable.
Higher revenue-funded rewards should attract more staking capital. As more NEAR becomes staked, the same reward pool is distributed across more tokens, naturally reducing the individual APY.
At the same time, consistently high revenue would demonstrate that some existing emissions may no longer be necessary.
-–
# 10. Long-term objective
The objective should **not** be:
> “NEAR must reach 0% inflation.”
Nor should it be:
> “NEAR must become deflationary as soon as possible.”
The objective should be:
$$
\boxed{
\textbf{Replace dilution-funded network security with revenue-funded network security as quickly as safely possible.}
}
$$
A mature system could eventually look like:
$$
\text{Required staking/security compensation}
$$
funded first by:
$$
\text{Protocol revenue}
$$
with new issuance covering only:
$$
\text{Any remaining security shortfall}
$$
If protocol revenue eventually exceeds what is required to maintain sufficient staking incentives and network security, surplus revenue could then be redirected toward mechanisms such as buyback-and-burn.
The theoretical long-term structure could therefore become:
$$
\text{Protocol Revenue}
\rightarrow
\begin{cases}
\text{Network security / staking rewards}\\
\text{Excess revenue → buyback/burn}
\end{cases}
$$
while:
$$
\text{New issuance}
\rightarrow
\text{only the amount still required for security}
$$
If eventually that required amount approaches zero, then emissions could approach zero naturally.
If security still requires some permanent issuance, that issuance should remain.
-–
# 11. Why I think this is preferable to a fixed inflation target
A fixed target such as “reduce inflation to 0.5%” assumes today that we already know how much compensation the network will require years from now.
We don’t.
This mechanism instead allows NEAR’s actual economic activity to reveal the answer over time.
It automatically adapts to:
* protocol growth,
* revenue growth,
* token price,
* staking participation,
* validator requirements,
* bear markets,
* bull markets,
* changing network maturity.
The monetary policy therefore becomes increasingly based on **observed economic productivity rather than arbitrary percentages**.
-–
# Questions for validators, developers and governance participants
I would particularly appreciate feedback on the following:
* Is redirecting protocol revenue toward staking rewards technically practical?
* Should revenue-funded rewards be distributed proportionally through the existing staking system?
* Is a **2× safety margin** conservative enough?
* Is using the **weakest month of a 12-month period** a reasonable way to measure sustainable revenue?
* Should the observation period be longer than 12 months?
* Should there also be a maximum percentage by which emissions can be reduced in a single adjustment?
* Which security metrics should be mandatory before approving a reduction?
* How should validator operating costs and required economic stake be incorporated?
* Would a security reserve be useful in addition to the 2× revenue buffer?
* At what point should excess protocol revenue transition from staking rewards back toward buyback/burn?
The core principle I am proposing is:
> **Do not reduce emissions simply because inflation is undesirable. Reduce emissions only when real network revenue has demonstrated that the corresponding issuance is no longer necessary—and maintain a large safety margin before doing so.**
This should allow NEAR to reduce long-term dilution while keeping network security as the primary constraint.