Helium

A Decentralized Machine Network

Amir Haleem Andrew Allen Andrew Thompson Marc Nijdam Rahul Garg
Helium Systems, Inc.
Release 0.4 (2018-08-10)

Abstract to affect. These networks are more complicated to decentral-

ize as they often require specialized hardware to function.
The Internet of Things is an $800 billion industry, with over
The Helium network is a wide-area wireless networking sys-
8.4 billion connected devices online, and spending predicted
tem, a blockchain, and a protocol token. The blockchain runs
to reach nearly $1.4 trillion by 2021 [1]. Most of these
on a new consensus protocol, called the Helium Consensus
devices need to connect to the Internet to function. However,
Protocol, and a new kind of proof, called Proof-of-Coverage.
current solutions such as cellular, WiFi, and Bluetooth are
The Miners who are providing wireless network coverage in a
suboptimal: they are too expensive, too power hungry, or too
cryptographically verified physical location and time submit
limited in range.
proofs to the Helium network, and the Miners submitting the
The Helium network is a decentralized machine network best proofs are elected to an asynchronous byzantine fault tol-
that enables machines anywhere in the world to wirelessly erant consensus group at a fixed epoch. The members of the
connect to the Internet and geolocate themselves without consensus group receive encrypted transactions submitted by
the need for power-hungry satellite location hardware or other Miners and forms them into blocks at an extremely high
expensive cellular plans. Powering the Helium network is transaction rate. In addition to the blockchain protocol, the
a blockchain with a native protocol token incentivizing a two- Helium Wireless protocol, WHIP, provides a bi-directional
sided marketplace between coverage providers and coverage data transfer system between wireless Machines and the In-
consumers. With the introduction of a blockchain, we inject ternet via a network of independent providers that does not
decentralization into an industry currently controlled by rely on a single coordinator, where: (1) Machines pay to send
monopolies. The result is that wireless network coverage & receive data to the Internet and geolocate themselves, (2)
becomes a commodity, fueled by competition, available Miners earn tokens for providing network coverage, and (3)
anywhere in the world, at a fraction of current costs. Miners earn fees from transactions, and for validating the
integrity of the Helium network.
Our secure and open-source primitives enable developers to
build low-power, Internet-connected machines quickly and Note: This whitepaper represents a continuous work in
cost-effectively. The Helium network has a wide variety of progress. We will endeavor to keep this document current
applications across industries and is the first decentralized with the latest development progress. As a result of the on-
machine network of its kind. going and iterative nature of our development process, the
resulting code and implementation is likely to differ from
what is represented in this paper.
1. Introduction
We invite the interested reader to peruse our GitHub repo
The world is becoming decentralized. A multitude of plat- at https://github.com/helium as we continue to open-
forms, technologies, and services are moving from central- source various components of the system over time.
ized proprietary systems to decentralized, open ones. Peer-
to-peer networks such as Napster (created by one of our 1.1 Key Components
founders Shawn Fanning) [2] and BitTorrent paved the way
for blockchain networks and crypto-currencies to be built. The Helium network is built around the following key com-
Now Bitcoin, Ethereum, and other blockchain networks have ponents:
shown the value of decentralized transaction ledgers. Exist-
ing Internet services such as file storage, identity verification, Proof-of-Coverage We present a computationally inexpen-
and the domain name system are being replaced by modern sive Proof-of-Coverage that allows Miners to prove they
blockchain-based versions. While software-level decentraliza- are providing wireless network coverage. We anchor these
tion has moved quickly, physical networks are taking longer proofs using a Proof-of-Serialization that allows miners

1
 to prove they are accurately representing time relative to • Miners join the network by asserting their satellite-derived
others on the network in a cryptographically secure way. location, a special type of transaction in the blockchain,
and staking a token deposit.
Helium Network We demonstrate an entirely new purpose-
built blockchain network built to service WHIP and pro- • Miners specify the price they are willing to accept for
vide a system for authenticating and identifying machines, data transport and Proof-of-Location services, and Routers
providing cryptographic guarantees of data transmission specify the price they are willing to pay for their Ma-
and authenticity, offer transaction primitives designed chine’s data. Miners are paid once they prove they have
around WHIP, and more. delivered data to the Machines’ specified Router.
Helium Consensus Protocol We present a novel consensus • Miners participate in the creation of new blocks in the
protocol construction that creates a permissionless, high blockchain by being elected to an asynchronous byzantine
throughput, censor-resistant system by combining an asyn- fault tolerant consensus group.
chronous byzantine fault tolerant protocol with identities • Miners are rewarded with newly minted protocol tokens
presented via Proof-of-Coverage.
for blocks that are created while they are part of the
WHIP We introduce a new open-source and standards- consensus group.
compliant wireless network protocol, called WHIP, de- • A Miner’s probability of being elected to the consensus
signed for low power Machines over vast areas. This group at a given epoch is based on the quality of the
protocol is designed to run on existing commodity radio wireless network coverage they provide.
chips available from dozens of manufacturers with no
proprietary technologies or modulation schemes required. • The blockchain employs Proof-of-Coverage to guarantee
that Miners are honestly representing the wireless network
Proof-of-Location We outline a system for interpreting the coverage they are creating.
physical geolocation of a Machine using WHIP without
the need for expensive and power-hungry satellite location [Figure 1] shows a visual representation of the Helium
hardware. Machines can make immutable, secure, and network.
verifiable claims about their location at a given moment
in time which is recorded in the blockchain.
2. The Helium DMN
DMN We present a decentralized machine network (DMN)
that provides wireless access to the Internet for Machines We introduce the core conmponents of the DMN.
by way of multiple independent Miners and outlines the
Helium network and WHIP specification by which partici- 2.1 Participants
pants in the Helium network should conform. Routers pay
this network of Miners for sending data to and from the In- There are three types of participants in the Helium network:
ternet, and Miners are rewarded with newly-minted tokens Machine, Miner, or a Router.
for providing network coverage and delivering Machine
Machines send and receive encrypted data from the Internet
data to the Internet.
using hardware compatible with WHIP [Section 2.4]. Data
sent from Machines is fingerprinted, and that fingerprint
1.2 System Overview stored in the blockchain.

• The Helium network is a decentralized machine network Miners provide wireless network coverage to the Helium
built around WHIP on a purpose-built blockchain with a network via purpose-built hardware, called Gateways
native token. [Section 2.5], which provide a long-range bridge between
WHIP machines and the Internet. Users join the Helium
• Machines take the form of hardware containing a radio network as Miners by purchasing or building a gateway
chip and firmware compatible with WHIP, and spend that conforms to WHIP, and staking a token deposit
tokens by paying Miners to send data to and from the proportional to the density of other Miners operating in
Internet. their area [Section 5.3.3]. Miners participate in the Proof-
• Miners earn tokens by providing wireless network cover- of-Coverage [Section 3] process to prove that they are
continuously providing wireless network coverage that
age via purpose-built hardware which provides a bridge
Machines can use. Miners join the Helium network with
between WHIP and Routers, which are Internet applica-
a score [Section 3.3.4] that diminishes as blocks pass
tions.
without valid proofs being submitted. At a given epoch,
• Machines store their private keys in commodity key- a new group of Miners are elected to a consensus group
storage hardware and their public keys in the blockchain. which mine new blocks in the blockchain and receive the

2
 Token Exchange
Peer-to-Peer
GPS
GPS/GNSS
Authentication
Coverage

Gateway Gateway

Machine Router
Token Token
Gateway Blockchain
Router

Figure 1. System Overview

block reward and transaction fees for any transactions The blockchain consists of blocks which contain a header and
included in the block once mined. As a Miner’s score a list of transactions. There are several kinds of transactions,
drops their probability of being elected to the consensus outlined in [Section 5].
group and mining blocks diminishes.
At a given epoch a given block consists of:
Routers are Internet applications that purchase encrypted
Machine data from Miners. In locations with a sufficient Block Version
number of Miners, Routers can pay several Miners to Block Height
obtain enough copies of a packet to geolocate a Machine Previous Block Hash
without needing satellite location hardware, which we Transactions 1..n Merkle Hash
call Proof-of-Location. Routers are the termination point Threshold signature by the current consensus group
for Machine data encryption. Machines record to the
blockchain to which Routers a given Miner should send As the Proof-of-Coverage [Section 3] is valuable to the net-
their data, such that any Gateway on the Helium network work, Miners are required to submit their proofs at regu-
can send any Machines data to the appropriate Router. lar intervals. All Miners have a score, which decays over
Routers are responsible for confirming to Gateways that time, and is boosted by submitting Proofs-of-Coverage to
Machine data was delivered to the correct destination and the blockchain. At a fixed epoch, a HoneyBadgerBFT [4]
that the Miner should be paid for their service. consensus group of the highest scoring Miners is elected. For
that epoch, all transactions are encrypted and submitted to
the consensus group for inclusion in the blockchain. The con-
2.2 Blockchain sensus group is responsible for decrypting transactions using
threshold decryption, agreeing on the validity and ordering of
The Helium network is a distributed ledger designed to pro- transactions, forming them into blocks, and appending them
vide a cost-effective way to run application logic core to to the blockchain for which the members of the consensus
the operation of a DMN, store immutable Machine data fin- group receive a reward.
gerprints, and furnish a transaction system. The Helium net-
work is an immutable append-only list of transactions which As the consensus group is validating transactions with-
achieves consensus using the Helium Consensus Protocol out having to provide an associated block-proof (beyond
[Section 6]. Users internal and external to the DMN have ac- a threshold signature), there is practically no settlement time,
cess to the blockchain, which is a new protocol built from and the transaction throughput is extremely high compared
scratch specifically for the DMN. to a Nakamoto Consensus blockchain such as Bitcoin or

3
Ethereum. The Helium Consensus Protocol is outlined in 2.4 Wireless Protocol (WHIP)
detail in [Section 6].
2.4.1 Motivation

2.3 Physical Implementation Several Low Power Wide Area Network (LPWAN) tech-
nologies are available today. These wireless technologies
The Helium network is also a physical wireless network focus on creating long-range, low-power Internet commu-
instantiation. The participants in the Helium network can nication for sensors and other smart Machines. Typically
be thought of as follows: these technologies trade throughput for range, with data rates
as low as 18 bits per second (bps) and range measured in
WHIP The Helium network uses a new open wireless pro- miles. In comparison, a typical WiFi network has signifi-
tocol, called WHIP. WHIP is a long-range, low-power, cantly higher data rates but ranges limited to only a few dozen
wireless network protocol suitable for use with commod- feet. Several of these new technologies, such as LoRa [6]
ity open-standards hardware. WHIP compatible hardware and RPMA [7], have gained good traction and there are
can communicate over many square miles in dense urban many commercial products available compatible with these
environments or hundreds of square miles in rural settings. systems. However, we believe a decentralized machine net-
WHIP compatible hardware can also last for several years work should use non-proprietary protocols and modulation
using standard batteries. WHIP uses strong public key schemes and that participants in the Helium network should
cryptography and authentication occurs using the Helium have the freedom to choose between competing hardware
blockchain, and data is encrypted end-to-end between the vendors. We do not consider an open alliance built on top of
machine and corresponding Internet-hosted router. proprietary hardware to be an acceptable compromise. While
there are many open-standard wireless networking stacks,
Gateways are physical network devices that provide wide- such as IEEE 802.15.4 [8] used in the first generation of our
area wireless coverage and participate in the Helium net- wireless products, none meet our extremely long range and
work. Gateways transmit data back and forth between low power criteria. It is this lack of open solutions that drove
Routers on the Internet and Machines while generat- the creation of a new protocol.
ing Proofs-of-Coverage for the Helium network [Sec-
tion 3]. Gateways are manufactured using commodity
open-standards components with no proprietary hardware. 2.4.2 Outline
Gateways can co-operate and geolocate Machines using
the Helium network without any additional required hard- We introduce WHIP. WHIP is a highly secure, long range,
ware. Each Gateway can support thousands of connected low power, bi-directional wireless network protocol that is
Machines, and provide coverage over many square miles. compatible with a wide range of existing radio transceivers
Miners operating Gateways specify the price they are will- operating in the sub-GHz unlicensed frequency spectrum.
ing to accept for transport and Proof-of-Location services Authentication with the wireless network uses modern public-
for Machines. key encryption and NIST P-256 ECC key pairs, with the
public keys for all participants stored in the blockchain.
Machines exist in the form of hardware products that contain
The modulation format is simple and widely supported, easy
a WHIP-compatible radio transceiver and communicate
to implement and has excellent resistance to RF noise. There
with Gateways on the Helium network. WHIP is designed
are dozens of vendors implementing radio transceivers com-
to facilitate low power data transmission and reception, so
patible with WHIP, such as Texas Instruments, Microchip,
typically Machines exist in the form of battery-powered
and Silicon Labs.
sensors that can operate for several years using standard
batteries (although mains-powered Machines also work WHIP is a narrowband wireless protocol which creates
quite well). Machines can exist in a variety of forms, several channels within the unlicensed spectrum and employs
depending on the product or use case, and a variety of frequency hopping to switch between channels. Typically
transmission and reception strategies can be employed frequency hopping requires a complex time-synchronized
to optimize for transmission/reception frequency or bat- system that is limited in capacity. However, machines using
tery life. Machine manufacturers are encouraged to use WHIP do not need to coordinate with gateways on channel
hardware-based key storage which can securely generate, selection as gateways are capable of hearing all channels
store, and authenticate public/private key pairs without within the available spectrum at any time. We choose narrow-
leaking the private key. band to accomplish the following goals:

In this section, we expand on the components of the wireless Spectral Efficiency It is necessary to operate within unli-
network. censed RF spectrum very efficiently. RF is a shared, lim-

4
 ited resource, and therefore a focus on efficiency to in- Satellite location information is also correlated with packet
crease capacity and improve robustness is necessary. arrival events to provide Proof-of-Location for Machines if
multiple Gateways observe the same packet. This allows ma-
Co-Existence Performance As the number of Machines and chines to locate themselves without requiring a GPS/GNSS
networks increase, the ability to operate in noisy RF envi- transceiver physically, and therefore provide accurate loca-
ronments without interference is a critical consideration. tion data at a fraction of the battery life and cost of competing
Range Narrowband allows for extremely long-range com- methods. This method is described in detail in [Section 4].
munications, with data rates that scale both up and down We will make both a complete open-source reference design
depending on the density of Gateways. and a finished product available at launch of the Heilum
network.
2.4.3 Implementation
2.6 Machines
WHIP supports several data rates, channel bandwidths, and
error-correction techniques. Gateways and Machines dynami- A Machine is any wireless hardware capable of communicat-
cally negotiate the combination of these options using a sig- ing with Gateways via WHIP. WHIP is designed to facilitate
nalling packet delivered at the lowest bandwidth and symbol low power data transmission and reception, so typically ma-
rate to ensure maximum range for the initial communication. chines would exist in the form of battery-powered sensors
that can function for several years using standard batteries.
The full WHIP specification will be made available by the
Decentralized Machine Network Alliance. WHIP is designed such that Machines can be manufactured
using commodity hardware available from a wide variety
of vendors with a very low-cost bill of materials (BOM).
2.5 Gateways The technology in modern radio transceivers, such as the
Texas Instruments CC1125 or STMicroelectronics S2-LP,
Gateways are physical network devices operated by Min- enables exceptionally long-range network systems that can
ers that create wireless RF coverage over wide areas. They be built without the need for proprietary modulation schemes
transmit data back and forth between Routers on the Internet or physical layers. Some of these radios are available for
and Machines on the network, process blockchain transac- around $1 at reasonable volumes.
tions, and create Proofs-of-Coverage for the Helium network
[Section 3]. Gateways can connect to the Internet using any It is recommended that each Machine use the Microchip
TCP/IP capable backhaul, such as Ethernet, WiFi or Cellu- ECC508A or equivalent hardware-based key storage device,
lar. Each Gateway contains a radio frontend chip capable of which can securely generate, store, and authenticate pub-
listening to several MHz of radio spectrum at a time and can lic/private NIST P-256 ECC [3] key pairs without leaking
hear all wireless traffic transmitted within that spectrum. In the private key. Also, a wide array of defense mechanisms
this configuration modulation and demodulation is done in prevent logical attacks on the encrypted data between the
software, which is typically referred to as a Software Defined key storage device and its host Machine, along with physical
Radio (SDR). The benefit of this structure is that Gateways protections on the security device itself. Users program their
can hear any Machine traffic transmitted within the frequency key storage device as part of the onboarding process defined
range, and no synchronization between the Gateway and in the WHIP wireless specification using a defined API.
Machine needs to occur. This allows Machines to remain in-
expensive and relatively simple and reduces wireless protocol 2.7 Routers
overhead. If a Miner wishes to minimize their Gateway hard-
ware costs, synchronized frequency hopping schemes are also Routers are Internet-deployed applications that receive pack-
permitted within the specification as a cheaper alternative to ets from Machines via Gateways and route them to appropri-
a more expensive radio frontend. ate destinations such as an HTTP or MQTT endpoint.
Gateways require a GPS or GNSS receiver to obtain accu- Routers serve several functions on the Helium network,
rate position and date/time information. This satellite-derived including:
location is used in conjunction with other techniques to ver-
ify that a Gateway is, in fact, providing wireless network • Authenticating Machines with the Helium network;
coverage in the location it claims. Because satellite location • Receiving packets from Gateways and routing them to the
messages are easy to fabricate and do not necessarily prove Internet;
that wireless RF coverage is being created, multiple mecha-
nisms are required to validate this work as described in more • Delivering downlink messages, including OTA updates,
detail in [Section 3]. to Machines via Gateways;

5
 • Providing delivery confirmations to ensure transport trans- we can obtain cryptographic proof of the approximate loca-
actions are honest; tion and time of events occurring within the Helium network.
• Providing authentication and routing mechanisms to third-
party cloud services such as Google Cloud Platform or 3.1 Motivation
Microsoft Azure; and
Most existing blockchain networks such as Bitcoin [9] and
• Storing and making available a full copy of the blockchain Ethereum [5] use a Proof-of-Work system that relies on an
ledger by acting as a full node [Section 5.5] algorithmic puzzle that is asymmetric in nature. These proofs
are extremely difficult to generate, but simple for a third
When a Gateway receives a data packet from a Machine on
party to verify. Security on these networks is achieved by
the Helium network, it queries the blockchain to determine
the network-wide consensus that the amount of computing
which Router to use given the Machine’s Helium network
power required to generate a valid proof is difficult to forge,
address. Anyone is free to host their own Router and define
and as subsequent blocks are added to the blockchain, the
their Machines’ traffic to be delivered there by any Gateway
cumulative difficulty of the chain becoming prohibitively
on the Helium network. This ability allows users of the
difficult to fabricate.
Helium network to create VPN-like functionality whereby
encrypted data is delivered only to a Router (or set of Routers) These computation-heavy proofs are, however, not otherwise
that they specify and can optionally host themselves. useful to blockhain networks. We define useful as work that
is valuable to a blockchain network beyond securing the
Routers can implement a system called a channel which han-
ledger. While there have been attempts in other networks to
dles the authentication and routing of data to a specific third
turn mining power into something useful, such as Ethereum
party Internet application, such as Google Cloud Platform
executing small programs called smart contracts, the majority
IoT Core. These channel implementations can take advan-
of the work is not useful or reusable. The mining process is
tage of a Machine’s onboard hardware security to create a
also extremely wasteful, as the determining factor in the work
secure, hardware-authenticated connection to a third party
is typically computational power, which consumes massive
which would otherwise be difficult to implement directly on
amounts of electricity and requires significant hardware to
an embedded microcontroller. We will make available an
execute.
open source reference implementation of a Channel that can
be used to build additional interfaces to Internet services. The proofs used in the Helium network must be resistant to
Sybil attacks in which dishonest Miners create pseudonymous
We will also host a high-availability cloud router for anyone
identities and use them to subvert the Helium network and
to use and also provides and maintains an open-source router
gain access to block rewards to which they should not be
that is available either as source code or a binary package for
entitled. This is a particularly difficult attack vector to manage
a variety of operating systems and distributions.
in a physical network like the Helium network. We must also
The protocol specification required for implementing a router be resistant to a new attack vector: alternate reality attacks,
is defined in the WHIP Wireless Specification document that which exist where a dishonest group of Miners are able to
will be made available by the Decentralized Machine Network simulate that wireless network coverage exists in the physical
Alliance. world when it in fact does not. An example of this would
be running the mining software on a single computer and
simulating GPS coordinates and RF networking.
3. Proof-of-Coverage and
We later propose the Helium Consensus Protocol [Section 6]
Proof-of-Serialization
that uses Proof-of-Coverage to both secure the blockchain and
provide an extremely useful service to the Helium network,
In the Helium network, Miners must prove that they are pro-
which provides wireless network coverage that Machines can
viding wireless network coverage that Machines are able to
use to send data to and from the Internet.
use to communicate with the Internet. Miners do this by com-
plying with the Proof-of-Coverage protocol which the Helium
network and other Miners audit and verify. We use a Proof-of- 3.2 Inspiration
Serialization to ensure that Miners are correctly representing
their time in relation to others on the network, and obtain Proof-of-Coverage is an innovative proof that allows Miners
cryptographic proof of dishonest behavior. Several compo- to prove that they are providing wireless network coverage
nents of the Helium network, such as Proof-of-Coverage, use W in a specific region to a challenger, C. Proof-of-Coverage
Proof-of-Serialization as a cryptographic “anchor” that root is an interactive protocol where a set of targets Tn assert that
those occurrences with a cryptographic time proof. With a W exists in a specific GPS location L and then convinces C
combination of Proof-of-Coverage and Proof-of-Serialization that Tn are in fact creating W and that said coverage must

6
have been created using the wireless RF network. Proof-of- 3. RF travels at the speed of light with (effectively) no
Coverage is the first such protocol that attempts to prove latency
the veracity of miners in a physical space, and then use it to
Our goal is to verify whether Miners in a physical region
achieve consensus on a blockchain network.
are acting honestly and creating wireless network coverage
With Proof-of-Coverage we aim to solve for the following: compatible with WHIP. To do this, a challenger C determin-
istically constructs a multi-layer data packet O which begins
• Prove that Miners are operating RF hardware and firmware
at an initial target, T1 , and is broadcast wirelessly to a set of
compatible with WHIP; sequential targets, Tn , each of which are only able to decrypt
• Prove that Miners are located in the geography they claim the outer-most layer of O if they were the intended recipient.
by having them communicate via RF; and Each target signs a receipt, Ks , delivers it to C, removes their
layer of O, and broadcasts it for the next target. Essentially
• Correctly identify which version of reality is correct when an “envelope of envelopes” only decipherable by the intended
there is a conflict recipient.
Proof-of-Coverage is inspired by the Guided Tour Protocol
(GTP) [13] which devises a system for denial of service
prevention by requiring a client c to make a request to a Challenger
(C )
variety of “tour guide” computers Gn in order to gain access
to a server s. The tour guides must be visited in a specific KT 1 KT KT L

order and a hash of data exchanged which reveals the location

of the next Gn in order. Only after every Gn has been visited
can c gain access to s. O O1 OT OL

Once c gets to the last stop of the tour, it submits evidence

of the first and last stop to s who is able to verify that the Target 1 Target Target L
(T1) (T ) (TL)
first and last stops of the tour are correct without needing to
contact Gn , and that c could only know the first and last stops Figure 2. Multi-Layer Data Packet Deconstruction
if it had completed the tour correctly.
While an extremely clever and innovative system, GTP 3.3.1 Selecting the Initial Target
is not directly suitable as a proof in the Helium network
as RF networking has limited range and therefore cannot We aim to deterministically locate a geographic reference tar-
communicate with peers anywhere on the Helium network. get, T , for the challenger, C. Both C and T are Miners in the
We aim to construct a proof loosely based on the ideas Helium network. T does not need to be geographically proxi-
presented in GTP, but applicable to our protocol. mate to C. To locate T , C initially seeds verifiable entropy, η,
into the selection process by signing the current block hash
We combine Proof-of-Coverage with Proof-of-Serialization— with its private key. Since the probabilities associated to each
a proof that allows Miners on the Helium network to achieve miner form a discrete probability distribution [Equation 1],
cryptographic time consensus among decentralized clients. C uses the probability associated to each eligible Miner to
We aim to achieve rough time synchronization in a secure locate T and applies the inverse cumulative distribution func-
way that does not depend on any particular time server, and in tion using a uniform random number generated via η. This
such a way that, if a time server does misbehave, then clients allows us to ensure that we always target potentially dishonest
end up with cryptographic proof of that behavior. Miners as they have a lower score, thus increasing their prob-
ability of being targeted by C. Given that a Miners score is
3.3 Constructing Proof-of-Coverage diminishing linearly over time [Section 3.3.4], it is necessary
to create this inverse relationship to give low-scoring Miners
With the Proof-of-Coverage protocol, we aim to construct a an opportunity to participate in the process and increase their
proof that takes advantage of the following characteristics score. This diminishing score also incentivizes all the partic-
of radio frequency (RF) communication that are unique and ipants to send receipts to C and broadcast the remainder of
different to Internet communication: O.
1. RF has limited physical propagation and, therefore, dis-
tance; 3.3.2 Constructing the multi-layer challenge

2. The strength of a received RF signal is inversely propor- Once T has been selected, C must construct a multi-layer
tional to the square of the distance from the transmitter; challenge, O. O is a data packet broadcast over the Helium
and network and received by geographically proximate targets Tn .

7
Geographically proximate is defined as within a radius of T , a
network value T radius . Each layer of O, Ol , consists of a three-
tuple of E (S, ψ, R), where E is a secure encryption function
using the Elliptic-Curve Diffie-Hellman (ECDH) derived
symmetric key, S is a nonce, ψ is the time to broadcast the
next layer of the challenge and R is the remainder of O T1
consisting of recursive three-tuples. The maximum number
of Ol is bounded by a network value, Omax . T2
T
The construction logic of O by C is as follows:
T3
1. A set of candidate nodes, Tn , are selected such that all
members of Tn are within a contiguous radio network that TL
also contains T ;
2. Two targets, T1 and TL , are selected by finding the highest
scoring targets in Tn furthest from T ;
3. A weighted graph, Tg , is constructed from Tn such O1=E(S1,ψ,R)
that members of Tg in radio range of each other are
connected
 by an edge weighted
 by the value of 1 −
score(Ta ) − score(Tb ) ;

4. The shortest path between T1 to T to TL is computed

using Dijkstra’s algorithm [10] using the edge weights
from the previous step;
5. An ephemeral public/private keypair Ek and E k-1 are
generated;
6. A layer Ol is created and added to O, and S is encrypted
with the combination of the public key of TL , retrieved
from the blockchain as TLk and E k-1 as an ECDH ex-
change to compute a shared secret, known only to both O
parties C and TL ; and Figure 3. Construction of O
7. The previous step repeats with additional layers added to
O until all TL → T1 have a layer Ol included in O 3. T records both the time of arrival β and the signal strength
υ of O;
The resulting O can be visually represented as depicted in
[Figure 3]. 4. If successful, T then creates signed receipt Ks , where
Ks = (S||β||υ) signed by the private key of T ;
3.3.3 Creating the Proof 5. T submits Ks to C via the Helium network, removes the
outer most layer, and wirelessly broadcasts the remainder
Once O has been constructed, it is delivered to T1 via the
O; and
Helium network and immediately broadcast by T1 via the
Helium network. WHIP is not a point-to-point system, so 6. These steps repeat for T1 ..T ..TL , with TL being the last
several Miners within proximity of T1 will hear O. In this target in the graph
example, only the specific target T will be able to decrypt E
and send a valid receipt back to the challenger, C. C expects to hear responses from Tg within a time threshold
λ, otherwise it considers the Proof-of-Coverage to have con-
We describe the approximate flow of Proof-of-Coverage cluded. Because C is the only party with complete knowledge
creation as follows: of O, upper bounds of the values for β and υ are assigned by
C which are used to verify that each layer of O was trans-
1. T1 receives O from C via the Helium network, decrypts
mitted approximately where and when it was expected. The
the outermost layer and immediately broadcasts it R via
upper bound for β is limited by the speed of light τ between
the Helium network;
Tn and Tn − 1. Thus we know that, subject to some slight
2. T hears O and attempts to decrypt the value of E by using delays from reflection or multipath, the packet should not
its private key where pk : Epk (S, ψ, R); arrive at Tg later than τ multiplied by the geographical dis-

8
  
tance D plus some small episilon value, υ = τ × D +  . Using the above we can now construct a staleness-factor, δ,
which would be used in determining the score of the Miner
For υ, because of the inverse-square law, we can calculate
M.
the maximum RSSI (Received Signal Strength Indication)
possible for a packet transmitted, µ, from Tg − 1 to Tg as
µ = D12 . Gateways that are closer than expected, or which

0 2
−(8.h )
 v0 = 0
02
are transmitting at a higher power to mask their location dis- δm = v 0 .(1 − min(0.25,v
h
v0 > 0
0) )
parity, are unlikely to get µ correct, given that they do not 
 0
know who the next layer of O is addressed to. v .(1 − 10.v 0 .h02 ) v0 < 0

Once TL has delivered receipt to C, or λ has elapsed, the The above conditions strictly adhere to the following princi-
Proof-of-Coverage is completed. The collection of signed ples:
receipts, Ks , constitute the Proof-of-Coverage that C will
submit to the Helium network. 1. A negative v indicates that the Miner is consistently failing
verification.
K L = (S L || β || υ)
2. If v = 0, then we do not have any trust information,
therefore, we use a steep parabolic curve for the decay
K T = (S T || β || υ) dependent on h0 .
3. If v > 0, then it implies that the Miner has been suc-
K 1 = (S 1 || β || υ) cessfully verified consistently, hence, we use an inverse
parabolic curve that crosses the Y axis at 1, where the
width of the parabola increases as a factor of v up to
Challenger Target 1 Target Target L
(C ) (T1) (T ) (TL)
0.25. This implies that the more positive verifications
[Section 3] the Miner has accrued, the slower its score
decays as a factor of h0 .
Figure 4. Proof-of-Coverage flow
4. Finally, if v < 0, then this is the inverse of the above case,
wherein, a Miner has consistently been failing verification.
3.3.4 Scoring Therefore, we use a similar parabola as above; however,
the width of the parabola decreases as a factor of v, leading
The score allocated to a Miner, and therefore the resulting to a higher score decay for the Miner as a factor of h0 .
score of the Proof-of-Coverage, is an integral part of the [Figure 5] shows the trends for each of the above functions.
Helium Consensus Protocol described in [Section 6]. When
Miners join the Helium network, they are assigned a score, 5
v0 < 0
4
φm . We consider any Miner with a score greater than φm to 3
2
be an honest miner. This score depreciates according to the 1
number of verifications the Miner has as well as the height 0
−1
since its last successful verification. As φm decreases the −2
−3
probability of the Miner M being the target for C increases, −4
v0 > 0
−5
such that the Helium network continually attempts to prove −6
δm

−7
that the lowest scoring Miners are acting honestly, and giving −8
Miners a reasonable chance to improve their scores. −9
−10
−11 v0 = 0
In order to achieve this behavior we define the following −12
−13
invariants: −14
−15
−16
M, Miner −17
v, number of successful verfications for M - −18
−19
number of failed verifications for M −20
0 0.13 0.25 0.38 0.5 0.63 0.75 0.88 1 1.13 1.25 1.38 1.5
h, height since the last successful verification for M 0
h
If we assume that the ideal verification interval for any Miner
Figure 5. Trendlines for the scoring functions
is close to 240 blocks (4 hours if we assume a 60 second block
time), we scale these invariants to fit the scoring functions:
Adhering to the above set of rules, we define the following
0 scoring function, which is essentially a variation of a sigmoid
v, v/10.0
h0 , h/480 curve fluctuating between values (0, 1):

9
 arctan(2.δm) + 1.58
φm =
3.16

This scoring function yields [Figure 6], which shows the

variation of the score with the staleness-factor:

0.8

0.6 Figure 8. Snapshot of a random subset of the network after

10000 iterations
φm

0.4
3.3.5 Target Selection

0.2
Due to the way scoring decays, there is a possibility that a
given Miners’ score may become stale as that Miner may
not be verified within a reasonable interval. We therefore
0
structure the target selection mechanism to give Miners a
−10 −5 0 5 10 statistically greater chance to increase their score by being
δm selected as a target as their score decays. This is accom-
plished by biasing the probability of Miners being selected
Figure 6. Scoring algorithm and the resulting staleness as potential targets based on their individual scores.
factor
Let the set of miners be defined as:
[Figure 7] shows a snapshot of a random subset of the Helium N = {m1 , m2 , m3 . . . mn | n > 1}
network at any blockchain height h. The Miners represent
random locations with an illustrated score, while the edges Let the set of miner scores be defined as:
are calculated using Dijkstra’s algorithm [10]. S = {φm , m ∈ N }

We assign the target selection probability to each miner in the

following way:
1 − φm
P (m) = n (1)
X
n− φm i
i=1

The above equation ensures that the Miner with the lowest
score is assigned the highest probability of being selected as
a potential target while the opposite holds for the Miner with
the highest score.
Figure 7. Snapshot of a random subset of the initial network Furthermore, it also asserts that the probabilities are inversely
proportional to the score of an individual Miner. This allows
After 10,000 iterations the Helium network appears as repre- us to successfully target potentially low scoring Miners and
sented in [Figure 8]. improve the overall balance of the scoring system.
The goal of this system is to ensure that the scoring algorithm Another valuable aspect of assigning the probability as shown
considers that some Miners may attempt to act dishonestly. above is that all the probabilities together form a discrete
However, because the calculated edge-weights (via Dijkstra’s probability distribution. A discrete probability distribution
algorithm) and the target selection mechanism ensure that we satisfies the following equation:
only boost the score of a Miner when it is being verified by
other high scoring Miners, we believe that the system will
X
P (M = i) = 1
favor legitimate Miners and deter dishonest ones. i

10
3.3.6 Verifying the Proof 3. M generates a nonce, R, which is a SHA512 hash of the
Proof-of-Coverage, which M has partially constructed;
Once TL has delivered Ks , or λ has elapsed, the Proof-
of-Coverage is considered complete. When C submits this 4. M then generates a salted hash commitment, K, called
proof, via a special type of transaction, all receipts Ks from the proof-kernel, where K = H (R||M1 ||M2 );
T1 ...TL are included in the transaction published to the 5. M sends K to M1 . M1 replies with T , a signed message
Helium network. As all the steps originally completed by including the current time T1 and K; and
C are deterministic in nature with verifiable and recreatable
randomness, it is simple for a verifying Miner, V , to recreate 6. M knows that the reply from M1 was not pre-generated
the original steps and verify that the proof is legitimate. because it includes the nonce R that M generated
Because M can not trust M1 , it will ask for another time
Verifying Miners in the consensus group [Section 6] who see
from M2 :
the proof transaction are able to verify the Proof-of-Coverage
by recreating the following steps: 1. For the second request, a new nonce R is generated using
T truncated to 512-bits, blinded by XOR’ing a randomly
1. The verifying Miner, V , reconstructs the set of Miners N ;
generated 512-bit number;
2. The random seed η can be verified by V to have been
2. M then generates a sub-proof-kernel, L = H (R||T ||K),
created at approximately the correct time by the private
and sends it to M2 ;
key of C;
3. M2 replies with U , a signed message including the current
3. V then selects T from N , as seeding with η will result in
time T2 and L; and
the same target selection;
4. U is now a proof artifact that shows that M desired and
4. The set of candidate Tn are reconstructed from which T1
then proved a serialization between M1 and M2
and TL are determined;
With only two servers, M can end up with proof that some-
5. Dijkstra’s algorithm is used to reconstruct the graph Tg ;
thing is wrong, but no idea of the correct time But with half
and
a dozen or more independent servers, M will end up with
6. The Ks receipts contained in BC are verified to have been chain of proof of any server’s misbehaviour, signed by several
signed by the private keys of T1 ..T ..TL others, and enough accurate replies to establish the correct
time, Tt .
Assuming these steps are completed successfully, the Proof-
of-Coverage is verified the score of C is adjusted appropri- K=H(R||M 1 ||M 2 ) L=H(R||T||K)
ately. K M L

3.4 Constructing Proof-of-Serialization

To achieve cryptographic time consensus among decentral-

ized clients, we implement a simplified form of Google’s M1 T U M2
Roughtime [12]. Roughtime is a protocol that aims to achieve
T=(T 1 ||K) U=(T 1 ||L)
rough time synchronization in a secure way that does not
depend on any particular time server, and in such a way that, Figure 9. Creating Proof-of-Serialization
if a time server does misbehave, clients end up with crypto-
graphic proof of that behavior. 3.4.2 Verifying the Proof
This section describes the construction of the Proof-of-
Serialization protocol. If we assume that the times from M1 and M2 are significantly
different, and the time from M2 is before M1 , then M has
proof of misbehaviour. The reply from M2 implicitly shows
3.4.1 Creating the Proof that it was created later because of the way that M constructed
the nonce. If the time from M2 is after M1 , then M can
We outline the approximate process to achieve cryptographi-
reverse the roles of M1 and M2 and repeat the process to
cally secure time as follows:
obtain, assuming steady clocks, a misordered proof as in the
1. To begin, a Miner M pseudo-randomly picks two Miners other case.
M1 and M2 , with whom to prove contact serialization;
To verify the correct time, it is necessary for M to repeat
2. It is assumed M has a public key for M1 and M2 , the time synchronization process with enough Miners to gain
otherwise M should obtain it from the blockchain; consensus on the correct time:

11
1. A Miner M again pseudo-randomly selects n Miners 4.1 Motivation
M1 ...Mn ;
Location tracking is one of the most valuable use cases for
2. M generates a salted hash commitment, K, and delivers low power Machines. It is expected that there will be at least
it to M1 , where K = H (R||M1 ||M2 ); 70 million asset tracking devices shipping by 2022 [14].
3. M1 again responds with T , a signed message containing Today, Global Navigation Satellite Systems (GNSS) are
the current time T1 and K; used by the majority of Machines which require geolocation
services, with GPS being the most popular implementation.
4. M generates a sub-proof-kernel, L = H (R||T ||K), and GPS systems use a technique called Time of Arrival (TOA)
sends it to the next Miner Mn ; to determine the location of a receiver in relation to 20 or
so satellites orbiting the earth. GPS satellites synchronize
5. The next Miner replies with U , a signed message includ-
their time using a high precision on-board clock and regular
ing the current time and L;
synchronization with control servers on the ground. GPS
6. These steps repeat through Mn until at least three time receivers receive precisely timestamped data from a number
responses, Tn , are monotonic; and of satellites overhead and use a technique called trilateration
to provide a precise location on earth.
7. Tn can then be confirmed to be Tt , the correct time
GPS has matured into an extraordinarily reliable service used
in a wide range of applications for providing both location
K and time services. However, there are significant drawbacks to
T M GPS particularly in the realm of low power Machines that the
Helium network is designed to facilitate. It can take around 2
L minutes for a GPS receiver to achiehve lock with sufficient
U satellites, which translates to drastically reduced battery life.
As an example, a Machine transmitting its location around
25 times a day may only last a month on a AA battery
M1 M2 Mn compared with several years of life on the same battery
without GPS. Using GPS indoors is generally impossible,
as the GPS receiver typically needs line of sight with the
Figure 10. Verifying Proof-of-Serialization
sky in order to see the 3-4 satellites required to calculate an
accurate location. GPS data is also delivered unencrypted,
which leaves the system extremely vulnerable to spoofing,
3.4.3 Utilizing the Proven Time jamming, and other attack vectors.

Once the correct time, Tt , has been determined via Proof- We are interested in low power implementations of location
of-Serialization, it is used by M and included during proof services that, in conjunction with an immutable distributed
construction as described in [Section 2.2]. The randomness, ledger, can be used to verify location and time. Given the
η, used to compute O and, thus, obtain the Proof-of-Coverage above factors, we conclude that GPS is an unacceptable
is tied to the previous block, which contains Tt . This allows mechanism for these requirements.
us to prove, with relative certainty, that some piece of data
D was created between the time of the previous block bt and 4.2 Constructing Proof-of-Location
Tt . D in this case is the Proof-of-Coverage. Thus, we know
that D must have been constructed between bt and Tt . This Our goal is to verify the physical geolocation of a given
ensures that the Proof-of-Coverage cannot be pre-computed. Machine, D, without using GNSS hardware. To do this, we
rely on the fact that we have already determined and proven
the physical geolocation and cryptographic time consensus
4. Proof-of-Location of a given Miner, M , using the Proof-of-Coverage and Proof-
of-Serialization protocols described in [Section 3].
Using Proof-of-Coverage and Proof-of-Serialization, we
achieve cryptographic proof of a Miners location and crypto- 4.2.1 Precise timestamping of RF data
graphic time consensus among Miners. We can take advan-
tage of these proofs to determine the physical geolocation There are a handful of techniques used by positioning systems
of WHIP-compatible Machines and generate a new type without the use of GNSS, which include Received Signal
of proof based on the Machines geolocations. We call this Strength Indication (RSSI), Time of Arrival (ToA), and
Proof-of-Location. Time Differential of Arrival (TDoA). These techniques use

12
radio frequency transmissions, usually received by one or record the timestamp. Typically, a Field Programmable Gate
more receivers, combined with various algorithms based on Array (FPGA) is used as the processor for this data as these
characterstics of those transmissions. types of processors are able to process data in a determinis-
tic way. However, FPGAs are fairly expensive, power hun-
Our conclusion is that TDoA is the most accurate but chal-
gry, and emit significant heat. Instead, our Gateway mining
lenging technique to implement [15], [16], [17], [18]. TDoA,
hardware uses a novel technique using commodity low-cost
in simple terms, relies on the variance between precisely
components to process I/Q data and achieve timestamping
synchronized and recorded timing information between a
at this level of precision. As a comparative example, an ex-
transmitter and several receivers. As such, it is critical to
isting low-cost LoRaWAN [23] access point is only capable
accurately timestamp RF packets Machines emit, and syn-
of providing timestamp data accurate within several millisec-
chronize the clocks of Miners on the Helium network.
onds of precision - as radio waves travel at the speed of light,
An example timestamping flow is as follows: each millisecond equates to approximately 300,000 meters
of physical distance, which we deem practically useless for
1. A Machine, D, broadcasts a packet P containing arbitrary
any accurate geolocation. Further information on the tech-
data via the Helium network;
niques, components and schematics used in our Gateway will
2. Several Miners, Mn , hear P , and record a timestamp Tn be released as open source software at launch of the Helium
of their reception time of P ; network.
3. Tn is created based on the nanosecond time received via
GNSS and stamped using raw radio sample data received 4.2.2 Using timestamps to derive location
by the Gateway radio frontend;
Now that the Machines Router, R, is in possession of a variety
4. A signed transaction including P and Tn are delivered to
of signed messages, which include the precise timestamps,
the router R belonging to D by Mn ; and
Tn , it is possible to solve for the location of the Machine D.
5. R has now received several copies of P , each of which A variety of TDoA algorithms exist such as [20], [21], [19]
has a slightly varying value of Tn and [22]. If a sufficient density of Mn and, therefore, Tn are
GPS/GNSS
recorded for a given packet, the location of D can be derived
down to a few meters depending on a variety of factors. We
encourage the interested reader to read the cited papers for
Gateway 1 Gateway 2 Gateway 3
further details on TDoA algorithms, as they are beyond the
scope of this whitepaper.

4.2.3 Verifying Proof-of-Location

Once R has computed a location of D, it may become nec-

t2
essary to verify that the reported location of D was accurate
at that given moment in time. As the Proof-of-Location is
t1
deterministic and derived from information publicly avail-
t3 able in the blockchain it is possible to reconstruct every step
involved:
• From the signatures contained within the timestamped
packets, Tn , every Miner involved in providing times-
tamps can be verified;
Device
• By inspecting the assert_location [Section 5.3.3]
Figure 11. Geolocation via TDoA transaction, the claimed GPS location of those Miners
can be determined; and
Typically, it is challenging to accurately record these times- • The Proofs-of-Coverage and scores [Section 3] for each
tamps as any nanosecond-level variance in the timestamp can Miner can be retrieved from the blockchain and inspected
lead to significant variance in the resulting location solution.
To achieve this level of precision it is necessary to use ex- By auditing the above steps the router operator can crypto-
tremely high-bandwidth raw in-phase and quadrature (I/Q) graphically prove (or disprove) the location of each of the
data from the Miner’s radio hardware and a fast enough pro- Miners involved in providing the components for Proof-of-
cessor to sample this data, identify an appropriate packet, and Location for a given Machine D.

13
The accuracy of the proof will depend heavily on the number potentially paying more for the transaction fees than the
of Mn involved and, therefore, Tn received. Additional RF value being exchanged. This is a similar problem to buying
factors, such as reflections and multipath, can significantly small-value items using credit cards today. The vendor
affect the accuracy of the location calculation. pays a minimum fee on each credit card transaction, and
under a certain charge they lose money on the transaction.
These heavyweight transactions are clearly not suitable
5. Transactions for use as a micro transaction system within the Helium
Transactions in the Helium network provide functionality that network.
enables address-to-address transfers of protocol tokens, simi-
lar to many existing blockchain networks, but also provide a Zero-fee Transactions While highly desirable from a ma-
set of primitives that enable core functionality that is critical chine perspective, a true zero-fee blockchain would be
to the operation of a DMN. We will first address Helium’s need fraught with spam transactions. It would be trivial to write
for microtransactions and propose a new solution. a script to pollute the blockchain with transactions meant
only to waste space on the blockchain and increase conges-
5.1 The Helium Nework’s Need for Microtransactions tion on the network. Some ostensibly zero-fee blockchain
implementations solve this issue in clever ways, such as of-
Machines Pay Per Packet The goal of the Helium network floading the work of processing and verifying transactions
is to offer Internet data transport fees (the fees paid by to the transactors themselves. However, these implementa-
Machines to Miners) that are an order of magnitude less tions have their own issues, for example IOTA [24] has not
than anything currently available for this type of service. yet proved it is capable of operating this type of system
This transport fee would need to be metered per-packet without the need for a centralized coordinator.
in order to allow for maximum flexibility — this way,
a Machine could transact with any Miner, even just to State Channels State channels [31] allow two parties to
send or receive a single packet without having previously exchange value, usually in small increments at a time,
established a relationship with that Miner. with very limited risk. If one party thinks the other is
All Transactions Occur On-Chain The Helium network is acting dishonestly, it can publish the final transaction in
built on the philosophy that all transactions should occur the state channel to the blockchain and close the channel.
on-chain; that is, blocks should be sized and mined with At most one payment is usually at risk. However, there
a frequency such that every transaction which occurs on are several downsides: the payer has to lock up significant
the Helium network should be stored in the blockchain. funds for the lifetime of the state channel, meaning they
To accomplish this goal, the cost of mining must be low, may be unable to open state channels with other parties
blocks must be large enough to encapsulate a large number or pay other dues; transactions in the state channel do not
of transactions, and blocks must be created frequently appear on the main chain at all; and these implementations
enough that transactions are processed quickly. are relatively complex to execute well (note that neither
Lightning [29] nor Raiden [30] have become widely used
Allow Machines to Persist Data to the Blockchain Because yet).
the Helium network services a specific use, the DMN,
blocks must additionally be able store fingerprints of data Payment in Arrear Payment in arrear, after the services
sent from Machines along with the transaction, which have been rendered, is an extremely risky method in
pays a Miner for its transport service. We believe that this a decentralized pseudo-anonymous system. There is no
holistic tamper-proof data trail will enable entirely new mechanism to gain certainty around the intent or honesty
use cases where the authenticity and veracity of sensor of the entities transacting, nor do you know if the entities
data is critical. control the requisite funds when the debt comes due. This
model only works when the parties involved trust each
5.2 Limitations of Existing Solutions other or have some other recourse to recover funds.
Now that we have discussed the requirements of transactions
within the Helium network, we outline the existing solutions
for micropayments on a blockchain and address their short- 5.3 Types of Fees in Helium
comings as they apply to the Helium network.
Heavyweight Transactions This first option is suitable only In this section we outline the types of fees needed on the
for larger transactions as the service fee is smaller than the Helium network, and propose solutions that take advantage of
payment. This method does not work well for very small the unique characteristics of the Helium Consensus Protocol
transactions as whoever pays the transaction fee ends up [Section 6].

14
5.3.1 Transport Fees network, we root them in reality. The Helium network’s
primary purpose is to facilitate a network of wireless Internet
Machines using the Helium network to send and receive data coverage. In order to accomplish this in the long term,
to and from the Internet must pay Miners what is known as a all of the economics of the system must align to make it
transport fee. This fee compensates the Miner for delivering practical for the primary users to transact on the Helium
data packets between the Machine and the intended router network. If one set of fees were to outstrip the others, then
on the Internet, and is unrelated to the transaction fee that the Helium network would quickly lose its utility for the key
Miners earn for mining transactions as part of blocks that are user segment.
recorded to the blockchain. The fee is negotiated between
the Router to which the Machine belongs, and the Miner, as To enable Miners and other light clients to determine an
Machines are not directly connected to the blockchain. appropriate fee, full nodes [Section 5.5] will expose a fee
suggestion API. This way resource constrained entities that
Miners set the price they are willing to accept to transport do not maintain a complete copy of the blockchain will not
data to and from the Internet on a per-byte basis. need to compute the fee from the most recent transactions.
A Machines router pays Miners the transport fee on trans- During the block submission process, Miners in the consensus
mission or reception of the data. This means that the Miner group [Section 6] will verify the correctness of the block
will receive the transport fee prior to the transaction being and ensure that no fee has deviated beyond the acceptable
mined in a block and recorded into the blockchain. This en- threshold of δ.
tails some risk for the Miner, as they must believe that the Due to the censorship-resilience built into the Helium Consen-
transport payment is not malicious or fraudulent prior to it sus Protocol [Section 6], there is no incentive to include larger
being confirmed in the blockchain. However, given how low transaction fees. Unlike Bitcoin, where miners cherry-pick
the per-byte transport amount is likely to be, this risk seems the transactions with the largest fees from their mempool to
tolerable. A Miner can blacklist a Machine or organization include in their blocks, Helium miners cannot see the contents
address if they continually abuse the system. of the transactions without collaborating with other members
An example transport fee process is as follows: of the consensus group to decrypt them. Transactions with
incorrect fees (either too high or low) will be rejected prior
1. A Miner, M , hears a packet, P , broadcast by Machine D; to the block being appended to the blockchain.
2. M uses the address of D, attached to P , to identify a
router, R, as the owner of D; 5.3.3 Staking Fees

3. M sends the signature, K(P ), of P and an offer of n The assert location transaction, mentioned below [Sec-
tokens for transport to R; tion 5.4], has a special type of fee calculation, a dynamic fee.
Because the Helium network reaches maximum usefulness
4. R receives K(P ) and the payment offer and determines
at a specific density of Gateways, we want the fees to incen-
if it accepts the packet for the offered price,
tivize the Helium network density to be as close to that ideal
5. Assuming R accepts the packet at the offered price, it as possible. To that end, the transaction fee for asserting a
constructs a transaction T of value n payable to M and location can be thought of as the y coordinate on a curve with
sends it to the Miner; and the formula:
4
y = (x − D) + F
6. Once M sees the transaction in the reply it delivers P to
R and submits T to the consensus group for inclusion in where D is the ideal Gateway density and F is the unit fee
the Helium network for a location transaction. A sample graph of this function
where D = 3 and F = 1 follows:
5.3.2 Transaction Fees As can be seen, Gateways near the ideal network density are
cheap to add, but establishing a new network or overpopu-
Transaction fees are an essential part of most blockchain
lating a network gets expensive very quickly. This serves to
implementations. They incentivize Miners to include a trans-
dis-incentivize Gateway deployments that are not beneficial
action in their draft block and ensure that spam transactions
to the network. In particular, Alternate Reality Attacks and
do not pollute the Helium network.
warehouses full of Miners become prohibitively expensive.
To determine the appropriate fee for a new transaction, the
Miners who have not asserted their location, and therefore
transactor will take the median of the past δ packet transport
not paid the staking fee, will not be considered for inclusion
fees, within some margin of error. Until δ packet transports
in the consensus group [Section 6].
have occured on the Helium network, the fee will be fixed
at a constant value α. By anchoring the transaction fee to Miners who move physical location will need to assert a new
the current fees being charged for transport on the Helium location, and pay the new staking fee.

15
 Property Description
80
payer address the address of the sender
payee address the address of the recipient
60 nonce a monotoically increasing integer
value an integer-based representation of the
tokens to send
Fee

40
signature the signature of the sender

20
5.5 Light Clients and Full Nodes

Until now, we have discussed how to deal with microtrans-

0
actions in a cost-effective way, however we have not yet
0 1 2 3 4 5 6 addressed how to deal with the inevitable continuously in-
Density
creasing size of the blockchain. One requirement for the
Figure 12. Staking fee vs Miner density Helium network is that all transactions occur on-chain. This
means that the size of the full blockchain will eventually grow
quite large. This is compounded by the fact that all Miners on
5.4 Primitives in The Helium Network the Helium network are Gateway devices, relatively limited
in computation power and storage space.
Having discussed the philosophy of our transaction system
and presented our approach to facilitating microtransactions We solve this constraint by allowing mining nodes to operate
on the Helium network, we now delineate the transaction as light clients on the blockchain, pruning old blocks and
primitives and their properties. transactions as needed and keeping only the latest ledger
values. They will communicate over the peer-to-peer network
add gateway Registers a new Gateway on the Helium net- with full nodes which maintain a complete history of the
work, adding it to an existing account that will be respon- blockchain to verify transactions.
sible for supplying its stake (required for mining) and will
This raises a question: who is responsible for operating full
receive mining rewards [Section 6] and fees earned by the
nodes, and what is their incentive to do so? Routers are
gateway
software-only applications with access to scalable, cloud-
based storage and will be required to operate full nodes in
Property Description order to fulfill their purpose. We will operate a set of hosted
gateway address the public key address of the gateway routers that will make it easy for developers to launch prod-
being added to the network ucts without needing to deploy their own router. However,
owner address the address of the owner account many enterprise developers, who are required to maintain a
signatures mutual signatures of the owner and higher standard of privacy, will want to host their own router.
Gateway Together, these routers will form a network of full nodes capa-
ble of supporting resource constrained Gateways and wallets
operating light clients.
assert location Asserts a Gateway’s location in the form of
geographic coordinates, requiring a dynamic stake 6. Helium Consensus Protocol
Instead of an extremely computationally expensive and power
Property Description
hungry Proof-of-Work, Miners generate Proofs-of-Coverage
gateway address the address asserting its location [Section 3]. In this section we present how these useful proofs
nonce a monotonically increasing integer can be used to create permissionless network consensus.
latitude the latitude of the Gateway
longitude the longitude of the Gateway 6.1 Motivation
altitude the altitude of the Gateway
signature the signature of the Gateway Many current generation blockchains rely on a computation-
ally difficult Proof-of-Work to protect the Helium network
against Sybil attacks, also known as Nakamoto Consensus.
payment Moves tokens from one account, the payer, to The fact that the Proof-of-Work is computationally expensive
another account, the payee, including the requisite fee. to create, but cheap to verify means that in order to propose

16
a new valid block to the Helium network there is evidence particular block being mined and is not otherwise useful
that a significant amount of computation has been expended. or reusable on the network. An ideal consensus system
Due to the fact that computation is limited by hardware cost, would contain work that is both useful and reusable to the
power cost, physical space and computational efficiency of network beyond simply securing the blockchain.
modern technology, Sybil attacks become impossible. How-
High confirmed transaction rate Our ideal consensus pro-
ever, this approach, while fundamental to the mainstream
tocol would be able to process a very high number of
adoption of blockchain technology, has several downsides.
transactions per second, and once a transaction is seen
Chief among the downsides is the power consumption; it is
in a block it would be considered confirmed. Many exist-
estimated that the Bitcoin network is consuming more power
ing blockchains require a lengthy settlement time while
than many small countries. Bitcoin’s Proof-of-Work is so
the network achieves consensus which is not ideal in a
wasteful it is now on the list of the top uses of electricity in
system like the Helium network, which may experience a
the world and whenever the value of Bitcoin goes up, so do
very high number of transactions and where waiting for a
the resources devoted to mining it.
transaction to settle is not tenable.
Related to the power problem is the mining pool problem.
Transactions are censor-resistant Ideally, Miners would
Many blockchains have mining pools where users band
not be able to censor or otherwise pick and choose trans-
together to, in parallel, mine a single block and listing the
actions prior to mining them. This would not only nullify
pool’s address as the party to get paid. The pool then shares
any attempts to nefariously censor transactions, but would
the block reward with the members of the pool. This ends
allow for otherwise unattractive transactions (such as
up defeating many of the advantages of decentralization as
fixed-fee transactions) to be included in the blockchain.
both Bitcoin and Ethereum have come to be dominated by
less than 10 mining pools each. These large pools effectively The remainder of this section lays out our construction of a
prevent independent parties from mining blocks on their own. consensus protocol with these design goals in mind that we
This means that the consensus protocol for these blockchains refer to as the Helium Consensus Protocol.
is effectively controlled by a very small number of mining
pools and risks becoming further centralized. 6.2 Helium Consensus Protocol
More recently there has been increased momentum around
making blockchain consensus protocols less wasteful and We propose a unique consensus protocol around Proof-of-
more useful to the network. Filecoin [25] has a Proof-of- Coverage to capture the useful work of verifying the Helium
Spacetime and Ethereum [5] is moving towards a Proof-of- network as a replacement for Proof-of-Work, combined with
Stake [26] approach. a variant of the HoneyBadgerBFT (HBFT) [4] asynchronous
byzantine fault tolerant protocol.
For the Helium network, we desire a consensus protocol with
the following attributes: 6.2.1 HBFT
Permissionless Nodes should be able to freely participate
HBFT is an asynchronous atomic broadcast protocol designed
in the Helium network without permission or approval
to achieve optimal asymptotic efficiency, initially presented
from any other entity, as long as those nodes operate in
in 2016. In HBFT, the setting assumes a network of N
accordance with the consensus rules.
designated nodes with distinct well-known identities (P0
Extremely decentralized in nature Network consensus should through P N-1 ). In our HCP instantiation, this network of
be designed such that there is no incentive available for nodes is known as the consensus group C. The consensus
taking advantage of macro-economic factors, such as group receives transactions as input, and its goal is to reach
cheaper access to electricity in certain geographies, and common agreement on an ordering of these transactions and
that simply buying more hardware in the same location form them into blocks to be added to the blockchain.
is either ineffective or cost prohibitive. Additionally, it
The protocol proceeds in rounds, where after each round, a
should be impossible for mining pools to form and for
new batch of transactions is appended to the blockchain. At
groups to collaborate in mining blocks.
the beginning of each round, the group chooses a subset of
Byzantine Fault Tolerant The protocol should be tolerant the transactions in its buffer and provides them as input to an
of Byzantine failures [27] such that consensus can still instance of a randomized agreement protocol. At the end of
be reached as long as a threshold of actors are acting the agreement protocol, the final set of transactions for this
honestly. round is chosen.
Based on useful work Achieving network consensus should HBFT relies on a threshold encryption scheme [28] that
be useful and reusable to the network. Work performed in requires transactions be encrypted using a sharded public
Nakamoto Consensus-based systems is only useful for the key, such that the consensus group must work together to

17
decrypt it. This means that no individual node is able to run the TPKE.DecShare(SKi , e) → σi function to produce
decrypt or censor a particular transaction without colluding their decryption share. Members broadcast their σi to the
with the majority of the group. other members of C, and once f + 1 members have seen σi
shares they can proceed to the TPKE.Dec function using PK,
6.2.2 Applying Proof-of-Coverage to HBFT e and the σi shares and attempt to decrypt the transaction.
Each member of C appends decrypted transactions to its own
In the Helium network, miners are required to submit Proofs- instantiation of the next block kept in a local buffer. Double-
of-Coverage to the Helium network at an epoch, ∆p . These spend and other malformed transactions are removed from
proofs are submitted as a special type of transaction, and these blocks at this stage.
subsequently recorded to the blockchain. As detailed in
As members of the group cannot decrypt e on their own,
[Section 3], Miners increase their scores as they submit valid
a given member cannot censor a transaction prior to its
proofs to the Helium network. At an epoch, ∆c , the highest
inclusion in the candidate block without f + 1 members of C
scoring Miners, N , are elected as the new HBFT consensus
colluding as transactions are received. Any honest member
group, C.
of C that has t in the first B of its transaction queue will
By using Proof-of-Coverage to elect the members of C we eventually be able to include t in a block as the other members
are essentially substituting for well-known identities in the of C cannot decrypt the transaction until it has been agreed
HBFT protocol. As we desire a permissionless network, we to, at which point it is too late to censor it. As the members
can use Proofs-of-Coverage to determine whether Miners are of C for a ∆c epoch are selected based on their submitted
acting honestly and reward the most honest Miners at a given Proofs-of-Coverage, making the members unpredictable, this
epoch by electing them to the HBFT consensus group. type of collusion would be extremely challenging to execute.
Once f + 1 nodes have agreed on the transactions for the
6.2.3 The consensus group block, a TPKE threshold signature is obtained over the block.
This certifies that enough nodes to exceed the byzantine fault
During ∆c , the currently elected consensus group is responsi- threshold have agreed on a block. Members of C that are
ble for creating blocks and appending them to the blockchain. censoring or disagreeing on the contents of the block will
All new transactions on the Helium network are submitted produce an incompatible signature share that cannot be used
to the current members of the consensus group. New blocks to count towards the signature threshold. This block is then
are created by C at a fixed interval ∆b and recorded to the gossiped via the Helium network to all Miners and added to
blockchain. A token block reward is split among the members the blockchain.
of C for every block submitted, along with the sum of all
fees contained within valid transactions. In the unusual case C
that there are no transactions during ∆b , an empty block is
appended to the blockchain. σi σi
B
N N N

6.2.4 The mining process

B
Once the consensus group C has been elected for a given ∆c
epoch, a distributed key generation phase occurs to bootstrap
a threshold encryption key TPKE. TPKE is a cryptographic B
e
primitive that allows any party to encrypt a transaction to
a master public key PK, such that C must work together to
decrypt it. Once f + 11 correct members of C compute and B
reveal decryption shares, σi , the transaction can be recovered.
Once PK is generated via the TPKE.Setup function, a block
containing PK is immediately submitted to the blockchain. M B
Each member Nm in C receives a secret key share, SKi , of
PK. Figure 13. The Consensus Group and Mining
Miners on the Helium network submit new transactions t
to C. Each member of C takes a random subset of the first 6.2.5 Conclusion
B transactions in its queue and applies the TPKE.Enc(PK,
t) → e function and submits them to the other member of We have presented the Helium Consensus Protocol which
C. Once the members of C receive at least N − f e they combines a modern, asynchronous and highly efficient byzan-
tine fault tolerant consensus protocol with a novel mecha-
1f is a protocol parameter equal to the number of tolerable byzantine faults nism for substituting permissioned identity with a useful and

18
reusable Proof-of-Coverage. The resultant protocol satisfies and direction was critical to some of the design decisions and
the design requirements of being permissionless, decentral- evolution of this project. We also thank the Blockchain at
ized, byzantine fault tolerant, based on useful work, and with Berkeley team for their help and detailed review of this work.
a very high-rate censor proof transaction mechanism.
We would also like to acknowledge many of the prior works
We refer the interested reader to [4] for a detailed breakdown and inventions that have allowed us to create this project,
and analysis of the HoneyBadgerBFT protocol. most notably Bitcoin [9] and Ethereum [5].

7. Future Work
This paper presents a well thought-out design for building
the Helium network. However, we consider this to be just
the beginning of the engineering, research and design of
decentralized wireless networks. We believe that this tight
integration of real-world hardware with a blockchain and
a native token is a novel and valuable innovation that can
be applied to other kinds of networks and wireless physical
layers. We believe that the future of blockchains is not about
who has the most hashing power or access to the cheapest
electricity, but about blockchains where the mining proof is
tied to providing a valuable, verifiable service.
There are several initiatives that we either have or intend to
undertake, including:
• Investigate the applicability of applying these ideas to
other physical layers such as WiFi, Bluetooth and Cellular
• Explore the potential for the delivery of 5G 60GHz+
mmWave connectivity through a similar design
• Research and implement more Proofs-of-Coverage to
keep the Helium network secure as it grows
• Game theoretical analysis of the incentive system

• Formally prove the scoring algorithm used in the Proof-

of-Coverage
• Create and release the WHIP wireless specification

• Manufacture Gateways and Machine modules for avail-

ability at launch of the Helium network
• Investigate the deployment of a smart contract environ-
ment beyond the basic DMN primitives
• Continued work and evolution of Forward Error Correc-
tion techniques

Acknowledgments
This document is the result of collaborative work by members
of our team, and would not have been possible without the
help, feedback, and review of our board of directors, advisors,
investors and collaborators. We extend our most heartfelt
thanks to all involved.
We would also like to extend our thanks to Jeremy Rubin of
the MIT Digital Currency Initiative. Your earliest feedback

19
References [21] Peter W. Boettcher, Gary A. Shaw. A Distributed Time-
Difference of Arrival Algorithm for Acoustic Bearing
[1] Marcus Torchia, Monika Kumar. IDC - Worldwide Semiannual Estimation 4.2.2
Internet of Things Spending Guide, 2017 (document) [22] Shuai He, Xiaodai Dong, Wu-Sheng Lu. Asynchronous Time
[2] Shawn Fanning. Napster - independent peer-to-peer file Difference of Arrival Positioning System, 2015 4.2.2
sharing, 1999 1 [23] LoRa Alliance. LoRaWAN - LoRa Alliance Technology, 2014
[3] Mehmet Adalier. Efficient and Secure Elliptic Curve 4.2.1
Cryptography Implementation of Curve P-256 2.6 [24] David Snsteb, Sergey Ivancheglo, Dominik Schiener, and
[4] Andrew Miller and Yu Xia and Kyle Croman and Elaine Shi Serguei Popov. IOTA - Next Generation Blockchain, 2015 5.2
and Dawn Song. The Honey Badger of BFT Protocols, 2016 [25] Protocol Labs. Filecoin - A decentralized storage network,
2.2, 6.2, 6.2.5 2017 6.1
[5] Vitalik Buterin. Ethereum, 2014 3.1, 6.1, 7 [26] Wikipedia. Proof-of-Stake 6.1
[6] LoRa Alliance. LoRa Alliance - Wide Area Networks for IoT, [27] K Driscoll, B Hall, M Paulitsch, P Zumsteg, H Sivencrona.
2013 2.4.1 The Real Byzantine Generals, 2004 6.1
[7] Ingenu. RPMA Technology 2.4.1 [28] Joonsang Baek, Yuliang Zheng. Simple and Efficient Threshold
Cryptosystem from the Gap Diffie-Hellman Group, 2003 6.2.1
[8] IEEE. IEEE Standard for Low-Rate Wireless Networks, 2015
2.4.1 [29] Joseph Poon, Thaddeus Dryja. Lightning Network - Scalable,
Instant Bitcoin/Blockchain Transactions, 2017 5.2
[9] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash
system, 2008 3.1, 7 [30] brainbot. The Raiden Network - Fast, cheap, scalable token
transfers for Ethereum, 2017 5.2
[10] E. W. Dijkstra. A note on two problems in connection with
graphs, 1959 4, 3.3.4 [31] Jeff Coleman. State Channels, 2015 5.2

[11] David Karger, Eric Lehman, Tom Leighton, Matthew Levine,

Daniel Lewin, Rina Panigrahy. Consistent Hashing and
Random Trees: Distributed Caching Protocols for Relieving
Hot Spots on the World Wide Web, 1997
[12] Adam Langley, Google. Roughtime - a project that aims to
provide secure time synchronisation 3.4
[13] Mehmud Abliz, Taieb Znati. A Guided Tour Puzzle for Denial
of Service Prevention, 2009 3.2
[14] Mobile Experts Asset Tracking IoT Devices, 2017 4.1
[15] Guofang Dong, Bin Yang. TDOA-Based and RSSI-Based
Underground Wireless Positioning Methods and Performance
Analysis 4.2.1
[16] Mohamed Laaraiedh, Lei Yu, Stephane Avrillon. Comparison
of Hybrid Localization Schemes using RSSI, TOA, and TDOA,
2011 4.2.1
[17] Mohamad Yassin, Elias Rachid, Rony Nasrallah. Performance
Comparison of Positioning Techniques in Wi-Fi Networks,
2014 4.2.1
[18] Muhammad Farooq-i-Azam, Muhammad Naeem Ayyaz.
Location and Position Estimation in Wireless Sensor Networks,
2016 4.2.1
[19] Sangdeok Kim, Jong-Wha Chong. An Efficient TDOA-Based
Localization Algorithm without Synchronization between Base
Stations, 2015 4.2.2
[20] Igor Olegovych Tovkach, Serhii Yakovych Zhuk. Recurrent
Algorithm for TDOA Localization in Sensor Networks, 2017
4.2.2

20