NEAR Governance Votes To Scrap Developer Gas Rebates In Tokenomics Shift

NEAR governance has voted to remove the network’s 30% developer gas rebate program, redirecting all execution fees toward a protocol-level burn once the change is implemented through the nearcore v2.14 upgrade.

That timing matters because the rebate is not gone from mainnet until the upgrade happens.

Still, the decision is notable. NEAR’s gas rebate model was originally designed to reward developers when their applications generated activity. The logic was simple: if a contract brings users and transactions to the network, the developer receives a share of the fees.

Now governance is moving toward a cleaner burn model.

Developer gas rebates were one of NEAR’s more distinctive design choices.

They gave builders an economic reason to deploy useful contracts. If an app generated transactions, the developer could receive a portion of the fees. In theory, that aligned developers with network usage.

It was a simple incentive story: build apps people use, earn from the activity.

That can be powerful in early ecosystem growth. Developers need reasons to commit time and resources to a chain. Fee rebates can help make app development feel less dependent on grants, token incentives, or external fundraising.

But incentive programs can also become complicated over time.

As a network matures, governance may ask whether the rebate still creates enough value to justify its tokenomics impact. If the program is not clearly driving meaningful developer retention or application quality, redirecting fees may look more attractive.

That appears to be the direction NEAR is taking.

Moving execution fees to a protocol-level burn changes who benefits from network activity.

Under the rebate model, developers captured part of the fees generated by their contracts. Under the burn model, fees are removed from circulation, which can make network activity more directly relevant to token supply.

That is why tokenomics watchers care.

Fee burns are easy for markets to understand. More usage can mean more fees burned, and more fees burned can reduce supply pressure. The actual impact depends on transaction volume, fee levels, issuance, and broader token economics, but the logic is cleaner.

Instead of splitting fees with developers, the network directs all execution fees toward burn.

That may make NEAR’s economic model easier to explain to investors, but it also removes a developer-specific reward mechanism.

The obvious question is whether developers lose something important.

If a team was relying on gas rebates as part of its business model, the change could matter. It may reduce passive revenue from contract usage and push developers toward other monetization models, such as app fees, subscriptions, protocol revenue, grants, or token incentives.

That is not necessarily bad.

A network may decide that direct app-level business models are healthier than protocol-level rebates. But it does change the builder incentive landscape.

For early-stage developers, even small rebate income can feel validating. For larger apps, the amount may be less meaningful compared with other revenue sources.

The real test is whether removing rebates affects developer behavior.

Do teams keep building? Do apps stay active? Does governance replace rebates with better support programs? Or does the change make NEAR less attractive for certain builders?

Those answers will take time.

There is also value in making the economic model simpler.

Crypto networks often accumulate complex incentives: rebates, emissions, grants, subsidies, reward programs, and fee splits. Each one may make sense when introduced, but the combined system can become hard to understand.

A burn model is easier.

Users pay fees. Fees are burned. Network usage has a clearer relationship to supply.

That does not automatically make the token more valuable, but it can make the narrative cleaner and reduce confusion around where fees go.

For NEAR, that may be part of the appeal. The network has been pushing toward clearer governance and tokenomics through House of Stake, and HSP-027 fits that broader effort.

The final caveat is timing.

Governance approval is not the same as implementation. The change is expected with nearcore v2.14, so users and developers should not assume the rebate has already disappeared from mainnet.

That implementation step matters.

For NEAR, the decision marks a shift from developer-specific gas sharing toward network-wide fee burn economics.

Whether that proves better depends on what the ecosystem values more right now: direct developer rebates or cleaner tokenomics tied to usage.

Governance has made its choice. The next test is whether builders and users agree with it.

This article was written by the News Desk and edited by Samuel Rae.