Skip to main content

Proof-of-Coverage

The Helium Network uses a unique consensus algorithm called "Proof-of-Coverage" (PoC) to verify that Hotspots accurately represent their location, configuration, and the wireless coverage they create.

Proof-of-Coverage incentivizes Hotspot Operators to deploy Hotspots in underserved areas and report their deployments accurately so that users of the Helium Network can see where coverage is likely to be available.

Why Proof-of-Coverage

The Helium Network is a physical wireless network that succeeds based on the reliable coverage it can create for users deploying connected devices. As such, it required a working algorithm built for this use case.

Proof-of-Coverage leverages unique, undeniable properties of radio frequency (RF) propagation to produce meaningful proofs to the Helium Network and its participants. Specifically, PoC relies on the following characteristics:

  • RF has limited physical propagation and, therefore, distance.
  • The strength of a received RF signal is inversely proportional to the square of the distance from the transmitter.
  • RF travels at the speed of Light with (effectively) no latency.

The Helium Network uses the data generated by ongoing proofs to verify the wireless coverage provided by Hotspots on the network.


Oracled Proof-of-Coverage

  • Oracled Proof-of-Coverage ChainVar was set in block 1,731,335.
  • The first Oracled Proof-of-Coverage Receipts were in block 1,731,339.
  • "Bitter Concrete Parakeet" is the animal name of the Injector Oracle for Oracled PoC.

Oracled PoC moves the responsibility of validating all PoC events to dedicated Oracles, powerful machines that ingest completed challenges, verify challenges, and witness validity, then inject the results back into the Helium Network for rewards to be issued.

Oracles interact with data and systems outside of a native blockchain environment where the processing can be completed much more efficiently and at scale, providing a solution to a fundamental limitation of smart contracts.

Oracled Proof-of-Coverage allows Hotspots running miner version 2022.12.13.0 or later to "self-beacon", transmitting Beacons on their own to participate in Proof-of-Coverage, ensuring more reliable Beacon events.

At the start, Hotspots self-beacon every 6 hours, though this time window may change as Oracled PoC is improved. The Beacon rate includes a "jitter" component to offset the Beacon timing across Hotspots on the Network to avoid overloading the Oracles with large data spikes.

Oracled PoC is essential in implementing HIP-70 and the Helium Network's migration to the Solana blockchain and is a significant step forward in increasing the usability and scalability of the Network.


PoC Reward Scaling

Rewards for Beacons and Witness events under PoC are prioritized by a scheme that was introduced under HIP-17, which was designed to pay higher rewards for Beacon events that are transmitted from less-covered areas as a way to encourage Hotspot owners to deploy Hotspots in these areas and discourage deployments in areas that are already densely covered.

PoC currently judges an area as over- or under-served by consulting a table of density scale values, which dictates how many Hotspots are needed to effectively cover a given area.

As each Hotspot is added to or removed from the Network, the Oracle examines the deployment and how it affects the Hotspot count at each of the seven scales, computing a new Transmit Scale (TS) for every Hotspot in the regions affected.

If the change is an addition to the Network which increases the density of Hotspots at a particular scale beyond the ideal density, every Hotspot in that region has its Transmit Scale reduced.

Currently, there are seven “targets” in the list, each of which is a pairing of an area scale and the ideal number of Hotspots that should be deployed at that scale.

In every epoch, rewards split amongst Hotspots that had a role in that reward pool.

For example, a Hotspot might earn a "reward unit" for witnessing a beacon. If five additional Hotspots successfully witnessed a Beacon during the epoch, each Hotspot earns a "reward unit." In that case, each Hotspot gets 1/6th of the 20% of rewards in that epoch.

The activation of HIP-15, HIP-17 and HIP-104 introduced the idea of scaling these reward units. So the units earned when being witnessed or witnessing a packet scale depend on three things:

  1. The number of Witnesses, as detailed in HIP-15
  2. The number of Hotspots in the hex tile of the transmitter, detailed in HIP-17
  3. The adjusted parameters from HIP-17, detailed in HIP-104

The HIPs themselves provide a rich explanation of these mechanisms, but they can be summarized as follows:

From HIP-15

  • For the Transmitters: The more witnesses, the more the transmitter earns.
  • For the Witness: Each additional Witness past a total of four reduces what is earned by each Witness in that challenge.

From HIP-17

  • The Witness earns less if the number of Hotspots in the area of the transmitter exceeds the "target density." Target density varies by hex resolution, as detailed in the HIP and defined in several chain variables.

From HIP-104

  • The Hotspots in rural areas (or less densely covered regions) now earn more PoC rewards than they did previously, in order to guide the Helium IoT Network coverage towards a more well-balanced and expansive state.

IOT token rewards

Daily IOT token rewards by reward category