HIP 149: Helium Utility and Emissions Realignment

[hiptron]

HIP 149: Helium Utility and Emissions Realignment

• Author: @madninja
• Start Date: 2026-06-02
• Category: Economic, Technical
• Original HIP PR: #1200
• Tracking Issue: #1201
• Voting Requirement: veHNT Holders

---

Summary

This HIP bundles four governance decisions, executed in a single program upgrade at passage:

1. Mobile data deployers earn HNT pro-rata of rewardable bytes. A USD-anchored backstop tops up that baseline whenever it falls below 50% of the carrier-paid burn rate Nova sets under HIP 143.
2. An operations and growth capitalization: a per-epoch HNT mint into a Nova-administered Squads multisig vault for a flat-rate window followed by a multi-year linear taper. Total ~141M HNT over 36 months, about 72% of current circulating HNT supply, front-loaded (~50% in the first 12 months). Both windows are hardcoded at passage and self-terminate.
3. Retirement of Proof-of-Coverage on both Mobile and IoT. Mobile data deployers earn pro-rata of rewardable bytes; the on-chain Service Provider allocation under HIPs 82/87 is reframed as a flat Mobile Operations Fund. IoT data transfer continues at the existing $/DC peg.
4. A 7-seat Advisory Council with standing oversight of how the operations and growth capitalization is used, with the authority to escalate to a community termination vote.

One veHNT vote approves all four decisions together.

Rendered View

https://github.com/helium/HIP/blob/main/0149-helium-utility-and-emissions-realignment.md

[waveform06]

@madninja suggest you add the "Updates" tag as well, as it will update/replace many previous HIPs. And "Governance" as it adds the council.

[madninja]

@madninja suggest you add the "Updates" tag as well, as it will update/replace many previous HIPs. And "Governance" as it adds the council.

Done. Ty

[Siegfried-B]

1. Not sure when or if I'll be able to create a pull request, but phrasings of the following kind make it unnecessarily harder to understand what's going on:

• "The 0.75 factor accounts for the backstop flowing through the existing sub-DAO allocation (see Decision 3)."

• "Backstop flow. Decision 1's backstop flows through the standard sub-DAO allocation."

This whole "flowing through the sub-DAO allocations" way of phrasing should be replaced by a more easily understandable approach along the following lines:

The backstop - when needed - adds additional HNT to data rewards bucket. We implement this by re-emitting a part of the burned HNT during an epoch that increases the total amount of HNT emitted and distributed to all recipients of daily HNT emissions. As only a percentage of the daily HNT mint flows to the data rewards bucket for Mobile deployers, we need to re-emit more HNT than what the data rewards bucket for mobile deployers needs to create the deployer floor.

2. This way of implementing the deployer floor also makes me wonder if calling the decision only a "deployer floor" is a misnomer to a degree: at the end of any epoch that has a backstop >0, all rewardable entities get HNT that is additional to what they'd get based on (emissions schedule + net emissions) - and thus an increase of HNT proportional to the increase of standard mobile data rewards (in HNT terms) caused by the backstop.

3. The fixed value 0.75 afaics is incorrect. The calculation of that value is partly based on the emissions split between Mobile and IOT subnetwork. This split is not fixed, but depends on the veHNT delegations to each subnetwork. As these can vary, not only the factor 0.75 is incorrect afaics, but any fixed factor is incorrect. It needs to be replaced by a variable that properly represents the dependence of the value on the emissions split between the subnetworks at the time of daily calculation of the backstop.

[unikt5]

HIP 149 Alternatives instead of a flat "no"
Marc asked for alternatives, not blanket opposition. Fair. Here are three.
First, the core concern: this isn't a top-up. In the first 12 months the Nova vault receives ~90% of HNT issued during that window (≈9.5× current network emission) and max supply moves from 223M → ~364M. That's a lot to approve in one bundled yes/no. ⚠️
👀Look at Cardano, last week. The Foundation bundled a 14M ADA treasury request. DReps pushed back on the size, so the team split it into separate votes, cut the budget ~22%, added milestone-gated payments and an independent oversight committee. Even after all that, the revised proposal still fell short of approval. Worth reading before we vote here.
Three alternatives:
1️⃣ Split the vote. The HIP itself lists bundling as a drawback. PoC retirement, the deployer floor, and the Council each stand on their own. The 141M mint is the contested part, let it pass or fail separately.
2️⃣ Milestone tranches, not front-loaded. Releasing ~half in year one removes the community's leverage exactly when it matters. Release funds against real targets (carrier deals, GB/day growth).
3️⃣ Yearly renewal, not 36 months locked. The HIP says fixed windows give hiring certainty. Cardano shows yearly approval and multi-year operations can coexist. A 12 month window with a transparency report before renewal gives runway and a real off-ramp.
None of this blocks growth. It's the difference between funding the network and rewriting its supply in a single vote. Starting with 1 + 3 seems reasonable.
Let's keep Helium a network owned by its people. 🌐

[Siegfried-B]

The circulating supply number used in the HIP (196 million) is outdated.
The current number is <183 million (~182.5).
I suggest to update that number (and redo the calculations where it's been used), because:

1. Using the 196 million number means the HIP publishes a new max supply (~364 million) that is by 13 million too high. If the HIP passes, the new max supply in reality starts out at ~351 million, not ~364 million.
2. A too high updated max supply number will also mean, FDV calculations using the static number where max supply starts out will always be too high on CMC, Coingecko, etc. Those places should use up to date, lower max supply numbers, but they still don't.