NEAR Governance Discussion: Sovereign Fund

[illia]

I am withdrawing this proposal.

Thank you to everyone who engaged here, and to the many people I spoke to outside the forum over the last two weeks. The quality of the responses was higher than I’d hoped for, and several of them changed my thinking.

The strongest thread running through the feedback is about discretion. A fund that generates yield needs someone deciding where the capital goes, and someone deciding who receives the proceeds. Both are judgment calls, and therefore both introduce risk: manager discretion, counterparty and contract risk, and the political risk that comes with any body allocating a growing pool of capital. Several of you made the point that validator rewards today are algorithmic, and that replacing them with an allocation, however well governed, turns security from something the protocol guarantees into something a human process decides. These are risks the protocol should not internalize.

We also want to make sure that buy back revenue from intents and other sources doesn’t ever come back to circulation - that was my underlying assumption with a proposal but the proposed mechanism doesn’t guarantee that. Making sure it’s that so is important here.

The second, and related, concern is around “public goods,” which now has a lot of baggage and is perceived as easily corrupted. Any definition wide enough to be interesting is wide enough to be captured, and the discussion here surfaced good arguments that the category tends to expand to fit the funding available. If we revisit a similar idea in the future, the scope of public goods should be tightly specified and boring: validators, node operators, MPC, i.e. the infrastructure the network can’t run without. In order to minimize the risks that come with human decision-making, there shouldn’t be room for judgment about what does and doesn’t qualify.

As for where attention should go, I think the feedback is right that the binding constraint today is demand, not what we do with the treasury. The highest leverage work in front of us is to grow assets and volume on Intents, adoption and NEAR staking for AI. Those generate real external revenue and utilization of NEAR tokens. Until that revenue is large and durable, questions about how to invest it are premature, and the structure could likely cost more than it earns.

To be clear, I think this discussion went the way it should. I put forward an idea, people with real skin in the game pushed back with numbers and specifics, and the outcome is different from what I proposed. That is what this discussion process is for, and it sends a better signal about NEAR’s governance than the proposal passing would have been. Thank you especially to those who deeply engaged with this conversation.

Now the floor is open. If you have a view on how protocol revenue should be handled, whether that is burn, native staking with permanently locked principal, direct algorithmic distribution to validators, or something not raised here, please post it. Several of the alternatives in this thread deserve their own threads, and I’d love to see them debated on their own terms and carry the conversation beyond the replies to mine.

[NEAR_MAXi]

One alternative worth considering: AnnuityNEAR.

Protocol buybacks could be staked into an LST with a hard-coded 30-year unstaking period. The underlying NEAR is therefore effectively removed from circulation for a generation (or more!), while the LST remains liquid, earns staking rewards, can be used as Defi collateral (with appropriate deeper haircut), and has a secondary-market price which could in the future find a floor from the likes of insurance companies and pension funds that have decades long dated liabilities to fund, if NEAR and crypto become more mainstream as an asset class.

Instead of distributing liquid NEAR as DeFi and other ecosystem incentives, the protocol could distribute AnnuityNEAR. Recipients still get something immediately valuable and sellable, but selling it does not release the underlying NEAR back into circulation.

[cizi31]

I think the strongest option is a simple, algorithmic burn.

If Intents and other protocol products generate real revenue, use a defined portion to buy and permanently burn $NEAR.

No committees. No discretionary allocation. No political risk.

More usage → more revenue → more $NEAR burned.

That gives the token a clear and transparent value-accrual mechanism.

[NEAR_MAXi]

Another way to frame AnnuityNEAR is as a liquidity-management tool.

Central banks sometimes talk about “mopping up excess liquidity.” Here the protocol would use external revenue to buy spot NEAR, then term that liquidity out for 30 years by converting it into AnnuityNEAR.

That directly addresses your concern that buyback NEAR should not simply find its way back into circulation: the underlying NEAR is structurally unavailable for decades.

But unlike a burn, the protocol retains the economic benefit in the form of a liquid, coupon-paying claim that can be deployed for growth, incentives or other uses as appropriate.

So the trade is essentially: sterilize spot NEAR liquidity while preserving the capital’s economic utility.

[vadim_hom]

A pity this got withdrawn. Most of the discussion was about the mechanics, but the context that mattered sat one level up: NEAR keeps cutting inflation, and the end state is fixed supply, where security is paid from real revenue instead of emission. The fund was one possible mechanism for that. Waiting for the next proposal.

[NEAR_MAXi]

An illustration of how AnnuityNEAR would work

[rdp4by]

Proposal: A USD-Denominated Security Budget and NEAR Revenue Router

NEAR should replace fixed-percentage security issuance with a security budget denominated in USD.

One NEAR issued when the token trades at $1 and one NEAR issued when it trades at $100 cause the same dilution but provide radically different purchasing power to validators.

With approximately 1.302B total supply, maximum annual issuance of 2.5%, and roughly 90% allocated to validator and delegator rewards, the protocol may distribute approximately 29.3M NEAR annually for security.

That represents:

• $29.3M at $1 per NEAR;

• $293M at $10 per NEAR;

• $2.93B at $100 per NEAR.

Validator hardware, monitoring, staffing, and redundancy costs do not increase one hundredfold merely because the token appreciates.

The protocol should therefore determine the minimum security budget required in USD and issue only the amount of NEAR that remains necessary after applying real protocol revenue.

Core mechanism

For each settlement period, define:

• B = the security budget for the period, denominated in USD;

• P = a robust NEAR/USD reference price;

• S = B / P = the required security rewards denominated in NEAR;

• Q = the amount of NEAR actually purchased with verified net external protocol revenue.

The protocol applies the following rules:

• Revenue-funded rewards = min(Q, S)

• New issuance = max(0, S − Q)

• Burn = max(0, Q − S)

Therefore:

Net supply change = S − Q

Existing gas burns remain additional to this calculation.

Every NEAR purchased with external revenue either replaces one NEAR that would otherwise have been issued or, after issuance reaches zero, is permanently burned.

The protocol no longer targets an arbitrary inflation percentage. It targets the lowest dollar security budget capable of maintaining a safe and decentralized validator set.

Inflation becomes only the residual funding source.

Example

Assume the minimum sustainable security budget has been discovered to be $20M annually.

NEAR at $1 with $5M of external revenue

• Required security rewards: 20M NEAR.

• Revenue purchases 5M NEAR.

• The purchased 5M NEAR is used for validator and delegator rewards.

• The protocol issues only the remaining 15M NEAR.

• Net supply growth before gas burns is 15M NEAR.

NEAR at $100 with the same $5M of external revenue

• Required security rewards: 200,000 NEAR.

• Revenue purchases 50,000 NEAR.

• The protocol issues only 150,000 NEAR.

• Validators and delegators still receive the same $20M security budget.

NEAR at $100 with $30M of external revenue

• Security requires 200,000 NEAR.

• Revenue purchases 300,000 NEAR.

• 200,000 NEAR is used for security rewards.

• New issuance is zero.

• The remaining 100,000 NEAR is burned.

• The network becomes deflationary before accounting for gas burns.

The $20M figure is illustrative. The final budget should not be selected politically or assumed in advance.

Discovering the minimum security budget

The minimum budget cannot be calculated from server bills alone.

It must cover:

1. validator hardware, redundancy, monitoring, security, and professional operation;

2. sufficient compensation to maintain an adequate share of NEAR in staking;

3. the cost of maintaining a large and decentralized validator set;

4. operational and capital risk.

The protocol should discover the minimum through a gradual descending process. The staking market itself should reveal the lowest budget that preserves the required security conditions.

Initial budget

The initial USD budget should equal the trailing 180-day USD value of existing validator and delegator rewards.

This preserves the current level of security expenditure without imposing an immediate income shock.

It also prevents a rising NEAR price from automatically multiplying validator compensation while infrastructure costs remain broadly unchanged.

Six-month adjustment cycle

Every six months, the protocol evaluates objective security indicators.

If all indicators remain in the green zone throughout the period, the annual USD security budget decreases by 5%.

Suggested green-zone conditions:

• at least 40% of total NEAR supply remains staked;

• at least 350 active validators remain;

• block and chunk performance remains above the defined protocol threshold;

• stake concentration does not deteriorate relative to the activation baseline;

• geographic, infrastructure-provider, and hosting concentration does not materially worsen.

If the network enters a warning zone, the budget remains unchanged.

Suggested warning-zone conditions:

• 35–40% of total supply is staked;

• 300–349 active validators remain;

• concentration or network performance moderately deteriorates.

If a hard security floor is breached, the budget automatically increases by 10%.

Suggested hard floors:

• less than 35% of total supply is staked;

• fewer than 300 active validators remain;

• block or chunk production materially deteriorates;

• stake concentration materially increases.

Budget reductions require sustained evidence. Increases occur faster because temporarily overpaying for security is safer than underpaying for it.

The process continues until another reduction would push the network into the warning zone. This is how the protocol discovers the minimum sustainable security budget.

Operational cost floor

The security budget must never fall below a transparent operating-cost index.

The index should be calculated from:

• official hardware requirements for each validator role;

• public prices from multiple hosting providers;

• required backup infrastructure;

• monitoring and security costs;

• a predefined operating and risk margin;

• the target number of validators.

The formula and every input must be public and reproducible.

Validators should not vote on their own reimbursement or submit discretionary applications for support.

The staking-participation controller will likely stop budget reductions before the operating-cost floor is reached. Nevertheless, the floor protects the network against an obviously inadequate budget.

NEAR/USD reference price

Using an instantaneous spot price would expose issuance to manipulation and excessive volatility.

The reference price should use:

• a rolling median or time-weighted price;

• multiple independent and liquid markets;

• both on-chain and reputable external inputs;

• deviation checks and circuit breakers;

• regular but limited update intervals.

A 90-day rolling median is a reasonable starting point.

If price sources fail or materially disagree, the protocol should suspend further budget reductions and use a conservative fallback that favors security.

USD serves only as the accounting unit. Validators and delegators continue receiving NEAR.

Permissionless reward distribution

This proposal does not create a validator-support committee.

The USD budget is converted into the necessary quantity of NEAR and distributed through the existing protocol reward mechanism.

There are:

• no applications;

• no politically selected “core validators”;

• no House of Stake allocation decisions;

• no fund managers;

• no yield strategies;

• no synthetic token;

• no human decisions about which validator deserves payment.

Revenue may reduce issuance, but it can never reduce the total security budget.

If revenue declines, issuance automatically fills the difference.

If the NEAR price rises, fewer NEAR are required.

If the price falls, more NEAR are issued to preserve the minimum dollar security budget.

Issuance may increase again after previously reaching zero if revenue falls. This is a deliberate security mechanism, not a policy failure. Zero issuance should be an economic outcome, not an irreversible political promise made before revenue is durable.

Why staking participation must be monitored

Server costs alone do not determine Proof-of-Stake security.

Delegators lock capital and accept liquidity, smart-contract, and protocol risks. If the security budget becomes too small, staking returns may fall below the level required by tokenholders, causing the staked ratio to decline.

The budget therefore cannot simply equal estimated infrastructure expenditure.

The descending-budget process tests the real supply curve for stake.

If holders continue staking, the previous budget was higher than necessary.

If participation approaches a security floor, reductions stop.

Why purchased NEAR may be used for rewards

Some may object that purchased NEAR returns to circulation when paid to validators and delegators.

However, every purchased NEAR used for rewards prevents exactly one new NEAR from being issued.

Compare two outcomes:

• issue 20M NEAR and purchase and burn 5M NEAR;

• issue 15M NEAR, purchase another 5M NEAR, and use it for rewards.

In both cases, validators and delegators receive 20M NEAR, while total supply increases by 15M NEAR.

The final supply and distribution effects are economically equivalent.

The difference is that the second model gradually replaces inflation-funded security with revenue-funded security.

Eligible protocol revenue

Only realized net external revenue should qualify.

Eligible revenue must:

• come from real users, customers, or commercial counterparties;

• be calculated after rebates, partner payments, and direct subsidies;

• be realized rather than based on token valuations or unrealized investments;

• be independent of NEAR issuance and ecosystem incentive loops;

• be converted into NEAR and delivered by an approved protocol revenue source.

The following must not qualify:

• staking rewards;

• liquidity-mining incentives;

• tokens generated through subsidized internal activity;

• transfers between commonly controlled entities;

• headline “revenue” offset by larger grants or incentives.

Revenue generated by an independent company belongs to that company unless it has contractually committed a defined share to the protocol.

Consensus does not need to value stablecoins or rely on an off-chain revenue oracle. Only NEAR already purchased and delivered to the Revenue Router counts as Q.

Revenue Router

The Revenue Router should be a narrow protocol mechanism, not a treasury organization.

It may perform only three actions:

1. receive NEAR purchased with verified protocol revenue;

2. send the required amount to the existing validator and delegator reward mechanism;

3. burn any amount exceeding the security requirement.

It must have:

• no investment mandate;

• no lending or leverage;

• no DeFi exposure;

• no synthetic token;

• no grant-making authority;

• no managers or management fees;

• no discretionary withdrawal function.

The existing protocol treasury is not transferred into this mechanism. Its history, ownership, performance, and intended use should be audited and discussed separately.

Buyback execution

Revenue conversion must use transparent and competitive execution.

For every conversion, the protocol should publish:

• the revenue source and net amount;

• the asset received;

• the amount of NEAR purchased;

• the average execution price;

• slippage;

• the solver or venue used;

• the amount used for security;

• the amount of issuance avoided;

• the amount burned.

If safe conversion cannot be completed, normal issuance continues.

A failed buyback, oracle failure, or router malfunction must never reduce validator and delegator rewards.

Public goods remain separate

The security budget covers only protocol-defined validator and delegator rewards.

Grants, marketing, education, regional hubs, ecosystem organizations, and other discretionary expenditures must be considered separately through explicit budgets, audits, conflict disclosures, and recipient accountability.

Combining permissionless security with subjective ecosystem spending would expose monetary policy to political capture.

House of Stake may participate in public discussion like any other community venue, but it should not control protocol revenue, select beneficiaries, or receive a share of the mechanism’s flows.

Rollout

Phase 1: Twelve-month shadow calculation

Publish:

• the calculated USD security budget;

• the NEAR/USD reference price;

• the required NEAR rewards;

• revenue-funded rewards;

• hypothetical issuance;

• hypothetical burns;

• validator count;

• staked ratio;

• stake concentration;

• network performance.

No tokenomics changes occur during this phase.

Phase 2: Limited activation

For the following twelve months:

• the USD budget cannot decline by more than 10% from its initial level;

• only new external protocol revenue is used;

• the existing treasury remains untouched;

• any price-feed or router failure automatically restores the previous issuance mechanism.

Phase 3: Automatic budget discovery

After an independent technical and economic review, activate the six-month adjustment cycle.

No committee selects the final budget. The network discovers it through measurable validator and staking behavior.

Success criteria

The mechanism succeeds if:

• validators and delegators receive expected rewards without interruption;

• every unit of eligible revenue is publicly reconcilable;

• issuance decreases exactly by the amount of purchased NEAR used for security;

• surplus revenue is provably used to purchase and burn NEAR;

• the NEAR/USD price is calculated through a transparent and manipulation-resistant methodology;

• validator count, stake participation, concentration, and network performance remain within defined security limits;

• no person or committee can redirect the financial flows.

Conclusion

NEAR should not promise a permanent fixed inflation percentage.

It should guarantee a measurable level of security.

The rule should be:

Determine the minimum security budget in USD. Convert it into NEAR using a robust market price. Fund it first with real external revenue. Issue only the shortfall. Burn the surplus.

At a low NEAR price, the protocol issues more tokens because more NEAR is required to pay for security.

At a high NEAR price, the protocol issues dramatically fewer tokens because the same security services can be purchased with fewer NEAR.

If real external revenue eventually exceeds the minimum dollar cost of security, issuance automatically reaches zero and the remaining revenue makes NEAR deflationary.

This aligns issuance with the cost of the service being purchased instead of creating an arbitrary windfall whenever the token appreciates.

Most importantly, the mechanism creates no investment fund, synthetic asset, or discretionary pool of capital that anyone can capture.

[Kwai]

Here is your forum post, formatted and ready to publish on the official NEAR Governance Forum:
Title: Contribution to the NEAR Sovereign Fund Discussion — Risk Framework & Implementation Suggestions
Author: [Your username/handle]
Summary
The NEAR Sovereign Fund proposal marks a critical maturation point for the ecosystem. Shifting from pure inflationary security funding to a productive capital model — drawing inspiration from university endowments and sovereign wealth funds (Norway, Singapore) — is economically superior to simple token burning. It preserves productive capital, generates recurring yield, and creates a credible path toward $NEAR becoming a fixed-supply asset.
I strongly support this direction. The purpose of this post is to contribute practical suggestions that strengthen the implementation layer: risk mitigation, transition mechanics, and governance safeguards.
What the Proposal Gets Right
Strength Rationale
Productivity over Burning Reinvesting protocol revenue into yield strategies is mathematically superior to burning. Capital stays productive inside the ecosystem rather than being destroyed.
Validator Support Program Paying smaller validators in stable, predictable USD terms solves the long-tail stake concentration problem and strengthens real decentralization.
House of Stake Governance Tying fund management to decentralized governance legitimizes decisions and prevents unilateral control.
Phased Rollout A milestone-based transition reduces market shock and allows the community to adjust based on real performance data.
Key Risks Requiring Mitigation

1. Smart Contract & DeFi Risk
   Deploying treasury capital into yield-generating strategies exposes the fund to smart contract exploits, hacks, and impermanent loss. A significant principal loss would permanently impair the fund’s ability to fund security.
2. Pro-Cyclical Concentration in $NEAR
   Holding the fund 100% in $NEAR creates structural risk: in a bear market, the fund’s USD value collapses exactly when protocol revenue also declines. Traditional sovereign funds diversify precisely to dampen this cyclicality.
3. Governance Capture
   Capital allocation decisions (where to deploy for yield, which public goods to fund) are inherently political. Large stakers could capture this process to direct yield toward their own interests.
4. Premature Inflation Reduction
   Cutting inflation before the fund reaches critical mass may reduce staking attractiveness and trigger capital migration to other L1s with higher nominal yields.

---

Proposed Improvements
A. Layered Risk Structure (Tranches)
Do not deploy the entire fund into a single strategy. I propose the following allocation framework:
• Low Risk (60–70%): Native NEAR staking, tokenized T-bills, overcollateralized lending in audited blue-chip protocols.
• Medium Risk (20–30%): Stable pool liquidity, NEAR Intents market-making with high collateral requirements.
• High Risk (5–10%): Incentives for emerging ecosystem verticals or dynamic strategies.
Hard Rule: No more than 10% of total AUM in any single protocol or dApp.
B. Yield Diversification Reserve (Not Principal Diversification)
I agree the treasury should remain primarily $NEAR-denominated. However, the yield generated should be partially diversified. I suggest converting 10–20% of annual yield into lower-volatility assets (stablecoins, liquid high-volume pairs). This creates a liquid reserve to pay validator operational expenses during extended bear markets without creating artificial sell pressure on $NEAR.
C. Spending Rule (Endowment Model)
Following the Norwegian GPFG framework, only a fraction of real yield should be distributed. I suggest a 4–5% annual spending cap on realized yield, with the principal preserved to compound over time.
Critical Addition: Before any distributions begin, the fund should accumulate a stabilization reserve (“rainy day fund”) covering 12–24 months of minimum infrastructure expenses. This guarantees validator payments even in years of negative or depressed yield.
D. Metric-Conditioned Transition (Objective Triggers)
Inflation reduction should not follow calendar dates. It should follow objective performance triggers:
Phase Trigger Action
1 Fund > $50M AUM + sustained yield > 4% p.a. Reduce inflation by 25%
2 Fund > $100M AUM + yield covers 50% of security costs Reduce inflation by 50%
3 Fund > $200M AUM + yield covers 100% of security costs Zero inflation
Safety Clause: If yield coverage falls below the phase threshold for 2 consecutive quarters, inflation should be partially reactivatable as an emergency network security backstop.
E. Anti-Capture Mechanisms
To prevent the fund from being dominated by large stakeholders:
• High quorum requirement for strategic allocation changes.
• Veto power for non-staking token holders on high-impact decisions.
• Rotating mandates for the fund allocation committee.
F. Real-Time Transparency & Auditing
Create a public on-chain dashboard displaying:
• Total AUM and yield generated
• Infrastructure coverage ratio (yield vs. security costs)
• Risk-weighted allocation by protocol
• Automated alerts when risk limits are breached
All DeFi strategies must maintain:
• Multiple independent security audits
• Active bug bounty programs
• Insurance coverage (e.g., Nexus Mutual, InsurAce)
G. Reinvestment Incentive (Compounding Accelerator)
For the first 2–3 years, offer a reinvestment bonus (e.g., 1.2x multiplier on next period’s yield) for stakers who opt to compound rather than withdraw earnings. This accelerates fund growth and reduces short-term sell pressure.
Open Questions for the Community

1. What yield strategies does the community consider “blue-chip” enough for Low Risk tranche allocation?
2. Should the spending rule be fixed (e.g., 4%) or variable based on a trailing average?
3. What is the community’s appetite for partial stablecoin diversification of yield vs. 100% $NEAR reinvestment?
4. How should the “rainy day fund” target be calculated — fixed $NEAR amount, or dynamic based on validator count?

---

Final Thoughts
The NEAR Sovereign Fund is one of the most important tokenomic evolutions proposed for an L1 since the transition to Proof-of-Stake. The vision is sound: replace dilution with capital productivity.
For this fund to endure 30+ years — as Norway’s and Singapore’s have — we must design it with the same institutional rigor: clear risk boundaries, objective transition triggers, and governance safeguards against capture.
This post is not a critique of the vision, but a contribution to the implementation layer. I look forward to the community’s feedback and to refining these ideas together over the coming weeks.
Thank you to the NEAR team and Illia for putting this forward for community debate.
Discussion welcomed. Let’s build this right. This analysis was prepared with the assistance of KIMI, an artificial intelligence.