HSP-027: Remove the NEAR Developer Gas Rebate

[hos_official]

Frontmatter

hsp: 027
title: Remove the NEAR Developer Gas Rebate
description: Eliminate the 30% developer gas rebate and direct all execution fee burn to the protocol.
author: Anton Astafiev (NEAR One) - @bendersgreat
discussions-to: https://houseofstake.org/proposals/27
status: Voting
track: Decision
type: Simple Majority
category: Economic Governance
stakeholders: Tokenholders, Developers, Protocol Contributors, NEAR Ecosystem
created: 2026-06-15

Abstract

This proposal removes the developer gas rebate from the NEAR Protocol by reducing the rebate rate from 30% to 0%.

Under the current mechanism, smart contracts receive 30% of gas fees burned during contract execution. This proposal redirects the full amount to protocol-level burn. The objective is to strengthen token value accrual, simplify protocol economics, and retire an ecosystem subsidy introduced during an earlier growth stage. The expected outcome is increased alignment between network usage and token value accrual while preserving NEAR’s low-fee user experience and existing application business models.

Payload

The protocol parameter governing developer rebates shall be modified such that:

burnt_gas_reward = 0

Context

NEAR introduced a developer rebate mechanism whereby smart contracts receive 30% of gas fees burned during contract execution. The mechanism was designed to create a protocol-native incentive for application developers and public infrastructure providers.
At the time of introduction, ecosystem growth and developer acquisition were strategic priorities. The rebate allowed contracts to receive protocol-generated revenue directly from network usage.
Based on historical network activity, developer rebates have distributed the following amounts:

Month	Contracts Receiving Rebates	Rebate Upper Bound (NEAR)	Avg. Reward per Contract (NEAR)*
2025-06	2,224	61,371.86	27.60
2025-07	6,477	65,161.09	10.06
2025-08	8,660	48,868.57	5.64
2025-09	71,867	24,679.61	0.34
2025-10	223,698	25,509.46	0.11
2025-11	79,182	24,343.86	0.31
2025-12	65,594	21,432.89	0.33
2026-01	4,807	20,120.05	4.19
2026-02	4,161	18,254.92	4.39
2026-03	3,510	19,926.33	5.68
2026-04	4,414	6,197.22	1.40
2026-05	4,526	7,231.52	1.60

* Average reward per contract = rebate_upper_bound_near / contracts_receiving_rebates. Upper Bound is the maximum possible rewards distributed.

Over the past 12 months, the average reward per contract/month ranged from 27.6 NEAR in June 2025 to below 1 NEAR later that year, highlighting how quickly the developer rebate becomes diluted as rewards are spread across a growing number of contract instances. Even at its peak, the average rebate per contract represented only a modest revenue stream, suggesting that the mechanism is not a meaningful source of funding for most development teams.
Since its introduction, the NEAR ecosystem has matured significantly. Today, applications rely on a variety of revenue sources, including protocol fees, treasury assets, staking economics, token ecosystems, service revenue, and other business models. The developer rebate remains one of the few protocol-level subsidies embedded in network economics.
This proposal evaluates whether the original rationale for the subsidy remains sufficiently compelling to justify continued diversion of fee revenue away from protocol burn.

Problem

The current developer rebate creates three challenges.

• First, it reduces token value accrual by redirecting 30% of eligible execution fee burn away from the protocol.
• Second, it rewards gas consumption rather than economic value creation. Contract compensation is determined by gas burned rather than user adoption, revenue generation, assets secured, or other measures of ecosystem value.
• Third, it adds complexity to the protocol’s economics while providing limited value.
  This becomes even more apparent as NEAR moves toward sharded applications and user-owned contract deployments. The rebate rewards the account that executes the contract, not necessarily the developer who wrote it. In a sharded contract future, execution may happen across thousands of contract instances instead of a single application-owned contract. As a result, rebate rewards become fragmented across the accounts running the code, making the mechanism significantly less effective at rewarding application developers.

Given these limitations, it is worth reassessing whether a permanent protocol subsidy remains the best use of fee revenue.

Approach

This proposal removes the developer rebate entirely.
Rather than distributing 30% of execution fee burn to contract accounts, all eligible execution fees will be burned according to the protocol’s existing burn mechanism.
Alternative approaches considered include:

• Maintaining the 30% rebate → Doesn’t resolve the issues identified (see section “Problems”)
• Reducing the rebate without eliminating it → Reduces the economic impact, but preserves the additional complexity and incentive misalignment.
• Redirecting rebate funds to a treasury or governance-controlled pool. → Removes the economic impact, but preserves extra complexity, and associated governance overhead.

The proposed approach is preferred because it is simple, transparent, minimizes protocol complexity, and maximizes alignment between network usage and token value accrual.
A tradeoff of this approach is that contracts currently receiving rebate income will no longer receive that revenue stream.
However, the proposal assumes that the ecosystem has matured beyond the need for protocol-level developer subsidies and that applications should primarily rely on adoption-driven business models rather than protocol-funded incentives.

End-to-end Value Hypothesis

Objective

Remove the protocol-level developer rebate and direct 100% of eligible execution fee burn toward protocol burn.

Outcome

Tokenholders benefit from stronger alignment between network activity and token value accrual.
Protocol economics become simpler and easier to understand.
Developers continue to compete based on product quality, adoption, and sustainable business models rather than protocol subsidies.
The ecosystem transitions away from a bootstrapping incentive toward a mature fee model.

Dependencies

• NEAR Protocol Upgrade Process: Implementation requires the protocol upgrade process established by the NEAR Protocol and applicable governance procedures to modify the developer rebate parameter.
• NEAR House of Stake Governance Process: The proposal must successfully complete the governance process defined in the applicable Constitutional Documents, including review by the Screening Committee, Security Council, and House of Stake Directors, and approval by tokenholders through a governance vote.

Key Performance Indicators (KPIs)

• Developer rebate rate reduced from 30% to 0%.
• Successful protocol upgrade deployment.
• Increase in protocol-level fee burn attributable to removal of the rebate.
• No critical protocol incidents caused by implementation.

Technical Specification

Modify the protocol economic configuration governing developer rebates such that:

• Current developer rebate rate = 30%
• New Developer rebate rate = 0%

All execution gas fees currently eligible for developer rebate shall instead follow the protocol burn mechanism.

No changes are proposed to:

• gas pricing,
• gas accounting,
• transaction execution,
• validator rewards,
• staking economics,
• user fee calculations.

Backwards Compatibility

This proposal changes protocol economics but does not change application interfaces, APIs, contract execution behavior, or user transaction flows.
Existing contracts will continue to function without modification.
The proposal is not backwards compatible with respect to developer rebate revenue expectations.

Security Considerations

Economic Risk

Some applications may experience reduced revenue.
Mitigation:

• The rebate is removed uniformly across the ecosystem.
• Existing business models remain unaffected.

Ecosystem Participation Risk

Some developers may perceive reduced incentives to build on NEAR.
Mitigation:

• NEAR maintains low fees, strong developer tooling, and ecosystem support mechanisms.
• Sustainable applications should rely on user-driven business models rather than protocol subsidies.

Governance Risk

Stakeholders receiving rebate income may oppose the proposal.
Mitigation:

• Transparent public discussion and publication of economic impact analysis before voting.

Stakeholders

Activity / Decision	Responsible	Accountable	Consulted	Informed
Proposal drafting	NEAR One	NEAR One	Community	Tokenholders
Economic review	Protocol Working Group	NEAR One	Developers, Validators	Tokenholders
Governance vote	Tokenholders	Screening Committee/Security Council/HoSF directors	Community	Ecosystem
Protocol implementation	NEAR One	NEAR One	Developers	Tokenholders
Deployment communication	Governance Team	Head of Governance	Ecosystem Participants	Public

Implementation Plan

Definition of Done:

• Proposal approved through House of Stake governance process.
• Required protocol change implemented.
• Upgrade deployed to mainnet.
• Developer rebate rate set to 0%.
• Documentation updated.
• Public communication completed.

Milestones

Milestone name	Target date	Deliverable	Success criteria
Governance Approval	June–July 2026	Approved HSP	Proposal passes HoS vote
Protocol Implementation	July 2026	Code merged	Developer rebate parameter updated
Mainnet Deployment	Any release after v2.13	Protocol upgrade	Developer rebate disabled on mainnet
Post-Implementation Report	7 days after mainnet upgrade	Upgrade report	Change in protocol burn quantified and proven

Budget & Resources

Not applicable.

Conflict of Interest

The author has read and agrees with the House of Stake Conflict of Interest Policy.
The author declares no conflicts of interest except those disclosed during proposal discussion.

Copyright

Copyright and related rights waived via CC0 1.0.

[slimedrgn]

@hos_official

highlighting how quickly the developer rebate becomes diluted as rewards are spread across a growing number of contract instances

rebate is not spread across contracts, gas is rebated to contracts that are used by people, so ai slop contracts or rising number of global contracts probably have like 0.01 near of rebates and that’s as expected

@hos_official

Avg. Reward per Contract

congrats, out of all possible metrics you found the worst one. more contracts = bad?

@hos_official

only a modest revenue stream

for my app (intear dex) it’s like half of the entire revenue, if not more. for most contracts (like global contracts) there is no revenue at all so idk what you’re tracking

@hos_official

Since its introduction, the NEAR ecosystem has matured significantly

it was coughing baby, now it’s crying baby, matured significantly. only near intents and rhea dapps consistently have more than ~100 interactions per day afaik

@hos_official

• it reduces token value accrual by redirecting 30% of eligible execution fee burn away from the protocol

revenue vs emissions of jun 1 2026 (according to revenue.near.org): 16.81%. revenue: 11.6k protocol fees + 130.8k intents fees. if we divide protocol fees by 0.70, that would be 16.57k protocol fees, a 3.3% increase in daily revenue and 0.57% increase in token value accrual vs inflation (16.81% → 17.39%). very marginal improvement if implemented

@hos_official

• In a sharded contract future, execution may happen across thousands of contract instances instead of a single application-owned contract

i don’t believe that, and even if that happens, the developers will definitely find a way to capture that value, either by deleting accounts refunding near, or having a cli that claims from all contracts. currently i know only one sharded contract and can list hundreds of non-sharded contracts, sharded contracts are a pain to work with in general, not just collecting fees. and custom protocol fees have to be sharded in thousands of accounts too, if the developer doesn’t want to make user experience worse by requiring +1 / +2 blocks for transfer receipts

@hos_official

ecosystem has matured beyond the need for protocol-level developer subsidies and that applications should primarily rely on adoption-driven business models rather than protocol-funded incentives

it’s not a protocol-level subsidy or protocol-funded incentive, it’s part of tokenomics

overall i’m not against removing the 30% rebate, it always felt weird to me, and was a big security issue for me as a wallet dev (this never happened afaik, but an app could request a function call key with unlimited allowance and spam calls to its contract to steal 30% of user’s near), but the proposal looks like ai slop or like written by someone with no understanding of near ecosystem.

also a concern: maybe some contracts relied on gas rebates for storage deposit. a lot of apps don’t implement storage accounting but somehow still work, i’m assuming that’s because gas rebates keep the total balance above required amount for storage. would need a good analysis and approval of ecosystem devs to make sure it doesn’t break their apps.

also i’d like to open a discussion here about gas becoming 30% cheaper, since the gas paid to network to prevent dos was essentially 70% of the amount paid, because the developer could spend the refunded 30% again. so if gas becomes 30% cheaper, the network security will be kept the same, but the blockchain will become much cheaper, and gas-heavy apps like intear dex will become more affordable for users. high-volume apps like near intents will have less overhead too. user-facing 30% gas cost reduction would be much more noticeable than network becoming 0.7% closer to being deflationary.

[vadim_hom]

A few points against this.

1. The upside is tiny. By the math in this thread, removing the rebate adds about +0.57% to value accrual vs inflation. Noise. No holder will notice.

2. The downside is real. It removes a revenue stream for developers and weakens the incentive to build on NEAR, all for a negligible protocol gain.

3. “It pushes contracts to burn excess gas” doesn’t hold economically. A contract that wastes gas to farm the rebate just loses users to one that doesn’t.

This isn’t the place to burn NEAR. If the goal is more burn and a bigger value-accrual number, point the proposal at the NEAR Foundation. NF holds a large NEAR balance, and burning part of it would show numbers orders of magnitude beyond 0.57%, with zero cost to builders. That’s where this should go @hos_official

[vinibarbosa]

I have mixed feelings.

As @slimedrgn pointed out, using the average reward per contract is not the best metric to understand rebate’s relevancy to contract owners as contracts can be easily spammed and my guess is that the vast majority of these 4k contracts are either inactive or doesn’t have a significant amount of users.

Best approach would be to look at the top X more active contracts (by earned rewards or other activity metric) and understand what the rebate relevancy is for each one of them.

The last thing we want, in my opinion, is a mass migration from the few projects building smart contracts on NEAR due to a broken revenue system, as the 30% are an inherent (and well-documented) part of NEAR’s tokenomics and may have influenced the decision to deploy (or not) a contract or app – or to structure a business plan.

We also need to consider the existence of ‘public goods’ or projects without a clear revenue stream but that may still be useful to the ecosystem and may use the rebates as a viable way to finance low-frequency maintenance.

That said, I do think projects shouldn’t rely exclusively in protocol subsidies and the technical complexity argument is a strong one, especially regarding sharding.

I do think we should remove all the frictions that could push the “sharded” vision/implementation further and this might be a good starting point.

To that, I also agree with both slime and @vadim_hom that the protocol revenue gains from these 30% gas fees is not the main selling point. I’d very much rather see a 30% gas fees reduction than adding this small amount to the burn pot.

Reducing 30% gas fees focus on the users.

Improving the utility economics, rather than the buy & hold economics we achieve through burning.

A 70% burn is already good enough for that.

All that said, my opinion is not formed yet and I don’t have any big objections to this proposal.

I would be ok voting YES at its current state, even though I believe it could (and should) be improved.

Looking forward to hearing other people’s opinion, especially from developers like Slime who may have the rebates as a relevant project funding share.

[frol]

This will simplify the balance tracking for users as this was a major point of confusion for many users who saw no deposit to their account, but saw the tiny growth of their balance.

Every even non-transfer event (e.g. multisig, lockup) brought some gas rewards to the account: Account balance is increasing without transfers · Issue #402 · near/near-explorer · GitHub

The rewards are so tiny that they do not make any sense. For the proper monetization, the protocols should just request to attach the deposit to the function call or even design for payments in FT/MT tokens.

As a developer, I am sick of maintaining these pointless calculations and explaining them to the users.

I support this proposal

[fiatisabubble]

Sharing on the forum for visibility:

For tomorrow’s HoS GM Community Call we’ll be having @bendersgreat present this proposal and answer any questions. Extending the invitation to all NEAR stakeholders

Tomorrow June 18 at 4 PM UTC
Link to the Google Meet

[bendersgreat]

Thanks everyone for the input so far. Let me provide more details.

Data sources

This is the most important piece. Unfortunately the only way to get precise rebate information I am aware of is to run a script against an archival node. Dune does not have exact information required, so the table in the original proposal is produced using this query. It tracks the maximum potential rebate, best effort estimate of the real rebate (subtracting some non-rebated gas burn), and the total number of unique contracts called in the time period. Even for an aggregate view across last 12 months it times out more often than not, so the best metric that I was able to collect for this time span is average per contract. For better understanding I dug into shorter time periods and will be sharing more detailed results for May (latest complete month) and October (anomalous number of unique contracts used). Let me know if you spot inaccuracies in the queries.

Global Contracts

Even if the developers come up with a sweep function they need to call it on hundreds of thousands of accounts to collect <1 milliNEAR from each. October last year was a month with 223,698 unique contracts called. 220,379 of them were XXXX.craft.tg, the most popular of them was called 35 times and accumulated at most 1.76 milliNEAR. They were all using global contract trading-zone-gc.tg, served 270,375 calls and accumulated no more than 34 NEAR. A trading app with 0.1 onchain TPS collected at most 1 NEAR per day. And to get that 34 NEAR developers would need to sweep 220k accounts - I am leaving to the reader to calculate the cost of it. Yes, more contracts is bad for the current rebate model.

Another important point, global contracts are normally deployed by users to the accounts they control. They have full access keys for those accounts and may have NEAR balance as well. They may frontrun the developers. And blindly sweeping full balance means stealing from them.

Also, above proves that global contracts are very much used.

Sharded Contracts

Sharded contracts use global contracts and have the same sweeping problem. It is a newer feature and is not widely used yet, although e.g. Intents team no longer writes non-sharded contracts at all. And for a good reason. Non-sharded contracts do not have future. They are stuck to a single shard and cannot be split if they reach the limit. There are 2 major scaling factors for contracts: TPS and storage. NEAR’s per shard TPS is pretty high and even the most used contracts are somewhat far from the limit at the moment. The storage is a very different story. Aurora uses 13.71 GB of storage and keeps growing. It is already so big that it has a dedicated shard just for it and it is getting close to the limit of what a single shard can handle. There is no way forward after that without using sharded contracts. intents.near is much younger, but grows much faster and is already at 9.20 GB. It was 8.18 GB last month. These contracts will have to migrate to sharded contracts very soon. And if you aim at any decent adoption you should stop writing non-sharded contracts today.

Per Contract rebates

Here is a per contract rebate query, sorted from the highest. Copying the first page for simplicity:

month	account	rebate_upper_bound_near	rebate_estimate_near
2026-05-01 00:00:00	v2.jars.sweat	939.43006270111	787.979872472734
2026-05-01 00:00:00	claim.sweat	918.725359475307	805.875006924759
2026-05-01 00:00:00	game.hot.tg	542.078916925404	317.042112966482
2026-05-01 00:00:00	token.sweat	502.119100532959	224.708568736626
2026-05-01 00:00:00	v1.signer	469.843902440916	365.162099907591
2026-05-01 00:00:00	intents.near	469.320789061813	377.539174837087
2026-05-01 00:00:00	sweat.jwt.fast-auth.near	464.5463790268	444.625866326288
2026-05-01 00:00:00	dclv2.ref-labs.near	437.255989973556	364.721162714801
2026-05-01 00:00:00	aurora	421.574493122567	375.382979449951
2026-05-01 00:00:00	v2.ref-finance.near	415.459706971659	293.834488037747
2026-05-01 00:00:00	btc-connector.bridge.near	169.198345212573	158.434344913327
2026-05-01 00:00:00	wrap.near	165.430441359832	44.7704426868291
2026-05-01 00:00:00	pyth-oracle.near	130.048860388951	79.3190137882047
2026-05-01 00:00:00	fast-auth.near	117.607547544798	42.4552077882615
2026-05-01 00:00:00	17208628f84f5d6ad33f0da3bbbeb27ffcb398eac501a31bd6ad2011e36133a1	93.6357822830427	43.243143706957
2026-05-01 00:00:00	v2_1.omni.hot.tg	93.2815300155812	60.5213131141285
2026-05-01 00:00:00	jars.sweat	79.1509989355846	76.2506278872496
2026-05-01 00:00:00	aa-harvest-moon.near	66.8311706948639	38.6379776197929
2026-05-01 00:00:00	jwt.fast-auth.near	61.8963236802213	16.9227167640358
2026-05-01 00:00:00	usdt.tether-token.near	45.0789497614927	15.1470927248217
2026-05-01 00:00:00	zec.omft.near	36.3937466762795	12.0258513544999
2026-05-01 00:00:00	contract.wormhole_crypto.near	35.5286994260362	28.2870720479062
2026-05-01 00:00:00	meta-pool.near	33.1626912293811	26.4567127958578
2026-05-01 00:00:00	client-eth2.bridge.near	30.9572961636255	25.2719587685355
2026-05-01 00:00:00	firedrop.hot.tg	30.6172551920528	24.3794294986928

Only 14 contracts cleared 100 NEAR per month bar, 25 contracts got 30 NEAR or more. I am pretty sure none of them treats this as a meaningful revenue stream and for most of them I know it from talking to the teams.

You can find dex.intear.near at the page 2, row 40 with 8.5 NEAR rebate btw.

[vinibarbosa]

@frol

For the proper monetization, the protocols should just request to attach the deposit to the function call or even design for payments in FT/MT tokens.

Yes, this is a very good solution for monetization.

Thanks for sharing. I agree it’s better than the 30% protocol-level rebate.

Your vision as a developer is also super important and I think it’s a fair reasoning that makes sense.

@bendersgreat

Thanks everyone for the input so far. Let me provide more details.
(…)

Also, thank you very much for the quick follow-up @bendersgreat

It all makes a lot of sense and, at this point, I don’t see any concrete reason for voting AGAINST this proposal.

I’m ready to support it, unless I see any compelling AGAINST argument in the following days.

[coffee-crusher]

Thank you so much, @bendersgreat for this proposal. I’m ready to support this for an on-chain vote.

Moving to a more predictable economic model is the right call, and I agree that relying on adoption-driven business models is a better path for the ecosystem than keeping these fragmented, protocol-level subsidies around. It’s also a cleaner and simplier solution.

That said, we should be real about the impact on the ground. Even if the current rebate is small, it could be considered a passive revenue stream for some - to cover costs. We need to make sure this change doesn’t create a barrier for the smaller, newer teams that are just starting to build on NEAR.

If we’re cutting this incentive, we need to be clear about how we plan to keep the environment attractive for builders. We should be mindful of that as we move forward, ensuring we’re still fostering a place where new teams can get off the ground and succeed. Tks!

[Mayor_of_Pumpopolis]

I’m against this change.

It fundamentally changes some of the assumptions of the contract usage. As an example, when players call move_player to claim in-game tokens, the small gas burn offsets the growing size of storage. Yes, other solutions are possible, but that’s not what we signed up for when we decided to build on NEAR.

Very few people engaging with governance have actually built a product on-chain. Fewer still have built a paid, non-subsized product.

This proposal illustrates the natural conflict between the productive classes and the political eaters. It was clear from the beginning that these conflicts would arise. Here we are.

[slimedrgn]

@bendersgreat

Non-sharded contracts do not have future

bold statement in bold text, based on a lot of nothing. 0 contracts are even 1% close to saturating a single shard, current tps of the entire blockchain is 2-4, it’s probably higher at different times but was never close to reaching ~14,000 tps per shard demonstrated in the 1 million tps benchmark. sharded contracts add around 500% to development complexity, 2700% to testing complexity, and 69% to attack surface. are you saying that apps that don’t generate 14,000 transactions per second don’t have a future? i don’t think even openai or anthropic generate anywhere that many. or are you saying an app that doesn’t store 10+gb on chain doesn’t have a future? nobody stores that much, only 2 contracts, and if there’s a 14gb limit per shard, i think that’s a near issue and not app issue, both solana and ethereum have hundreds of gb in state and are not sharded

[Griff]

The fast track finished before i had a chance to vote, but when the real vote opens, I’m voting yes. This simplifies things, and that’s usually the right call.

[fiatisabubble]

HSP-027 has cleared the Fast Track Vote and is now open for the Live Vote (30% YES votes carry over).

Voting is LIVE until Friday 3 July 11PM UTC.

Remove the NEAR Developer Gas Rebate

[Yuen]

Voted “FOR” for the removal gas rebate proposal

My reason for voting in favor is that this proposal helps simplify gas fee calculations for users, making the overall experience clearer and easier to understand and also burns NEAR tokens.

That said, we should also consider alternative support mechanisms for developers who currently rely on gas rebates to maintain their dApps, especially during the transition period.

Based on the calculations shared, the rebated amount does not appear to be very high compared to the previous volume before. While I understand that some developers do depend on these rebates, we need to explore more sustainable and helpful ways to support them in the coming months.

[Paul]

Absolute madness in the worst sense for Wars Of Cards. The 30% rebate is a genuine flywheel for our blackjack (and hopefully poker soon). Our dealer runs on-chain and has to burn gas to moderate every round, so that rebate is not a subsidy we sit on; it recycles part of our operating costs, and player calls to the same contract feed it too.

This proposal looks seductive, especially when KPIs have to be met in quarterly reports. For big players whose projects already sit on solid liquidity, it is probably irrelevant… the author’s own context table shows as much, and users may even be happy with lower fees. However, for developers holding a tiny fraction of the capital of the largest teams, it is simply a burden and a discouragement to keep building.

[Mayor_of_Pumpopolis]

These small amounts help offset growing storage concerns for Pumpopoly.

Up-thread, someone mentioned subaccounts. If these amounts are already inaccessible, then they are effectively burned.

Gas is probably the smallest fraction in the entire emissions/fees scheme. Developer “rebates” are a fraction of a fraction. Basically dust in the larger context. It isn’t like we are profiting from this. The “rebate” term makes it seem like developers actually receive this. What actually happens is it lowers the friction for players, by not forcing them to sign a storage deposit transaction in these cases.

A coherent proposal would structure emissions so that fees/buybacks from intents are always greater. A sliding window would be appropriate here. This would solve the entire debate.

The other Q here, when “buybacks” happen, those tokens are held by the team, potentially to fund more insider aligned projects, rather than automatically and programmatically burned.

Whatever the opinions of the dev “rebates” are, the intents “buyback” structure is more troubling. Okay, you want to squeeze devs, great but look what is going on on the other side, for the politically connected classes.

Finally, there has been some language floating around in this thread and elsewhere about how NEAR is now a “mature” ecosystem, therefore devs don’t need incentives. As I mentioned above, the “rebates” aren’t exactly an incentive for developers. In practice they reduce user friction. Secondly and more crucially, claiming that an ecosystem where few if any new dapps are launched and most have died is “mature”, is ridiculous.

NEAR is less of a mature ecosystem and more of a curated, gatekept Potemkin village.

Potemkin village

[vadim_hom]

I support removing the rebate, but I’d reframe the case. The proposal leads with token value accrual — burn more, and it’s economically better for the token. I don’t think that’s the strongest argument, and for a tokenholder vote it reads awkwardly, like tokenholders redirecting a developer reward toward themselves. The better reason is simplicity: this removes an extra mechanism and makes the protocol cleaner and easier to reason about.

And given NEAR’s sharded design, I’d expect gas to stay cheap by default — so 30% of an already small fee was never going to be a real business model for a project anyway. That makes it well worth giving up for a simpler, faster protocol.