Helium Improvement Proposals are the change process, not the code

What a HIP is and where the process actually lives

Helium Improvement Proposals are the core unit of change in the Helium Network. The project documentation compares them to how a bill becomes a law, which is a useful shorthand for a numbered document that gets debated, amended, voted on and then becomes binding.

The process itself is not defined in the top-level documentation. The project documentation points to HIP 7, A Process For Managing Helium Improvement Proposals, for the details on process and how to participate. That is the first thing to read, because the numbering scheme only makes sense once you know that HIP 7 is the constitution and the rest are amendments to it.

Participation happens in two places, and the project documentation is explicit that the repository's Discussion section is where you propose changes, give feedback and discuss ideas on how to make Helium governance better. Issues and pull requests in the repository appear to be the mechanism for the formal document changes, since the status badges in the index link to specific issues and pull requests, and those links are where the discussion of the actual text lives.

One practical note is also in the project documentation. Applications for HIP19 hotspot manufacturer status have moved out of this repository into a dedicated one at dewi-alliance/hotspot-manufacturers. That is a sign of a repository that is being actively pruned of things that have found a better home, which is worth knowing if you go looking for the manufacturer process here and do not find it.

Reading the index: status badges and the vote marker

The index is a table with four columns, and the two that matter are the status and the vote.

Each row links to the proposal file, shows a status badge, and shows a badge labelled Voted With. The status values visible in the index are Deployed and Closed. Deployed means the proposal is live in the network. Closed means it is finished but not the rule in force, which covers proposals that were rejected, superseded, or folded into another change.

The Closed rows are not all the same kind of closed, and the links tell you which. HIP 5, the PoC fairness and epoch challenge limit, links to a specific issue comment. HIP 6, the ramp-up period for data transfer rewards, links to a pull request. HIP 9, ensuring trust for non-Helium hotspots, also links to a pull request. HIP 11, an amendment to the proportional data transfer reward scheme, links to a pull request and a specific issue comment within it.

The point of those links is that a closed proposal is not dead text. A closed proposal that was deployed and then superseded by a later amendment is the historical record of why the current rule looks the way it does, and the amendment is usually numbered immediately after it. HIP 10 and HIP 11 are exactly that pair, the reward scheme and its amendment, filed back to back.

The Voted With column shows a single badge with the token ticker HNT on it for every row in the index. That is a deliberate design point: votes on HIPs are recorded as token-weighted votes, so the badge tells you the voting instrument rather than a count.

The visible index rows include Longfi and LoRaWAN (1), Sign miner (2), Expensing Data Credits for LoRaWAN Traffic (4), the PoC fairness limit (5), the reward ramp-up period (6), the HIP process itself (7), an XOR filter for LoRaWAN packet routing tables (8), trust for non-Helium hotspots (9), the proportional reward scheme for data transfers (10) and its amendment (11), and Remote location assertion (12).

The proposal set reads like a change log for the network

The file listing is the most informative view of what the network has actually changed, because the numbers are the order in which the changes happened.

Early proposals deal with the mechanics of getting data onto the network. HIP 1 covers Longfi and LoRaWAN, HIP 2 covers the Sign miner, and HIP 4 deals with expensing Data Credits for LoRaWAN traffic. HIP 8 is an XOR filter for LoRaWAN packet routing tables, which is a routing optimisation, and HIP 12 is remote location assertion.

Then the middle of the range is where the economics and the security model get worked out. HIP 5 and HIP 6 are about proof-of-coverage fairness and about a ramp-up period for data transfer rewards, both closed. HIP 9 is about ensuring trust for non-Helium hotspots, which is the DIY gateway question, also closed. HIP 10 and 11 are the proportional reward scheme and its amendment. HIP 13 is the transfer hotspot, HIP 14 the PoC ripple method, HIP 15 beaconing rewards, and HIP 16 random consensus group election.

Later numbers show the network maturing and splitting into specialised areas. HIP 19 is the third-party manufacturers proposal that has now moved to its own repository. HIP 20 is HNT max supply, HIP 21 the PoC link layer, HIP 22 DIY concentrators, HIP 23 decoupling consensus from gateways, HIP 24 reward splitting, and HIP 25 validators. HIP 26 is payment notes, HIP 27 CBRS 5G support, HIP 28 consensus reward adjustments, HIP 29 multisignature keys, and HIP 30 update threshold cryptography.

The last stretch is clearly governance and validator tooling. HIP 31 is governance by token lock, with HIP 41 being governance by token lock v2, which is the same amendment pattern as HIP 10 and 11. HIP 32 splits DCs, HIP 33 is regional reward adjustments, HIP 34 validator node security, HIP 35 a safe RF metadata side channel, HIP 36 block heights instead of time, HIP 37 the Omni protocol PoC, HIP 38 validator oracles, HIP 39 HNT redenomination, HIP 40 a validator denylist. HIP 43 is software release guidelines, HIP 44 witness decay, HIP 45 and 46 LoRaWAN frequency plan selection and NetID routing, HIP 47 an increase in the DKG penalty, HIP 48 IP support, HIP 49 max EIRP adjustment, HIP 50 displaying all potential beacon witnesses, and HIP 51 the Helium DAO.

A template file and a numbering convention you can read at a glance

The repository root holds 0000-template.md, which is the starting point for a new proposal. Having a zero-numbered template next to the numbered proposals is a small but meaningful convention: it tells a reader that the sequence starts at 1 and that a proposal has a defined shape before anyone writes one.

The naming convention is consistent throughout. Every proposal file is a four-digit zero-padded number, a hyphen, and a slug describing the subject: 0010-usage-based-data-transfer-rewards.md, 0022-diy-concentrators.md, 0036-blockheights-instead-of-time.md, 0051-helium-dao.md. The slug is descriptive rather than cryptic, which means you can guess whether a proposal exists before opening the index.

The repository also carries the standard supporting files for a document repository rather than a code repository. There is a .markdownlint.json and a .prettierrc, which together mean the Markdown is machine-formatted, and a .claude/ directory, which suggests the repository ships instructions for automated contributors so that generated edits follow the same formatting rules a human would apply.

What is absent is as telling as what is present. There is no build system, no package manifest, no test suite and no source directory. The deliverable is the document set, and the toolchain around it is a linter and a formatter for Markdown. For a repository whose primary language is listed as Jupyter Notebook, which is an unusual classification for a governance document set, the practical reading is that some proposals include notebook-format content alongside the Markdown.

Apache 2.0, an active repository, and no versioned releases

The licence is Apache-2.0, and for a governance document set that is a sensible choice, since the text of a network's rules is meant to be quotable, forkable and reusable without restriction.

Upkeep is visible. The last push was on 2026-09-02, and the repository is not archived. The default branch is main and the repository publishes no GitHub releases, which is right for this kind of project: there is nothing to release, because the documents are versioned by their own numbering and the git history.

The absence of tagged releases also means there is no way to pin a specific version of the rule set other than pinning a commit, and a commit pin is not a natural unit for a governance document. This is the main practical difference between a HIP repository and a normal software release stream, and it is worth internalising before you build automation on top of it.

There is also a scale question. The file listing shows proposals numbered up to at least 56, and the numbering is dense enough that the gaps are small, which is a healthy sign for a process that is actually used rather than one that exists on paper. A process where the numbers climb but nothing deploys would show a lot of Closed proposals with no Deployed ones, and the visible index rows are a mix of both.

The other observation about the collection is that several proposals are about decentralising governance itself, with governance by token lock appearing twice, once as an original proposal and once as a v2, and DAOs appearing for the general network, for IoT and for mobile. A network whose own improvement process has proposals about DAOs and token-lock governance is doing something that most infrastructure projects never reach, which is turning the rules into the thing being governed.

Editorial conclusion

The HIP repository suits anyone whose work depends on Helium Network rules, particularly hotspot operators, validator node operators and developers building on the network, because it is the authoritative record of how a rule came into being and who voted for it. It is the wrong tool if you are looking for software to run, since what it ships is proposals rather than software to run. Before relying on any Helium rule in your own deployment, find the proposal that introduced it in the index, read its status badge, and check whether the proposal was amended later, since the index shows closed proposals alongside deployed ones and a later amendment can change the meaning of an earlier one.

Frequently asked questions

Official sources

1. helium/HIP on GitHub
2. Issues
3. License: Apache-2.0
4. README