Packet Purchasing

A trustless and decentralized way to allow coverage providers and coverage users to exchange value is core to the Helium Network.

Packet purchasing is implemented on the Helium Blockchain with two specific primitives:

  • Organizationally Unique Identifiers
  • State Channels

Organizationally Unique Identifier

Organizationally Unique Identifiers (OUIs) are registered identities on the Helium Blockchain. To send and receive packets to an end-device, a network user needs to be serviced an OUI. This can be their own OUI or one operated by a third party, such as Console operated by Helium, Inc.

An OUI has some specificities related to LoRaWAN and packet routing, documented here, but with respect to the blockchain, what's important is that only libp2p addresses registered as endpoints for the OUI may open and close state channels on behalf of an OUI.

For example, this account purchased the first OUI on the Helium Blockchain. The address 112qB3YaH5bZkCnKA5uRH7tBtGNv2Y5B4smv1jsmvGUzgKT71QpE operates the OUI on behalf of the owner. You can monitor its activity here.

OUIs are purchased (see current fee schedule) and numbered in incrementing order. You can query the API for a list of existing OUIs using the following endpoint.

State Channels

State channels are side-chains opened by OUI operators (any of the libp2p addresses registered to the OUI). With an state_channel_open transaction, the operator stakes two times the amount of Data Credits (DC) available to be spent in the channel. In addition, the amount of blocks until channel expiration is configured.

Once a state channel is opened, hotspots and OUIs operators are able to transact within the channel. Generally, the flow is as follows:

  • a packet is offered by a hotspot to the OUI operator, with some metadata but without the actual payload
  • the OUI operator decides whether to purchase the packet; if it decides to purchase, the offer is signed
  • the packet is delivered by the hotspot to the OUI operator

These signed offers are added to the state channel "banner", which allows the device to confirm that it is being given credit for its work during the lifetime of the state channel. This is possible even as many other hotspots have their own transactions added to the same banner.

Sometime before the expiration block, the OUI operator will submit a state_channel_close transaction channel, a transaction which also explicits how many data credits are being burned in the name of which hotspots. Should a hotspot not be credited the appropriate amount, it has recourse during a "grace period" the ten blocks after the closure to file a dispute, using the signed offers as evidence. This is done in the form of alternate state channel close transactions.

If there is no overspend or disputes, the second half of the stake and any remaining credit is returned to the OUI operator. Otherwise, the entire stake is kept and, in the event of a dispute, the appropriate amount of data credit burns are attributed to the hotspots with valid disputes.

Should the operator neglect to close the state channel before the expiration block, closes by all parties are still accepted during the ten block grace period. Should the OUI operator still neglect to close the channel, they will lose their whole stake.