Inconsistent Rewards and Improvements Coming with HIP-70

Article author
Customer Support
  • Updated

The TL;DR Version

Today, Proof of Coverage activity and rewards for Hotspots are inconsistent and oftentimes not providing the full amount of rewards a Hotspot should be getting. After the migration to Solana, PoC mechanisms are fundamentally changing and this will result in vast improvements for all Hotspot owners:

  • No more Validators, PoC and Data Transfer moved off-chain to Oracles
  • 6.85% of HNT emissions (~2 million HNT annually) added to Hotspot PoC rewards pool
  • No more randomly being chosen to Beacon, all Hotspots Beacon automatically once per hour
  • No more 14 Witness limit for Beacons and you won't need to be chosen randomly to have your Witness count - all Beacons you see will be rewarded
  • Improved security and the ability to have different PoC mechanisms for IOT, MOBILE, and new networks

What is Proof of Coverage?

The Helium network of today is all about providing wireless backhaul coverage for IoT devices using a technology called LoRaWAN, which is similar to WiFi but at a much lower power and reaching much larger ranges. Helium is currently building out coverage for cellular offloading via 5G hotspots, and more networking technologies are sure to come in the future. In this article, we'll focus on IoT LoRaWAN proof of coverage.

In order to make the network attractive to potential users and ensure a seamless experience, there needs to be actual wireless coverage for network users to utilize to transfer their sensor data. Simply adding hotspots to the network is not enough, the hotspots need to be spread out as evenly as possible and their location needs to be believable. The way Helium validates this coverage and maps it is via a mechanism called Proof of Coverage (or PoC for short).

PoC tries to verify, on an ongoing basis, that Hotspots are honestly representing their location and the wireless network coverage they are creating from that location.

For technical details on how PoC functions, see this documentation by Nova Labs (the Helium development team).

How Proof of Coverage Functions Currently

In examining how PoC works, we'll focus on a few of the key players of the network, namely Validators and Hotspots.

Validators are specific nodes run on high powered servers which are responsible for keeping track of the blockchain, providing blockchain information to hotspots, performing consensus work (choosing valid blocks and adding them to the chain), issuing Challenges, and more. To run a Validator, you must stake 10,000 HNT and ensure your Validator node remains up-to-date and online and performing work. In return for this, Validators earn HNT rewards for performing this service. 

Hotspots are the devices most network participants use. These are small, low power devices (similar to Raspberry Pi units) which are equipped with antennas, LoRa transceiver cards, and other hardware and software needed to send and receive LoRa signals. Hotspots are Beaconers when Challenged by a Validator, and are also Witnesses when detecting another Hotspot's sent beacon.


Every new block, Validators can issue a Challenge to a Hotspot which is a request for the Hotspot to send a Beacon. A Challenge tells the hotspot to construct a particular type of LoRa packet (a Beacon) and broadcast it out of its antenna to the surrounding physical area. Other hotspots which are physically in radio range will detect this Beacon with their antennas and send a Witness Receipt back to the Validator to let it know the Beacon was successfully heard.

Part of this Witness Receipt will include information on signal strength and other details which help the network recognize Hotspots which are not where they claim to be or are otherwise trying to cheat the system and will result in no rewards for the cheating Hotspot.

The amount of Challenges allowed per block is controlled by a blockchain variable: poc_challenge_rate. This rate can be increased or decreased as needed. Increasing the rate causes more PoC activity to take place but can also slow down block processing time for the Validators. Decreasing the rate makes block processing easier but also lowers the PoC activity taking place resulting in decreased rewards for hotspots.

Validators issue Challenges to Hotspots via a selection algorithm. Details of this algorithm can be found in this section of the documentation, but to keep things simple it's accurate enough to say Validators choose their Challengees (Hotspots to receive a Challenge) randomly. If the amount of Challenges occurring stays the same (the poc_challenge_rate variable) and the number of hotspots added to the network increases, this results in any given Hotspot being chosen to beacon less frequently.


When a Hotspot is Challenged by a Validator to send a Beacon, it constructs a special packet and sends it over the air to all Helium Hotspots that can hear it. In order to receive the Challenge successfully, the Hotspot needs to have a working internet connection and cannot have any firewall rules in place that will block the traffic coming from the Validator.

Once the Beacon is sent, it travels over the air similar to any other LoRa signal and other Hotspots which are physically close enough will hear the Beacon. They will use the information in the Beacon to look up the Validator who issued the challenge and send a Witness Receipt to the Validator letting them know the Challenged Hotspot did broadcast a beacon and provide other information such as signal strength which the network will use to determine if the Witness is valid. Out of all of the received Witness Receipts, the Validator will randomly choose a maximum of 14 valid Witnesses to record for that particular PoC process, and those witnesses chosen will be rewarded.

If a Hotspot reports it Witnessed a Beacon, the signal strength information will be used to calculate the likelihood of that Hotspot actually having seen the Beacon based on both Hotspot's asserted locations (where they show up on the map). For example, if a Hotspot reports hearing a Beacon from another Hotspot which is 500KM away, the characteristics of RF propagation indicate it should not have been able to detect the signal so the Witness will be discarded as invalid. The exact mechanisms of this cheating Hotspot detection are not revealed to anyone outside of Nova Labs developers for security reasons.

In order for a Hotspot to send a Beacon successfully, it needs to receive the Challenge from the Validator and must have working LoRa components. 


When a Hotspot hears a Beacon packet sent from another Hotspot, it will record properties of the packet and send a Witness back to the Validator who issued the challenge. It does this by performing a lookup request to its currently connected Validator and finding the Challenger via information provided in the Beacon packet.

A Witness will include information regarding the RF signal of the Beacon which will be used by the network to determine if the Witness should be considered valid. Because Beacons are broadcast out to all devices in radio range, there could be a large number of Witness receipts sent to the Validator. Each Beacon can have a maximum of 14 valid Witnesses recorded. When more than 14 Hotspots submit Witness receipts, the Validator will randomly choose Hotspots from the list of Witnesses up to the maximum of 14. This means your Hotspot often Witnesses many more Beacons than you can see on the Helium Explorer, as being chosen as one of the 14 recorded Witnesses is always random.

In order to successfully perform a Witness, a Hotspot will need to detect the Beacon with its LoRa equipment, have a working internet connection with which to send the Witness Receipt to the Validator, and be randomly chosen from among all Witnessing Hotspots to have its Witness counted for that Beacon.

PoC Rewards

HNT is awarded to Validators who construct Challenges and record the final PoC transaction details, Hotspots who are randomly chosen and send valid Beacons when Challenged which are Witnessed, and Hotspots who Witness valid Beacons and are randomly chosen to have their Witness recorded. 

Current PoC mechanisms employ quite a bit of randomness which can contribute to very inconsistent PoC and rewards activity.

The Current State of the Network

This short video from Nova Labs CEO Amir Haleem highlights some of the current issues with PoC and how the Helium developers plan on addressing these issues in the near future.

At present, all PoC activity that happens on the Helium network is recorded on the blockchain. At the time of writing, the Helium network has 945,991 onboarded LoRaWAN hotspots, with almost 25,000 being added in the last month! At the current rate there will be over 1 million hotspots on the network within the next two months. This is a great achievement and bodes well for the future of the network, however it also means the blockchain is having a harder and harder time keeping up with PoC activity. This is also putting increased strain on Validators, and in order to keep the block times low Nova Labs has been forced to lower the poc_challenge_rate variable meaning less Challenges are sent every day and there is less PoC and reward activity for hotspots.

These problems are compounded by the random nature of Beaconer selection and Witness selection. All of these issues combine to create a situation where PoC activity can be incredibly inconsistent. Nova Labs has openly acknowledged that Hotspots are normally going multiple days between each Beaconing activity which means the amount of Witnesses is also decreasing. At current, it's normal to see a Hotspot go up to a week between sending Beacons however, due to the random nature of PoC as it is now, you can also sometimes see multiple Beacons occur in the same day.

This randomness and inconsistency in PoC activity means rewards are not predictable or steady. It also makes it that much harder to determine if there is anything wrong with your Hotspot or setup. If the network is not stable, it's much more challenging to know if the low activity you're seeing is due to a real problem or simply due to the state of the network.

HIP-70 and Network Improvements

We recommend reading HIP-70 in full. It can be found here on the Helium Github.

What is HIP-70?

In an effort to address many pain points with the development of Helium (one being these Proof of Coverage issues), Nova Labs has put forth HIP-70 for vote by the community. A HIP is a Helium Improvement Proposal, and HIP-70 details the reasons and mechanisms for a migration from Helium's own developer maintained blockchain over to Solana, a layer 1 blockchain (similar to Ethereum, Algorand, etc). In moving to Solana, transactions for all parties involved with Helium will be faster, more fault tolerant, and cheaper. There will also be additional improvements which will finally address inconsistent PoC and rewards activities for Hotspot owners.

Proof of Coverage Oracles

While at current PoC activity occurs on-blockchain, after migration to Solana this PoC activity will be moved off-chain onto Oracles. Oracles are entities (usually servers) which are outside of the blockchain and provide real world data to feed into a blockchain for use on the chain. The most common type of Oracle is a Price Oracle - for example DeFi trading platforms based on Ethereum need a way to know the current market price of the cryptocurrencies they trade, and Oracles provide this external data to the blockchain for it to use in its processes.

The end result of having PoC activities recorded on Oracles rather than on the blockchain itself is that PoC processing will be highly scalable - if more hotspots are added and more resources are needed to process the PoC activity, the servers can simply be scaled up to handle the increased demand thereby keeping activity consistent for the hotspots. This will also decouple PoC processing from the blockchain which will allow for caching - if the Solana chain goes down temporarily, PoC activity will continue normally and the results can simply be fed into the blockchain later when it is operational again. This also allows for the option to cache PoC results for transfer on-chain at a later time in case of network congestion or abnormally high transaction fees (although this is highly unlikely on Solana, it's good to have the option available).

Data Transfer Oracles

Similar to moving PoC off-chain, data transfer mechanisms and accounting will also be moved onto Oracles. All benefits listed for moving PoC activity to Oracles also applies to moving data transfer to Oracles. Similar to PoC, if Solana were to go down temporarily sensors and hotspots could still transfer data with no issues. Having the ability to quickly scale for demand and cache data transfer accounting will make the Helium network much more resilient to downtime.

Validators Removed and Increased Hotspot Rewards

With the move to Oracles for off-chain processes and Solana already having its own consensus mechanisms, Validators will no longer be a part of the Helium ecosystem. 6.85% of all HNT emissions currently go to Validators for various processes. After the migration to Solana, the 6.85% of HNT emissions (roughly 2 million HNT annually) which now goes to Validators will instead be distributed to Hotspots, increasing PoC rewards!

Programmatic Proof of Coverage

The current iteration of PoC involves a large amount of random choice - Validators issue Challenges randomly, Challenges are issued randomly to Hotspots, Witness Receipts from Witnesses are chosen randomly - this all results in a lot of inconsistency. While the final details of PoC processes may change after some iteration and testing, these are the general goals of the new off-chain PoC mechanism:

Rather than being Challenged, Beaconing will occur in a programmatic way. Hotspots will automatically Beacon once per hour without needing to first be challenged by another entity. This will remove randomness and increase consistency, and allow for easier troubleshooting. At current, it's sometimes impossible to tell if a lack of activity is due to network issues or something specifically affecting your device. After the change you will be able to quickly tell if your device is behaving normally or not.

Improved security features will help ensure Beaconing activity cannot be forged or replayed, cheating the system for invalid rewards. Oracles will help with these increased security measures.

Witness Receipts will be sent directly to the Oracle, which will process and cache the PoC data. There will no longer be a cap of 14 Witnesses per Beacon. This removal of the cap plus the removal of random Witness Receipt selection means your Hotspot should get PoC credit for every Beacon it sees now, not only the ones it sees and is lucky enough to be chosen for.

Oracles will do all PoC processing, so the same Oracles can handle different types of PoC processes - IOT/LoRa, MOBILE/5G, WiFi, and any other future sub-DAO networks' specific PoC processes. This will eliminate the previous need to have multiple Validator versions to support multiple sub-DAO network PoC processes.

Multiple Oracles will be implemented - this will result in PoC activity ingestion and processing happening on some Oracles, distribution of PoC activity rewards handled by different Oracles, data transfer accounting happening on other Oracles and so on. Taking a multiple Oracle approach will increase the decentralization of Helium and add more fault tolerance and scalability to the network as a whole.

Additional Benefits of Solana Migration

In addition to the improvements to Proof of Coverage activity and rewards and data transfer mechanisms, there will be additional benefits for all network participants after the migration to Solana.

Without the need to maintain and iterate on their own layer 1 blockchain, Nova Labs developers will be freed up to focus their resources on making improvements to the network and adding new sub-DAO networks. At current, a large number of resources are dedicated to updating and maintaining the current Helium blockchain.

Operating on Solana will also allow Helium users to take advantage of wallet software already used on Solana such as Solflare Wallet, DeFi platforms of Solana such as Orca DEX, and much more. It will also open the Helium ecosystem up to a much larger group of active developers and current and future Solana developers can make all sorts of interesting and useful Helium related tools.

What About Current Helium Wallets and Funds?

Due to the fact that Solana and the current Helium blockchain use the same private key/wallet standard, all existing Helium private keys/seed phrases will be compatible with Solana. There will be no steps needed to migrate a wallet to Solana after the migration, and your same seed phrase will still work for your existing funds and Hotspots.

Hotspot ownership will be handled by minting NFTs of hotspots, and your wallet will own the NFT of the Hotspot similar to how your wallet currently owns the Hotspot object on the Helium blockchain. There will be no need to transfer Hotspots for the migration.

After the migration, your public address may be different, so be sure to take note of this if receiving funds. Aside from this minor change, you will also be able to not only use the Helium Hotspot and Helium Wallet apps for your wallet needs, but you'll also be able to use any Solana based wallets such as Solflare Wallet.

What Steps You Can Take in the Meantime to Improve Earnings

So, what can you do to improve earnings today while waiting for these changes to come about? You can take many of the same steps as have been suggested for Helium mining since the beginning!


Ensure you have a good placement for your Hotspot, or consider moving it to another location if you have a better spot. It should be in LoRa range of other Hotspots in order to participate in PoC, however the more congested the area is the lower the reward scale of nearby Hotspots. If possible, find a balance between being near others and having your own space. This isn't always possible, especially with almost 1 million Hotspots deployed, but it's worth checking into. If you can't find a better spot when it comes to Hotspot saturation, try to pick a spot that's as high up as possible. For example, if you can install the Hotspot at the top of a high rise building, you will have much better reach to the surrounding areas. We can't all have amazing placements available to us, so just pick the best one you have.


Aside from placement consider changing to a different antenna that better suits your particular environment, topology of the area, placement of other miners, etcetera. There are many guides online which can assist in determining the best type of antenna for a given situation. Here are a few useful resources:


While LoRa signals are better at penetrating obstructions than 5G or WiFi for example, obstacles can still impede the signal and prevent it from reaching other Hotspots. Things like large amounts of tree cover, heavy brush, surrounding houses, surrounding high rise buildings, and more can interfere with LoRa signals making it from your antenna to other antennas. In general, the denser the material (foliage vs dirt vs concrete and brick) the worse signal penetration will be. If you have some mild tree cover near your antenna, this could cause some signal issues however being surrounded by concrete high rise buildings extending higher up than your antenna will have a much more drastic effect. 


Related to obstructions, height is an important consideration for your setup. If you can elevate your antenna well above any surrounding obstructions, your signal will reach much farther. You will also have a higher chance of making a line-of-sight connection with other antennas, which will provide the best signal. In general, higher is almost always better.

EU868 Specific - Noise Filtering

Due to the specific frequency range used by EU868 Hotspots, they can experience a higher level of noise than other frequency range Hotspots. This is because more noise sources transmit close to 868MHz than 915MHz or others. Sources of noise can be nearby airports, military installations, communications towers, industrial plants, or any device transmitting on frequencies near 868MHz. Typically when RF noise is an issue, your miner will have low to no Witnesses but will still send Beacons which can have the full 14 or sometimes less than 14 Witness Receipts.

If you suspect RF noise in the area might be affecting your rewards, we suggest installing a SAW Bandpass filter on your setup. Typically Bandpass filters are quite cheap (under $30 USD). These are small box or barrel shaped adapters which have connectors on both ends and can be connected either to the port on your Hotspot or at the antenna end and help with cleaning up the received signals. This helps the Hotspot to discard background noise and focus on actual signals from other Hotspots. Many customers have seen their Witness rates increase dramatically after installing a filter in noisy areas.

This is an example of a SAW Bandpass filter:


Some things to keep in mind when buying and installing a filter:

  • Filters introduce some signal strength loss, typically 2-3dB meaning your signal strength will decrease slightly
  • Most filters have SMA connections, not RP-SMA like most Helium Hotspots. You may need to purchase SMA to RP-SMA adapters to use with the filter, which can introduce a small amount more signal loss
  • Placing the filter near the antenna end of your setup is preferable, if possible. But attaching directly to the Hotspot's LoRa port typically produces great results too
  • The filter must match your Hotspot's frequency! Don't buy an 868MHz filter and install it on a US915 miner for example, this will have the opposite effect and block out legitimate signals
  • Any time you are connecting or disconnecting antennas, filters, adapters, cables, or anything else attached to the LoRa port of your miner, it's always recommended to power off your miner first to avoid damaging the LoRa card
  • Any time you make a change to your Hotspot's setup - whether changing antennas, placement, moving the antenna, adding a filter - you will need to give the Hotspot 1-3 days before you can get any meaningful data from the activity - this is due to the inconsistent nature of PoC at the moment. Once the proposed changes to PoC take effect, you'll be able to quickly and reliably see if changes to your setup are beneficial or not!

Was this article helpful?