Skip to main content


Removing A Hotspot from the Denylist with Crowdspot

If a Hotspot has been added to the Denylist in error, the only method to have it removed is to file a Removal Request using Crowdspot.

Instructions for submitting a removal request can be found on the Denylist Removal Request documentation page.

What is the Denylist?

The Denylist is a list of Hotspot public keys and a cryptographic signature that have been identified not to be accurately contributing to Network coverage or are otherwise circumventing the good faith of the Network in an attempt to earn Rewards. Rewards gaming by dishonest actors, even as a small percentage of the Network, erodes Network integrity.

Examples include, but are not limited to: Cluster Packet Forwarders, Misasserted Locations, Misasserted Antennas, Multiple or Shared Antennas, Attenuators, Amplifiers and Data Credit Farming

Helium Network Validators optionally subscribe to the Denylist to block HNT Rewards to dishonest Hotspots while recording on-chain records of the denied transactions. The Denylist is another tool in a broader range of tools to incentivize Hotspots on the Network to provide the most honest and accurate wireless coverage possible.

The Denylist is sourced from the community to keep the Network decentralized. Credible decentralization ensures that no one entity can control the Network. Any coordinated effort to game rewards, block data transfer, or censor information to benefit one party while harming another, undermines our mission of creating global, open wireless Networks.

How “gaming” is defined is left to Denylist operators, members of the Helium Community, and ultimately the choice of inclusion by Validators.


The Helium Foundation has not and will never run its own Denylist out of the interest of decentralization.

Network Impact

Hotspot Owners: For any well-asserted, appropriately compensated Hotspot, the Denylist only benefits you. By denying HNT to dishonest Hotspots, that HNT is shared amongst honest Hotspots.

Validators: Validators can choose to subscribe to any Denylist(s). The Validator will ingest the Denylist from the third party. Using the ingested list, it will cross-reference denied Hotspots to inbound transactions while it is a member of a consensus group.

Bad Actors: The message is simple: Stop. If your Hotspots are earning HNT without providing coverage, they are likely to appear on the Denylist and will stop earning HNT Rewards.

The Role of Validators

Validators will have the ability to subscribe to one or many Denylists and to add or remove a subscription at any time.

A Validator cannot simply ignore a transaction from a given Hotspot without risk of being penalized. Therefore, the Honey Badger BFT Consensus Group demands that action must be taken for all transactions.

The protocol allows a transaction to be marked invalidated with a majority of the Consensus Group in favor while not penalizing the opposing Group members. To execute a transaction denial, Validators within consensus will vote to block rewards for individual witness receipts within a receipts transaction.

Operators will specify their preferences for Denylists in a configuration file. This configuration will hold the URLs and public keys of the chosen Denylist(s). The Validator will fetch each Denylist on a regular schedule and check its authenticity using the libp2p_crypto routines. If the list is authentic, the Validator will update its local store of denied Hotspots using this fetched list.

Only Validators in an active Consensus Group are eligible to vote on an individual witness receipt within a receipts transaction. In order to keep a PoC activity from being paid, a challenge or receipt must accrue 2F+1 votes against. So for example, in a 43 member consensus, 29 votes must be cast to block payment of a receipt.

Because Validators have the choice to subscribe to more than one list, they can select from Denylists with varying specialties. For example, some Denylist operators may work primarily off community submissions, while others may work off in-field surveys, statistical analysis, machine learning models, or other means.

Denylist Generation

Denylist generation is handled by the open-source xorf-generator library. This tool both allows for key signing of the Denylist as well as the construction of the binary filter that Validators use to check transactions against.

Frequently Asked Questions

What if a Validator Operator blocks all but their own Hotspots?

To effectively block any transaction, a 2F+1 majority of Validators in a consensus must agree, meaning that 29 of the 43 members in a consensus group must agree. With over 2900 Validators online and 43 randomly selected from that pool for consensus, it would be prohibitively expensive for a bad actor to deny arbitrary Hotspots.

What if the Denylist doesn’t have all of the gaming Hotspots?

The Denylist is one disincentive of many to keep gaming at bay. Above all, Proof of Coverage and more direct detection methods all work in concert to ensure the security of PoC.

What if not enough Validators sign up to use a denylist?

If Validator operators don’t feel the need to run a denylist, then we must assume that the Network is in good health. Through the long-term staking of their HNT, Network Validators are incentivized to do what is in the best interest of the Network.

Will the Denylist have the ability to block data transfer or rewards for data transfer?

Yes, any Hotspot considered ‘denied’ of Proof of Coverage rewards will still be able to act as a data-only Hotspot, providing data transfer network coverage where possible, but these hotspots will be blocked from data transfer rewards. Because it is generally the case that these Hotspots did not provide sensor coverage in the first place, hence their inclusion. Is it important to understand the uninterrupted data transfer ability in the case of errant inclusions.