HNT is a governance asset first. A burn-input second. Everything else is downstream.

Helium’s early story trained people to see HNT as “the mining reward.” That framing is now incomplete. After the Solana migration and the subsequent unwind of subnetwork token emissions, HNT sits at the top of the system as the unit that (1) governs protocol change and (2) gets destroyed to buy network usage via Data Credits. Helium’s own docs describe HNT as the protocol token, used to reward Hotspot operators, while developers and enterprises pay the network via Data Credits derived from burning HNT.

This matters because it changes how you should read “tokenomics.” The economic question is no longer “how much HNT do I mine.” It is “who can redirect emissions, fees, and burns.” That is governance. It is power distribution wearing a token wrapper.

If you want a refresher on common terms before you evaluate these trade-offs, start with our tokenomics FAQ.

History that actually changed the token design

HNT’s first emission was July 29, 2019, and Helium states there was no pre-mine.

The first major monetary-policy hardening came with HIP-20, which introduced a two-year halving schedule for net issuance, with the first halving set for August 1, 2021.

The first major architectural and governance-power shift came with HIP-70. It moved Proof-of-Coverage and Data Transfer Accounting to oracles and made Helium’s “more scalable L1” choice explicit: Solana. The migration date is documented as April 18, 2023.

Then came the economic simplification reversal: HIP-138 (start date November 8, 2024) proposed return to HNT by phasing out IOT and MOBILE emissions and returning rewards directly to HNT, while also ending HNT emissions to Helium Security Token (HST) holders. Helium’s governance docs also note that HIP 138 “returned governance to single token governance using just HNT, and removed direct governance by the IOT and MOBILE tokens.”

As a Governance Power Analyst, the throughline is simple. Each step reduced the number of “independent” constituencies in the system and increased the importance of whoever controls (a) the HNT vote and (b) the oracle-mediated measurement of work.

Supply, emissions, and allocations (where the pie used to go)

Helium’s current token documentation ties max supply to HIP-20 and the two-year halving schedule. It states the network targeted 5,000,000 HNT per month at launch and that slow block times in year 1 reduced the originally implied maximum, putting max supply at approximately 223,000,000 HNT at the time HIP 20 was approved.

The cleanest “allocation” lens for Helium is not a one-time genesis split. It is ongoing emissions routing. HIP-20 explicitly published the intended emission splits by stakeholder class, year by year. That schedule is important because it reveals the original power bargain: insiders and early stakeholders were not just early buyers. They had a protocol-level claim on emissions.

That last sentence is the key governance-power point. HIP-70 explicitly says removing the need for staked validators “returns the full 6.85% of HNT emissions back to the rewards pool.” So even before HIP-138, Helium had already begun rewriting who the protocol pays, and why.

HIP-138 then goes after the other structurally contentious allocation. It identifies HST holders as investors in and early employees of Nova Labs, and states they “currently receive 30% of emitted HNT, decreasing every year to 15%,” and that HIP-138 would discontinue those emissions and redirect the remaining scheduled HNT to the rest of network participants.

Utility, fees, and the burn-mint plumbing (the part people over-romanticize)

Helium’s “demand-side” token design is real, but it is tightly scoped. The network is paid in Data Credits (DCs). DCs are not a market-traded gas token. They are deliberately stable in USD terms: 1 DC = $0.00001. Users obtain DCs by burning HNT, and the amount of DC created per HNT depends on the HNT/USD price feed (Helium docs reference Pyth as the price provider).

A few details matter more than the slogan:

DCs are non-transferable. Once minted, they cannot be sent to another wallet, which is a strong design choice against secondary-market leakage and a strong constraint for composability.

DCs pay for more than “real usage.” They also pay protocol actions like onboarding and asserting locations. Helium’s DC documentation lists example fees, including IoT Hotspot onboarding at $10 and Assert Location at $1 (denominated via DC).

Now the part that creates analytical confusion: Helium’s HNT supply is capped, but it also has a mechanism called Net Emissions. Helium’s HNT token docs explain that Net Emissions monitor the amount of HNT burned and add that to the amount minted for rewards, and also explicitly state that HNT produced via Net Emissions “do not add to the total outstanding” and therefore do not violate max supply.

There is a cap. The docs state Net Emissions are capped at 1% of the epoch emissions at the time HIP 20 was approved, and they provide the current daily cap figure: 1,643.83561643 HNT (with the note that the epoch is now daily).

From a fiscal-flow lens, Helium therefore runs two coupled loops:

(1) Usage loop: burn HNT to mint DC, spend DC for network actions and data transfer at a USD-pegged unit price.

(2) Rewards loop: scheduled emissions plus Net Emissions feed rewards to network participants, with Net Emissions acting as a constrained re-minting of burned HNT rather than unlimited reflexive inflation.

The political economy implication is uncomfortable. The token does not become “backed by revenue” just because burns exist. Burns reduce supply. They do not automatically create stable demand for HNT unless someone is reliably buying HNT to burn. Helium’s design tries to make that buyer the network user, but it also makes DC acquisition sensitive to an oracle-fed HNT/USD price.

Governance and parameter control: where “decentralized” claims go to die

Helium governance is formally structured around HIPs (Helium Improvement Proposals). Helium’s governance docs state anyone can submit a HIP, that HIPs are published in a public GitHub repo, and that HNT must be locked for voting, with voting power determined by number of locked tokens and lock duration (up to four years).

In practice, the control surface is narrower than “anyone can submit.” What matters is who can pass.

Helium uses vote-escrowed positions (veHNT) and runs voting through Realms. If you’re comparing vote-escrow mechanics across protocols, our Lido DAO review is a useful reference point for vote-escrowed governance.

The system has explicit thresholds:

A proposal needs a 67% supermajority of voting power to pass. It also needs a quorum of 100,000,000 tokens represented (the docs describe this quorum as equal across the Network and all subnetworks). Those voting thresholds are not just “high.” They are structurally centralizing.

This quorum number is not just “high.” It is structurally centralizing. It creates a standing advantage for large holders and organized blocs, because diffuse retail cannot reliably coordinate to clear quorum on every contentious parameter change. If a few big wallets abstain, nothing happens. That is power.

The lock mechanic also concentrates influence by design. Helium’s staking docs describe vote power as amount times duration and explicitly note there is no additional vote power multiplier beyond 4 years. Realms documentation also notes that vote power can decay, and that voting sooner can apply greater voting power if a position is in decay mode.

Then there is institutional stewardship. Helium’s governance docs say the Helium Foundation serves as a steward for the governance process. Their tooling role is also explicit. Helium’s staking docs say Helium utilizes “Modular Governance” as an open application built by the Helium Foundation and deployed as Helium Vote.

None of this is inherently bad. It is operationally coherent. It is also a governance centralization trade-off: if key governance interfaces, process coordination, and protocol engineering stewardship are anchored to a foundation, you have a clear locus of influence even when votes are on-chain.

Finally, the oracle shift changes where power lives. HIP-70 explicitly moved to oracles Proof-of-Coverage and Data Transfer Accounting and positions that as the route to scalability and reliability. That decoupling is a performance win. It is also an accountability shift: if rewards and “work performed” are increasingly mediated by oracle pipelines, the political question becomes how those implementations are chosen, updated, and contested.

Helium answers that procedurally with HIP governance. The concentration risk is that the same governance system that can change oracle rules is itself vote-power weighted and quorum-gated.

Risk analysis: where this design strains under real power

Helium has put serious thought into monetary-policy legibility. HIP-20 made supply and emission splits more understandable to outsiders. DC pricing stability also removes a huge adoption barrier for non-crypto users who just want predictable costs for packet delivery or Wi-Fi offload.

The weak point is not “tokenomics theory.” It is governance and operational control. The dominant failure mode is not a broken burn mechanism. It is a capture of parameter change and measurement, followed by value reallocation that users cannot practically stop.

We also track recurring governance failure modes and mitigation patterns in our crypto research.

Top 3 risks

  1. Dominant risk: Governance capture via veHNT + high quorum + foundation-centered process. Trigger: A period of low turnout, market drawdown, or stakeholder fragmentation that makes it harder to reach the 100,000,000 quorum threshold. Mechanism: Voting power is explicitly proportional to locked stake and duration, up to four years, and passing requires a 67% supermajority of voting power. When combined with quorum, a small set of large lockers can become both the enabling coalition (to pass preferred changes) and the veto coalition (to prevent changes they dislike) simply by coordinating participation. Who bears it: Smaller Hotspot operators, smaller HNT holders, and application developers whose unit economics depend on stable reward logic, fee schedules, and oracle scoring rules. Measurable indicators: (i) recurring votes failing quorum despite clear majorities among those who vote, (ii) persistent concentration of voting power in a small set of veHNT positions, (iii) repeated rule changes that redirect emissions or burn handling toward one constituency (for example, ending a large stakeholder emission stream as HIP-138 proposes for HST holders).

    The uncomfortable point: Helium’s governance system is designed to prioritize “long-term aligned” capital. That is what vote escrow does. Helium says as much by tying vote power to lock duration and describing the goal as long-term stakeholder alignment. The trade-off is explicit power concentration. If you cannot or will not lock for long durations, your ability to resist adverse changes is structurally limited.

    This isn’t abstract. Helium has already used governance to rewrite major economic rights. HIP-138 explicitly targets and removes ongoing emissions to HST holders and redirects remaining scheduled emissions to other participants. That may be a net positive reallocation. The governance-power lesson is that the system is capable of sweeping redistribution. If you’re building a business model atop rewards, you are exposed to that governance surface whether you like the politics or not.

    And because Helium’s architecture moved key accounting responsibilities to oracles under HIP-70, governance capture has a second lever. It can change what “counts” as coverage, what “counts” as data transfer work, and how scoring feeds emissions. That creates an upgrade path. It also expands the scope of “parameter governance” from on-chain constants to off-chain measurement pipelines whose outputs determine who gets paid.

  2. Oracle-dependence risk (measurement power). Trigger: Oracle outages, oracle rule changes, or disputed oracle outputs that materially affect rewards or DC accounting. Mechanism: PoC and Data Transfer Accounting are mediated through oracle pipelines, which means measurement disputes can become economic disputes. Who bears it: Hotspot operators (rewards volatility), and application developers (billing/reliability perceptions, especially because DC pricing is meant to be stable). Indicators: (i) measurable divergence between physical activity and recorded reward outcomes, (ii) incident reports where oracle pipeline issues disrupt expected accounting, (iii) governance proposals that frequently adjust oracle-related parameters or eligibility logic.

  3. Burn economics becoming mostly narrative (demand not matching emissions). Trigger: DC burn remains small relative to scheduled emissions for extended periods, or burn is volatile and largely driven by non-recurring actions (onboarding, asserts) rather than sustained network usage. Mechanism: DCs are pegged to USD and are created by burning HNT, but HNT supply also includes scheduled emissions plus Net Emissions that can re-emit burned HNT up to a daily cap, which limits deflation even during higher burn periods. Who bears it: Passive HNT holders (price pressure), and late Hotspot deployers who depend on token rewards as ROI rather than on a sustainable cashflow loop. Indicators: (i) sustained low DC burn levels, (ii) rising circulating supply despite burn narrative, (iii) reward rates that rely primarily on emissions rather than on usage-linked burn and fee recycling.

If you’re integrating HNT into a product or designing incentives around Helium participation, treat governance like an adversarial surface, not a community vibe. If you need help stress-testing parameter-change risk, a short engagement in tokenomics consulting can be worth it, specifically around governance attack paths and reward-model stability under HIP-driven change.



This article is part of our Tokenomics Deep Dive series.