# HSP-027: Remove the NEAR Developer Gas Rebate
**URL:** https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213
**Category:** Proposals
**Created:** [June 15, 2026, 5:05pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213 "2026-06-15T17:05:22Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@hos\_official](https://gov.near.org/u/hos_official)
#### Post date: [June 15, 2026, 5:05pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/1 "2026-06-15T17:05:22Z")
# Frontmatter
```auto
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: Final
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](https://docs.near.org/protocol/transactions/gas#gas-as-a-developer-incentive). 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](https://github.com/near/nearcore/blob/master/docs/architecture/how/gas.md#contract-reward) shall be modified such that:
```yaml
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.
---
### Author:  [@slimedrgn](https://gov.near.org/u/slimedrgn)
#### Post date: [June 15, 2026, 9:20pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/2 "2026-06-15T21:20:15Z")
> [@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](http://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.
---
### Author:  [@vadim\_hom](https://gov.near.org/u/vadim_hom)
#### Post date: [June 16, 2026, 10:39am UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/3 "2026-06-16T10:39:39Z")
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
---
### Author:  [@vinibarbosa](https://gov.near.org/u/vinibarbosa)
#### Post date: [June 16, 2026, 6:12pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/4 "2026-06-16T18:12:27Z")
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.
---
### Author:  [@frol](https://gov.near.org/u/frol)
#### Post date: [June 16, 2026, 6:46pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/5 "2026-06-16T18:46:45Z")
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](https://github.com/near/near-explorer/issues/402)
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
---
### Author:  [@fiatisabubble](https://gov.near.org/u/fiatisabubble)
#### Post date: [June 17, 2026, 4:37pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/6 "2026-06-17T16:37:04Z")
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](http://meet.google.com/fnx-jbzq-evg)
---
### Author:  [@bendersgreat](https://gov.near.org/u/bendersgreat)
#### Post date: [June 17, 2026, 10:31pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/7 "2026-06-17T22:31:02Z")
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](https://dune.com/queries/7678854). 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](https://dune.com/queries/7740192) and accumulated [at most 1.76 milliNEAR](https://dune.com/queries/7740179). They were all using global contract [trading-zone-gc.tg](https://nearblocks.io/address/trading-zone-gc.tg), [served 270,375 calls and accumulated no more than 34 NEAR](https://dune.com/queries/7739111). **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](https://nearblocks.io/address/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](https://nearblocks.io/address/intents.near) is much younger, but grows much faster and is already at 9.20 GB. [It was 8.18 GB last month](https://near.zulipchat.com/#narrow/channel/407288-core.2Fresharding/topic/Status.20update/near/593000635). 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](https://dune.com/queries/7733788) 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.
---
### Author:  [@vinibarbosa](https://gov.near.org/u/vinibarbosa)
#### Post date: [June 18, 2026, 1:21pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/8 "2026-06-18T13:21:03Z")
> [@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.
---
### Author:  [@coffee-crusher](https://gov.near.org/u/coffee-crusher)
#### Post date: [June 19, 2026, 8:44pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/9 "2026-06-19T20:44:03Z")
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!
---
### Author:  [@Mayor\_of\_Pumpopolis](https://gov.near.org/u/Mayor_of_Pumpopolis)
#### Post date: [June 22, 2026, 3:35am UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/10 "2026-06-22T03:35:43Z")
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.
---
### Author:  [@slimedrgn](https://gov.near.org/u/slimedrgn)
#### Post date: [June 24, 2026, 3:09am UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/11 "2026-06-24T03:09:43Z")
> [@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
---
### Author:  [@Griff](https://gov.near.org/u/Griff)
#### Post date: [June 26, 2026, 6:10pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/12 "2026-06-26T18:10:20Z")
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.
---
### Author:  [@fiatisabubble](https://gov.near.org/u/fiatisabubble)
#### Post date: [June 29, 2026, 1:00pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/13 "2026-06-29T13:00:56Z")
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](https://houseofstake.org/proposals/27)**
>
> Frontmatter \`\`\`yaml hsp: TBD title: Remove the NEAR Developer Gas Rebate desc...
---
### Author:  [@Yuen](https://gov.near.org/u/Yuen)
#### Post date: [June 30, 2026, 6:51am UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/14 "2026-06-30T06:51:28Z")
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.
---
### Author:  [@Paul](https://gov.near.org/u/Paul)
#### Post date: [July 1, 2026, 5:39pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/15 "2026-07-01T17:39:48Z")
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.
---
### Author:  [@Mayor\_of\_Pumpopolis](https://gov.near.org/u/Mayor_of_Pumpopolis)
#### Post date: [July 2, 2026, 4:05am UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/16 "2026-07-02T04:05:32Z")
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](https://en.wikipedia.org/wiki/Potemkin_village)**
>
> A Potemkin village\[a\] (Russian: \[pɐˈtʲɵmkʲɪn\]) is a construction, literal or figurative, that provides a façade to a situation, to make people believe that the situation is better than it actually is.
> The term comes from stories of a fake portable village built by Grigory Potemkin, a field marshal and former lover of Empress Catherine II, solely to impress the Empress during her journey to Crimea in 1787. Modern historians agree that accounts of this portable village are exaggerated. The origi...
---
### Author:  [@vadim\_hom](https://gov.near.org/u/vadim_hom)
#### Post date: [July 2, 2026, 7:15pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/17 "2026-07-02T19:15:24Z")
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.
---
### Author:  [@Mayor\_of\_Pumpopolis](https://gov.near.org/u/Mayor_of_Pumpopolis)
#### Post date: [July 3, 2026, 7:42am UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/18 "2026-07-03T07:42:29Z")
For me the proper frame is still in unaccountable Intents buyback redistribution vs. removing a feature for developers. Even if it is a small amount, it still has a use. Furthermore it is politically neutral and programmatic.
I do appreciate you adding an alternative argument, but I’m not convinced it is stronger. This will be an argument from empiricism whereas the benefit of the rebate was something we could understand from pure reason. Categorically weaker.
> [@vadim\_hom](#):
>
> …this removes an extra mechanism and makes the protocol cleaner and easier to reason about.
Easier to reason about for whom?
I’ll open with my own observation.
I’ve been dealing with users for over four years now, and I cannot recall a single instance of a user asking about gas costs. If the topic of gas comes up it is always because a user lacks the balance to sign a transaction. The subject is never about the cost breakdown.
If this is a genuine concern, it seems like a UX failure on the block explorers.
Perhaps proponents would offer their own anecdotes so we can better understand where this problem is?
---
### Author:  [@Paul](https://gov.near.org/u/Paul)
#### Post date: [July 4, 2026, 10:07am UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/19 "2026-07-04T10:07:05Z")
From a purely NEAR perspective, I understand the rationale and it does make sense!
But it’s worth noting that with changes like this, a new era has arrived: NEAR, once friendly by design to low entry projects, has become “too mature” for them simply by no longer allowing gas rebates to accrue on contract balances and help offset operating and storage costs.
---
### Author:  [@system](https://gov.near.org/u/system)
#### Post date: [July 6, 2026, 2:26pm UTC](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/21 "2026-07-06T14:26:56Z")
On **July 3, 2026** , the House of Stake ratified **[HSP-027: Remove the NEAR Developer Gas Rebate](https://houseofstake.org/proposals/27)**, completing the governance process for the proposal.
With governance concluded, the proposal now moves into the implementation phase. This update summarizes the expected rollout, what developers and builders should expect, and the current implementation timeline.
## **Implementation Timeline**
Ratification does **not** immediately change protocol behavior.
The proposal is scheduled to be implemented as part of **Protocol Update v2.14** , currently targeted for **August 2026**. As with all protocol upgrades, the final activation date depends on engineering readiness, testing, and validator coordination.
Implementation is expected to proceed in three stages.
### **Phase 1: Protocol Implementation**
The required changes are implemented in the [nearcore codebase](https://github.com/near/nearcore/releases).
The protocol parameter governing the developer gas rebate will be updated from **30% to 0%**. No other transaction fee parameters are expected to change.
### **Phase 2: Testnet Validation**
The v2.14 release candidate will be deployed to Testnet, where contributors will validate:
- transaction execution;
- contract compatibility;
- fee accounting;
- validator operation and consensus.
### **Phase 3: Mainnet Activation**
After successful testing and validator upgrades, Protocol Update v2.14 will be activated on Mainnet.
Once activated:
- the developer gas rebate becomes **0%** ;
- **100% of eligible execution fees** are now allocated to the protocol’s existing fee-processing mechanism;
- validator rewards, gas pricing, and user transaction fees remain unchanged.
## **What Developers Should Expect**
For application developers, the implementation is expected to be operationally straightforward.
The update does **not** introduce:
- breaking API changes;
- contract migrations or redeployments;
- changes to gas pricing;
- changes to validator economics.
The primary behavioral change is that contract owners will no longer receive the automatic protocol-level rebate on gas consumed during contract execution.
For most existing applications, no code changes are expected to be required.
## **Background**
The developer gas rebate was introduced during NEAR’s early growth to encourage smart contract deployment by returning a portion of execution fees to contract owners.
HSP-027 proposed removing that mechanism and directing **100% of eligible execution fees** to the protocol’s existing fee mechanism.
During the [governance process](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213#p-141123-global-contracts-2), discussion covered several themes, including:
- the long-term complexity of maintaining the rebate mechanism within the protocol;
- historical data indicating that the rebate was not a significant source of funding for the majority of applications;
- available data suggesting that where the rebate constituted meaningful revenue, those applications were generally mature enough to absorb the change through existing business models.
- the compatibility of the rebate mechanism with future protocol architectures, including global and sharded contracts.
Community members can review the complete proposal, discussion, and supporting analysis on the House of Stake proposal page.
## **Preparing for Future Protocol Architecture**
As outlined during the [proposal discussion](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213/7#p-141123-global-contracts-2), one motivation for the change is simplifying dApp development. The existing rebate model assumes execution within a traditional single-contract account. As NEAR evolves toward sharded contracts, maintaining rebate accounting across large numbers of user-controlled accounts would introduce significant complexity for application developers in order to continue claiming these rewards.
Removing the rebate eliminates that dependency in addition to making the protocol simpler.
## **Monitoring the Rollout (KPIs)**
Following activation, implementation will [be considered successful](https://houseofstake.org/proposals/27) if:
- the developer rebate is reduced to 0% across the network;
- protocol fee allocation reflects the updated parameters;
- validator and network performance remain stable throughout the upgrade;
- no unintended impact is observed for transaction execution or developer tooling.
House of Stake will continue to provide implementation updates as Protocol Update v2.14 progresses through testing and toward Mainnet activation.
* * *
## **Message from the Proposal Author**
> _"I’d like to thank everyone who participated in the discussion and voting process, regardless of their position on the proposal._
>
> _The proposal received strong support through House of Stake governance, reflecting broad agreement that the developer rebate had fulfilled its original purpose and that simplifying the protocol is the right long-term direction._
>
> _At the same time, I recognize that this change will affect some builders more than others. While the available data suggests the rebate was not a significant source of revenue for most applications, some smaller teams and independent developers will lose a modest stream of income. I want to acknowledge that impact and thank those builders for the work they continue to do across the ecosystem._
>
> _My hope is that this change helps create a simpler protocol that better supports long-term ecosystem growth, and the next generation of applications on NEAR. Let’s continue to shape that future together."_
**Anton Astafiev _/ CTO NEAR One, Proposal Author (_**@bendersgreat)
* * *
House of Stake is a community governance mechanism within the NEAR ecosystem. Participation in governance does not constitute an investment activity and does not entitle participants to financial returns of any kind.
Vote at House of Stake: [NEAR Proposals | House of Stake Governance](https://houseofstake.org/proposals)
Acquire voting power: [NEAR Assets | Lock & Stake Your Tokens](https://houseofstake.org/assets)
Telegram: [Telegram: View @NEAR\_HouseOfStake](https://t.me/NEAR_HouseOfStake)
Announcements: [Telegram: View @HOSannouncements](https://t.me/HOSannouncements)
X: [NEAR House of Stake (@NEARGovernance) / X](https://x.com/NEARGovernance)
Discussions: [House of Stake - NEAR Forum](https://gov.near.org/c/house-of-stake/158)
_Nothing in this communication constitutes investment advice, a solicitation, or an offer to buy or sell any token or other financial instrument. The strategies, tools, and approaches discussed are subject to change and may be modified or discontinued at any time based on regulatory developments, governance decisions, or other factors. NEAR token holders have no rights vis-à-vis the NEAR Foundation._
[Next page](https://gov.near.org/t/hsp-027-remove-the-near-developer-gas-rebate/42213.md?page=2)