![]({useBaseUrl("img/blockchain/primitives.png")})
-
-# Helium Blockchain Primitives
-
-Below are some of the larger components and concepts of the Helium blockchain.
-
-### Blocks
-
-Blocks are used to record the most recent set of transactions in the Helium
-blockchain. Blocks are mined based on time, as defined in the `block_time` chain
-variable. The current target block time is `60000` milliseconds (or 60 seconds).
-During any given epoch, the most recent block consists of:
-
-- Block Version
-- Block Height
-- Previous Block Hash
-- Transactions (stored as a Merkle hash)
-- Threshold signature from the current consensus group
-
-The easiest way to see the blocks being mined is with the
-[Helium Blockchain Explorer](https://explorer.helium.com/). The
-[Helium Mobile App](https://helium.com/app) also shows block details. Developers
-can also use the Helium blockchain API to access all blockchain transactions and
-metadata.
-
-### Epochs
-
-An `epoch` is the target time period for which a given group of Validators is
-elected to serve as the consensus group. The target time for an epoch is
-currently `30 blocks`, as defined in the `election_interval` chain variable.
-Approximately every 30 blocks mined marks the passing of an epoch, after which a
-new group of Validators is elected to form the next consensus group. Mining rewards
-are distributed per epoch (as opposed to per block in most blockchain-based
-systems). At the conclusion of each epoch, the consensus group will distribute
-all the $HNT produced in that block via the `rewards` transaction.
-
-### Transactions
-
-The Helium blockchain currently has 36 native transaction types. Some appear in
-nearly every block mined while others were created to be used only once and will
-never be heard from again.
-
-You can see various transaction types in action using the
-[Helium Blockchain Explorer](https://explorer.helium.com/). At a low level,
-transactions are represented as
-[Protocol Buffers](https://developers.google.com/protocol-buffers), aka
-"protobuf". To sign a transaction, other signature fields (if present) are
-cleared and the serialized protobuf is signed by the actor.
-[The protobuf definitions are available here](https://github.com/helium/proto).
-
-All transactions occur on-chain, and all transactions require Helium Data
-Credits to be submitted and confirmed. The following is a list of the supported
-transactions:
-
-- `add gateway` - Add a new gateway to the Helium Network. For the purposes of
- transactions, a “gateway” is the term for a Helium-compliant Miner that is
- mining and providing coverage.
-- `assert location` - Assert a gateway’s location on the Helium Network. This
- happens after a gateway has been added via the add gateway transaction. Once
- asserted, this location is then used as part of Proof of Coverage challenges.
- A Miner’s location can be asserted more than once but each subsequent
- assertion will a) cost a fee and b) reset that Miner’s score to neutral (.15)
-- `chain vars` - Change a chain variable.
-- `coinbase` - Similar to the bitcoin blockchain’s coinbase transaction but used
- only during testnet phases of the Helium blockchain. The `rewards` transaction
- has taken its place.
-- `coinbase data credits` - Created the initial 10,000 Data Credits required to
- bring the first group of Miners online.
-- `consensus group` - Marks the election of a new consensus group, responsible
- for mining during the next epoch.
-- `create hashed timelock` - Creates a transaction that can only be redeemed by
- providing the correct pre-image to the hashlock within the specified timelock.
-- `create proof of coverage request` - Submitted by a Miner wishing to initiate
- a challenge.
-- `data credits` - Burn HNT for DCs at the current oracle price and deliver them
- to the target wallet address.
-- `genesis gateway` - Used to define the initial group of Miners that
- bootstrapped the blockchain.
-- `multi-payment` - Used to send $HNT from one wallet to multiple wallets.
-- `OUI` - Create a OUI for a new router on the Helium network. In the Helium
- blockchain, Miners forward packets to Routers that own them based on their OUI
- as stored in the blockchain.
-- `payment` - Used to send $HNT from one wallet to another.
-- `proof of coverage receipts` - The result of a POC submitted to the network
- upon completion.
-- `redeem hashed timelock` - Redeem the transaction created using the create
- hashed timelock transaction.
-- `reward` - A token payout for a specific event on the network such as
- submitting a valid proof of coverage request, participating in a consensus
- group, etc.
-- `rewards` - Bundles multiple reward transactions at the end of each epoch and
- distributes all $HNT produced in that block to wallets that have earned them.
-- `routing` - Update the routing information associated with an OUI.
-- `security coinbase` - Distribution of security tokens in the genesis block.
-- `security exchange` - The transfer of security tokens from one address to
- another.
-- `state channel open` - Opens a new state channel on a Helium Router
-- `state channel close` - Closes a specific state channel on a Helium Router
-- `token burn exchange rate` - Change the exchange rate for burning $HNT to DCs.
-- `stake validator` - Stake a new Validator on the Helium Network.
-- `transfer validator` - Transfer a staked Validator to a new owner or a new Validator.
-- `unstake validator` - Unstake a previously staked Validator.
-
-**Extended Reading on Transactions**
-
-- [Helium Blockchain Core on GitHub](https://github.com/helium/blockchain-core)
-- [Transaction protobuf definitions on GitHub](https://github.com/helium/proto)
-
-### Chain Variables
-
-Chain Variables, often referred to as `chain vars`, are a series of
-configuration settings for the Helium blockchain. Chain Variables can be used to
-change things like target block time, target epoch time, the minimum number of
-targets in a POC Challenge, and much more. Chain Variables can be altered by
-submitting a transaction containing the chain variable to be changed, its new
-value, and a signature of the chain variable master key.
-
-A full list of chain vars and their current values
-[can be found here](https://helium.plus/chain-vars).
-
-### Accounts, Wallets, and Keys
-
-The Helium blockchain uses an account-based system for wallets and balances
-(similar to Ethereum and others) as opposed to a UTXO-based ledger like Bitcoin
-blockchain. Users have several options for creating Helium wallets and managing
-their private keys:
-
-- If you’re using the [Helium Mobile Wallet](https://helium.com/app) (iOS,
- Android), your private key is encrypted locally (and can be recreated on
- another mobile device using the 12 word passphrase generated when your wallet
- was first created);
-- Using the [Helium CLI Wallet](https://github.com/helium/helium-wallet-rs),
- users are responsible for creating, storing, and securing a wallet’s private
- key and associated passphrase;
-
-Both the Helium Mobile Wallet and the CLI Wallet create and use keys based on
-the [ed25519 public key signature system](https://ed25519.cr.yp.to/). The CLI
-can also support NIST p-256 keys. And the Helium blockchain supports both key
-types.
-
-To learn more about existing wallet solutions, check out our
-[section on wallets](/wallets).
-
-### Validators
-
-Introduced in [HIP25](https://github.com/helium/HIP/blob/master/0025-validators.md), and officially [deployed to Mainnet on July 7, 2021](https://dewialliance.medium.com/validators-are-live-on-the-helium-network-fcf549a5e182), Validators are cloud-based nodes responsible
-for processing blocks and managing the blockchain consensus group. In return for securing the blockchain, Validators earn the 6% of HNT allocated
-to the consensus group reward. To operate a Validator, one must stake 10,000 HNT.
-
-* [Validators on the Helium Blockchain Explorer](https://explorer.helium.com/validators)
-* [Deploy a Validator](/mine-hnt/validators)
-
-
-
diff --git a/docs/blockchain/blockchain.mdx b/docs/blockchain/blockchain.mdx
deleted file mode 100644
index 21efa3fae..000000000
--- a/docs/blockchain/blockchain.mdx
+++ /dev/null
@@ -1,53 +0,0 @@
----
-id: blockchain
-hide_title: true
-sidebar_label: Introduction
-slug: /blockchain
-hide_table_of_contents: true
----
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-
-
-
-
-
-
-
-
-
- ![]({useBaseUrl("img/blockchain/blockchainicon.png")})
-
-
-
-
- The Helium Blockchain
-The Helium Blockchain is a new blockchain built from the ground up to incentivize the creation of decentralized, public wireless networks.
- -
-
-
diff --git a/docs/blockchain/consensus-protocol/consensus-protocol.mdx b/docs/blockchain/consensus-protocol/consensus-protocol.mdx
deleted file mode 100644
index 4743a5fbf..000000000
--- a/docs/blockchain/consensus-protocol/consensus-protocol.mdx
+++ /dev/null
@@ -1,91 +0,0 @@
----
-id: consensus-protocol
-hide_title: true
-sidebar_label: Consensus Protocol
-slug: /blockchain/consensus-protocol
----
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-
-
-
-
- Introduction
-
-
- The Helium Blockchain is based on a new, novel work algorithm called Proof of Coverage (PoC), and rewards miners in $HNT, the native token of the Helium blockchain. Officially launched on July 29, 2019, the Helium Blockchain powers the largest, public, decentralized LoRaWAN Network in the world.
-If you are a developer and interested in contributing, or simply just interested in learning more, join us in the #blockchain-development channel on our Discord.
-
- ![]({useBaseUrl("img/icons/docicon.svg")})
Blockchain Primitives
- Mining and Rewards
- Proof of Coverage
- Packet Purchasing
- Consensus Protocol
- The Helium Token ($HNT)
- Oracles
- Transaction Fees
-
- Quick Links
- Blockchain Primitives
- Mining and Rewards
- Proof of Coverage
- Packet Purchasing
- Consensus Protocol
- The Helium Token ($HNT)
- Oracles
- Transaction Fees
- ![]({useBaseUrl("img/blockchain/consensus.png")})
-
-# The Helium Consensus Protocol
-
-The Helium blockchain uses a new consensus protocol, called simply the **Helium
-Consensus Protocol**.
-
-## Consensus Protocol Design Goals
-
-In designing the protocol, we wanted to emphasize the following characteristics:
-
-- **Permissionless** - Any Hotspot operating in accordance with the consensus
- rules and network specifications should be able to participate freely in the
- Helium Network.
-- **Truly decentralized by design** - No incentive should be available for
- taking advantage of factors like inexpensive energy cost or deploying more
- hardware in the same location.
-- **Byzantine Fault Tolerant** - The protocol should be tolerant of Byzantine
- failures such that consensus can still be reached as long as a threshold of
- participants are acting honestly. For this, we selected a variant known as
- `HoneyBadgerBFT` detailed below.
-- **Based on useful work** - Achieving network consensus should be useful and
- reusable to the network. In Nakamoto Consensus-based systems like the bitcoin
- blockchain, work performed to achieve consensus is only valid for a specific
- block. By comparison, Helium’s consensus system should perform work that is
- both useful and reusable to the network beyond simply securing the blockchain.
-- **High rate of confirmed transactions** - The protocol should be able to
- achieve a high number of transactions per second, and once the transaction is
- seen by the blockchain it should be assumed confirmed. Users sending device
- data through the Helium Network cannot tolerate long block settlement times
- typical of other blockchains.
-- **Censorship-resistant transactions** - Hotspots should not be able to censor or
- otherwise select / deselect transactions to be included in a block.
-
-## HoneyBadger BFT
-
-The Helium Consensus Protocol is based on a variant of the HoneyBadgerBFT
-(HBBFT) protocol. HBBFT is based on a body of research originally kicked off by
-Andrew Miller and the team at the University of Illinois, Urbana-Champaign.
-
-HBBFT is an asynchronous atomic broadcast protocol designed to enable a group of
-known nodes to achieve consensus over unreliable links. In Helium’s
-implementation, a consensus group of [elected Validators](https://explorer-beta.helium.com/validators) receives encrypted
-transactions as inputs and proceeds to reach common agreement on the ordering of
-these transactions before forming a block and adding it to the blockchain.
-
-HBBFT relies on a scheme known as threshold encryption. Using this scheme,
-transactions are encrypted using a shared public key, and are only decryptable
-when the elected consensus group works together to decrypt them. The usage of
-threshold encryption enables the Helium Consensus Protocol to achieve
-censorship-resistant transactions.
-
-### Extended Reading
-
-- [HoneyBadger BFT (PDF)](https://eprint.iacr.org/2016/199.pdf)
-- [Introducing the Helium blockchain](https://blog.helium.com/introducing-the-helium-blockchain-dc2f8997083c)
-
-## The Consensus Group Election
-
-A new Consensus Group \(CG\) is elected once per epoch. Currently there are `40` members elected to each consensus group, as defined in the `num_consensus_members` chain variable.
-
-:::info
-
-For a more complete overview of how Validators are elected to the consensus group, see the [Election Process Documentation](/mine-hnt/validators/penalties/#the-election-process)
-
-:::
-
-
-## Rewarding Hotspots
-
-At the end of each epoch, mining rewards are distributed by the consensus group to the wallet addresses that have earned them. Currently `65%` of all mining rewards go to the hotspot infrastructure \(with the remaining `35%` being distributed to Helium, Inc and other network investors\). A graphical overview of token reward system can be [viewed here](https://www.helium.com/tokens).
-
-During the course of any epoch, Hotspots are rewarded for the following list of activities:
-
-* Submitting valid proof of coverage challenges \(as a “challenger”\)
-* Successful participation in proof of coverage as a target \(as a “challengee”\)
-* Witnessing a proof of coverage challenge
-* Transferring device data over the network
-* Serving as consensus group member
-
-The Consensus Group then splits `6%` of all HNT mined, as well as any transaction fees collected during the epoch.
-
-Each one of the above activities is recorded in a block using the `reward` transaction. At the completion of each epoch, all the individual `reward` transactions are grouped in a `rewards` transaction at which point all $HNT mined in that epoch are distributed.
\ No newline at end of file
diff --git a/docs/blockchain/helium-token/helium-token.mdx b/docs/blockchain/helium-token/helium-token.mdx
deleted file mode 100644
index 6426308fe..000000000
--- a/docs/blockchain/helium-token/helium-token.mdx
+++ /dev/null
@@ -1,196 +0,0 @@
----
-id: helium-token
-hide_title: true
-sidebar_label: Helium Token
-slug: /blockchain/helium-token
----
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-![]({useBaseUrl("img/blockchain/heliumtoken.png")})
-
-# The Helium Token
-
-The Helium Token is the native cryptocurrency and protocol token of the Helium
-blockchain. Its symbol is `HNT`. Prior to the launch of the Helium blockchain, there was no premine of `HNT`.
-The first `HNT` was produced on July 29th, 2019 [as part of the block 93](https://explorer.helium.com/txns/sEP-cbb2tvSrfbBleT21yGDNM8FIjNr3UT3k3BeZELw).
-
-
-:::info
-For statistics on HNT, [see the Market section on the Helium Explorer](https://explorer.helium.com/market).
-:::
-
-## Helium Token Usage
-
-The Helium Token is designed to serve the needs of the two primary parties in
-the Helium blockchain ecosystem:
-
-1. **Hotspot Hosts and Network Operators**. Hosts
- [mine HNT](/blockchain/mining) while deploying and maintaining network
- coverage.
-2. **Enterprises and developers using the Helium Network** to connect devices
- and build IoT applications. Data Credits, which are a $USD-pegged utility token
- derived from HNT in a burn transaction,
- [are used to pay transaction fees](/blockchain/transaction-fees) for wireless
- data transmissions on the network (in addition to things like adding Hotspots
- and sending).
-
-## HNT Token Economic Concepts
-
-The Helium blockchain uses three distinct token economic concepts to ensure HNT
-supply is both plentiful for network needs but also relatively scarce, with a
-known maximum. Let's take a look at them in some detail.
-
-### Max Supply
-
-At launch [genesis block](https://explorer.helium.com/blocks/1), the
-Helium Network targeted `5,000,000` HNT per month. And since the
-[community approval of HIP 20](https://github.com/helium/HIP/issues/73), the
-Helium blockchain uses a two year halving schedule, with a maximum supply of
-`223,000,000` HNT.
-
-HNT halving happens every two years from the genesis block, on the following
-schedule.
-
-:::info
-In the below issuance schedule, year 1 starts on **August 1, 2019**. The first halving happened
-on approximately day one of the beginning of year three, **August 1, 2021**. The network is
-now producing `2,500,000` HNT until the next scheduled halving.
-:::
-
-| Year | HNT at start of year | Total HNT Minted |
-| :--- | :------------------- | :--------------- |
-| 1 | 0 | 60,000,000.0 |
-| 2 | 60,000,000 | 60,000,000.0 |
-| 3 | 120,000,000 | 30,000,000.0 |
-| 4 | 150,000,000 | 30,000,000.0 |
-| 5 | 180,000,000 | 15,000,000.0 |
-| 6 | 195,000,000 | 15,000,000.0 |
-| 7 | 210,000,000 | 7,500,000.0 |
-| 8 | 217,500,000 | 7,500,000.0 |
-| 9 | 225,000,000 | 3,750,000.0 |
-| 10 | 228,750,000 | 3,750,000.0 |
-| 11 | 232,500,000 | 1,875,000.0 |
-| 12 | 234,375,000 | 1,875,000.0 |
-| 13 | 236,250,000 | 937,500.0 |
-| 14 | 237,187,500 | 937,500.0 |
-| 15 | 238,125,000 | 468,750.0 |
-| 16 | 238,593,750 | 468,750.0 |
-| 17 | 239,062,500 | 234,375.0 |
-| 18 | 239,296,875 | 234,375.0 |
-| 19 | 239,531,250 | 117,187.5 |
-| 20 | 239,648,438 | 117,187.5 |
-| 21 | 239,765,625 | 58,593.8 |
-| 22 | 239,824,219 | 58,593.8 |
-| 23 | 239,882,813 | 29,296.9 |
-| 24 | 239,912,109 | 29,296.9 |
-| 25 | 239,941,406 | 14,648.4 |
-| 26 | 239,956,055 | 14,648.4 |
-| 27 | 239,970,703 | 7,324.2 |
-| 28 | 239,978,027 | 7,324.2 |
-| 29 | 239,985,352 | 3,662.1 |
-| 30 | 239,989,014 | 3,662.1 |
-| 31 | 239,992,676 | 1,831.1 |
-| 32 | 239,994,507 | 1,831.1 |
-| 33 | 239,996,338 | 915.5 |
-| 34 | 239,997,253 | 915.5 |
-| 35 | 239,998,169 | 457.8 |
-| 36 | 239,998,627 | 457.8 |
-| 37 | 239,999,084 | 228.9 |
-| 38 | 239,999,313 | 228.9 |
-| 39 | 239,999,542 | 114.4 |
-| 40 | 239,999,657 | 114.4 |
-| 41 | 239,999,771 | 57.2 |
-| 42 | 239,999,828 | 57.2 |
-| 43 | 239,999,886 | 28.6 |
-| 44 | 239,999,914 | 28.6 |
-| 45 | 239,999,943 | 14.3 |
-| 46 | 239,999,957 | 14.3 |
-| 47 | 239,999,971 | 7.2 |
-| 48 | 239,999,979 | 7.2 |
-| 49 | 239,999,986 | 3.6 |
-| 50 | 239,999,989 | 3.6 |
-
-:::important
-While the above schedule states approximately `240,000,000`
-HNT will be produced, year one of the blockchain only produced around
-`43,000,000` of the target `60,000,000` due to some slow block times. So the
-actual maximum supply is `223,000,000` HNT.
-:::
-
-### Data Credits and Burn-and-Mint Economics
-
-As noted above, **Data Credits** are a $USD-pegged utility token derived from
-HNT in a burn transaction and used to pay
-[all transaction fees](/blockchain/transaction-fees) on the Helium Network.
-One Data Credit will always cost `$0.00001`. Or, `$1.00` will always buy you
-`100,000` Data Credits. But, as noted above, Data Credits are produced by
-burning HNT. And the market price of HNT will of course fluctuate.
-
-This HNT to DC relationship is based on a design commonly called a
-[burn and mint equilibrium](https://multicoin.capital/2018/02/13/new-models-utility-tokens/)
-and is intended to allow for the supply of HNT to respond to network usage
-trends such that, when equilibrium is found, the amount of HNT that exists
-remains static month on month. (Helium borrowed heavily from Factom’s usage of
-this design though other blockchains have also used it.) The amount of Data
-Credits produced by burning HNT will move up and down based on the USD price
-of HNT as reported by the [HNT Oracles](/blockchain/oracles). Let's look at
-a few examples of how this works on-chain.
-
-**Example 1**
-
-- As always, the price of one DC is `$.00001`
-- The current HNT Oracle price is `$1`
-- Burning `1` HNT would produce `100,000` DCs
-
-**Example 2**
-
-A Helium Network user requires `50,000` DCs per month to send data for their
-fleet of Helium-connected mouse traps. (Yes, these actually exist, and they are
-glorious.) To acquire these 50,000 DCs per month,
-they would burn .5 HNT using the following math:
-
-- Again, the price of DC is `$.00001`
-- The current HNT Oracle price is `$1`
-- Burning `.5` HNT would produce the needed `50,000` DCs
-
-:::important
-Once burned, DCs are owned by the Helium wallet specified in the
-burn transaction. They are non-transferrable and can only be used by the wallet
-owner.
-:::
-
-### Net Emissions
-
-:::info
-Though Net Emissions was introduced as part of HIP 20, it has not yet been activated on chain.
-:::
-
-At this point, the astute reader might be asking themselves the following
-question:
-
-> If HNT supply is capped at 223,000,000 AND the Network is constantly burning
-> HNT to mint Data Credits to enable transactions, won't we run out of HNT?
-
-**Yes.** This is where the idea of Net Emissions comes in. Along with Max
-Supply, [HIP 20](https://github.com/helium/HIP/issues/73) also introduced the
-idea of Net Emissions. Net Emissions give the protocol enough HNT to reward consensus
-group members and Hotspots in perpetuity.
-
-The [complete Net Emissions discussion in the HIP](https://github.com/helium/HIP/blob/master/0020-hnt-max-supply.md#net-emissions)
-is the best resource on this, but we'll provide a quick summary here:
-
-- Using Net Emissions, the blockchain would monitor how many HNT were
- burnt for Data Credits in a given epoch and add them to the number of HNT to be
- minted that epoch. For example, if 10 HNT were burned for
- Data Credits in an epoch, the system would mint 10 more HNT than were expected in
- that given epoch.
-- Because HNT produced via Net Emissions do not add to the total outstanding, they
- do not violate max supply.
-- However, Net Emissions would counteract the desired, deflationary effect of Burn and
- Mint. If the system replaces all the HNT that are burned to create Data Credits, there
- is no resulting reduction of supply.
-- Because of this, when implemented, there will be a cap on the number of HNT
- that can be created via Net Emissions per epoch. When the HNT burned for DCs exceeds
- this cap, there will be a reduction in supply.
-
diff --git a/docs/blockchain/mining/mining.mdx b/docs/blockchain/mining/mining.mdx
deleted file mode 100644
index 04974ccf9..000000000
--- a/docs/blockchain/mining/mining.mdx
+++ /dev/null
@@ -1,216 +0,0 @@
----
-id: mining
-hide_title: true
-sidebar_label: Mining & Rewards
-slug: /blockchain/mining
----
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-![]({useBaseUrl("img/blockchain/mining.png")})
-
-# Mining and Token Rewards
-
-While there's no exact formula for calculating how much `HNT` you'll earn
-over a given period, there are some higher level concepts, design elements, and
-rules to keep in mind that will help better explain what you might earn and why.
-This section covers these, as well as some mining and token reward basics.
-
-## How Do Hotspots Earn Helium Tokens?
-
-The Helium blockchain rewards Hotspots for providing wireless coverage and
-verifying the Helium Network. Hotspots are rewarded in Helium Token, $HNT.
-
-Every epoch, the current consensus group mines approximately 30 blocks on the
-blockchain. In each block, Hotspots perform various types of work and are awarded
-according to the following distribution:
-
-| Reward Type | Description |
-| :-------------------- | :---------------------------------------------------------------------------------------------------------------- |
-| PoC Challenger | Rewarded to any Hotspot that creates a valid PoC challenge and submits the corresponding receipt to the blockchain. |
-| PoC Challengees | Awarded to any Hotspot that transmits a PoC packet after being targeted by the challenger. |
-| Witnesses | Distributed to all Hotspots that witness a beacon packet as part of a PoC Challenge. |
-| Consensus Group | Divided equally among the Validators that are part of the outgoing Consensus Group, responsible for mining blocks. |
-| Security | Awarded to Helium, Inc and other Network investors who hold Security Tokens. |
-| Network Data Transfer | Distributed each epoch to Hotspots that route LongFi sensor data for sensors on the Network during that epoch. |
-
-**_Do I Have To Actively Participate to Earn Rewards Once My Hotspot is
-Deployed?_**
-
-No. Once your Hotspot is completely deployed and fully synced with the Helium
-blockchain, you as the owner are not required to do anything else in order to
-earn $HNT. Your Hotspot will perform all of the above activities on its own
-while it runs.
-
-## Target $HNT Production Per Epoch
-
-As of August 1, 2021 (the most-recent halving), the target production rate for new $HNT minted per month is `2,500,000`. This
-means that, if the blockchain performs as designed, it will produce `2,500,000`
-HNT per month. This target rate is based on the following two parameters, as
-defined in their specific chain variables:
-
-- Target **block time** is `60` seconds.
-- Target **epoch size** is `30` blocks.
-
-Recall that, in the Helium blockchain, blocks contain some number of individual
-transactions, and epochs are comprised of all the blocks mined by the current
-Consensus Group since the last epoch.
-
-So, if the Network achieves its target block time of `60` seconds, and target
-epoch of `30` blocks, the blockchain will produce `2,500,000` HNT per month. Per
-epoch, this equals roughly `1712.704154343` HNT. The math for this is as follows:
-
-- `(43200 minutes per month / 30 minutes per epoch) = 1440 epochs per month`
-- `(2500000 tokens minted per month / 1440 epochs per month) = 1736.1111 HNT per epoch`
-
-### What Are The Current Block and Epoch Times?
-
-At any point you can go to the
-[Helium blockchain Explorer](http://explorer.helium.com/) to view recent block
-and epoch statistics, past $HNT production numbers, and much more.
-
-## HNT Distributions Per Epoch
-
-As calculated above, the target `HNT` per epoch is approximately `1736.1111`. The
-next logical question is, "Where does all this HNT go?" Let's take a look.
-
-Below are the mining rewards per epoch as of August 1, 2021. For every complete epoch, marked by the
-election of a new Consensus Group, all the `HNT` produced are distributed over
-the following reward types:
-
-| Reward Type | Percentage | HNT Earned by Reward Type |
-| :-------------------- | :------------ | :------------------------ |
-| PoC Challenger | 0.90% | 15.6250 |
-| PoC Challengees | 5.02% | 87.1527 |
-| Witnesses | 20.08% | 348.6111 |
-| Consensus Group | 6% | 104.1666 |
-| Security Tokens | 33% | 572.9166 |
-| Network Data Transfer | _Up to 35%_ | _Up to 607.6389_ |
-| **Total** | **100%** | **1736.1111** |
-
-**Rewards Change Over Time**
-
-In the above table you can see the maximum allotted rewards per reward type in
-accordance with HIP 10 (described below). If you want to see the current reward
-type percentage, you can always query the
-[Chain Variables API](/api/blockchain/chain-variables).
-The next maximum allotted rewards change is currently scheduled for **August
-1, 2022.**
-
-## HIP10 and Variable HNT Rewards for Network Data Transfer
-
-As noted above,
-[HIP10 was activated on August 24th, 2020](https://github.com/helium/HIP/blob/master/0010-usage-based-data-transfer-rewards.md).
-HIP10 was introduced by Helium Community Member `hashc0de` and was adopted by
-the Helium Community. It ensures that $HNT is rewarded at a rate of 1:1 to the
-amount of Data Credits (DCs) routed by any given Hotspot per epoch. In doing so,
-the Network Data Transfer reward is proportional to the DC spent that epoch.
-This proportional relationship between Network Data Transfer reward type and DC
-is capped at 35% (607.6389 HNT). Therefore, if the DC burned doesn't equal
-the value of `607.6389` HNT, the remaining HNT is redistributed to the Proof of
-Coverage (PoC) rewards groups pro-rata.
-
-Here are a few examples to illustrate how this works in practice:
-
-**Example 1: DC Burn does not exceed 35% HNT**
-
-- In a given epoch, `2,000,000` DCs are transferred across the network
-- The HNT Oracle Price is `$2.00`
-- In this scenario, total HNT value of DC transferred in this epoch is `10HNT`.
- This calculation is:`(2,000,000 DC * $0.00001 / $2 HNT Oracle Price)`
-- These `10 HNT` would be split proportionally to the Hotspots who did the work
- routing packets at the 1:1 rate.
-- The remaining `597.6389` from the Network Data Transfer reward would be
- distributed ratably among the Challengers, Witnesses and Challengees.
- - `20.6457` to the Challenger group
- - `461.5945` to the Witness group
- - `115.3986` to the Challengee group
-
-**Example 2: DC Burn exceeds 35% HNT**
-
-- In a given epoch, `500,000,000` DCs are spent on data transfer across the
- network
-- The HNT Oracle Price is `$2.00`
-
-In this scenario, total HNT value of DC transferred in this epoch is `2500HNT`.
-This calculation is:`(500,000,000 DC * $0.00001 / $2 HNT Oracle Price)`
-
-- Because the Network DC burn exceeded the `607.6389` available to the
- Network Data Transfer reward, all Hotspots who did the work over this epoch with
- split the full `1113.0145HNT` proportionally.
-
-**Additional Notes on Reward Types and Payouts**
-
-- All Validators in the `Consensus` group will earn an equal reward.
-- All Hotspots participating in PoC, including `Challengers`, `Challengees` and
- `Witnesses` will earn rewards proportional to how many events they
- participated in out of the total number of events per epoch.
-- All Hotspots participating in `Network Data Transfer` will earn rewards
- proportional to their share of the total data transfer in that epoch, as shown
- above.
-- Hotspots can earn one or more reward types during any given epoch.
-- Hotspots are only eligible to submit one Proof of Coverage Challenge - which
- results in them earning the `PoC Challenger` reward - **up to once per 360 blocks**.
-- `PoC Challenger`, `PoC Challengee`, and `Witness` reward types get distributed
- in the epoch that includes the corresponding PoC receipt.
-- A Hotspots can earn more than one `PoC Challengee` and `Witness` rewards per
- epoch.
-
-## HNT Proration and Slow Block Times
-
-The Helium blockchain is still new and growing quickly, so there are bugs to be
-squashed and optimizations to be made. Target block and epoch times can be
-difficult to attain consistently. To account for this, the Helium blockchain
-uses something called `proration` to ensure that the target of `2,500,000` is
-achieved even if block and epoch times aren't on target.
-
-**Target HNT Depends on Blocks, Not Clocks**
-
-It's easiest to think of target HNT production over the span of one month. If
-the blockchain performs on target, resulting in roughly 1460 epochs per month,
-then `2,500,000` new HNT will be produced. "One month" is a period of time
-measured by a clock. However, under the hood, we use block time, and the
-resulting epochs, to mark HNT production against our target. So when blocks are
-slow, HNT production is reduced proportionally.
-
-### What Happens to HNT When Block Times are Slow?
-
-Occasionally, due to the rapid growth of the network, there can be
-less-than-optimal block times. This results in slower epochs. When this happens
-the blockchain will produce **less** HNT over the same period of time. This may
-seem counterintuitive. _Shouldn't the blockchain produce more HNT when block
-times are slower to ensure the `2,500,000` per month target is hit?_ No. Again,
-think blocks, not clocks. Here's a step-by-step example to make it clearer:
-
-- Let's assume for a given `60` minute period, the average block time was `120`
- seconds (which is double the target of `60` seconds).
-- This would mark `30` blocks over the `60` minute period, conclude an epoch,
- and result in HNT rewards being distributed.
-- As with any epoch, we would distribute the target of (approximately) `1736.1111`
- HNT.
-- However, since this epoch took twice as long as normal - `60` minutes versus
- `30` minute target - the blockchain essentially distributes HNT at **half the
- normal rate**.
-
-### When Block Times Slow Down, Everyone Earns Less
-
-The most important take away here is that, when block times slow and HNT
-production is reduced, everyone participating in the Network - Witnesses,
-Challengers, Security Token Holders, etc. - **is impacted equally** (with the
-exception of Consensus Group members; more on this below). So, although it's
-annoying that the effective rate of HNT may have dropped over a given period of
-time, know that you're not the only one earning less. And this is by design.
-
-### Consensus Groups and Slow Block Times
-
-The only group that doesn't see its HNT reduced per epoch when blocks are slow
-is the Consensus Group. Currently there are 40 members of each Consensus Group,
-sharing 6% of the HNT produced per epoch.
-
-This amount stays fixed while every other category of HNT payout is prorated so
-that members of the Consensus Group are incentivized to keep elections fast.
-Otherwise, a malicious Consensus Group member might be inclined to prolong
-elections. This could be done, for example, to prevent a subsequent election,
-thus ensuring current membership in the Consensus Group stays intact. By
-distributing a fixed amount of HNT per `30` block epoch (as opposed to prorating
-payouts), we remove the incentive to disrupt elections.
diff --git a/docs/blockchain/oracles/oracles.mdx b/docs/blockchain/oracles/oracles.mdx
deleted file mode 100644
index d27164e76..000000000
--- a/docs/blockchain/oracles/oracles.mdx
+++ /dev/null
@@ -1,145 +0,0 @@
----
-id: oracles
-hide_title: true
-sidebar_label: Oracles
-slug: /blockchain/oracles
----
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-![]({useBaseUrl("img/blockchain/oracle.png")})
-
-# HNT Price Oracles
-
-HNT converts to Data Credits at a rate pegged to `$.00001` , and so the
-blockchain requires a canonical HNT/$USD price for this conversion. Beginning in
-June 2020, the Helium blockchain
-[started using a system](https://engineering.helium.com/2020/05/29/HNT-Price-Oracles.html)
-of decentralized price oracles to supply the $USD to HNT price used for on-chain
-for burn transactions. (This system is inspired by
-[the Maker Foundation's Oracle usage.](https://blog.makerdao.com/introducing-oracles-v2-and-defi-feeds/))
-
-To find this price, nine oracles (this number may change in the future)
-periodically submit
-HNT/$USD prices. Once the blockchain has enough new price data, it will calculate a new HNT/$USD
-price that will remain valid until enough new, valid oracle inputs are
-submitted, triggering a new price revision.
-
-### Calculating the HNT Price
-
-Every `10` blocks (roughly every 10 minutes) the blockchain will attempt to
-establish a new HNT/$USD price. To do this:
-
-1. The blockchain looks for recent price submissions from valid Oracles
- (submitted using a transaction called `price_oracle_submission`). A valid
- price submission is anything that was submitted within the last 25 hours but
- is older than 1 hour. This enables the blockchain to calculate a trailing 24
- hour median while also having a buffer against outlier price inputs in the
- most recent 60 minutes.
-2. If there are enough new, valid price submissions in the 24 hour window, a new
- price will be calculated. For this to happen, a majority of the price Oracles
- need to have submitted a price in the window - `((N / 2) +1 )`. So, in our
- system of `9` Oracles, we would need valid prices from at least `5`. (If
- there aren’t `((N / 2) +1 )` new prices, no new HNT price is calculated.)
-3. If there are at least `5` new prices, we then proceed to sort-order the list
- low to high, and take the median. So, if we had `7` valid submissions of
- `$.20,` `$.22`, `$.235`, `$.238`, `$.25`, `$.27`, `$.45`, the blockchain
- would select `$.238`, and use this as the external price of HNT for all HNT /
- DC burn transactions until a new price is established \(which could be as
- soon as `10` blocks\).
-
-**What's the current HNT Oracle Price?**
-
-- [Click here.](https://api.helium.io/v1/oracle/prices/current)
-
-### Who are the HNT Price Oracles?
-
-The HNT Oracle price feeds are supplied by a group of eleven (11) Oracles, composed
-of companies, organizations, and individuals. They are:
-
-- Helium, Inc
-- Decentralized Wireless Alliance ([DEWI](https://www.dewi.org/))
-- Nine (9) Anonymous Individual Community Members
-
-We’ve chosen to keep the names of the individual feed contributors anonymous as
-it’s essential to prevent any external attempts at extortion or blackmail. The
-names of large companies and organizations that supply feeds, however, are
-public and it’s easier for them to combat potential attacks and bad actors.
-
-The current set of public keys for the eleven HNT Price Oracles are (in no
-particular order):
-
-```text
-13CFFcmPtMvNQCpWQRXCTqXPnXtcsibDWVwiQRKpUCt4nqtF7RE
-1431WVQvoV7RAJpoLCaBrTKner1Soed4bk69DddcrHUTCWHV6pj
-136n9BEbreGUNgXJWtyzkBQcXiNzdMQ5GBoP8L2J6ZReFUAwUjy
-14sqAYg1qxzjKTtyHLYZdH6yDtA3KgyoARhWN1cvLZ94dZw5vEc
-145J6Aye86pKTJrUHREiXu7qqppZBcWY1bvWo8id7ZjxyuainYj
-14EzXp4i1xYA7SNyim6R4J5aXN1yHYKNiPrrJ2WEvoDnxmLgaCg
-147yRbowD1krUCC1DhhSMhpFEqnkwb26mHBow5nk9q43AakSHNA
-13ZGgWX4Ajz9g9t3tM9ohDyso12o2E2CpYbMF2RBaT93rj7souE
-1489qpKWAoLrURcaQEM1wJEViD4mk9WcqZMGhiTFfNGmaz8NFdX
-14hntpRicek9pxzHBDPVWPwYHHmExrksaxzAsTjjstgLfnfG5Ve
-14aQaRARuwLTLHLygiDNNapKZ7bcLSyXhHq9DeZ5kB2dnCxiiKv
-```
-
-You can [list activity for a specific Oracle](https://docs.helium.com/api/blockchain/oracle-prices/#list-activity-for-a-specific-oracle) at:
-```
-https://api.helium.io/v1/oracle/:address/activity
-```
-
-
-## Submitting an HNT Oracle Price
-
-An HNT price will only be accepted if the transaction is signed by the private
-key associated with one of the known oracle public keys listed above.
-
-### Required Software
-
-Currently Oracles use the
-[Helium Wallet CLI](https://github.com/helium/helium-wallet-rs) for submitting
-prices to the blockchain. Download this and get comfortable with it on your
-machine if you're not using it already.
-
-#### Submitting HNT Prices
-
-We've added a new transaction to the blockchain for Oracle price submissions -
-`price_oracle_submission`, and a corresponding CLI command - `oracle report`.
-
-When you download the CLI and run `helium-wallet oracle report --help`, you'll
-see something like this:
-
-```text
-helium-wallet-oracle-report
-Construct an oracle price report and optionally commit it to the Helium Blockchain
-
-USAGE:
- helium-wallet oracle report [FLAGS] --block ![]({useBaseUrl("img/blockchain/packetpurchasing.png")})
-
-# 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](/use-the-network/console) operated by Helium,
-Inc.
-
-An OUI has some specificities related to LoRaWAN and packet routing,
-[documented here](/lorawan-on-helium#the-oui), but with respect to the
-blockchain, what's important is that
-[only libp2p addresses registered as endpoints for the OUI](https://github.com/helium/proto/blob/master/src/blockchain_txn_oui_v1.proto#L6)
-may open and close state channels on behalf of an OUI.
-
-For example,
-[this account](https://explorer.helium.com/accounts/13tyMLKRFYURNBQqLSqNJg9k41maP1A7Bh8QYxR13oWv7EnFooc)
-[purchased the first OUI](https://explorer.helium.com/txns/6ACW9A5Hj3KDnOJELWAvAVG3yM71OpNAYpdAPM3ti1A)
-on the Helium Blockchain. The address
-`112qB3YaH5bZkCnKA5uRH7tBtGNv2Y5B4smv1jsmvGUzgKT71QpE` operates the OUI on
-behalf of the owner. You can monitor its activity
-[here](https://explorer.helium.com/accounts/14oSuAgRmAFPFPZRY1MUwir5AJSLGkaXHzuSZJ92BuYCfLMN1Et).
-
-OUIs are purchased (see current
-[fee schedule](/blockchain/transaction-fees#transaction-fee-schedule)) and
-numbered in incrementing order. You can query the API for a list of existing
-OUIs using [the following endpoint](/api/blockchain/ouis#list-ouis).
-
-## 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`](https://github.com/helium/proto/blob/master/src/blockchain_txn_state_channel_open_v1.proto)
-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`](https://github.com/helium/proto/blob/master/src/blockchain_txn_state_channel_close_v1.proto)
-transaction channel, a transaction which also shows 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.
diff --git a/docs/blockchain/proof-of-coverage/proof-of-coverage.mdx b/docs/blockchain/proof-of-coverage/proof-of-coverage.mdx
deleted file mode 100644
index db41da67e..000000000
--- a/docs/blockchain/proof-of-coverage/proof-of-coverage.mdx
+++ /dev/null
@@ -1,142 +0,0 @@
----
-id: proof-of-coverage
-hide_title: true
-sidebar_label: Proof of Coverage
-slug: /blockchain/proof-of-coverage
----
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-![]({useBaseUrl("img/blockchain/proofofcoverage.png")})
-
-# Proof of Coverage
-
-The Helium blockchain uses a novel work algorithm called “Proof of Coverage”
-(PoC) to verify that Hotspots are located where they claim. Put another way, PoC
-tries to verify, on an ongoing basis, that Hotspots are honestly representing
-their location and the wireless network coverage they are creating from that
-location.
-
-**See Proof of Coverage in Action**
-
-The [Helium Network Explorer](https://network.helium.com) is the best resources for viewing POC-related data.
-Before you dive into the POC internals, here are a few POC Challenges to help
-you visualize how this works:
-
-- [Cheesy Brick Mustang from block 641265](https://explorer.helium.com/txns/qmJF48v8ZlEfsPg_7jc2CrsLlOvgC7w-pvB_BWQAoOk)
-- [Plain Mocha Mouse from block 643923](https://explorer.helium.com/txns/kQVfUV88j3s1Glj4fRXFb5MqBeFdTq8ILK2RlaFTnvQ)
-
-## Why Proof of Coverage?
-
-The Helium Network is a [physical wireless network](https://explorer.helium.com)
-that succeeds based on the amount of reliable coverage it can create for users
-deploying connected devices on it. As such, it required a work algorithm that
-was built for this use case. Proof-of-Coverage takes advantage of the unique,
-undeniable properties of radio frequency (RF) to produce proofs that are
-meaningful 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; and
-- RF travels at the speed of light with (effectively) no latency;
-
-Using these properties, the blockchain is constantly interrogating Hotspots
-using a mechanism known as a “PoC Challenge”. The ultimate power of
-Proof-of-Coverage lies in the fact that the data generated by the ongoing proofs
-and stored in the Helium blockchain is definitive verification of the wireless
-coverage provided by Hotspots on the Network.
-
-## Proof of Coverage Challenges
-
-The "challenge" is the discrete unit of work for Proof of Coverage. To date, there
-have been 10s of millions of challenges issued and processed by the Helium blockchain.
-With each new challenge, the blockchain records more data about the quality of the network.
-Let's take a look at how challenges actually happen.
-
-### Hotspot Roles
-
-POC Challenges involve three distinct roles:
-
-1. **Challenger** - The Hotspot that constructs and issues the POC Challenge. Hotspots issue
-challenges approximately once per every 360 blocks. (See note below)
-2. **Transmitter** - Sometimes called "Challengee". This Hotspot is the target of the POC
-challenge and is responsible for transmitting (or "beaconing") challenge packets to potentially be witnessed by
-geographically proximate Hotspots.
-3. ** Witness** - Hotspots that are geographically proximate to the Transmitter and report the existence of the
-challenge packet after it has been transmitted.
-
-(Note: The goal is to reduce the PoC Interval to 200 blocks or lower)
-
-
-### Challenge Proof Construction and Target Selection
-
-As noted above, Hotspots are currently allowed to submit a challenge proof roughly once per
-360 blocks. They do this reliably [to earn the portion of HNT rewards allocated to challengers](/blockchain/mining).
-The Challenger first generates an ephemeral public/private key pair to be used in the challenge.
-A SHA256 digest of the public key and the SHA256 digest of the private key are both submitted,
-along with the current block hash, as a PoC request. If the request is valid and accepted by the
-blockchain, the hash of the block that the receipt appears in is combined with the hash of the
-ephemeral public key and the challenger's identity to generate verifiable entropy. A uniform random
-number generated via this entropy is then used to select the target from all Hotspots on the Network.
-
-After the the challenge packet is created, it is then delivered to the transmitter via the Helium Peer-to-Peer Network.
-The target receives the challenge packet, decrypts the outermost layer using its private key and the ephemeral public
-key for this challenge (this ephemeral public key appears in the PoC packet and the receiving Hotspot can inspect
-the blockchain for an active PoC receipt with the corresponding SHA256 of the ephemeral key), and immediately
-transmits the resultant packet to the Helium Network. Any number of proximate geographic Hotspots will hear it and will Witness the packet.
-
-### Witnesses
-
-As of [HIP 15](https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md), Proof of Coverage
-relies entirely on beaconing. A beacon is a single transmission witnessed by any Hotspot. Previous
-versions used multi-hop challenge paths that didn't accurately test Hotspots on what they are built to do:
-capture RF packets.
-
-After a Transmitter receives the challenge, it will beacon the challenge packet. There is no
-intended recipient of this packet, and any Hotspot that is geographically proximate to the transmitter
-is eligible to witness it and report back to the blockchain. After a Hotspots witnesses a beacon from a
-transmitter, it will submit this as part of the POC Challenge receipt that gets assembled and submitted
-to the blockchain by the POC Challenger.
-
-### POC Reward Scaling
-
-For every epoch, each [reward type](/blockchain/mining) is split amongst Hotspots who had a role in that reward pool.
-For example, if your Hotspot was challenged during an epoch, it will be eligible to a portion of the 5.31% of rewards that
-go to PoC Transmitters. A practical way of thinking about this is that a Hotspot might earn a "reward unit" for succeeding at a challenge.
-If five additional Hotspots succeeded at a challenge during the epoch and each of them also earned a "reward unit",
-then each Hotspot gets 1/6th of the 5.31% of rewards in that epoch.
-
-With the activation of [HIP15](https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md) and
-[HIP17](https://github.com/helium/HIP/blob/master/0017-hex-density-based-transmit-reward-scaling.md), we introduced
-the idea of scaling these "reward units", so the units earned when being witnessed or witnessing a packet scale
-depending on two things:
-
-1. The number of witnesses, detailed in HIP15
-2. The number of Hotspots in the hex tile of the transmitter, detailed in HIP17
-
-The HIPs themselves provide a rich explanation of these mechanisms, so you're encouraged to read those, but they can be summarized as follows:
-
-**From HIP15**
-* 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.
-* A change made with the 2021.09.14.0 release randomly shuffles the valid received witness receipts, and selects (up to) 25 of those valid to write to the chain.
-
-**From HIP17**
-* 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.
-
-
-
-### Verifying the Proof
-
-Once the Challenger has the complete set of receipts from the POC Witnesses and Transmitter, or the elapsed time since
-the challenge was issued has passed the upper time bound, the POC Challenge is considered complete. At this point, the
-Challenger then submits the proof receipt as a transaction to the blockchain to be verified by the current consensus group.
-Because the steps taken by the Challenger to construct and complete the proof are deterministic and easily reproduced,
-members of the consensus group can verify the legitimacy of the proof. Specifically the Challenger reveals the secret
-ephemeral key it used for both obtaining the original PoC request and for encrypting each layer of the challenge packet.
-This crucial information, which has been hidden until the receipt is published, allows the re-creation of the deterministic entropy.
-
-
-
diff --git a/docs/blockchain/transaction-fees/transaction-fees.mdx b/docs/blockchain/transaction-fees/transaction-fees.mdx
deleted file mode 100644
index 04f7c8b5f..000000000
--- a/docs/blockchain/transaction-fees/transaction-fees.mdx
+++ /dev/null
@@ -1,100 +0,0 @@
----
-id: transaction-fees
-hide_title: true
-sidebar_label: Transaction Fees
-slug: /blockchain/transaction-fees
----
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-![]({useBaseUrl("img/blockchain/fees.png")})
-
-# Transaction Fees
-
-Like most blockchains, Helium has a system of transaction fees. All transactions
-in the Helium blockchain are paid in Data Credits (DCs). Data Credits are
-produced via burning some amount of `HNT` using an on-chain transaction. And
-thanks to a system called "Implicit Burn", users (typically) don't need to
-manually supply `DCs` to pay fees. As long as the Helium wallet being used to
-submit the transaction contains enough `HNT` to burn to `DCs` to fund the
-transaction, the burn will happen implicitly, requiring no user intervention.
-
-### Transaction Fee Schedule
-
-The following is a list of the current set of fees required for various
-transactions, along with their details. Transaction fees are paid in Data
-Credits. (Note that the cost is not shown in `HNT` as this number is variable
-based on the current $USD/HNT price as defined by the HNT Price Oracle.)
-
-| Fee Type | Fee Description | **Cost (DC)** | Cost ($USD) |
-| :------------------------------ | :--------------------------------------------------------------------------------------------------------------------------- | :------------ | :---------- |
-| Send HNT | Transferring HNT from wallet to wallet | `Variable` | `Variable` |
-| Transferring Device Packet Data | Fee paid by device owner when sending or receiving sensor data. Metered per 24 bytes. | `1` | `$.00001` |
-| Add Full Hotspot | Fee paid to add full Hotspot to the blockchain. **Fee is generally covered by Hotspot maker**. | `4000000` | `$40` |
-| Add Data Only Hotspot | Fee paid to add a Data Only Hotspot to the blockchain. | `500000` | `$5` |
-| Assert Hotspot Location | Required when asserting a Hotspot's location. \(The **first assertions** is generaly covered by Hotspot maker\) | `1000000` | `$10` |
-| Purchasing a blockchain OUI | Buy an OUI from the Helium blockchain | `10000000` | `$100` |
-| Purchasing a blockchain Subnet | Buy a Subnet from the Helium blockchain | `10000000` | `$100` |
-
-### Calculating the DC cost for Sending HNT
-
-As noted above, the `DC` cost of a `Send` transaction is variable. The precise
-cost is based on the size of the transaction, in bytes. Once the size is
-calculated, we apply a `5000x` multiplier. For a typical send transaction, where
-one wallet is sending to one wallet
-([like this one here](https://explorer.helium.com/txns/RP8xdjuYsvIAaEuyNvMmlBF7Kc8ShNoURtA1ccgMGpk)),
-the complete transaction is made up of the following:
-
-| Transaction Component | Component Size (Bytes) |
-| :-------------------- | :------------------------------- |
-| Payer Wallet Key | 33 |
-| Payee Wallet Key | 33 |
-| Payer Signature | 64 |
-| Nonce | 3 (approximate; ranges from 2-4) |
-| Payment Amount | 6 (approximate; ranges from 4-8) |
-
-- In total, this is `139` bytes.
-- Each `24` bytes requires one Data Credit (as is the case when you're
- transferring device packet data).
-- `139` / `24` results in `6` Data Credits.
-- We then apply our 5000x multiplier, and the result is a transaction fee
-- This results in a `30000 Data Credit` cost for the above transaction.
-
-### Transaction Fees and Implicit Burn
-
-The Helium blockchain uses something called `implicit burn` when paying fees.
-
-**Implicit Burn™**
-
-The term `implicit burn` was coined by Helium PM Coco "cokes" Tang, a recognized
-innovator in the blockchain technology and terminology space.
-
-Thanks to Implicit Burn™, if you have enough HNT in your wallet to pay the
-transaction fee, the Helium Mobile Wallet (or the Helium Wallet CLI) will
-calculate the DC cost of your transaction and the blockchain will automatically
-burn the precise amount of HNT to supply the required DCs for the transaction.
-For example:
-
-- You need to send `10 HNT` from a Helium Wallet that contains `11 HNT`
-- The cost for this `send` transaction is `35000 DCs`
-- Let's assume the `HNT/$USD` Oracle Price is `$.35` at the time you send the
- `HNT`. This means that you'll need to supply a `1HNT` to fund the `35000 DCs`
- for this transaction.
-- When you send the `10 HNT`, the Helium Wallet automatically supplies the
- `1 HNT` to be burned into `DCs`.
-- After the transaction is submitted and processed, your resulting Helium Wallet
- balance will be `0 HNT`.
-
-In the above example, had you attempted to send `10.0001HNT` with only `11 HNT`
-in your wallet, this transaction would have failed as burning `.999 HNT` would
-only result in `34965 DCs`, a mere 35 DCs short of the `35000` required for a
-`send` transaction.
-
-### Failed Transactions Result in No DCs Being Spent
-
-Transactions in the Helium blockchain are `atomic`. In short, this means that
-they either succeed entirely or they don't. So, if you attempt to send HNT from
-a Helium Wallet without enough HNT to supply the required Data Credits, the
-transaction will fail after being submitted to the blockchain API by your
-wallet. And your `HNT` balance will be the same. No `DCs` were burned (or
-harmed) in this failed transaction.
diff --git a/docs/community-governance/community-governance.mdx b/docs/community-governance/community-governance.mdx
deleted file mode 100644
index cad8ff2ce..000000000
--- a/docs/community-governance/community-governance.mdx
+++ /dev/null
@@ -1,92 +0,0 @@
----
-id: community-governance
-hide_title: true
-sidebar_label: Community
-slug: /community-governance
----
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-![]({useBaseUrl("img/community/community.png")})
-
-# Community and Governance
-
-The Helium Community is the home to over tens of thousands developers and network operators who collaborate every day across the world to build the Helium Network. Any and all are welcome to take part. Join us!
-
-### Discord
-
-The [Helium Discord](https://discord.gg/helium) is the primary communication channel for the Helium Network Community. Here you'll find real-time, in-depth discussion on all parts of the Helium Network. It is also the primary venue to get support for using the Network.
-
-- [Join the Helium Community Discord](https://discord.gg/helium)
-
-#### Discord Roles
-
-- @admin
-- @Helium Team 👑
-- @Wick
-- @Moderator
-- @DeWi
-- @chaingang
-- @carl-bot
-- @Vendor
-- @Helium Contributor
-- @Community Developer
-- @Community Designer
-- @Patron
-- @Insiders
-- @Validator
-- @Hotspot Owner
-- @Server Booster
-- @Helium Hacks Hardware Winner
-- @troll 💩
-- @Discord.RSS
-- @bot
-- @Zapier
-- @FF
-- @verified
-- @ProBot ✨
-- @Muted
-- @Quarantine
-- @Docs Contributor
-- @@everyone
-
-### Helium Improvement Proposals
-
-The Helium Community uses a governance mechanism called **Helium Improvement Proposals** (known as "HIPs"). Modeled on BIPs from the Bitcoin community, HIPs are used to introduce, debate, and approve/reject new changes to major elements of the Network like the core blockchain, $HNT token economics, and Network governance itself.
-
-HIPs are managed entirely from the [HIP GitHub repository](https://github.com/helium/HIP). HIP discussion also happens in the `Improvement Proposal` section of [Helium Discord](https://discord.gg/helium). Any and all members of the Helium Community are encouraged to create HIPs, and participate in the governance process.
-
-- [HIP Repo on GitHub](https://github.com/helium/HIP)
-
-### Regularly Community Events
-
-#### Monthly Community Calls
-
-The Helium Community holds monthly video calls (led by the [DEWI](https://www.dewi.org/)). These typically happen on the the **4th Wednesday of each month at 12PM ET**. Each call has an open agenda, and any community member can join and add items to the agenda to be discussed.
-
-- [Community Call Notes and Agenda](https://docs.google.com/document/d/1bMm2alBigBj3detA775Dn0Gz9UM5XczAeK9vnjBB3l0/edit#)
-- [Video recordings of all previous community calls](https://vimeo.com/dewialliance)
-
-#### Helium Hacks Happy Hour
-
-Held every Wednesday at 2PM Pacific on Zoom, Helium Hacks Happy Hour (4H) covers all things hardware, sensors, and connectivity. If you're building something on the Network and want to share, or simply want to learn, 4H is for you.
-
-* [Register for Helium Hacks Happy Hour](https://tinyurl.com/3kjrv9z5)
-* [Selected highlights of previous Happy Hours](https://www.youtube.com/playlist?list=PLtKQNefsR5zMDgluPZtPL3wwFBG7e_FHl)
-
-### Community Programs
-
-#### Patrons
-
-For anyone who has deployed `15` or more Hotspots, you can receive the `Patron` Discord status, Patron-exclusive Newsletter content, and custom Patron swag. To join the program, please email patron@helium.com with proof of purchase for `15` or more of any [community-approved Hotspot options](https://helium.com/mine).
-
-### Social Media
-
-Helium is everywhere. Here's the full list:
-
-- [Twitter](https://twitter.com/helium)
-- [Telegram](https://t.me/helium_network)
-- [Reddit](https://www.reddit.com/r/HeliumNetwork/)
-- [LinkedIn](https://www.linkedin.com/company/heliuminc/)
-- [Facebook](https://www.facebook.com/heliumsystems)
-- [Instagram](https://www.instagram.com/helium/)
diff --git a/docs/community-governance/community-voting.mdx b/docs/community-governance/community-voting.mdx
deleted file mode 100644
index 05ad55234..000000000
--- a/docs/community-governance/community-voting.mdx
+++ /dev/null
@@ -1,53 +0,0 @@
----
-id: community-voting
-sidebar_label: HIP Voting
-slug: /community-voting
----
-
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-
-# Voting on Helium
-In order to approve or deny changes to the blockchain, economics, or governance of the Helium Network; Helium and DeWi leverage on-chain voting which is open to the entire community. This on-chain voting is currently facilited through the website [helium.vote](https://helium.vote).
-
-For most votes, voting power is currently determined by the HNT balance of the voting wallets at a rate of one vote per HNT. However, voting power may change vote-to-vote, depending on what the community is reaching consensus on. As example, a vote on on frequency plan for a region would only concern Hotspots in the region and one would use number Hotspots in the region as votes. Proposals to implement more involved voting mechanisms have been presented, but have not been voted on or implemented yet. See: [HIP41](https://github.com/helium/HIP/blob/master/0041-governance-by-token-lock-v2.md)
-
-HNT holders are able to vote by issuing a small token burn transaction from their wallet to a wallet associated with a particular ballot option, typically `For` or `Against`. Voting just a portion of a wallet's balance is not supported.
-
-
-
-## Helium Vote Configuration
-This information is offered for the sake of transparency to the Helium Community and for the documentation of DeWi practices. Vote configuration is handled by DeWi to ensure that the accrued DC from a vote are burned from existance at the end of the voting period.
-
-### How a HIP Becomes a Vote
-A vote can be created by opening a PR against the [Helium Vote repository](https://github.com/helium/helium-vote/). Templates are provided within the repo. Authors are encouraged to write their HIP description in a nonbiased manner, and are subject to review.
-In partnership with DeWi and Helium, a block height deadline, vote ID, and voting addresses will be provided.
-
-**Create Vote ID**
-
-The vote ID has no direct ties to the blockchain, but must be unique. The simplest way to generate a unique value is to create a quick Helium wallet.
-```shell
-helium-wallet create basic
-```
-The returned address can be used as the vote ID.
-```
-+-----------------------------------------------------+---------+--------+------------+
-| Address | Sharded | Verify | PwHash |
-+-----------------------------------------------------+---------+--------+------------+
-| 13fDZC6rCtZKebjNigeJP3HNMJTBrxJVLjV8JdoPMkyNS9aCHSJ | false | true | Argon2id13 |
-+-----------------------------------------------------+---------+--------+------------+
-```
-This wallet does not need to be retained, as it will not be used for any on-chain transactions.
-
-**Create Each Vote Option**
-
-Most votes will be binary, only needing one address `for` and `against`. The wallet generation process is the same. A wallet is be created for each vote option. These wallet keys should be retained by DeWi for the sake of burning accrued DC at the end of the vote.
-
-**Post Vote Cleanup**
-
-In order to burn the accrued DC, we leverage a neat feature of the HNT pay transaction. We transfer 1 HNT into a wallet needing to be cleared, then transfer it back out. On the outbound transaction we can specify an arbitrary DC fee. Any fee specified that is at least enough to cover the transaction will be accepted by the blockchain.
-```shell
-helium-wallet pay one
-
-
-
-
- ![]({useBaseUrl("img/home/docsheader.png")})
-
-
-
- Get Started
-
-
- Get Started
with Helium
- Build amazing connected solutions on the world’s largest decentralized wireless network.
- -![]({useBaseUrl("img/quicklinkarrow.svg")})
-
-
-
--
-
-
-
-
-
-
- Introduction
-
-
- Helium is a global, distributed network of Hotspots that create public, long-range wireless coverage for LoRaWAN-enabled IoT devices. Hotspots produce and are compensated in HNT, the native cryptocurrency of the Helium blockchain. The Helium blockchain is a new, open source, public blockchain created entirely to incentivize the creation of physical, decentralized wireless networks. Today, the Helium blockchain, and its hundreds of thousands of Hotspots, provide access to the largest LoRaWAN Network in the world.
-
-
- This documentation provides details on the technology that underpins Helium, as well as how to mine HNT, and how to deploy IoT devices that use the Helium Network. Start your journey below.
-If, at any time, you don't find what you need, join us in our Discord.
-Thanks for being a part of Helium.
-
-
-
-
-
- ![]({useBaseUrl("img/home/blockchainicon.png")})
- ![]({useBaseUrl("img/icons/linkarrow.svg")})
- Blockchain Primitives
- Mining HNT
- Proof of Coverage
- Consensus Protocol
- Helium Token
- Transaction Fees
-
-
- Helium Blockchain
-The Helium Blockchain is a new blockchain built from the ground up to incentivize the creation of decentralized, public wireless networks.
- Learn More
- Quick Links
- Blockchain Primitives
- Mining HNT
- Proof of Coverage
- Consensus Protocol
- Helium Token
- Transaction Fees
-
- ![]({useBaseUrl("img/home/mineicon.png")})
- ![]({useBaseUrl("img/icons/linkarrowblue.svg")})
- ![]({useBaseUrl("img/icons/dociconblue.svg")})
What is a Helium Miner?
- Approved Hotspots
- Run an HNT Validator
- Hotspot Makers
- Build a Packet Forwarder
-
-
- Mine $HNT
-Hotspots create The People’s Network, a long-range wireless coverage for very low power and inexpensive IoT devices and are rewarded $HNT for doing so.
- Learn More
- Quick Links
- What is a Helium Miner?
- Approved Hotspots
- Run an HNT Validator
- Hotspot Makers
- Build a Packet Forwarder
-
- ![]({useBaseUrl("img/home/useicon.png")})
- ![]({useBaseUrl("img/icons/linkarrowgreen.svg")})
- ![]({useBaseUrl("img/icons/docicongreen.svg")})
Devices
- Helium Console
- LoRaWAN on Helium
-
-
- Use the Helium Network
-The Helium Ecosystem includes thousands of ready-to-use devices, powerful integrations, and robust developer tools.
- Learn More
- Quick Links
- Devices
- Helium Console
- LoRaWAN on Helium
-
- ![]({useBaseUrl("img/home/communityicon.png")})
- ![]({useBaseUrl("img/icons/linkarrowred.svg")})
- ![]({useBaseUrl("img/icons/dociconred.svg")})
Discord Community Chat
- Helium Improvement Proposals
- Open Source Software
-
-
-
- Community, Governance, & Open Source
-Helium’s decentralized ‘People’s Network’ relies on a community of supporters, developers and advisors.
- Learn More
- Quick Links
- Discord Community Chat
- Helium Improvement Proposals
- Open Source Software
-
-
-
-
--
-
-
-
-
-
diff --git a/docs/home/home.mdx b/docs/home/home.mdx
new file mode 100644
index 000000000..6b000b7c5
--- /dev/null
+++ b/docs/home/home.mdx
@@ -0,0 +1,23 @@
+---
+id: home
+hide_title: true
+title: Home
+pagination_label: Home
+sidebar_label: Introduction
+description: Helium Documentation
+image: https://docs.helium.com/img/link-image.png
+slug: /
+hide_table_of_contents: true
+pagination_next: null
+pagination_prev: null
+---
+
+import useBaseUrl from '@docusaurus/useBaseUrl'
+
+
-
-
-
- Tools, Technologies & Initatives
-
-
-
- ![]({useBaseUrl("img/home/console.svg")})
-
-
-
-
- Console
-Provision and Manage Devices
-
- ![]({useBaseUrl("img/home/explorer.svg")})
-
-
-
-
- Explorer
-Helium Blockchain Block Explorer
-
- ![]({useBaseUrl("img/home/mappers.svg")})
-
-
-
-
- Mappers
-Community-driven Coverage Mapping
-
- ![]({useBaseUrl("img/home/walletapp.svg")})
-
-
-
-
- Wallet App
-iOS & Android Helium Wallet
-
-
-
- ![]({useBaseUrl("img/home/cli.svg")})
-
-
-
-
- Helium Wallet CLI
-Interact with Blockchain via Command Line
-
- ![]({useBaseUrl("img/home/longfi.svg")})
-
-
-
-
- Helium Light Hotspots
-Packet forwarder for the Helium-enabled Gateways.
-})
+
+The Helium Network powers two distinct wireless networks; a global LoRaWAN™ network for IoT
+devices, and a cellular offload Wi-Fi network for mobile connectivity. Wireless gateways called
+"Hotspots", operated by the Helium community, provide the coverage for these networks. Hotspot
+owners are incentivized with the Helium HNT token for providing coverage and handling wireless
+traffic.
diff --git a/docs/home/style-guide.mdx b/docs/home/style-guide.mdx
new file mode 100644
index 000000000..c7b8b7e5a
--- /dev/null
+++ b/docs/home/style-guide.mdx
@@ -0,0 +1,208 @@
+---
+id: style-guide
+title: Style Guide
+sidebar_label: Style Guide
+---
+
+You can write content using [GitHub-flavored Markdown syntax](https://github.github.com/gfm/).
+
+## Markdown Syntax
+
+To serve as an example page when styling markdown based Docusaurus sites.
+
+## Headers
+
+# H1 - Create the best documentation
+
+## H2 - Create the best documentation
+
+### H3 - Create the best documentation
+
+#### H4 - Create the best documentation
+
+##### H5 - Create the best documentation
+
+###### H6 - Create the best documentation
+
+---
+
+## Emphasis
+
+Emphasis, aka italics, with _asterisks_ or _underscores_.
+
+Strong emphasis, aka bold, with **asterisks** or **underscores**.
+
+Combined emphasis with **asterisks and _underscores_**.
+
+Strikethrough uses two tildes. ~~Scratch this.~~
+
+---
+
+## Lists
+
+1. First ordered list item
+1. Another item
+ - Unordered sub-list.
+1. Actual numbers don't matter, just that it's a number
+ 1. Ordered sub-list
+1. And another item.
+
+- Unordered list can use asterisks
+
+* Or minuses
+
+- Or pluses
+
+---
+
+## Links
+
+[I'm an inline-style link](https://www.google.com/)
+
+[I'm an inline-style link with title](https://www.google.com/ "Google's Homepage")
+
+[I'm a reference-style link][arbitrary case-insensitive reference text]
+
+[You can use numbers for reference-style link definitions][1]
+
+Or leave it empty and use the [link text itself].
+
+Some text to show that the reference links can follow later.
+
+[arbitrary case-insensitive reference text]: https://www.mozilla.org/
+[1]: http://slashdot.org/
+[link text itself]: http://www.reddit.com/
+
+---
+
+## Images
+
+Here's our logo (hover to see the title text):
+
+Inline-style:
+
+
+Reference-style: ![alt text][logo]
+
+[logo]:
+ https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png
+ 'Logo Title Text 2'
+
+Images from any folder can be used by providing path to file. Path should be relative to markdown
+file.
+
+
+
+---
+
+## Code
+
+```javascript
+var s = 'JavaScript syntax highlighting'
+alert(s)
+```
+
+```python
+s = "Python syntax highlighting"
+print(s)
+```
+
+```
+No language indicated, so no syntax highlighting.
+But let's throw in a tag.
+```
+
+```js {2}
+function highlightMe() {
+ console.log('This line can be highlighted!')
+}
+```
+
+---
+
+## Tables
+
+Colons can be used to align columns.
+
+| Tables | Are | Cool |
+| ------------- | :-----------: | -----: |
+| col 3 is | right-aligned | \$1600 |
+| col 2 is | centered | \$12 |
+| zebra stripes | are neat | \$1 |
+
+There must be at least 3 dashes separating each header cell. The outer pipes (|) are optional, and
+you don't need to make the raw Markdown line up prettily. You can also use inline Markdown.
+
+| Markdown | Less | Pretty |
+| -------- | --------- | ---------- |
+| _Still_ | `renders` | **nicely** |
+| 1 | 2 | 3 |
+
+---
+
+## Blockquotes
+
+> Blockquotes are very handy in email to emulate reply text. This line is part of the same quote.
+
+Quote break.
+
+> This is a very long line that will still be quoted properly when it wraps. Oh boy let's keep
+> writing to make sure this is long enough to actually wrap for everyone. Oh, you can _put_ >
+> **Markdown** into a blockquote.
+
+---
+
+## Inline HTML
+
+-
+
- Definition list +
- Is something people use sometimes. + +
- Markdown in HTML +
- Does *not* work **very** well. Use HTML tags. +
![]({useBaseUrl("img/lorawan-on-helium/lorawanheader.png")})
-
-# LoRaWAN On Helium
-
-The LoRaWAN Network on Helium is **compatible with all LoRaWAN devices**.
-However, Helium distinguishes itself in how it treats the LoRaWAN Network Server
-(LNS).
-
-In typical LoRaWAN Networks, a central or regional LNS is managed by a single
-entity. Helium’s design for a decentralized network, however, means not only do
-we want gateways (or what we sometimes call Hotspots) to be independently owned
-and operated, but we want to enable the independent operation of the LNS.
-Without this, access to the network would require permission from a single
-central entity, the LNS operator of the network.
-
-Therefore, we want to enable the _multi-tenancy_ of LNS’s on the same Public
-LoRaWAN Network. Achieving this distinguishes Helium’s LoRaWAN Network from any
-other: public wireless infrastructure is now compatible with privately-run
-network servers.
-
-The rest of this article will discuss the networking primitives. If you want to
-go ahead and run a network server, please checkout our article about [running
-a network server](/use-the-network/run-a-network-server).
-
-## The OUI
-
-Each LoRaWAN Network Server (LNS) on the Helium Network acquires an
-Organizationally Unique Identifier (OUI). This registers the LNS with the
-blockchain and allocates two very important routing objects owned and maintained
-by the OUI operator:
-
-- up to five **filters**, describing the sets (AppEUI, DevEUI) expected by the
- LNS
-- one or more **slabs** of DevAddrs, reserving NwkAddr space for the OUI's
- devices on the Helium Network
-
-A device defined by (AppEui, DevEui) can be allocated any of the DevAddrs owned
-by the OUI. It is even possible to multiplex many devices on the same DevAddr
-at the same time, using the Message Integrity Check (MIC) to disambiguate.
-
-### Join Request Frames and Filters
-
-A Join Request frame has the following unencrypted header:
-
-```bash
-+---------------------------------------------------------+
-| Size (octets) | 8 | 8 | 8 |
-+------------------+------------+------------+------------+
-| Join Request | AppEUI | DevEUI | DevNonce |
-+---------------------------------------------------------+
-```
-
-From the gateways perspective, the (AppEUI, DevEUI) may be used to figure out if
-one or more OUI's are interested in the Join Request.
-
-This is done by querying every filter maintained and written to the blockchain
-by every OUI. The filters themselves are _xorhash_ tables, thus the AppEui and
-DevEui cannot be extracted. Only with the AppEui and DevEui in-hand can the
-gateway run it through the table and to see if it's there.
-
-In response to the Join Request, a Join Accept is sent down, assigning the
-NwkAddr. Due to the multi-tenancy on the Helium Network, the LNS may only assign
-NwkAddrs within its DevAddr slab(s).
-
-### Data Frames and DevAddr Slabs
-
-Data packets have the followed unencrypted header (FHDR):
-
-```bash
-+----------------------------------------------------------------------+
-| Size (octets) | 4 | 1 | 2 | 0..15 |
-+------------------+------------+------------+------------+------------+
-| FHDR | DevAddr | FCtrl | FCnt | FOpts |
-+----------------------------------------------------------------------+
-```
-
-Within DevAddr, there is the NwkAddr of a device:
-
-```bash
-+------------------------------------------------+
-| DevAddr |
-+------------------------+-----------------------+
-| NwkID (bits 31–25) | NwkAddr (bits 24–0) |
-+-----------+--------------------+---------------+
-| Helium Network | allocated by slab |
-|(‘H’ / 0b1001000 / 0x48)| to OUIs |
-+-----------+--------------------+---------------+
-```
-
-
-From the gateways perspective, it is able to use DevAddr to determine the OUI of
-Data frames. A quick query can say which OUI owns this DevAddr slab. This look-up and routing by DevAddr instead of by \(AppEUI, DevEUI\) via _xorhash_
-filters is generally much quicker.
-
-
diff --git a/docs/lorawan-on-helium/lorawan-roaming/lorawan-roaming-on-helium.mdx b/docs/lorawan-on-helium/lorawan-roaming/lorawan-roaming-on-helium.mdx
deleted file mode 100644
index 98f70a01a..000000000
--- a/docs/lorawan-on-helium/lorawan-roaming/lorawan-roaming-on-helium.mdx
+++ /dev/null
@@ -1,46 +0,0 @@
----
-id: lorawan-roaming-on-helium
-sidebar_label: LoRaWAN Roaming on Helium
-slug: /lorawan-on-helium/lorawan-roaming-on-helium
----
-
-
-# LoRaWAN Roaming on Helium
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-The Helium Network is the [world's largest LoRaWAN Network](https://explorer.helium.com) - and continues to grow at a staggering pace. Because of this, it becomes a very attractive network to other public and private LoRaWAN Network Server providers (LNSes) who want to extend their coverage without deploying their own infrastructure and capital. And thanks the the Helium blockchain, direct roaming integrations are very simple. Most importantly, major LNSes are already roaming with the Helium Network today, which means the public coverage the community is building is now being used by LoRa devices onboarded to other networks, and Hotspot operators get compensated in $HNT for routing these packets.
-
-
-## Helium Roaming Architecture
-
-Helium Network roaming most closely resembles the LoRa Alliance's idea of "Passive Roaming". The Helium community operates a dedicated Roaming Server (the "Helium Roaming Server") that is distinct from our core LNS for native Helium Devices. The Helium Roaming Server purchases all packets for a target LoRaWAN `NetID` and forwards them to an endpoint ready to accept them on behalf of a Roaming Partner's LNS. Specifically the Helium Roaming Server connects any Helium gateway that captures target `NetID` packets via the Semtech GWMP UDP client.
-
-![]({useBaseUrl("img/mine-hnt/guides/dragino-guide-lora-config-US915.png")})
-
-
-## Configure LoRaWAN Settings
-
-Next, you will configure the LoRa packet forwarder on the Dragino to forward
-packets to the Helium Gateway service which will be installed on the Dragino in
-the next step.
-
-1. From the Dragino web interface, navigate to LoRaWAN > LoRaWAN from the menu.
-2. Select `Custom / Private LoRaWAN` from the Service Provider.
-3. Set the Server Address to `127.0.0.1` and both Uplink and Downlink ports to
- `1680`. This will configure the forwarder to use the default port used by
- Helium Gateway.
-
-form factor module! | - -[RAK2287]: https://store.rakwireless.com/collections/wislink-lpwan/products/rak2287-lpwan-gateway-concentrator-module -[RAK2247]: https://store.rakwireless.com/collections/wislink-lpwan/products/rak2247-lpwan-gateway-concentrator-module -[RAK2245]: https://store.rakwireless.com/collections/wislink-lpwan/products/rak2245-pi-hat - -[RAK2287 Pi HAT]: https://store.rakwireless.com/products/rak2287-pi-hat -[RAK2247 Pi HAT]: https://store.rakwireless.com/products/rak2247-pi-hat - -:::important -To use the concentrator module with a Raspberry Pi HAT, you must make sure to -order the variation with the SPI interface. -::: - -Let's get started! - -## Packet forwarder preparation - -To get started you must set up the packet forwarder and get some helpful -configuration tools used across this guide. - -#### Option 1 - -You can follow this -[installation procedure](https://github.com/RAKWireless/rak_common_for_gateway#installation-procedure) -if you are already familiar with the Raspberry Pi, and the RAK concentrator -modules. Furthermore, it's highly recommended to start from a fresh -[Raspbian Buster Lite image](https://www.raspberrypi.org/software/operating-systems/) -(now called'Raspberry Pi OS Lite'). - -#### Option 2 - -You can also follow the Quick Start Guide for your concentrator on the -[RAK Documentation Center](https://docs.rakwireless.com/Product-Categories/WisLink/#wislink-lpwan). - -- [RAK2287] -- [RAK2247] -- [RAK2245] - -[RAK2287]: https://docs.rakwireless.com/Product-Categories/WisLink/RAK2287/Quickstart/ -[RAK2247]: https://docs.rakwireless.com/Product-Categories/WisLink/RAK2247/Quickstart/ -[RAK2245]: https://docs.rakwireless.com/Product-Categories/WisLink/RAK2245-Pi-HAT/Quickstart/ - -### Select the region plan - -Enter the gateway configuration interface by using the following command. -``` -sudo gateway-config -``` - -Select the *Setup RAK Gateway Channel Plan* option, then *Server is TTN*, and in -the last step choose the proper plan according to your country. For instance, -the image shows the option to select US915. To finish, press OK. - -
![]({useBaseUrl("img/mine-hnt/mine-hnt-arch.png")})
-
-
-- Packet Forwarder: this is a utility that interacts with the radio front-end
-and sends and receives raw radio packets with the Helium Miner
-- Miner: the Helium Blockchain comes into the picture here; the Miner is
-responsible for routing packets to the appropriate Router and entering into
-micro-transactions brokered via libp2p
-- Router: a Helium compatible LoRaWAN Network Server, basically; this component
-is interested in receiving the packets relating to its devices and handles
-downlink messages when appropriate
-
-In addition to packet routing, the Miner also participates in POC and submits
-POC packets as witness events. When challenge, the Miner sends packets to the
-packet forwarder for transmission.
-
-The Miner connects to other Miners over libp2p where, amongst other things,
-it is gossiping and saving blocks, while maintaining a ledger of the blockchain.
-Constantly syncing the blockchain and downloading blocks uses significant
-bandwidth and CPU.
-
-In this guide, we will explain how to get a Docker image of the Helium Miner
-running on Ubuntu 20.04 LTS, and finally some tips on how to interact with a
-running Miner.
-
-When preparing the Miner for a Hotspot product, you will want to go a little
-further and follow the steps outlined [here](/mine-hnt/full-hotspots/become-a-maker/docker-integration),
-where you will learn how to integrate it with security modules and BLE.
-
-If you are interested in contributing to Miner development and code-review,
-please visit
-[the Miner's repository on Github](https://github.com/helium/miner).
-
-### Setting Up Ubuntu for Docker
-
-Ubuntu is a widely available Linux distribution. Notably, it has an easy-to-use
-image available for Raspberry Pi 3 and 4, so we use it as an example system.
-That being said, any ARM64 or AMD64 \(X86-64\) based OS that can run Docker is
-suitable.
-
-For Raspberry Pi, we recommend running the latest
-[64-bit RaspiOS](https://downloads.raspberrypi.org/raspios_arm64/images/) image.
-We currently do not have Docker image support for 32-bit systems, so please
-double-check that you're using a 64-bit image. Once you have followed the
-instructions and are logged into the system, you are ready for the rest of this
-guide.
-
-For most cloud service providers, launching an instance with Ubuntu 20.04 LTS
-should be fairly straightforward. With AWS for example, create an EC2 instance
-running Ubuntu 20.04. A t2.small will run the miner well once the initial
-blockchain sync has completed. Once that's launched and you're connected, you
-are ready for the rest of this guide.
-
-First, update the package manager registry:
-
-```text
-sudo apt-get update
-```
-
-Then, install Docker:
-
-```text
-sudo apt-get install docker.io
-```
-
-To avoid needing to user docker with `sudo` privileges, add your user to the
-`docker` group, replacing $USER with your username:
-
-```text
-sudo usermod -aG docker $USER
-```
-
-Log in and out of your account to apply these changes. You are now ready to use
-Docker!
-
-### Port Forwarding
-
-Before launching the Miner, you will want to configure ports on your network to
-forward two ports:
-
-- **44158/TCP**: the Miner communicates to other Miners over this port. The
-networking logic knows how to get around a lack of forwarding here, but you
-will get better performance by forwarding the port
-- **1680/UDP**: the radio connects to the Miner over this port. You will not be
-able to forward packets or participate in Proof of Coverage without this
-
-"Forwarding" on the second port is less relevant if you are running a radio
-packet forwarder on the same system at the miner \(both on a Raspberry Pi, for
-example\). But it is essential if you are running a Miner on the cloud for
-example.
-
-For AWS, for example, you will want to configure the "Security Group" of your
-EC2 as so:
-
-![]({useBaseUrl("img/mine-hnt/run-a-miner-security-group.png")})
-
-### Run a Docker Container
-
-Miner releases are available as amd64 and arm64 images on at
-[quay.io](https://quay.io/repository/team-helium/miner?tab=tags). We do not
-currently provide 32-bit support.
-
-**Note**: on amd64 systems, AVX support is required. Verify that it exists on
-your host system:
-
-```text
-grep avx /proc/cpuinfo
-```
-
-```text
-grep avx2 /proc/cpuinfo
-```
-
-If nothing is returned from these commands, your host system does not have AVX
-support and your Miner may not be stable.
-
-#### Start Container
-
-Before running the container for the first time, it is advisable to pick a
-'system mount point\`, i.e. a directory in your host system; some long-term
-miner data is stored there. This allows you to easily maintain your miner's
-blockchain identity \(i.e. swarm keys\) and blockchain state through miner image
-updates.
-
-If you are using a Linux system, you can just create a directory in your user's
-home directory:
-
-```text
-mkdir ~/miner_data
-```
-
-If you are using Ubuntu as user ubuntu, this path would now be
-`/home/ubuntu/miner_data`. This will be used later.
-
-Now you can try the `run` command to start your container for the first time:
-
-```text
-docker run -d --init \
---ulimit nofile=64000:64000 \
---env REGION_OVERRIDE=US915 \
---restart always \
---publish 1680:1680/udp \
---publish 44158:44158/tcp \
---name miner \
---mount type=bind,source=/home/ubuntu/miner_data,target=/var/data \
-quay.io/team-helium/miner:miner-xxxNN_YYYY.MM.DD
-```
-
-Replace xxxNN with the architecture used, i.e. amd64 or arm64, and with the
-release date of the image.
-
-The `-d` option runs in detached mode, which makes the command return or not;
-you may want to omit if you have a daemon manager running the docker for you.
-
-The `-env REGION_OVERRIDE=US915` tells your miner that you are connecting to a
-packet forwarder configured for the US915 region. You will want to change this
-to your region i.e.
-`US915 | EU868 | EU433 | CN470 | CN779 | AU915 | AS923 | KR920 | IN865`
-
-> Note: REGION_OVERRIDE may be completely omitted once your Miner has asserted
-> location and is fully synced, but leaving it there \(as long as the region is
-> properly configured\) is not harmful
-
-The `--restart always` option asks Docker to keep the image running, starting
-the image on boot and restarting the image if it crashes. Depending on how you
-installed Docker in your system, it'll start on boot. In the AWS AMI above, we
-use systemd \(`systemctl status docker` to check\).
-
-The `--publish 1680:1680/udp` binds your system port 1680 to the container's
-port 1680, where the Miner is hosting a packet forwarder UDP server; this is
-necessary if you want to do any radio interactions with your miner.
-
-The `--name miner` names the container, which makes interacting with the docker
-easier, but feel free to name the container whatever you want.
-
-The `--mount` with the parameters above will mount the container's `/var/data/`
-directory to the systems directory `/home/ec2-user/miner_data`.
-
-### Configure AWS Instance for Sync
-
-Amazon EC2 instances have CPU usage credits that will easily be depleted during
-the initial sync of the blockchain. To avoid having your instance throttled, you
-can temporarily uncap your instance by setting CPU credit usage to unlimited.
-Once your miner has reached full block height, a t2.small instance is sufficient
-to keep your miner running.
-
-### Interact with the Miner within the Container
-
-You may want to interrogate the Miner or interact with it it as described in the
-[using a miner section](/mine-hnt/build-a-packet-forwarder/#using-the-miner).
-Docker's `exec` command enables this e.g.
-
-```text
-docker exec miner miner info height
-```
-
-In other words, prepend `docker exec miner` to any of the commands documented in
-the
-[using a miner section](/mine-hnt/build-a-packet-forwarder/#using-the-miner)).
-Or create an alias such as: `alias miner="docker exec miner miner"`
-
-### Updating the Docker Image
-
-From time to time, the Helium Miner is updated. Keep tabs on
-[the releases here](https://github.com/helium/miner/releases). Depending on
-whether you are running a miner for fun, to route packets, or to participate in
-POC, keeping it updated may be more or less urgent. Each release tagged on the
-Github will be on the quay repository. Simply remove the current image:
-
-```text
-docker stop miner && docker rm miner
-```
-
-And start the container again as described above, but with the new release tag!
-Thanks to the `--mount` option, the blockchain data and the miner keys are
-preserved through updates.
-
-### Using the Miner
-
-These commands will assume you are running in Docker and they have the same
-prefix to get you executing a command within the docker: `docker exec miner` .
-If you want to make it easier, you can always create an an alias such as:
-`alias miner="docker exec miner miner"`.
-
-#### Checking the Logs
-
-This is always helpful to get some idea of what's going on:
-
-```text
-docker exec miner tail -F /var/data/log/console.log
-```
-
-Also, if you are particularly interested in radio traffic, it can be helpful to
-filter for `lora` as so:
-
-```text
-docker exec miner tail -f /var/data/log/console.log | grep lora
-```
-
-### Checking the P2P Network
-
-This is the first health check you can do to see how your Miner is doing. Is it
-finding other Helium miners over libp2p properly?
-
-The Helium blockchain uses an Erlang implementation of
-[libp2p](https://libp2p.io/). Because we expect Hotspot hardware to be installed
-in a wide variety of networking environments
-[erlang-libp2p](https://github.com/helium/erlang-libp2p) includes a number of
-additions to the core specification that provides support for NAT detection,
-proxying and relaying.
-
-The first order of business once the Miner is running is to see if you're
-connected to any peers, whether your NAT type has been correctly identified, and
-that you have some listen addresses:
-
-```text
-docker exec miner miner peer book -s
-```
-
-You will see an output roughly like the following:
-
-```bash
-+--------------------------------------------------------+------------------------------+------------+-----------+---------+------------+
-| address | name |listen_addrs|connections| nat |last_updated|
-+--------------------------------------------------------+------------------------------+------------+-----------+---------+------------+
-|/p2p/11dwT67atkEe1Ru6xhDqPhSXKXmNhWf3ZHxX5S4SXhcdmhw3Y1t|{ok,"genuine-steel-crocodile"}| 2 | 4 |symmetric| 3.148s |
-+--------------------------------------------------------+------------------------------+------------+-----------+---------+------------+
-
-+----------------------------------------------------------------------------------------------------------------------------+
-| listen_addrs (prioritized) |
-+----------------------------------------------------------------------------------------------------------------------------+
-|/p2p/11apmNb8phR7WXMx8Pm65ycjVY16rjWw3PvhSeMFkviWAUu9KRD/p2p-circuit/p2p/11dwT67atkEe1Ru6xhDqPhSXKXmNhWf3ZHxX5S4SXhcdmhw3Y1t|
-| /ip4/192.168.3.6/tcp/36397 |
-+----------------------------------------------------------------------------------------------------------------------------+
-
-+--------------------------+-----------------------------+---------------------------------------------------------+------------------------------+
-| local | remote | p2p | name |
-+--------------------------+-----------------------------+---------------------------------------------------------+------------------------------+
-|/ip4/192.168.3.6/tcp/36397|/ip4/104.248.122.141/tcp/2154|/p2p/112GZJvJ4yUc7wubREyBHZ4BVYkWxQdY849LC2GGmwAnv73i5Ufy|{ok,"atomic-parchment-snail"} |
-|/ip4/192.168.3.6/tcp/36397| /ip4/73.15.36.201/tcp/13984 |/p2p/112MtP4Um2UXo8FtDHeme1U5A91M6Jj3TZ3i2XTJ9vNUMawqoPVW| {ok,"fancy-glossy-rat"} |
-|/ip4/192.168.3.6/tcp/36397| /ip4/24.5.52.135/tcp/41103 |/p2p/11AUHAqBatgrs2v6j3j75UQ73NyEYZoH41CdJ56P1SzeqqYjZ4o | {ok,"skinny-fuchsia-mink"} |
-|/ip4/192.168.3.6/tcp/46059| /ip4/34.222.64.221/tcp/2154 |/p2p/11LBadhdCmwHFnTzCTucn6aSPieDajw4ri3kpgAoikgnEA62Dc6 | {ok,"skinny-lilac-mustang"} |
-+--------------------------+-----------------------------+---------------------------------------------------------+------------------------------+
-```
-
-As long as you have an address listed in `listen_addrs` and some peers in the
-table at the bottom, you're connected to the p2p network and good to go.
-
-If you are having trouble, try forwarding port `44158` to the miner. On AWS,
-double check your security group settings.
-
-### Checking Block Height
-
-As long as a genesis block is loaded, this query will work and return height 1
-at least:
-
-```text
-docker exec miner miner info height
-```
-
-If you are syncing, you should see something like this:
-
-```text
-~$ miner info height
-6889 280756
-```
-
-The first number is the election epoch and the second number is the block height
-of your miner. If you just launched an AMI instance, your Miner is been
-disconnected, or you simply have a slow connection, you may be a few blocks
-behind. To check, you can either check the mobile app, check
-[the browser-based block explorer](https://network.helium.com/blocks), or run a
-simple curl command to check in a Terminal:
-
-```text
-~$ curl https://api.helium.io/v1/blocks/height
-{"data":{"height":280756}}
-```
-
-### Backing Up Your Swarm Keys
-
-Periodically, we may release updates or you may want to migrate your miner from
-one machine to another. The most important thing is that you maintain a copy of
-your miner's private key, i.e. `swarm_key`. Fun tidbit: this is also how your
-three-word name is generated.
-
-Assuming you've mounted the Docker image as detailed above, it is located at:
-
-```text
-~/miner_data/miner/swarm_key
-```
-
-Another fun tidbit: for production hotspots sold by Helium, the swarm key is
-stored inside of a secure element and is thus unable to be migrated \(or
-compromised/accidentally lost unless physically damaged\).
-
-### Snapshots
-
-Snapshots are summaries of the current state of the blockchain. Since you don't
-need every single block ever to sync with the blockchain, it's really just a
-summary of the last few blocks and the account balance of every account on the
-blockchain.
-
-You generally want to be careful who you accept snapshots from as they might
-give you an incorrect state. However, we also store hashes of valid snapshots in
-the blockchain.
-
-#### Chain-based
-
-You can query a running Miner to see what snapshots it (1) knows about and (2)
-has a copy of:
-
-```text
-$ miner snapshot list
-Height 731521
-Hash <<129,14,18,225,133,83,34,24,205,69,10,10,84,42,129,207,42,186,18,28,192,
- 157,187,76,109,233,4,108,198,197,111,176>>
-Have true
-
-Height 730801
-Hash <<80,90,115,7,10,195,115,217,87,173,24,11,63,116,201,22,150,6,252,168,204,
- 60,65,83,106,68,94,19,7,13,72,165>>
-Have true
-```
-
-A Miner knows about a snapshot in two ways: it either syncs a block where the
-snapshot hash and height have been saved, or the configuration file of the Miner
-(`sys.config`) has the **blessed** height and hash written into it (ie:
-`blessed_snapshot_block_height` and `blessed_snapshot_block_hash`).
-
-If you have a fully synced Miner, you can extract these values from
-`snapshot list` and write them into the `sys.config` of another non-fully synced
-Miner. Restart the Miner to reload the `sys.config` and it will be able to
-"quick sync" to that snapshot. To make things go even faster, try manually
-connecting your Miner to one of your Miners that has the snapshot.
-
-```text
-miner peer connect /ip4/192.168.0.0.1/tcp/44158
-```
-
-The only down-side of this approach is that snapshots happen at some rhythm
-defined by the blockchain (currently 720 blocks). You can use the manual
-approach to pass around arbitrary snapshots by hand.
-
-#### Manual
-
-You can also manually move a snapshot file around. To take a snapshot:
-
-```text
-miner snapshot take /path/to/snapshot
-```
-
-Naming the snapshot something like `snap-XXXXXX`, where `XXXXXX` is the height
-of the blockchain is a typical convention. Also, when using a Docker container,
-it's usually a good idea to save the snapshot to `/var/data` so that you can
-easily copy the snapshot out of the Docker and into the host system.
-
-Loading the snapshot is as follows:
-
-```text
-miner snapshot load /path/to/snapshot
-```
-
-Sometimes the load command times out. If so, try to tail the logs and see if
-blocks are being applied. It's working just fine! It just needs a moment to
-finish loading the snapshot.
-
-## Connecting a Packet Forwarder to the Miner
-
-You're almost done. The last step after you have your Miner running is to
-connect to it.
-
-With your favorite editor, open `global_conf.json` that lives in the packet
-forwarder directory:
-
-```text
-nano ~/sx1302_hal/lora_pkt_fwd/global_conf.json
-```
-
-You want to change the field "server_address" from "localhost" to the IP address
-of the server, so in this case:
-
-You'll need to restart the packet forwarder for the configuration change to take
-effect.
-
-To verify that things are working, you can follow the logs on your miner. eg:
-
-```text
-docker exec miner tail -f /var/data/log/console.log | grep lora
-```
-
-At the very least, you should see PULL_DATA messages every few seconds. If so,
-then you've done it!
diff --git a/docs/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet.mdx b/docs/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet.mdx
deleted file mode 100644
index 2e0560ee3..000000000
--- a/docs/mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet.mdx
+++ /dev/null
@@ -1,84 +0,0 @@
----
-id: burn-hnt-to-maker-wallet
-sidebar_label: Burning HNT to Maker Wallet
-slug: /mine-hnt/full-hotspots/become-a-maker/burn-hnt-to-maker-wallet
----
-
-# Burning HNT to Your Maker Wallet
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-Any [approved Hotspot Maker](/mine-hnt/hotspot-makers/approved-makers) is responsible for supplying Data Credits (DCs) to the onboarding server for Hotspots they sell. They do this by burning HNT to their
-specific maker address.
-
-:::info
-
-A full list of approved maker wallet addresses [can be seen via this API](https://onboarding.dewi.org/api/v2/makers).
-
-:::
-
-## Maker Wallet Address Integration
-
-As an approved Maker, you will supply DeWi with the onboarding details for all the Hotspots you manufacture and distribute. In turn, the DeWi adds them to the onboarding server. When a Hotspot is onboarded by your end customer, the onboarding server knows to associate it with your Maker ID, and associated Maker Wallet address. If, when a Hotspot is onboarded, it's present in the onboarding server and you have ample Data Credits to pay the onboarding fees, the blockchain will add the Hotspot. And if you've [integrated your Hotspot in the Hotspot App onboarding flow](/mine-hnt/hotspot-makers/hotspot-integration-testing), the Wallet knows to use your approved Maker Wallet address. At this point, the Data Credits will be used for the transactions with your wallet address as the payer.
-
-
-## Hotspot Data Credit Fees
-
-In order for any Hotspot to join the Helium Blockchain, its maker address must have sufficient Data Credits. A full list of [Helium blockchain data credit fees can be found here](/blockchain/transaction-fees). Hotspot Makers need to account for at least `5,135,000` total Data Credits per Hotspot. Specifically, for each Hotspot, a Maker must supply:
-
-* `4,000,000` Data Credits for the **Add Hotspot** transaction. This is a one-time fee.
-* `65,000` Data Credits for the transaction fee to execute the **Add Hotspot** transaction.
-* `1,000,000` Data Credits for the **Assert Location** transaction. Each Hotspot Maker is required to supply at least one **Assert Location* for their Hotspots.
-* `70,000` Data Credits for the transaction fee to execute the **Assert Location** transaction.
-
-As a Maker, if you only supply the one-time **Add Hotspot** fee and one **Assert Location** fee, you'll supply `5,135,000` total Data Credits per Hotspot. Add `1,070,000` Data Credits for each additional **Assert Location** fee you wish to supply.
-
-:::warning
-
-If your wallet address does not have enough DCs to pay the required Hotspot transaction fees, these transactions will fail.
-
-:::
-
-
-## Maker Integration Test Wallet Address
-
-During the course of your testing, you can use the Maker Integration Test wallet address created by the DeWi. This wallet does not contain any Data Credits so onboarding transactions will fail but it allows you to smoke test the onboarding steps. Here is that address:
-
-[https://explorer.helium.com/accounts/138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr](https://explorer.helium.com/accounts/138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr)
-
-
-## Burning HNT to Supply Data Credits
-
-:::warning
-
-Once you burn HNT to a specified wallet address, they are lost and gone forever. The resulting DCs are non-transferable. Please double-check any wallet address before executing any HNT burn.
-:::
-
-
-The actual mechanism for burning HNT to DCs is via an on-chain burn transaction [using the Helium Blockchain Wallet CLI](https://github.com/helium/helium-wallet-rs). Follow the instructions to download and install the CLI Wallet on your local machine. Once installed, you'll use the `burn` command to supply data credits to your specified maker wallet.
-
-You can run `$ helium-wallet burn -h` for a full print-out of what options are available, but here's the basic command structure:
-
-```shell
-$ helium-wallet burn --amount ![]({useBaseUrl("img/mine-hnt/qr-onboarding-1.png")})
-
-![]({useBaseUrl("img/mine-hnt/qr-onboarding-2.png")})
-
-
-## Web Onboarding
-Web Onboarding allows Makers to generate a partial `add_gateway` transaction outside of the Maker App. Makers generate a deep link back to the Helium App/Maker App to finish the `add_gateway` transaction.
-[Read more about deep linking](https://docs.helium.com/wallets/app-wallet/deep-links-and-qr-codes/).
-
-To select Web onboarding, in the `hotspot.ts` file, specify `web` in `onboardType`.
-
-* [View the example in the Maker Starter app](https://github.com/helium/maker-starter-app/blob/main/src/makers/example/hotspots.ts)
-* [View the example in the Hotspot App](https://github.com/helium/hotspot-app/blob/bbcf058844965e6501295643b95021b6ef26b280/src/makers/__example__/hotspots.ts#L41)
-
-## Bluetooth Pairing
-
-The Maker App will start scanning for broadcasting Hotspots. Makers will need to update the `localname` with the product name and include the last 6 digits of the MAC identifier. The character limit is 170 but we do not recommend anyone go beyond 25-30 characters in the product name.
-
-The `localname` is the name used on the **Found Hotspots** page.
-
-To select Bluetooth onboarding, in the `hotspot.ts` file, specify `BLE` in `onboardType`.
-
-* [View the example in the Maker Starter App](https://github.com/helium/maker-starter-app/blob/f15a887afead44f2c0bba6ac7460cffebe02dc03/src/makers/example/hotspots.ts#L6)
-* [View the example the Hotspot app](https://github.com/helium/hotspot-app/blob/bbcf058844965e6501295643b95021b6ef26b280/src/makers/__example__/hotspots.ts#L8)
-* [Read more about BLE Services](/mine-hnt/full-hotspots/become-a-maker/hotspot-ble-services).
-
-# Constructing the Add Gateway Transaction
-
-If you’re using [Helium’s miner image](https://github.com/helium/miner), constructing a transaction is relatively easy.
-
-Every Hotspot on the blockchain goes through two transactions:
-* **add hotspot**: links the Hotspot's key (`swarm_key`) to a
-user's wallet
-* **assert location**: provides GPS location, elevation (in meters), and dBi antenna
-output for the Hotspot
-
-## Generate an Add Hotspot Transaction
-Use `miner` to generate the `add hotspot` transaction,
-
-```
-miner txn add_gateway owner=WALLET_ADDRESS --payer WALLET_ADDRESS
-```
-
-For testing, you'll set `payer` as `payer = 138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr`. In production, the Payer will be your unique Maker Account Address and will be provided at the appropriate stage with the Manufacturing Oversight Committee. The current list can be found [here](https://onboarding.dewi.org/api/v2/makers).
-
-When testing with this `payer` address, adding hotspots and asserting location transactions will be submitted and you’ll see them as pending transactions in the Hotspot App. However, once it reaches the blockchain, the transaction will be discarded as the payer address does not exist in the blockchain’s `chain_var` of valid addresses. This ensures no Data Credits are spent on testing, but allows trial and error as Makers finish app integration.
-
-Once you have the transaction, you will pass it onto the Helium app to sign the transaction. Once submitted, you can view the pending transaction using this API:
-
-* [https://api.helium.io/v1/accounts/138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr/pending_transactions](https://api.helium.io/v1/accounts/138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr/pending_transactions)
-
-The output is a JSON object:
-
-```
-{
- "address": "11TL62V8NYvSTXmV5CZCjaucskvNR1Fdar1Pg4Hzmzk5tk2JBac",
- "fee": 65000,
- "mode": "full",
- "owner": "14GWyFj9FjLHzoN3aX7Tq7PL6fEg4dfWPY8CrK8b9S5ZrcKDz6S",
- "payer": "138LbePH4r7hWPuTnK6HXVJ8ATM2QU71iVHzLTup1UbnPDvbxmr",
- "staking fee": 4000000,
- "txn": "CrkBCiEBrlImpYLbJ0z0hw5b4g9isRyPrgbXs9X+RrJ4pJJc9MkSIQA7yIy7F+9oPYCTmDz+v782GMJ4AC+jM+VfjvUgAHflWSJGMEQCIGfugfLkXv23vJcfwPYjLlMyzYhKp+Rg8B2YKwnsDHaUAiASkdxUO4fdS33D7vyid8Tulizo9SLEL1lduyvda9YVRCohAa5SJqWC2ydM9IcOW+IPYrEcj64G17PV/kayeKSSXPTJOMCEPUDo+wM="
-}
-```
-The `txn` output is then passed onto the Helium App over BLE, in QR code format, or through a deep link in this format: `helium://add_gateway/![]({useBaseUrl("img/mine-hnt/validator-hotspot-dev.jpg")})
-
-## Code and Development
-
-The bulk of the code that enables Light Hotspots on actual LoRaWAN gateways is
-called [gateway-rs](https://github.com/helium/gateway-rs). It's easiest to think
-of this as Helium's next-generation packet forwarder.
-
-Development of this code takes place in the above GitHub repo, as well at the
-`#gateway-developement` channel on the
-[Helium Discord Server](https://discord.gg/helium).
-
-# Development Timelines
-
-- **March 18 2021**: Data Only Hotspots routes free packets
-- **July 8 2021**: Hotspot Consensus work moves to Validators
-- **July 20 2021**: Data Only Hotspots activated on Helium Network (appears on chain)
-- **October 11 2021**: Data Only Hotspots mine HNT
-- **December 2021**: Validators creating challenges for software-based miners on Testnet
-- **January 2022**: Hardware Audit starts for Light Hotspot manufacturers
-- **February 2022**: Introduce hardware-based Hotspots on Testnet (Full Hotspots running Light Hotspot firmware). Validators create challenges using H3dex targeting.
-- **Tentative: End of Q1 2022**: All HIP-19 Approved Makers participating in Testnet
-
-Assuming HIP 54 and HIP 55 pass without additional changes
-
-- **Tentative: Q1/Q2 2022**: Code related to Light Hotspot merged to production, in an inactive state
-- **Several weeks later**: Activate set of chain variables to enable Light Hotspots on Mainnet
-- **Several weeks later**: Deactivate Miner on Light Hotspots on Mainnet such that they run gateway-rs only
-
-## Current progress on Testnet
-Hardware-based Hotspots are now participating in a new Proof-of-Coverage with Validators on Testnet. In this test, all Hotspots use Testnet Validators for blockchain information and do not need to sync the blockchain directly. They also receive PoC Challenges from Validators.
-
-You can see their progress on [Testnet](https://testnet-explorer.helium.com).
-
-These Hotspots are also running a dockerized version of [gateway-rs (rust-based gateway firmware)](https://github.com/helium/gateway-rs) and an updated packet forwarder that relies on Validators.
-
-*Note that these Hotspots are earning testnet tokens (TNT) and not HNT.*
-
-## Current progress on Mainnet
-A portion of the complete Light Hotspot software is also on mainnet, transferring non-PoC packets on a test Hotspot using the new packet forwarder that relies on Validators.
-
-### What's Next
-Invite all Makers to participate in our Testnet test by supplying a tag on [Quay, our image distribution tool, for Makers using Docker](https://quay.io/repository/team-helium/testnet?tag=latest&tab=tags).
diff --git a/docs/mine-hnt/maker-apps.mdx b/docs/mine-hnt/maker-apps.mdx
deleted file mode 100644
index ff11d529b..000000000
--- a/docs/mine-hnt/maker-apps.mdx
+++ /dev/null
@@ -1,41 +0,0 @@
----
-id: maker-apps
-title: Maker Apps
-sidebar_label: Maker Apps
-slug: /mine-hnt/maker-apps
----
-
-# Maker Apps
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-This document describes what Maker apps are and how users interact with them on the Helium Network.
-
-Beginning March 2022, all [HIP-19](https://github.com/dewi-alliance/hotspot-manufacturers#readme) Hotspot Manufacturers (aka Makers) are required to support their customers with a bespoke Mobile App to onboard their Hotspots, maintain their Hotspots with diagnostic tools, and various basic troubleshooting tools.
-
-Maker Apps can also include extra enhancements such as Proof-of-Coverage analysis, earnings tools, and more.
-
-For more information, [read our blog post announcing this change](https://blog.helium.com/the-future-of-hotspot-apps-and-wallets-in-the-helium-ecosystem-a5b904b01d62).
-
-
-## SDKs and Starter Apps
-
-To assist Makers in developing their apps, an SDK and supporting libraries are available. An example starter app is also open-sourced for forking and further customization.
-
-### React Native SDK
-
-The Helium React Native SDK is a collection of modules that can be used by a React Native application to interact with Hotspots and the Helium Blockchain. It has first class support for Typescript.
-
-[Read the full documentation](https://helium.github.io/react-native-helium/index.html)
-
-### Maker Starter App
-
-The [Maker Starter App](https://github.com/helium/maker-starter-app) includes support for deeplinking to the Helium Wallet App to sign transactions, removing any requirements for users to enter their 12 word seed phrase into the Maker App. **This is a security precaution and prevents potential lost of funds and Hotspots, as the seed phrase acts as a user's private key on the blockchain.** If you find a Maker app that asks for your seed phrase, do not trust it.
-
-#### Features
-The following features are supported in the Maker Starter App:
-- Add a Hotspot
-- Set a Location (including gain and elevation)
-- Transfer a Hotspot
-- Settings with PIN Code and language selection
-- Deeplinking to [Helium Wallet](/wallets/app-wallet) to sign transactions
diff --git a/docs/mine-hnt/mine-hnt.mdx b/docs/mine-hnt/mine-hnt.mdx
deleted file mode 100644
index ec30c3626..000000000
--- a/docs/mine-hnt/mine-hnt.mdx
+++ /dev/null
@@ -1,97 +0,0 @@
----
-id: mine-hnt
-hide_title: true
-sidebar_label: Introduction
-slug: /mine-hnt
-hide_table_of_contents: true
----
-
-
-
-
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-
-
-
-
-
-
-
-
-
- ![]({useBaseUrl("img/mine-hnt/minehnticon.png")})
-
-
-
-
- Mine HNT
-Helium Hotspots mine $HNT and were originally built by Helium, Inc. but are now built by our growing ecosystem of approved manufacturers.
- -
-
-
-
-
-
-
- Hotspots
-
-
-
- Want to help build the largest IoT network in the world? Want to provide coverage to IoT devices and earn HNT while you do?
-Check out some of these quick links for help getting started or join us in the #gateway-development channel on our Discord.
-
-
-
-
-
-
- Full Hotspots
-These Hotspots maintain a full copy of the HNT blockchain, Participate in Proof of Coverage rewards, and get rewarded for forwarding Data Packets. Details can be found here.
-
-
-
-
- Light Hotspots
-These Hotspots use Validators to get information about the HNT blockchain, Participate in Proof of Coverage rewards, and get rewarded for forwarding Data Packets. Details can be found here.
-
-
-
-
- Data Only Hotspots
-These Hotspots use Validators to get information about the HNT blockchain, and get rewarded for forwarding Data Packets. Details can be found here.
-
-
-
-
- Maker Apps
-Makers have their own App to perform Hotspot onboarding, diagnostics, and troubleshooting. Read more here.
-
-
diff --git a/docs/mine-hnt/validators/faqs-resources-providers.mdx b/docs/mine-hnt/validators/faqs-resources-providers.mdx
deleted file mode 100644
index ec59f54d2..000000000
--- a/docs/mine-hnt/validators/faqs-resources-providers.mdx
+++ /dev/null
@@ -1,128 +0,0 @@
----
-id: validators-faqs-resources-providers
-title: FAQs, Resources, and Providers
-sidebar_label: FAQs, Resources, and Providers
-slug: /mine-hnt/validators/faqs-resources-providers
----
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-## FAQs
-
-### General
-
-**How much HNT does it require to stake and become a validator?**
-
-10,000 HNT.
-
-**What’s the minimum number of validators needed to go to Mainnet?**
-
-The current proposal is 100 with no maximum number of validators that can participate. We will activate a separate chain variable when we reach the proposed minimum which will enable Consensus Group election from the validator pool.
-
-**Is there a validator cap?**
-
-No.
-
-**How many validators are elected to the consensus group?**
-
-Currently 43. Check the [block explorer](https://explorer.helium.com/validators) for latest consensus group size.
-
-**When a validator is in the consensus group can I update it?**
-
-Yes. There are no issues with updating a validator while it's in the consensus group.
-
-**My validator is connected. Why can't I see it in the Explorer?**
-
-API status updates can take up to 10 minutes for fully connected nodes.
-
-### Technical
-
-**Why do you [discourage running validators from home](/mine-hnt/validators/requirements)?**
-
-Many community members possess hardware that easily meets or exceeds the recommended CPU, memory, and storage guidelines. However, most home users rely on residential internet service providers. This is potentially problematic for the following reasons:
-
-* Residential ISPs rarely offer service level agreements (SLA) that guarantee network uptime. If your neighborhood experiences a service outage due to headend hardware failure, software misconfiguration, or your neighbor trenching their front lawn and slicing a fiber line, you will need to wait for service to return just like any other residential customer.
-* Most residential ISPs lack distributed denial of service (DDoS) or denial of service (DoS) protection. If a bad actor decides to target your public IP address with a botnet, you may see your cable modem, DSL modem, or optical network terminal crash spectacularly. You may not have control over the assignment of a new public IP address, so power-cycling your modem may not allow you to recover from a continuous attack. Remember, your public IP is broadcast across the helium peer-to-peer network when you connect.
-* Your ISP may implement QoS (Quality of Service) or traffic shaping policies that dynamically prioritize or deprioritize certain types of traffic without your knowledge. This could potentially impact latency between your validator nodes and other nodes in a consensus group. Bad latency can result in your eviction from a consensus group.
-* Bad actors may target your public IP address with port scanners or other scanning techniques to identify entry points. Outdated router software, poor port management, or zero-day exploits could put your entire home network (including your personal computers, crypto wallets, mobile devices, and IoT devices) at risk for attack and compromise.
-* Your ISP may automatically throttle your connection speed if the sustained traffic or connection load exceeds a value that could negatively impact the performance of other customers in your neighborhood.
-
-Despite the warnings above, some community members will decide to run their validator from home. Remember that Helium is not responsible for security, performance, or network issues that may result from your validator configuration.
-
-### Rewards
-
-**What is the expected APR of running Helium validator?**
-
-It depends on the number of validators and how often a validator is randomly chosen to participate in the consensus group. Validators split the Consensus Group reward, [which is 6% of all HNT mined](/blockchain/mining/#hnt-distributions-per-epoch).
-
-The community has produced several models which should be instructive. Please do your own analysis before deciding to stake.
-
-* [Basic $HNT Projections Model](https://docs.google.com/spreadsheets/u/1/d/1C0Tsz31Qa2b8PHXrl0gMDh2_fXcd2qSWVgF0hmg9Hqg/edit#gid=63991307)
-* [Helium Validator Rewards Forecasting with Validator Ramp Calculations](https://docs.google.com/spreadsheets/d/1E4XLpF-a3xo3ZtNpJzd9g6EcuMZ1nSKKvtmKy_LVjhE/edit#gid=1705424601)
-
-**When can I get my validator rewards?**
-
-There is no rewards distribution lock up. After staking, validators elected into the consensus group immediately receive rewards at the end of that epoch.
-
-### Staking and Unstaking
-
-**What happens when I unstake a validator?**
-
-It enters an unbonding state for approximately 5 months (250,000 blocks) and cannot be restaked. During this state the **validator does NOT earn rewards and the staked amount cannot be transferred or withdrawn**. After the unbonding state has passed, the stake is returned to the original owner’s wallet.
-
-**Is overstaking permitted? If so, what’s the benefit?**
-
-Initially there will be no overstaking. We'll decide later, via the HIP process, what kind of overstaking the network should allow and what it will mean for election into the Consensus Group and ultimately rewards.
-
-**Can I restake an unstaked validator?**
-
-No. Once a validator has been unstaked it cannot be restaked.
-
-**Can I transfer stake to an existing validator node that had been previously staked?**
-
-No.
-
-**If a validator is in the consensus group, can I unstake it or transfer stake?**
-
-No. You must wait until the validator is out of the consensus group.
-
-## Resources
-
-### Videos
-
-* [HIP25 Hips Don't Lie](https://www.youtube.com/watch?v=qOEAxXaANkI) - An in-depth discussion of [HIP25](https://github.com/helium/HIP/blob/master/0025-validators.md), the foundational HIP for validators.
-* [Validator Staking Tutorial](https://www.youtube.com/watch?v=S3eIIAPP9rk) - Full video guide on how to deploy a Validator from `jcarl`.
-* [Validator Quickstart](https://www.youtube.com/watch?v=4szCWSDowro) - Short overview from `joey` on how to deploy and stake a Validator.
-* [Staking provider comparison](https://www.youtube.com/watch?v=pnW72u3ysbo) - Courtesy of **@MattLong6**. [HNT Staking Vendors](https://docs.google.com/spreadsheets/d/1xl5IjZY3xeAXTmnbLk2Ynedb9Ssd6yxRBwHixJQg8xM)
-
-## Staking Providers
-
-:::info
-
-Links to these Staking Providers are provided as is. Helium, Inc. is not directly associated with any of the following vendors and makes no endorsements about the quality of their offering.
-Additionally, any pricing details listed here are likely to be out of date. Please verify pricing details with the given staking provider.
-
-:::
-
-| Provider | Non-custodial full node | Pooling | Pricing | Notes
-| :----------------------------------------------------------- |:----------------------- |:----------- | :-------------------------------------------------------------------|:-----
-| [Allnodes](https://www.allnodes.com) | Yes | No | $80 per month (Basic) or $0.2380 per hour (Advanced) |
-| [Argon.build](https://www.argon.build) | Yes | No | 3% comission on earnings |
-| [Bison Trails](https://www.bisontrails.co) | Yes | No | | Does not offer service to individuals who plan to run fewer than 10 nodes
-| [Blockdaemon](https://blockdaemon.com/) | Yes | No | 5% commission with flexible payment options | Cloud offerings.
-| [Chorus One](https://chorus.one/products/whitelabel-staking) | Yes | No | | Does not have public pricing.
-| [DLI](https://dlinodes.com) | Yes | Yes | All run in DLI Cloud, Staking, Nodes, 24/7 Support |
-| [Figment](https://figment.io/) | Yes | No | 5% comission |
-| [Foundry Digital](https://foundrystaking.com/) | Yes | No | $150 per month |
-| [Helium Rising](https://www.heliumrising.com) | Yes | Yes | 5% comission |
-| [Helium Staking](https://www.helium-staking.com) | Yes | Yes | $150 per month for non-custodial full node. 4% of rewards for pool. |
-| [HNT Staking](https://www.hntstaking.net) | Yes | Yes | $149 per monthly or $3 per day + 3% commission on earnings" |
-| [HNT Validators](https://www.hntvalidators.com) | Yes | No | $199 per month |
-| [HostNodes](https://hostnodes.online) | Yes | No | $119 per month| 10% discount for 6 months plan, 20% discount for 1 year plan
-| [Multipool App](https://www.multipool.app) | Yes | Yes | $120 per month for non-custodial full node or pool $120 shared between participants + 1.2% comission on earnings | 100 HNT min @ $1.2 (per 100 HNT increment)
-| [NodeValidators](https://nodevalidators.com) | Yes | Coming soon | $120 per month + 2.5% comission on earnings |
-| [Staked](https://staking.staked.us/helium-staking) | Yes | No | | Does not have public pricing.
-| [StakeJoy](https://stakejoy.com) | Yes | No | 3% comission on earnings |
-| [StakeMyHNT](https://www.stakemyhnt.com) | Yes | Coming soon | $169 per month |
-| [Validators Pool](https://helium.bx-host.com) | Yes | No | $120 per month + 2% comission on earnings |
-| [Vanager](https://vanager.io) | No | Yes | $4 per day + 3% comission on earnings |
diff --git a/docs/mine-hnt/validators/mainnet/deployment-guide.mdx b/docs/mine-hnt/validators/mainnet/deployment-guide.mdx
deleted file mode 100644
index 4ba67a07a..000000000
--- a/docs/mine-hnt/validators/mainnet/deployment-guide.mdx
+++ /dev/null
@@ -1,510 +0,0 @@
----
-id: validators-mainnet-deployment-guide
-title: Validator Deployment Guide - Mainnet
-sidebar_label: Deployment Guide - Mainnet
-slug: /mine-hnt/validators/mainnet/deployment-guide
----
-
-import useBaseUrl from "@docusaurus/useBaseUrl";
-
-This guide will cover the end-to-end process of deploying a Helium Validator on Mainnet. It assumes you're starting from scratch. At the end, you'll have a Helium Validator deployed on the Network.
-
-
-:::info
-
-If at any point during this process you need assistance or have general questions, please join the `#validator` channel on [Helium Discord](https://discord.gg/helium).
-
-:::
-
-## Prerequisites
-
-To successfully deploy a Helium Validator, you'll need to do the following:
-
-- Install the [Helium CLI Wallet](https://github.com/helium/helium-wallet-rs). You are welcome to build from source, but easiest to download the latest binary release.
-- Deploy a virtual server on a cloud service like AWS, GCP, Azure, or Digital Ocean. Or deploy a physical server on which to run the Validator. [The recommended hardware and networking requirements can be found here](/mine-hnt/validators/requirements/).
-
-## Create Wallet
-
-Once you have your [Helium CLI Wallet](https://github.com/helium/helium-wallet-rs) installed locally, it's time to create your Helium Wallet. Run the following command to create it. (This command format assumes you're using the executable. If you've built the wallet from source it'll look slightly different.)
-
-At any time use -h or --help to get more help for a command.
-
-:::warning
-
-It is a best practice to create your Helium CLI wallet on a separate machine from the one where you will run your Validator.
-
-:::
-
-```
-helium-wallet create basic
-```
-
-You'll be prompted to supply a new passphrase to complete it. This is used to encrypt/decrypt the `wallet.key` file, and is needed to sign transactions. **Don't lose it.**
-
-This command will produce a `wallet.key` file on your machine, along with output similar to the following:
-
-```
-+-----------------------------------------------------+---------+--------+------------+
-| Address | Sharded | Verify | PwHash |
-+-----------------------------------------------------+---------+--------+------------+
-| 1aP7nm6mGLMFtgiHQQxbPgKcBwnuQ6ehgTgTN8zjFuxByzJ8eA5 | false | true | Argon2id13 |
-+-----------------------------------------------------+---------+--------+------------+
-```
-
-Next, run the `info` command to get all the relevant details.
-
-```
-helium-wallet info
-```
-
-The output will look similar to this:
-
-```
-+--------------------+-----------------------------------------------------+
-| Key | Value |
-+--------------------+-----------------------------------------------------+
-| Address | 1aP7nm6mGLMFtgiHQQxbPgKcBwnuQ6ehgTgTN8zjFuxByzJ8eA5 |
-+--------------------+-----------------------------------------------------+
-| Network | mainnet |
-+--------------------+-----------------------------------------------------+
-| Type | ed25519 |
-+--------------------+-----------------------------------------------------+
-| Sharded | false |
-+--------------------+-----------------------------------------------------+
-| PwHash | Argon2id13 |
-+--------------------+-----------------------------------------------------+
-| Balance | 0.00000000 |
-+--------------------+-----------------------------------------------------+
-| DC Balance | 0 |
-+--------------------+-----------------------------------------------------+
-| Securities Balance | 0.00000000 |
-+--------------------+-----------------------------------------------------+
-```
-
-## Each Validator Requires 10000 HNT
-
-Running a Validator on Mainnet requires a stake of `10000 HNT` per Validator. After you've created your wallet, transfer a little more than `10000 HNT` into it for each Validator you intend to run to cover the transaction fee.
-
-:::info
-
-As is the case with every transaction on the Helium blockchain, `staking` requires a small fee paid in Data Credits. [Read more about transaction fees here](/blockchain/transaction-fees).
-
-:::
-
-
-## Run a Validator
-
-With your wallet funded, it's time to deploy and run the actual Validator.
-
-:::warning
-
-If you haven't already, please review the [Validator Technical Requirements](/mine-hnt/validators/requirements). Specifically, on non-ARM systems `AVX` support is required. Verify that it exists on your host system by running the following:
-
-```
-grep avx /proc/cpuinfo
-```
-
-If nothing is returned from this command, your host system does not have AVX support and your Validator may not be stable.
-
-:::
-
-You have two options for deploying the Validator. You just need to do ONE of the following:
-
-- [Deploy the Validator Using Docker](#deploy-the-miner-using-docker)
-- [Build the Validator form Source](#deploy-miner-from-source)
-
-### Deploy the Validator Using Docker
-
-Start by updating your packager manager registry:
-
-```
-sudo apt-get update
-```
-
-And install Docker itself. (If needed, full directions on installing Docker on Ubuntu [can be found here](https://docs.docker.com/engine/install/ubuntu/).)
-
-```
-sudo apt-get install docker.io
-```
-
-To avoid needing to use Docker with `sudo` privileges, add your user to the docker group, replacing $USER with your username here:
-
-```
-sudo usermod -aG docker $USER
-```
-
-Log in and out of your account to apply these changes. You are now ready to use Docker.
-
-Now that docker is installed and ready, let's run the Validator.
-
-#### Run the Docker Container
-
-Before running the container for the first time, it is mandatory to pick a "system mount point". This allows you to easily maintain your Validator's blockchain identity - specifically `swarm keys` - and blockchain state through image updates. Without doing this, you will lose these items when upgrading docker images.
-
-The `validator` directory should be created on a persistent EBS volume (if you're using AWS) or something similar that lives across server lifetimes.
-
-```
-mkdir $HOME/validator_data
-```
-
-You can then use the `run` command to start your container for the first time:
-
-```
-docker run -d --init \
---restart always \
---publish 2154:2154/tcp \
---publish 8080:8080/tcp \
---name validator \
---mount type=bind,source=$HOME/validator_data,target=/var/data \
-quay.io/team-helium/validator:latest-validator-amd64
-```
-
-- `-d` option runs in detached mode, which makes the command return or not; you may want to omit if you have a daemon manager running the docker for you.
-- `--init` to indicate that an init process should be used as the PID 1 in the container. This ensures the usual responsibilities of an init system, such as reaping zombie processes, are performed inside the created container. When `docker exec` commands are run, it's possible for these to create zombie processes on the host. This eliminates that issue. You can read more about this [here](https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/) and [here](https://docs.docker.com/engine/reference/commandline/run/).
-- `--restart always` asks Docker to keep the image running, starting the image on boot and restarting the image if it crashes. Depending on how you installed Docker in your system, it'll start on boot.
-- `--publish 2154:2154/tcp` maps the port 2154 on the docker container to 2154 on the host machine. This allows inbound connections on port 2154 to the host machine to be routed to the validator container. In addition to this mapping, it is up to you to ensure that this port is available from the public internet to the host machine. This will require modifying firewall and/or security group settings in your cloud provider of choice.
-- `--publish 8080:8080/tcp` maps the port 8080 on the docker container to 8080 on the host machine. This allows inbound connections on port 8080 to the host machine to be routed to the validator container. In addition to this mapping, it is up to you to ensure that this port is available from the public internet to the host machine. This will require modifying firewall and/or security group settings in your cloud provider of choice.
-- `--name validator` names the container, which makes interacting with the docker easier, but feel free to name the container whatever you want.
-- `--mount` the parameters above will mount the container's `/var/data/` directory to the systems directory `$HOME/validator_data`. You will want this folder to be persistent across runs of the docker container as it will contain both the blockchain data and the miner key of your Validator.
-- `quay.io/team-helium/validator:latest-validator-amd64` Lastly, this points to the docker **_image_** for the Validator that is tagged as the "latest" for the amd64 architecture. For arm architectures, replace with `latest-validator-arm64`.
-
-Additional flags that may be helpful:
-
-- `-e "NAT_INTERNAL_IP=192.168.0.139"` If your host machine is behind a firewall that is performing network address translation (NAT), adding this flag will assist the Validator to quickly determine the IP address of the host machine. Replace the IP with yours from `ip addr`. This goes hand-in-hand with the following flag:
-- `-e "NAT_EXTERNAL_IP=$( curl -s ipv4.icanhazip.com )"` This also assists the Validator in quickly identifying the external IP of the NAT. The `curl` commmand simply queries an external provider and returns the public IP address of the interface. You can remove this and replace with your external IP if it is known and will not change (static IP).
-- Similar commands are available with `NAT_INTERNAL_PORT` and `NAT_EXTERNAL_PORT` if any port translations are occuring. If not, these may be omitted.
-
-Once you run the command above, docker will retrieve the latest Validator image, and start the docker process. Barring any errors, your Validator is running.
-
-:::info
-
-Please watch and respond to upgrade requests on the `#validators-announcements` channel on the [Helium Discord](https://discord.gg/helium) server in a timely manner.
-
-:::
-
-#### Upgrade your Docker container
-
-To do manual upgrades, the latest miner tag [can be found here](https://quay.io/repository/team-helium/validator?tag=latest&tab=tags).
-
-To upgrade your docker container to the latest version, do the following. These commands will stop the running container then delete it; pull an updated Validator docker image from the repository; and finally delete any out of date Validator docker images.
-
-```
-docker stop validator && docker rm validator
-
-docker pull quay.io/team-helium/validator:latest-validator-amd64
-
-docker image prune -f
-```
-
-Finally, re-launch docker with the same command as above under the [Run the Docker Container](#deploy-the-validator-using-docker) section.
-
-#### Interact with the Validator within the Container
-
-You may want to interrogate the Validator or interact with it. Docker's `exec` command enables this. For example:
-
-```
-docker exec validator miner info height
-```
-
-As shown above, you can prepend `docker exec validator` to any of the commands documented or create an alias such as
-
-```
-alias miner="docker exec validator miner"
-```
-
-And start the container again as described above, but with the new release tag.
-
-And thanks to the `--mount option`, the blockchain data and the validator keys are preserved through updates.
-
-:::info
-
-Now that you have your Validator running, you need to [actually Stake tokens to make it official.](#stake-tokens-to-your-validator)
-
-:::
-
-### Deploy Miner from Source
-
-Ok, brave soul. Here's what you'll need to build and deploy the miner from source:
-
-- miner
-- Erlang package (the latest 22 or 23 versions are supported, the 24 release candidate will NOT work)
-- `libwxgtk` package
-- git
-
-Before we get started, make sure you're fully up to date:
-
-```
-sudo apt-get update -y
-```
-
-Next, let's install all the things. Start by cloning the `miner` repo on GitHub:
-
-```
-git clone https://github.com/helium/miner.git
-```
-
-Then proceed to get you some Erlang (here we're specifying `22.3.1`):
-
-```
-wget https://packages.erlang-solutions.com/erlang/debian/pool/esl-erlang_22.3.1-1~ubuntu~bionic_amd64.deb
-```
-
-Next, get the `libwxgtk` package:
-
-```
-wget http://mirrors.kernel.org/ubuntu/pool/universe/w/wxwidgets3.0/libwxgtk3.0-0v5_3.0.4+dfsg-3_amd64.deb
-```
-
-And finish things off by acquiring a some wonderful dependencies:
-
-```
-sudo apt install -y libdbus-1-dev autoconf automake libtool flex libgmp-dev cmake libsodium-dev libssl-dev bison libsnappy-dev libclang-dev doxygen make cargo g++ libsctp1 libncurses5 libwxbase3.0-0v5 build-essential cmake libdbus-1-dev mosh vim parallel
-```
-
-Then we need to unpack and install all of this stuff. Start with `libwxgtk`:
-
-```
-sudo dpkg -i libwxgtk3.0-0v5_3.0.4+dfsg-3_amd64.deb
-sudo apt update -y
-```
-
-Then onto Erlang. First `unpack` then `install`:
-
-```
-sudo dpkg -i esl-erlang_22.3.1-1~ubuntu~bionic_amd64.deb
-```
-
-```
-sudo apt-get install -f
-```
-
-We also need to use a newer version of Rust. The one that comes by default with Ubuntu will not work.
-
-```
-#Remove rustc so we can install a newer version
-sudo apt -y remove rustc
-
-#Install newer version of rust
-curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- --default-host x86_64-unknown-linux-gnu --default-toolchain stable --profile complete -y
-
-#This allows you to proceed without loging out and loging in on the server
-source $HOME/.cargo/env
-```
-
-Then navigate to your `miner` directory:
-
-```
-cd miner
-```
-
-Build the `miner`
-
-```
-./rebar3 as validator release
-```
-
-Then start the `miner`:
-
-```
-_build/validator/rel/miner/bin/miner start
-```
-
-#### Load the Genesis Block
-
-One last step. When building from source, you'll need to manually load the Helium blockchain genesis block once your miner is deployed and running. To do this, run the following:
-
-```
-wget https://snapshots.helium.wtf/genesis.mainnet
-miner genesis load
-```
-
-Note that in the above `miner` command, the `miner` binary here is nested within `_build/validator/rel/miner/bin/miner`.
-
-#### A Note on Errors
-
-Source builders have sometimes reported error messages (after the miner has been running well for a while) referencing `Too many open files`. This can occur when a `ulimit` limitation is exceeded for the number of open files.
-
-You can check your soft limit (often `1024` by default) with:
-
-```ulimit -Sn```
-
-Specifics instructions to increase the `ulimit` vary by OS (readily found with a Google search) and are beyond the scope of this guide.
-
-#### Enable Firewall on the server
-
-It's good practice to restrict access to the server and you should allow access only to ports that are needed. If you also use node_exporter or a different type of exporter for monitoring you should add those ports as well.
-
-```
-#Enable Firewall
-sudo ufw enable
-
-#Allow connections to SSH Port. It's good practice to use a different port other than 22 for ssh connections
-sudo ufw limit 22/tcp
-
-#Allow connections to the Validator default port
-sudo ufw allow 2154/tcp
-
-#Allow connections for Light Hotspots
-sudo ufw allow 8080/tcp
-```
-
-## Stake HNT to Your Validator
-
-Now that your Validator node is running, the final step in the process is to formally stake HNT to your Validator. As part of the staking process the Validator address needs to both be in the staking transaction and sign the transaction. After a wallet stakes a validator node, the wallet becomes that node’s owner, has control over that validator node, and receives rewards.
-
-:::info
-
-First, double check your wallet balance to make sure you have the `10000` HNT required to stake, **along with a few extra to cover the transaction fees**.
-
-:::
-
-```
-helium-wallet balance
-
-+-----------------------------------------------------+----------------+--------------+-----------------+
-| Address | Balance | Data Credits | Security Tokens |
-+-----------------------------------------------------+----------------+--------------+-----------------+
-| 1aP7nm6mGLMFtgiHQQxbPgKcBwnuQ6ehgTgTN8zjFuxByzJ8eA5 | 10005.00000000 | 0 | 0.00000000 |
-+-----------------------------------------------------+----------------+--------------+-----------------+
-```
-
-To stake HNT, we need to get the validator node address. Obtain it using the following:
-
-```
-miner peer addr
-```
-
-The resulting output will look like this (except with your specific validator address). The string after `/p2p/` is your Validator address. For example:
-
-```
-/p2p/1YwLbGTCEhVbwKEehRVQRC8N3q35ydXTH1B6BQys5FB1paHssdR
-```
-
-We can now use this address with the Helium Wallet CLI `validators stake` command to formally stake the `10000 HNT` required **along with extra to cover the fee**. Here's the full command using the Validator address from above as an example. (**Make sure you replace it with yours.**)
-
-```
-helium-wallet validators stake one 1YwLbGTCEhVbwKEehRVQRC8N3q35ydXTH1B6BQys5FB1paHssdR 10001 --commit
-```
-
-After running this, you'll need to input your wallet passphrase to sign the transaction.
-
-And with that, you're done. Congratulations! You're running a Helium Validator on Mainnet!
-
-## Verifying Validator Victory
-
-Now that you're up and running with a Validator, there are a few things you can examine to make sure things are hunky dory.
-
-### Time Expectations
-
-The blockchain takes time. The distributed nature of verifying transactions into the blockchain takes time. The validator information gossiped on the blockchain takes time. APIs that run to update the [explorer](https://explorer.helium.com) are scheduled and have intervals. Basically, you won't be able to run the validator and instantly see that everything is "good".
-
-After the validator has been up and running for 15 minutes, proceed with some of the steps below.
-
-### Check the API
-
-The [Validator API](/api/blockchain/validators) provides several useful calls to help monitor your Validator and the state of the Mainnet.
-
-```
-https://api.helium.io/v1/validators/
-```
-
-or
-
-```
-https://api.helium.io/v1/validators/
-
-
-
-
- ![]({useBaseUrl("img/validators/runvalidator.png")})
-
-
-
-
- Validators
-Validators confirm blocks transactions are valid and properly placed on the chain. They also serve block chain data to Light and Data Only Hotspots.
- -![]({useBaseUrl("img/validators/schematic.png")})
-
-
-
-:::tip
-
-HNT staking has been enabled for Validators on Mainnet!
-
-:::
-
-Validators are a new entity on the Helium Blockchain that perform the work of the consensus group including verifying transactions and adding new blocks to the blockchain.
-
-## Mainnet
-
-* [Mainnet Deployment Guide](/mine-hnt/validators/mainnet/deployment-guide) - How to get up and running with your Validator on Mainnet. This guide covers staking, running, updating, and monitoring.
-* [Validator Mainnet Explorer](https://explorer.helium.com/validators) - The easiest way to monitor the Validator magic on Mainnet.
-* [Validator Releases](/mine-hnt/validators/mainnet/validators-release) - A description of the type and cadence for Validator releases.
-* [Wallet Commands](/mine-hnt/validators/mainnet/wallet) - Additional wallet commands for use with validators.
-
-:::warning
-
-**Testnet to Mainnet Migration**
-
-There is no direct migration path to move Testnet Validators to Mainnet. To deploy on Mainnet, follow the deployment guide listed above.
-
-:::
-
-## Testnet
-
-* [Expectations](/mine-hnt/validators/testnet/expectations) - Read this guide first. These are the expectations of Testnet validators.
-* [Design](/mine-hnt/validators/testnet/design) - Differences between the Testnet and the Mainnet.
-* [Testnet Deployment Guide](/mine-hnt/validators/testnet/deployment-guide) - How to get up and running with your Testnet validator. Including staking, running, updating, and monitoring.
-* [Wallet Commands](/mine-hnt/validators/testnet/wallet) - Additional wallet commands for use with validators.
-* [Test Cases](/mine-hnt/validators/testnet/test-cases) - Test cases and areas of focus for the Testnet.
-* [Testnet Explorer](https://explorer.helium.wtf/validators) - There is a new Explorer being developed by Helium and the community.
-
-## General Resources
-
-* [Technical Requirements](/mine-hnt/validators/requirements) - Information on the hardware, software, and network recommendations on hosting a validator.
-* [Monitoring](/mine-hnt/validators/monitoring) - Monitoring a Validator
-* [Troubleshooting](/mine-hnt/validators/troubleshooting) - Troubleshooting help and additional resources.
-* [Penalties](/mine-hnt/validators/penalties) - Overview of validator penalties.
-* [FAQs and Resources](/mine-hnt/validators/faqs-resources-providers) - Videos, FAQS, and details on commercial staking providers active in the community.
diff --git a/docs/network-data/api-providers.mdx b/docs/network-data/api-providers.mdx
new file mode 100644
index 000000000..63a56db11
--- /dev/null
+++ b/docs/network-data/api-providers.mdx
@@ -0,0 +1,55 @@
+---
+id: api-providers
+title: Helium API Providers
+pagination_label: API Providers
+sidebar_label: API Providers
+description: Helium API Provider Documentation
+image: https://docs.helium.com/img/link-image.png
+slug: /network-data/api-providers
+---
+
+## Helium Entity API
+
+Helium provides a basic API for accessing high-level data about entities on the network.
+
+- [Entity API Documentation](/network-data/entity-api)
+
+## Third-Party API Providers
+
+Helium's open on-chain data and Oracles enable third-party API providers to offer rich,
+production-grade access to network data. These providers power robust applications and services in
+the Helium ecosystem.
+
+### HeliumGeek
+
+HeliumGeek delivers a production-grade Helium API that blends on-chain and off-chain intelligence
+into a single, reliable service. The same endpoints that drive our mobile apps and fleet management
+platform power rewards tracking, Hotspot health monitoring, performance tracking, and custom vector
+map tiles with confidence, giving us hands-on insight into what Helium operators really need.
+
+By focusing exclusively on Helium, we absorb every protocol change and publish new data the moment
+it becomes available. Customers and clients lean on us for live dashboards and community explorers
+because we operate the API around the clock, bolster it with proactive monitoring, and back it with
+a track record of accuracy and stability that has supported the ecosystem since 2021.
+
+Flexible paid plans align with deployments ranging from boutique operations to nationwide fleets,
+ensuring the infrastructure scales without sacrificing responsiveness or support. Our independent
+funding model keeps the platform sustainable, while we still extend complimentary access to research
+collaborations and other strategic partners that benefit the broader Helium community.
+
+- Website: [https://https://heliumgeek.com/api](https://https://heliumgeek.com/api/)
+- API Documentation: [https://docs.heliumgeek.com](https://docs.heliumgeek.com)
+
+### Relay
+
+Relay API provides an easy access to all Helium Oracle, on-chain, and historical data via simple
+REST endpoints. The API is public and free to use with the Community plan, sponsored by Helium
+Foundation. Community can get instant access to data like Hotspot earnings, Hotspot information,
+mobile data offload, and much more.
+
+Relay API also provides paid plans to help support users who are looking to access data at scale.
+Paid plans offer higher monthly API call limits, premium features, and allow to fetch all historical
+data, including from Helium L1.
+
+- Website: [https://www.relaywireless.com](https://www.relaywireless.com)
+- API Documentation: [https://docs.relaywireless.com](https://docs.relaywireless.com)
diff --git a/docs/network-data/entity-api.mdx b/docs/network-data/entity-api.mdx
new file mode 100644
index 000000000..2343ffed6
--- /dev/null
+++ b/docs/network-data/entity-api.mdx
@@ -0,0 +1,692 @@
+---
+id: entity-api
+title: Entity API Documentation
+pagination_label: Entity API
+sidebar_label: Entity API
+description: Helium Documentation
+image: https://docs.helium.com/img/link-image.png
+slug: /network-data/entity-api
+---
+
+import Tabs from '@theme/Tabs'
+import TabItem from '@theme/TabItem'
+
+# Entity API
+
+The Entity API is provided free of charge by Helium. The data provided focuses on infrequently
+changing attributes of Hotspots such as their owner and asserted location. This API is provided
+without any guarantees of uptime or support, and is intended for light use cases.For more in-depth
+analysis, refer to [Oracles](/network-data/oracle-data) and
+[Solana on-chain data](/network-data/solana-data).
+
+In the interest of anonymity, the latitude/longitude data provided by the API is obfuscated to
+[H3](https://h3geo.org/docs/core-library/restable/) resolution 8 rather than resolution 12 stored
+on-chain on Solana.
+
+:::note Active/Inactive Status
+
+Active or Inactive status is deprecated for this API and will return `false` for all Hotspots on all
+routes.
+
+:::
+
+## Wallet Info by Wallet Public Key
+
+```
+GET https://entities.nft.helium.io/v2/wallet/:walletPublicKey
+```
+
+Get wallet information by wallet public key including Hotspot count, list of Hotspot records, and
+token account balances.
+
+(Line 5: `entropy_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/entropy.proto#L5) | +| `foundation-iot-ingest` | `IotBeaconIngestReport` | `iot_beacon_ingest_report` | `iot_beacon_ingest_report.
(Line 97: `lora_beacon_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L97) | +| `foundation-iot-ingest` | `IotWitnessIngestReport` | `iot_witness_ingest_report` | `iot_witness_ingest_report.
(Line 104: `lora_witness_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L104) | +| `foundation-iot-packet-ingest` | `PacketReport` | `packetreport` | `packetreport.
(Line 8: `packet_router_packet_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/packet_router.proto#L8) | +| `foundation-iot-packet-verifier` | `InvalidPacket` | `invalid_packet` | `invalid_packet.
(Line 13: `invalid_packet`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/packet_verifier.proto#L13) | +| `foundation-iot-packet-verifier` | `IotValidPacket` | `iot_valid_packet` | `iot_valid_packet.
(Line 5: `valid_packet`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/packet_verifier.proto#L5) | +| `foundation-iot-verified-rewards` | `IotRewardShare` | `iot_reward_share` | `iot_reward_share.
(Line 239: `iot_reward_share`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L239) | +| `foundation-iot-verified-rewards` | `IotPoc` | `iot_poc` | `iot_poc.
(Line 216: `lora_poc_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L216) | +| `foundation-iot-verified-rewards` | `IotInvalidBeaconReport` | `iot_invalid_beacon` | `iot_invalid_beacon.
(Line 153: `lora_invalid_beacon_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L153) | +| `foundation-iot-verified-rewards` | `IotInvalidWitnessReport` | `iot_invalid_witness` | `iot_invalid_witness.
(Line 173: `lora_invalid_witness_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L173) | +| `foundation-iot-verified-rewards` | `GatewayRewardShare` | `gateway_reward_share`(Deprecated 4/18/23) | `gateway_reward_share.
(Line 171: `gateway_reward_share`)](https://github.com/helium/proto/blob/149997d2a74e08679e56c2c892d7e46f2d0d1c46/src/service/poc_lora.proto#L171) | +| `foundation-iot-verified-rewards` | `RewardManifest` | `reward_manifest` | `reward_manifest.
(Line 5: `reward_manifest`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/reward_manifest.proto#L5) | +| `foundation-iot-verified-rewards` | `NonRewardablePacket` | `non_rewardable_packet` | `non_rewardable_packet.
(Line 47: `non_rewardable_packet`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_lora.proto#L47) | +| `foundation-mobile-ingest` | `CellHeartbeatIngestReport` | `cell_heartbeat` | `cell_heartbeat.
(Line 65: `cell_heartbeat_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L65) | +| `foundation-mobile-ingest` | `CellSpeedtestIngestReport` | `cell_speedtest` | `cell_speedtest.
(Line 25: `speedtest_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L25) | +| `foundation-mobile-ingest` | `DataTransferSessionIngestReport` | `data_transfer_session_ingest_report` | `data_transfer_session_ingest_report.
(Line 366: `data_transfer_session_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L366) | +| `foundation-mobile-ingest` | `Heartbeat` | `heartbeat` | `heartbeat.
(Line 181: `heartbeat`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L181) | +| `foundation-mobile-ingest` | `SpeedtestIngestReport` | `speedtest_report` | `speedtest_report.
(Line 25: `speedtest_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L25) | +| `foundation-mobile-ingest` | `SubscriberLocationIngestReport` | `subscriber_location_report` | `subscriber_location_report.
(Line 92: `subscriber_location_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L92) | +| `foundation-mobile-packet-verifier` | `InvalidDataTransferSessionIngestReport` | `invalid_data_transfer_session_ingest_report` | `invalid_data_transfer_session_ingest_report.
(Line 372: `invalid_data_transfer_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L372) | +| `foundation-mobile-packet-verifier` | `ValidDataTransferSession` | `valid_data_transfer_session` | `valid_data_transfer_session.
(Line 24: `valid_data_transfer_session`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/packet_verifier.proto#L24) | +| `foundation-mobile-price` | `PriceReport` | `price_report` | `price_report.
(Line 7: `price_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/price_report.proto#L7) | +| `foundation-mobile-verified` | `ValidatedHeartbeat` | `validated_heartbeat` | `validated_heartbeat.
(Line 181: `heartbeat`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L181) | +| `foundation-mobile-verified` | `SpeedtestAvg` | `speedtest_avg` | `speedtest_avg.
(Line L226: `speedtest_avg`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L226) | +| `foundation-mobile-verified` | `VerifiedSpeedtest` | `verified_speedtest` | `verified_speedtest.
(Line L36: `verified_speedtest`)](https://github.com/helium/proto/blob/6cfd6dc952349e31187c7071dbbcd86780eb97e6/src/service/poc_mobile.proto#L36) | +| `foundation-mobile-verified` | `VerifiedSubscriberLocationIngestReport` | `verified_subscriber_location_report` | `verified_subscriber_location_report.
(Line 140: `verified_subscriber_location_ingest_report_v1`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L140) | +| `foundation-mobile-verified` | `RadioRewardShare` | `radio_reward_share` | `radio_reward_share.
(Line 247: `radio_reward_share`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L247) | +| `foundation-mobile-verified` | `MobileRewardShare` | `mobile_reward_share` | `mobile_reward_share.
(Line 295: `mobile_reward_share`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/service/poc_mobile.proto#L295) | +| `foundation-mobile-verified` | `RewardManifest` | `reward_manifest` | `reward_manifest.
(Line 5: `reward_manifest`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/reward_manifest.proto#L5) | +| `foundation-mobile-verified` | `SubnetworkRewards` | `subnetwork_rewards` | `subnetwork_rewards.
(Line 11: `subnetwork_rewards`)](https://github.com/helium/proto/blob/953da03fd03f1f655e7c27328f068fa9654d1954/src/blockchain_txn_subnetwork_rewards_v1.proto#L11) | +| `foundation-mobile-verified` | `InvalidShares` | `invalid_shares` | `invalid_shares.
})
+
+This guide exists to give an overview of Helium data on Solana, and some general Solana programming
+semantics. For a more in-depth guide, check out
+[The Solana Cookbook](https://solanacookbook.com/core-concepts/accounts.html)
+
+## Reading Data
+
+At its core, Solana is just a giant Key/Value store. A public key is the key, and there's some blob
+of data at that value. That blob of data is called an Account. You can imagine Public Keys like a
+primary key in a traditional database.
+
+For example, let's consider this public key: `6r4x69WHPPDzUuMpJ7vwSUiU6e73KJqeoPyZ8nHQTmFP`
+
+If we check the
+[Solana Explorer, under Anchor Data](https://explorer.solana.com/address/6r4x69WHPPDzUuMpJ7vwSUiU6e73KJqeoPyZ8nHQTmFP/anchor-account?cluster=devnet)
+for this account, we can see that this is a `DaoV0` on the devnet `helium-sub-daos` contract.
+
+
+
+Scrolling up we can see that it is, in fact, owned by the Helium subnetwork's program:
+
+
+
+This means that only the `helium-sub-daos` program can make changes to this account. On other
+chains, a Program may be called a Smart Contract. Accounts are either owned by a program or owned by
+the system program. An account owned by the System Program is generally either a Wallet (holding
+SOL), or an account that has yet to be initialized.
+
+On Solana, a Wallet is just an account with some amount of SOL tokens in it, owned by the system
+program. The owner of that Wallet controls the private key to that account, and so can sign
+transactions as that public key.
+
+### PDAs
+
+Program Derived Addresses (PDAs) are home to accounts that are designed to be controlled by a
+specific program. With PDAs, programs can programmatically sign for certain addresses without
+needing a private key. PDAs serve as the foundation for Cross-Program Invocation, which allows
+Solana apps to be composable with one another.
+
+A PDA is a Public Key that is derived from some set of seeds and a given program ID. Think of it as
+a one-way hashing to a new address. So, for example,
+
+
+```js
+getProgramAddress([Buffer.from("helium", "utf8")], helium_sub_daos.programId)
+```
+
+will always return the same address. Better yet, the `helium_sub_daos` is able to sign transactions
+as if it held the private key to this PDA.
+
+As you will see, the Helium programming model depends heavily on PDAs as indexes into the
+blockchain.
+
+If you imagine the world of Helium Data on Solana as a Graph, PDAs let us hook into particular
+subgraphs.
+
+A great example of this is the relationship between the Helium `dao` and the `hnt` mint address. The
+`DaoV0` definition from earlier exists at address:
+
+
+```js
+import { daoKey } from "@helium/helium-sub-daos-sdk"
+
+const daoAddr = daoKey(new PublicKey("...hnt mint..."))[0];
+```
+
+:::note Helium PDAs and Mints
+
+You'll notice that if you trace the graph of Helium PDAs, they always lead back to the address of
+either the HNT token mint, or the subnetwork token mint.
+
+This design is intentional. Rather than making DAOs, subnetworks, etc global, we opted to make them
+dependent on the specific mints being used. This allows us to set up testing scenarios in which we
+use a testing token alongside the real tokens. This design also allows for easier reuse of our
+contracts throughout the Solana community.
+
+:::
+
+### Aside - Tokens
+
+To understand the Helium model on Solana, it's important to understand how tokens work on Solana.
+
+You might imagine a Wallet is some kind of account (data struct) holding all of your tokens. This is
+not the case!
+
+Instead, a Wallet is really a collection of `TokenAccount`s (Accounts whose data is a
+`TokenAccount`). The token account itself has a reference to its owner, which is the Wallet. Note
+that `TokenAccount.owner` is different than the `Account.owner`. In this case, the Program that is
+allowed to make changes to a token account is the Token Program. That is the `Account.owner`.
+Whereas the owning wallet of the `TokenAccount` is the `TokenAccount.owner`. You can see a token
+account for a testing token we created
+[here](https://explorer.solana.com/address/BM9kx8NZGNThVr6HnBJo1CR5Jvk5Zc3EEy7wWztaJHS2?cluster=devnet)
+
+Every token, whether it be USDC, HNT, or MOBILE has a definition. This is called the token `Mint`.
+You can also see this key on the token account above. This includes definitions like current supply,
+mint authority, freeze authority, and decimals.
+
+A common confusion on Solana is understanding Accounts vs Token Accounts, owners vs Token Account
+owners.
+
+#### Associated Token Accounts
+
+Associated token accounts are often the first use of PDAs you will see as a developer on Solana.
+
+Given the above model, it is possible for a given wallet to have multiple token accounts for the
+same token. That is both messy and hard to index. Early in the days of Solana, a program called
+`associated-token` emerged. `Associated-token` says that the account for a given Wallet and mint can
+be derived by:
+
+
+```js
+ PublicKey.findProgramAddress(
+ [wallet.toBuffer(), TOKEN_PROGRAM_ID.toBuffer(), mint.toBuffer()],
+ ASSOCIATED_TOKEN_PROGRAM_ID
+ )
+```
+
+Generally, token accounts are created through the `associated-token` program so that they can be
+guaranteed to be accessed at an easy-to-find address.
+
+### Fetching Data
+
+The classic way of fetching data on Solana is to use @solana/web3.js connection object.
+
+
+```js
+import { PublicKey, Connection } from "@solana/web3.js"
+
+const connection = new Connection("...rpc url...")
+const account = await connection.getAccountInfo(new PublicKey("..."))
+
+console.log(account.data)
+```
+
+This will get you the binary data of any account stored on chain; however, you will need to decode
+the data yourself. Most programs come with their own SDKs for reading and deserializing data. For
+example, SPL Token (the token program), comes with @solana/spl-token
+
+
+```js
+import { PublicKey } from "@solana/web3.js"
+import { getAccount, getAssociatedTokenAddressSync } from "@solana/spl-token"
+
+const mint = new PublicKey("...wallet...")
+const wallet = new PublicKey("...wallet...")
+const tokenAddress = getAssociatedTokenAddressSync(mint, wallet)
+const tokenAccount = await getAccount(connection, tokenAddress)
+
+console.log(tokenAcount.amount, tokenAccount.owner)
+```
+
+In the case of Helium programs, they all use a framework called
+[Anchor](https://github.com/coral-xyz/anchor), which amongst other things generate SDKs for us.
+
+You can use the SDKs as follows:
+
+
+```js
+import { init } from "@helium/helium-sub-daos-sdk";
+import * as anchor from "@coral-xyz/anchor";
+
+anchor.setProvider(anchor.AnchorProvider.local("...rpc url..."));
+const provider = anchor.getProvider() as anchor.AnchorProvider;
+const program = await init(provider)
+
+const daoAccount = await program.account.daoV0.fetch(new PublicKey("...dao key..."))
+```
+
+## Sending Transactions
+
+Transactions are how we modify data on Solana. All Helium SDKs use the standard
+[Anchor](https://github.com/coral-xyz/anchor) SDK.
+
+That means the interface to all instructions are predictable. You should be able to look at either
+our IDLs, or the programs themselves, and see what accounts need to be passed to generate
+instructions.
+
+The best way to understand how to take certain actions against Helium on Solana is to look at
+[our tests](https://github.com/helium/helium-program-library/tree/master/tests).
+
+For example, to submit a Data Credit delegation, the code may look something like this:
+
+
+```js
+import { subDaoKey } from "@helium/helium-sub-daos-sdk";
+import { init as initDc } from "@helium/data-credits-sdk";
+import * as anchor from "@coral-xyz/anchor";
+
+anchor.setProvider(anchor.AnchorProvider.local("...rpc url..."));
+const provider = anchor.getProvider() as anchor.AnchorProvider;
+
+const iotMint = new PublicKey("...iot mint...");
+const iotSubDao = subDaoKey(iotMint)[0]
+
+const dcProgram = await initDc(provider)
+
+await program.methods
+ .delegateDataCreditsV0({
+ amount: toBN(10, 0),
+ routerKey: "router key",
+ })
+ .accounts({
+ subDao: iotSubDao,
+ })
+ .rpc();
+```
+
+## RPC & RPC Nodes
+
+An RPC is an application's gateway to the Solana cluster. RPC Nodes do not participate in consensus
+and instead are dedicated to data requests.
+
+All the RPCs used in the Solana Migration follow the Solana chain and will index the NFT data that
+Core Developers created in Compression NFTs. This is one reason the Helium Network can mint a
+million or more NFTs on Solana.
+
+You may need to run an RPC service to access public Solana clusters. Many services are free, and
+others are paid. The Foundation uses Helius as their RPC Provider, and it’s useful to use a PRC
+provider that is familiar with compression. They will all support this at some point.
+
+You can read more about RPC & RPC Nodes [here](https://solana.com/rpc).
+
+## Helium Programs on Solana
+
+The code for all of these Programs is open source, and available in the
+[helium-program-library](https://github.com/helium/helium-program-library) repository on Github.
+
+:::info Program Audits
+
+The Helium Programs have been audited by [sec3](https://www.sec3.dev/). The audit report was
+published March 20, 2023. The audit report is available from sec3 on their
+[GitHub reports repo](https://github.com/sec3-service/reports/blob/master/reports/sec3_helium_program_library_report.pdf).
+
+:::
+
+#### circuit_breaker
+
+- Program ID: `circAbx64bbsscPbQzZAUvuXpHqrCe6fLMzc2uKXz9g`
+- Generic program wrapping sensitive mint authorities and token accounts in the Helium system to
+ prevent large movements in the case of an exploit or bug.
+
+#### data_credits
+
+- Program ID: `credMBJhYFzfn7NxBMdU4aUqFggAjgztaCcv2Fo6fPT`
+- Manages the purchase, delegation, and burning of data credits.
+
+#### helium_entity_manager
+
+- Program ID: `hemjuPXBpNvggtaUnN1MwT3wrdhttKEfosTcc2P9Pg8`
+- Handles the issuance of NFTs representing entities that are rewardable on the Helium network, such
+ as Hotspots and mappers.
+
+#### helium_sub_daos
+
+- Program ID: `hdaoVTCqhfHHo75XdAMxBKdUqvq1i5bF23sisBqVgGR`
+- Manages the DAO/subnetwork structure proposed in HIP-51, including the minting of tokens to
+ subnetworks, HST holders, and the `lazy_distributor` for PoC earnings.
+
+#### lazy_distributor
+
+- Program ID: `1azyuavdMyvsivtNxPoz6SucD18eDHeXzFCUPq5XU7w`
+- Allows off-chain Oracles to distribute PoC rewards to rewardable assets (such as Hotspots) that
+ are represented as NFTs.
+
+#### lazy_transactions
+
+- Program ID: `1atrmQs3eq1N2FEYWu6tyTXbCjP4uQwExpjtnhXtS8h`
+- Used in the initial migration to Solana, this program allows compressing many transactions into a
+ merkle root to be executed lazily. This guarantees all transactions are executed exactly once.
+
+#### treasury_management
+
+- Program ID: `treaf4wWBBty3fHdyBpo35Mz84M8k3heKXmjmi9vFt5`
+- Manages the treasury of each subnetwork as proposed in HIP-51, allowing DNT tokens to be swapped
+ for HNT according to a formula.
+
+#### voter_stake_registry
+
+- Program ID: `hvsrNC3NKbcryqDs2DocYHZ9yPKEVzdSjQG6RVtK1s8`
+- Handles voting power via veHNT in Helium Governance.
+
+---
+
+## Packages (JS/Typescript)
+
+| Name | Description |
+| ------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- |
+| [@helium/circuit-breaker-sdk](https://github.com/helium/helium-program-library/tree/master/packages/circuit-breaker-sdk) | SDK to circuit breaker program |
+| [@helium/data-credits-sdk](https://github.com/helium/helium-program-library/tree/master/packages/data-credits-sdk) | SDK to the data credits program |
+| [@helium/distributor-oracle](https://github.com/helium/helium-program-library/tree/master/packages/distributor-oracle) | SDK for interacting with the lazy-distributor oracles to claim rewards |
+| [@helium/helium-entity-manager-sdk](https://github.com/helium/helium-program-library/tree/master/packages/helium-entity-manager-sdk) | SDK to the Helium entity manager program |
+| [@helium/helium-sub-daos-sdk](https://github.com/helium/helium-program-library/tree/master/packages/helium-sub-daos-sdk) | SDK to Helium sub daos program |
+| [@helium/idls](https://github.com/helium/helium-program-library/tree/master/packages/idls) | IDLs containing the typescript definitions for the raw anchor SDKs of our programs |
+| [@helium/lazy-distributor-sdk](https://github.com/helium/helium-program-library/tree/master/packages/lazy-distributor-sdk) | SDK to the lazy distributor program |
+| [@helium/lazy-transactions-sdk](https://github.com/helium/helium-program-library/tree/master/packages/lazy-transactions-sdk) | SDK to lazy transactions program |
+| [@helium/spl-utils](https://github.com/helium/helium-program-library/tree/master/packages/spl-utils) | General utils for interacting with Solana, tokens, etc |
+| [@helium/treasury-management-sdk](https://github.com/helium/helium-program-library/tree/master/packages/treasury-management-sdk) | SDK to the treasury management program |
+| [@helium/voter-stake-registry-sdk](https://github.com/helium/helium-program-library/tree/master/packages/voter-stake-registry-sdk) | SDK to the voter stake registry program |
+
+---
+
+## Important Addresses and Links
+
+All the tokens are on the `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA` Program.
+
+The mint IDs are as follows:
+
+| Name | ID |
+| ------ | ------------------------------------------- |
+| HNT | hntyVP6YFm1Hg25TN9WGLqM12b8TQmcknKrdu1oxWux |
+| MOBILE | mb1eu7TzEc71KxDpsmsKoucSSuuoGLv1drys1oP2jh6 |
+| IOT | iotEVVZLEywoTn1QdwNPddxPWszn3zFhEot3MfL9fns |
+| DC | dcuc8Amr83Wz27ZkQ2K9NS6r8zRpf1J6cvArEBDZDmm |
diff --git a/docs/network-data/solana/compression-nfts.mdx b/docs/network-data/solana/compression-nfts.mdx
new file mode 100644
index 000000000..1cd77256f
--- /dev/null
+++ b/docs/network-data/solana/compression-nfts.mdx
@@ -0,0 +1,62 @@
+---
+id: compression-nfts
+title: Compression NFTs
+pagination_label: Compression NFTs
+sidebar_label: Compression NFTs
+description: Helium Compression NFTs Documentation
+image: https://docs.helium.com/img/link-image.png
+slug: /network-data/solana/compression-nfts
+---
+
+import useBaseUrl from '@docusaurus/useBaseUrl'
+
+A new development on the Solana Blockchain has been
+[Compression NFTs](https://www.metaplex.com/posts/expanding-digital-assets-with-compression-for-nfts).
+
+With normal NFTs on Solana, each token is stored on-chain as a distinct spl-token mint, with
+decimals of 0 and supply of 1. This mint has some metadata attached to it, as well as a token
+account representing the ownership of the token. In total, this leads to 4 accounts with a cost of
+0.01197616 SOL in rent. Multiplying this by millions of Hotspots leads to not only a high cost but
+also a large usage of storage space on the blockchain.
+
+Enter: Compression NFTs. Compression NFTs use a Concurrent Merkle Tree to compress millions of NFTs
+into one 32-byte hash. Clients executing transactions on compressed NFTs can send a cryptographic
+proof to the blockchain that verifies the NFT and ownership. In other words, instead of sending a
+transaction with:
+
+```rust
+
+...
+pub mint: Account<'info, Mint>,
+pub metadata: Account<'info, Metadata>,
+pub master_edition: Account<'info, MasterEdition>,
+#[account(
+ constraint = token_account.amount >= 1,
+ token::owner = owner
+)]
+pub token_account: Account<'info, TokenAccount>,
+pub owner: Signer<'info>
+...
+```
+
+You can instead send:
+
+```rust
+
+pub struct ProofArgs {
+ pub hash: Vec})
+
+## Overview
+
+The Helium Program Library (HPL) is a collection of programs that enable the Helium Network to
+operate on the Solana blockchain. The HPL is designed to be a comprehensive resource for developers
+looking to build on the Helium Network, providing a suite of solana programs and tools to facilitate
+the seamless integration of the Helium Network with the Solana blockchain.
+
+## Features
+
+The Helium Program Library (HPL) offers a wide range of features to support the Helium Network's
+integration with the Solana blockchain. These features include:
+
+- **Solana Programs**: The HPL provides a comprehensive suite of programs designed to facilitate the
+ seamless operation of the Helium Network on the Solana blockchain. These programs are designed to
+ be easily accessible and customizable, allowing developers to build on the Helium Network with
+ ease.
+
+- **Documentation**: The HPL offers extensive documentation to support developers in interfacing
+ with the Helium Network on the Solana blockchain. This documentation includes detailed guides,
+ tutorials, and examples to help developers get started with building on the Helium Network.
+
+- **Tools**: The HPL provides a range of tools to support developers in building on the Helium
+ Network.
+
+## Getting Started
+
+To get started with the Helium Program Library (HPL), developers can access the HPL documentation
+and at [hpl.helium.com](https://hpl.helium.com). The HPL documentation provides detailed guides,
+tutorials, and examples to help developers get started with building on the Helium Network.
+
+The HPL GitHub repository can be found at https://github.com/helium/helium-program-library.
diff --git a/docs/network-data/solana/rewardable-entities.mdx b/docs/network-data/solana/rewardable-entities.mdx
new file mode 100644
index 000000000..e11363bb9
--- /dev/null
+++ b/docs/network-data/solana/rewardable-entities.mdx
@@ -0,0 +1,371 @@
+---
+id: rewardable-entities
+title: Rewardable Entities
+pagination_label: Rewardable Entities
+sidebar_label: Hotspots on Solana
+description: Helium Rewardable Entities Documentation
+image: https://docs.helium.com/img/link-image.png
+slug: /network-data/solana/rewardable-entities
+---
+
+import useBaseUrl from '@docusaurus/useBaseUrl'
+
+All actors in the network that receive tokens are considered "Rewardable Entities."
+
+A rewardable entity on the Helium Network is represented on Solana as an NFT (Non-Fungible Token).
+
+NFTs are ideal for this job as they represent ownership in a way that is easily transferable and
+recognized by all major wallets.
+
+## Fetching Rewardable Entities
+
+All rewardable entities are created by the `helium-entity-manager` program. Further, they exist
+under a collection that is managed by the Maker of that entity. The easiest way to fetch all Helium
+entities for a given wallet is to filter by the `helium-entity-manager-creator`
+
+We can get this address by running
+
+
+```js
+import { daoKey } from "@helium/helium-sub-daos-sdk";
+import { entityCreatorKey } from "@helium/helium-entity-manager-sdk";
+
+const hntMint = new PublicKey('...hnt mint...')
+const dao = daoKey(hntMint)[[0]]
+const creator = entityCreatorKey(dao)[0]
+```
+
+This should output: `Fv5hf1Fg58htfC7YEXKNEfkpuogUUQDDTLgjGWxxv48H`
+
+Now, we can use the Metaplex Digital Asset API to get rewardable entities my wallet
+(`BcJzP2hEYgzjUwpHEtS6RhuqGfEJVx8Rq3MejujAAWrR`) owns:
+
+```bash
+curl --request POST \
+ --url https://rpc-devnet.aws.metaplex.com/ \
+ --header 'Content-Type: application/json' \
+ --data '{
+ "jsonrpc": "2.0",
+ "method": "search_assets",
+ "id": "get-assets-op-1",
+ "params": {
+ "ownerAddress": "BcJzP2hEYgzjUwpHEtS6RhuqGfEJVx8Rq3MejujAAWrR",
+ "page": 0,
+ "creatorAddress": "Fv5hf1Fg58htfC7YEXKNEfkpuogUUQDDTLgjGWxxv48H",
+ "creatorVerified": true,
+ "sortBy": {"sortBy": "created", "sortDirection": "asc"}
+ }
+ }'
+```
+
+### Hotspots and ECC Compact Keys
+
+Hotspots on the Helium Network currently are uniquely identified by their ECC Compact Public Keys.
+
+At onboarding time, Hotspots can sign an onboard transaction proving physical ownership of the
+device.
+
+As such, the Helium Solana implementation enforces that all NFTs are unique by ECC Compact keys.
+
+If you have an asset id of an NFT on Solana, you can get the ECC Compact Key by fetching the digital
+asset and pulling out the last value from the content.json_uri.
+
+For example:
+
+
+```js
+import { getAsset } from "@helium/spl-utils";
+
+const asset = await getAsset(rpcUrl, new PublicKey("...asset id..."));
+
+const eccCompactKey = asset.content.json_uri.split("/").slice(-1)[0];
+```
+
+If you have only an ECC Compact key and would like to find the NFT, you can use the `KeyToAssetV0`
+struct that is stored on-chain:
+
+
+```js
+import { daoKey } from "@helium/helium-sub-daos-sdk"
+import { keyToAssetKey, init } from "@helium/helium-entity-manager-sdk"
+
+// Declare constants
+const hntMint = new PublicKey("...hnt mint...")
+const dao = daoKey(hntMint)[0]
+const eccKey = "...ecc compact key..."
+
+// Init program
+const program = await init(provider);
+
+// Get the asset id from the KeyToAssetV0 account on-chain
+const keyToAssetPkey = keyToAssetKey(dao, eccKey)[0]
+const keyToAssetAcc = await program.account.keyToAssetV0.fetch(keyToAssetPkey);
+const assetId = keyToAssetAcc.asset;
+
+// Now get the asset from the metaplex asset api
+const asset = await getAsset(rpcUrl, assetId)
+```
+
+## Onboarding Rewardable Entities
+
+The onboarding flow for an entity is generally that a customer purchases the hardware from a Maker,
+and then self-onboards to the network. Because all hardware is created by approved Makers, the
+onboard transaction must be approved by the Maker. This uses a similar flow to the legacy
+onboarding-server of the Helium blockchain.
+
+Makers are approved for specific subnetworks. A maker that creates IoT Hotspots cannot necessarily
+onboard Mobile Hotspots. Each network subnetwork must approve makers to issue rewardable entities.
+
+The following test shows the full flow of onboarding a Hotspot using the onboarding server.
+
+The [React Native Helium](https://github.com/helium/react-native-helium) SDK should greatly simplify
+this process.
+
+
+
+
+```js
+import Address from "@helium/address";
+import { Keypair } from "@helium/crypto";
+import { sendAndConfirmWithRetry } from "@helium/spl-utils";
+import { AddGatewayV1 } from "@helium/transactions";
+import { accountProviders } from "@metaplex-foundation/mpl-bubblegum";
+import {
+ Connection,
+ PublicKey,
+ Transaction,
+ Keypair as SolanaKeypair,
+} from "@solana/web3.js";
+import axios from "axios";
+import { BN } from "bn.js";
+
+function random(len: number): string {
+ return new Array(len).join().replace(/(.|$)/g, function () {
+ return ((Math.random() * 36) | 0).toString(36);
+ });
+}
+
+function sleep(ms: number) {
+ return new Promise((resolve) => setTimeout(resolve, ms));
+}
+
+describe("onboarding server", () => {
+ let me: Keypair;
+ let gateway: Keypair;
+ const maker = Address.fromB58(
+ "ENTER YOUR MAKER ADDRESS"
+ );
+ let onboardingKey: string;
+
+ let base = "https://onboarding.web.test-helium.com";
+ before(async () => {
+ me = await Keypair.makeRandom();
+ gateway = await Keypair.makeRandom();
+ onboardingKey = gateway.address.b58;
+ const result = await axios.post(
+ `${base}/api/v2/hotspots`,
+ {
+ onboardingKey,
+ macWlan0: random(10),
+ macEth0: random(10),
+ rpiSerial: random(10),
+ heliumSerial: random(10),
+ batch: "example-batch",
+ },
+ {
+ headers: {
+ authorization: "ENTER YOUR MAKER AUTH KEYS"
+ },
+ }
+ );
+
+ await sleep(2000);
+ });
+
+ it("should run issue txs", async () => {
+ const hotspot = (
+ await axios.get(`${base}/api/v2/hotspots/${onboardingKey}`)
+ ).data.data;
+ console.log(hotspot);
+ console.log(me.privateKey);
+ const solanaKeypair = SolanaKeypair.fromSecretKey(me.privateKey);
+ console.log("Solana pubkey: ", solanaKeypair.publicKey.toBase58())
+
+ await sleep(2000);
+
+ const result = await axios.post(
+ `${base}/api/v3/transactions/create-hotspot`,
+ {
+ location: new BN(1).toString(),
+ transaction: (
+ await new AddGatewayV1({
+ owner: me.address,
+ gateway: gateway.address,
+ payer: maker,
+ }).sign({
+ gateway,
+ })
+ ).toString(),
+ }
+ );
+
+ const connection = new Connection("https://api.devnet.solana.com");
+ const { solanaTransactions } = result.data.data;
+ for (const solanaTransaction of solanaTransactions) {
+ const txid = await sendAndConfirmWithRetry(
+ connection,
+ Buffer.from(solanaTransaction),
+ { skipPreflight: true },
+ "confirmed"
+ );
+ console.log(txid.txid);
+ }
+
+ let tries = 0;
+ let onboardResult: any;
+ while (tries < 10 && !onboardResult) {
+ try {
+ onboardResult = await axios.post(
+ `${base}/api/v3/transactions/mobile/onboard`,
+ {
+ entityKey: onboardingKey,
+ }
+ );
+ } catch {
+ console.log(`Hotspot may not exist yet ${tries}`);
+ tries++;
+ await sleep(2000); // Wait for Hotspot to be indexed into asset api
+ }
+ }
+
+
+ for (const solanaTransaction of onboardResult!.data.data
+ .solanaTransactions) {
+ const tx = Transaction.from(Buffer.from(solanaTransaction));
+ tx.partialSign(solanaKeypair)
+ const txid = await sendAndConfirmWithRetry(
+ connection,
+ tx.serialize(),
+ { skipPreflight: true },
+ "confirmed"
+ );
+ console.log(txid.txid);
+ }
+
+ const updateResult = await axios.post(
+ `${base}/api/v3/transactions/mobile/update-metadata`,
+ {
+ entityKey: onboardingKey,
+ location: new BN(1).toString(),
+ elevation: 2,
+ gain: 11,
+ wallet: solanaKeypair.publicKey.toBase58()
+ }
+ );
+
+ for (const solanaTransaction of updateResult.data.data.solanaTransactions) {
+ const tx = Transaction.from(Buffer.from(solanaTransaction));
+ tx.partialSign(solanaKeypair)
+ const txid = await sendAndConfirmWithRetry(
+ connection,
+ tx.serialize(),
+ { skipPreflight: true },
+ "confirmed"
+ );
+ console.log(txid.txid);
+ }
+ });
+});
+```
+
+## Claiming Rewards on Rewardable Entities
+
+A system of oracles keeps track of the rewards owed to each Rewardable Entity. For example, in the
+IoT network there are oracles that keep track of the HNT tokens earned by each Hotspot for PoC.
+
+These oracles are responsible ONLY for tracking the total lifetime rewards associated with a
+Hotspot. This frees the oracles from any kind of dependence on the blockchain. They don't care about
+the issuance or movement of tokens.
+
+The `lazy-distributor` program keeps track of, for each Hotspot, how much of the total lifetime
+rewards have been claimed. Claiming rewards, then, consists of two steps:
+
+1. Ask oracles to update the on-chain state to reflect the latest lifetime rewards for this Hotspot.
+2. Issue the difference between the total lifetime rewards and total claimed rewards to the Hotspot
+ owner.
+
+In practice, we have made it so that this can all happen in a singular transaction for PoC rewards.
+Staking rewards will happen in transactions combining up to 4 days of rewards.
+
+### Finding Current Rewards
+
+Oracles work off of a restful API that involves
+
+1. Grabbing lifetime rewards for all oracles.
+2. Constructing a transaction to set the rewards and passing the transaction to each oracle to
+ partially sign.
+3. Submitting the fully signed transaction to Solana.
+
+The SDK simplifies this process into two functions, `getCurrentRewards` and `formTransaction`.
+
+If you have interest in using the REST api, you can see the relatively simple client code
+[here](https://github.com/helium/helium-program-library/blob/master/packages/distributor-oracle/src/client.ts)
+
+To fetch rewards across all oracles for a given asset id:
+
+
+```js
+import { init, lazyDistributorKey } from "@helium/lazy-distributor-sdk";
+import { getCurrentRewards } from "@helium/distributor-oracle";
+import * as anchor from "@coral-xyz/anchor";
+
+anchor.setProvider(anchor.AnchorProvider.local("...rpc url..."));
+const provider = anchor.getProvider() as anchor.AnchorProvider;
+const program = await init(provider)
+
+const iotMint = new PublicKey("...iot mint...")
+const assetId = new PublicKey("...asset id...")
+const lazyDistributorPkey = lazyDistributorKey(iotMint)[0];
+const rewards = await getCurrentRewards(program, lazyDistributorPkey, assetId);
+
+rewards.map(reward => {
+ console.log(`Oracle ${reward.oracleKey} stating lifetime rewards of ${reward.currentRewards}`);
+})
+```
+
+### Claiming Rewards
+
+:::info
+
+The claim example in this section requires a connection to an RPC node (provider) that understands
+compressed NFTs. This is an advanced feature that is not yet supported by Solana's public RPC
+servers. **This example will not work unless you use an appropriate RPC provider such as
+[Helius](https://www.helius.xyz/).**
+
+:::
+
+You can then get a transaction to submit to the Solana blockchain using those rewards:
+
+
+```js
+
+import { formTransaction } from "@helium/distributor-oracle";
+import { sendAndConfirmWithRetry } from "@helium/spl-utils";
+
+const tx = await formTransaction({
+ program,
+ provider,
+ rewards, // from above
+ hotspot: assetId,
+ lazyDistributor: lazyDistributorPkey,
+})
+
+const signed = await provider.wallet.signTransaction(tx);
+
+await sendAndConfirmWithRetry(
+ provider.connection,
+ Buffer.from(signed.serialize()),
+ { skipPreflight: true },
+ 'confirmed',
+);
+```
diff --git a/docs/network-iot/hotspots-iot/data-only-hotspots.mdx b/docs/network-iot/hotspots-iot/data-only-hotspots.mdx
new file mode 100644
index 000000000..415a641d2
--- /dev/null
+++ b/docs/network-iot/hotspots-iot/data-only-hotspots.mdx
@@ -0,0 +1,105 @@
+---
+id: data-only-hotspots
+title: Data-Only Hotspots
+pagination_label: Data-Only Hotspots
+sidebar_label: Introduction
+description: Helium Data-Only Hotspot Documentation
+image: https://docs.helium.com/img/link-image.png
+slug: /iot/data-only-hotspots
+---
+
+import useBaseUrl from '@docusaurus/useBaseUrl'
+
+})
++
+ +Any LoRaWAN gateway can be used to transfer data through the Helium Network. Data-only Hotspots are +eligible for **network data transfer rewards** but not **Proof-of-Coverage rewards**. This class of +Hotspot offers a flexible path for companies and organizations looking to leverage the Helium +Network for their IoT needs. + +Since data-only Hotspots do not earn Proof-of-Coverage rewards, they may be permissionlessly added +to the network. When added to the blockchain, they will earn HNT for transferring network data. + +## Basic Architecture + +The [gateway-rs](https://github.com/helium/gateway-rs) client backs both data-only Hotspots as well +as Proof-of-Coverage enabled IoT Hotspots. Gateway-rs is designed to run alongside a packet +forwarder and handles communications with the Helium Packet Router. + +```mermaid +graph LR; + subgraph Gateway["Helium-Enabled Gateway (Hotspot)"] + PacketForwarder["Packet
Forwarder"] + HeliumGateway["Helium
Gateway-rs"] + + PacketForwarder -- "Semtech GWMP
over UDP" --> HeliumGateway + end + + HeliumRouter["Helium
Packet Router"] + LNS["LoRaWAN
Network Server"] + + HeliumGateway -- "gRPC" --> HeliumRouter + HeliumRouter --> LNS +``` + +The articles in this section will outline the 'Gateway' highlighted portion of the above diagram. + +### Packet Forwarder + +Gateway-rs is designed to interact with the +[Semtech Packet Forwarder](https://github.com/helium/packet_forwarder). If no packet forwarder is +installed on the target hardware, follow the manufacturer's instructions using their documentation +or one of the tutorials below. + +- [Dragino LPS8/DLOS8](/iot/data-only/dragino-data-only-hotspot) +- [RAKwireless Concentrator (RAK2245/RAK2247/RAK2287) + Raspberry Pi](/iot/data-only/rak-concentrators) + - [Using Balena: RAKwireless RAK2287 Concentrator + Raspberry Pi](/iot/data-only/balena-data-only-hotspot) +- [RAKwireless WisGate Edge Lite 2](https://github.com/HoBoWAN/Helium-Data-Only-Hotspot/blob/main/README.md) +- [Seeed Studio SenseCAP M2](https://wiki.seeedstudio.com/Network/SenseCAP_Network/SenseCAP_M2_Data_Only-Helium_gateway/SenseCAP_M2_Data_Only_Quick_Start/) + +### Gateway-rs + +Gateway-rs is the lightweight client that handles message signing and communications with Helium +Packet Router, the backbone of the IoT Network. + +Gateway-rs is designed to be installed directly adjacent to the packet forwarder on the gateway. For +the latest releases and build notes, refer to the repository +[readme](https://github.com/helium/gateway-rs/blob/main/README.md) on GitHub. + +For guidance on using gateway-rs, view the +[Data-Only Hotspot Onboarding](/iot/data-only-hotspots-onboarding) section. + +## Transactions & Cost + +A data-only Hotspot is capable of transferring network traffic without being onboarded. However, +rewards for data transfer will not be issued. + +To enable the Helium Network to reward a data-only Hotspot for network traffic and to report a +location, two criteria must be met: + +1. The data-only Hotspot must be 'onboarded' to the network. + The **Add Hotspot** transaction links the Hotspot's key (`swarm_key`) to a user's + [account](/wallets) and makes the Hotspot known to the network. This allows the Hotspot to be + rewarded for data transfer. +1. The specific location of the Hotspot should be declared. + This allows the network define regional parameters and aids in location-solving for certain + sensor applications. The **Assert Location** transaction provides the physical location + (lat/long), elevation (in meters), and antenna EIRP (in dBi) data for the Hotspot. A Hotspot must + be onboarded before its location can be asserted. + +The network fees are as follows: + +- **Add Data-Only Hotspot**: 50,000 Data Credits (USD \$0.50) +- **Assert Location**: 50,000 Data Credits (USD \$0.50) + +These fees are paid using [Data Credits](/tokens/data-credit). + +Transactions are submitted using the [CLI Wallet](/wallets/cli-wallet). The CLI Wallet should +**not** be installed on the gateway, doing so could expose account keys to the open internet if the +gateway is not properly secured. Existing accounts generated using the Helium Wallet App can be +[imported to the CLI](/wallets/cli-wallet#import-seed-phrase-account-into-cli). + +For guidance on submitting these transactions, view the +[Data-Only Hotspot Onboarding](/iot/data-only-hotspots-onboarding) section. diff --git a/docs/network-iot/hotspots-iot/data-only-onboarding.mdx b/docs/network-iot/hotspots-iot/data-only-onboarding.mdx new file mode 100644 index 000000000..507d233c1 --- /dev/null +++ b/docs/network-iot/hotspots-iot/data-only-onboarding.mdx @@ -0,0 +1,330 @@ +--- +id: data-only-hotspots-onboarding +title: Data-Only Hotspot Onboarding +pagination_label: Data-Only Hotspot Onboarding +sidebar_label: Data-Only Hotspot Onboarding +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/data-only-hotspots-onboarding +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +# Data-Only Hotspot Onboarding + +
})
++
+ +This guide walks through the process of onboarding a Data-Only Hotspot to the Helium Network. The +onboarding procedure expects a gateway configured with the Semtech Packet Forwarder and Helium +Gateway-rs. + +## Prerequisites + +- LoRaWAN Gateway with Gateway-rs installed. +- Helium Wallet CLI with a funded account imported. +- Token balances to onboard a Data-Only Hotspot. + - 100,000 ($1) Data Credits (DCs) comprised of + - 50,000 ($0.50) Data-Only Onboard + - 50,000 ($0.50) Data-Only Location Assert + - SOL (Solana's native cryptocurrency) to cover transaction fees (~0.01 Sol) + +## Installing Gateway-rs + +If the gateway is already configured with gateway-rs, skip to +[Prepare the Helium Wallet CLI](#prepare-the-helium-wallet-cli). + +If the gateway does not already have gateway-rs installed, follow these steps to install and +configure it. +For more in-depth guides, refer to the available tutorials. + +### Running From a Release + +Compiled releases are available directly from GitHub. + +- https://github.com/helium/gateway-rs/releases + +### Building From Source + +Build the program from source. The build chain for gateway-rs is +[Rust](https://www.rust-lang.org/tools/install). + +```sh title="Install Rust" +curl https://sh.rustup.rs -sSf | sh +``` + +```sh title="Add Rust to shell" +source "$HOME/.cargo/env" +``` + +```sh title="Install protobuf compiler" +sudo apt-get update && sudo apt-get install protobuf-compiler +``` + +```sh title="Clone the gateway-rs repository" +git clone https://github.com/helium/gateway-rs.git +``` + +```sh title="Build gateway-rs from within the gateway-rs directory" +cd gateway-rs/ +cargo build --release +``` + +The compiled `helium_gateway` program will be available in the `gateway-rs/target/release/` +directory. + +## Prepare Gateway-rs + +To simplify running the `helium_gateway` program, place it in a folder that is easily accessible or +in the `/usr/bin/` directory. Placing `helium_gateway` in this bin directory will automatically add +it to the shell path. + +```sh title="Copying the helium_gateway program to /usr/bin/" +sudo cp gateway-rs/target/release/helium_gateway /usr/bin/ +``` + +```sh title="Running the helium_gateway program after adding it to /usr/bin/" +$ helium_gateway --version +> helium_gateway 1.1.1 +``` + +### Configure `settings.toml` + +From the downloaded release or built source, copy the settings.toml file into a directory where it +will not be overwritten and can be easily found. + +The default path is `/etc/helium_gateway/settings.toml`. If using a different path, pass the +location of the settings.toml file to helium_gateway using the `-c` flag. + +```sh title="Initialize the default directory for Helium Gateway" +sudo mkdir /etc/helium_gateway +``` + +```sh title="Make a copy of settings.toml in the default directory" +sudo cp gateway-rs/config/settings.toml /etc/helium_gateway/ +``` + +For the subsequent steps, a command-line-based text editor is used. + +```sh title="Edit the copied settings.toml file" +sudo nano /etc/helium_gateway/settings.toml +``` + +#### [Optional] Region Plan + +Setting the gateway's region is only required if the Hotspot is not added and asserted to the +blockchain. For onboarded Hotspots, the region is retrieved via the asserted location stored +on-chain. The Hotspot will not transfer data unless one of these criteria is met. + +```toml title="Uncomment this line by removing the #. Set the appropriate region" +# region = "US915" +``` + +Determine the region plan that should be used. The selected region plan must match the region plan +in the Semtech Packet Forwarder. + +#### [Optional] Define `gateway_key.bin` Location + +The default path is `/etc/helium_gateway/gateway_key.bin`. If using a different path, update the key +location in `settings.toml`. + +The `gateway_key.bin` file stores the information used to identify the Hotspot on the network. The +key file will allow gateway-rs to securely sign all messages transferred from the Hotspot. Key +signing allows the Helium Network to confirm that data payloads are delivered from verifiable +sources. The gateway_key will be generated during the first run of the server if no existing key is +found. + +```toml +# File based: +keypair = "/etc/helium_gateway/gateway_key.bin" +``` + +It's advised to backup the `gateway_key.bin` file, especially if it needs to be recovered after the +onboarding process. + +### First Run + +With gateway-rs installed on the gateway, initialize the key for the Hotspot. If creating the +gateway_key in /etc/helium_gateway/, `sudo` may be required on first run to create the key file. + +```sh title="Generate a swarm_key by running gateway-rs." +sudo helium_gateway server +``` + +
})
+ })
+
+## Configure LoRaWAN Settings
+
+Next, you will configure the LoRa packet forwarder on the Dragino to forward packets to the Helium
+Gateway service which will be installed on the Dragino in the next step.
+
+1. From the Dragino web interface, navigate to LoRaWAN > LoRaWAN from the menu.
+2. Select `Custom / Private LoRaWAN` from the Service Provider.
+3. Set the Server Address to `127.0.0.1` and both Uplink and Downlink ports to `1680`. This will
+ configure the forwarder to use the default port used by Helium Gateway.
+
+})
+
+4. Click Save & Apply.
+
+## Install Helium Gateway (gateway-rs) on the Dragino
+
+Finally, you will install the Helium Gateway service. This requires SSH access to the Dragino.
+
+1. Connect to the Dragino over SSH. By default, the standard Dragino firmware uses port 2222 for SSH
+ (the OpenVPN firmware uses port 22) and the root user has access.
+ `ssh root@+ +### Verify If The Packet Forwarder Is Running + +When the LoRa packet forwarder is running as a service, some log messages are recorded in the +syslog. To inspect the logs, run the following command: + +``` +sudo tail -f /var/log/syslog | grep ttn-gateway +``` + +The log output should show something similar to: + +``` +rak-gateway ttn-gateway[1886]: JSON up: {"stat":{"time":"2021-07-21 16:25:00 GMT","rxnb":0,"rxok":0,"rxfw":0,"ackr":0.0,"dwnb":0,"txnb":0,"temp":0.0}} +rak-gateway ttn-gateway[1886]: INFO: [down] PULL_ACK received in 142 ms +rak-gateway ttn-gateway[1886]: INFO: [down] PULL_ACK received in 142 ms +rak-gateway ttn-gateway[1886]: INFO: [down] PULL_ACK received in 142 ms +rak-gateway ttn-gateway[1886]: ##### 2021-07-21 16:25:30 GMT ##### +rak-gateway ttn-gateway[1886]: ### [UPSTREAM] ### +rak-gateway ttn-gateway[1886]: # RF packets received by concentrator: 0 +rak-gateway ttn-gateway[1886]: # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00% +rak-gateway ttn-gateway[1886]: # RF packets forwarded: 0 (0 bytes) +rak-gateway ttn-gateway[1886]: # PUSH_DATA datagrams sent: 1 (122 bytes) +rak-gateway ttn-gateway[1886]: # PUSH_DATA acknowledged: 0.00% +rak-gateway ttn-gateway[1886]: ### [DOWNSTREAM] ### +rak-gateway ttn-gateway[1886]: # PULL_DATA sent: 3 (100.00% acknowledged) +rak-gateway ttn-gateway[1886]: # PULL_RESP(onse) datagrams received: 0 (0 bytes) +rak-gateway ttn-gateway[1886]: # RF packets sent to concentrator: 0 (0 bytes) +rak-gateway ttn-gateway[1886]: # TX errors: 0 +rak-gateway ttn-gateway[1886]: ### SX1302 Status ### +rak-gateway ttn-gateway[1886]: # SX1302 counter (INST): 210904434 +rak-gateway ttn-gateway[1886]: # SX1302 counter (PPS): 0 +rak-gateway ttn-gateway[1886]: # BEACON queued: 0 +rak-gateway ttn-gateway[1886]: # BEACON sent so far: 0 +rak-gateway ttn-gateway[1886]: # BEACON rejected: 0 +``` + +:::note + +`ttn-gateway` is just the name for the LoRa packet forwarder service in the configuration for these +RAK concentrators; this is a "legacy name" that doesn't change when using different network servers. + +::: + +### Edit the Packet Forwarder Settings + +You will need to edit some basic options in the packet forwarder configuration to forward the +packets to the address and port the helium_gateway service is listening to. + +Select the option _Edit packet-forwarder config_ within the _gateway-config_ interface. This option +will open the `global_conf.json` file using the nano editor. Then, set the `server_address` to +127.0.0.1 and the `serv_port_up` and `serv_port_down` to 1680, as follows: + +
+ +Close the editor by pressing CTRL + X simultaneously, press ENTER to save the file. + +Restart the packet forwarder to apply the changes by selecting the option _Restart packet-forwarder_ +within the _gateway-config_ interface. + +:::important + +Every time a new region is selected using the _Setup RAK Gateway Channel Plan_ option, these +settings are replaced with the default configuration. Make sure to keep this in mind if the region +is changed later. + +::: + +## Helium Gateway Service Installation + +### Downloading the Package + +Download the latest release from the [gateway-rs](https://github.com/helium/gateway-rs) repository +on GitHub, and set the `
+ + +
+ ) + return ( ++ + e.target.select()} /> +
+ ) +} + +const useLogin = () => { + const { + siteConfig: { customFields }, + } = useDocusaurusContext() + const interalServiceClient = new InternalServiceClient(customFields.EDU_API_URL) + + return () => + new Promise((resolve, reject) => { + let req = new LoginRequest() + req.setEmail(customFields.EDU_EMAIL) + req.setPassword(customFields.EDU_PW) + interalServiceClient.login(req, {}, (error, resp) => { + if (error !== null) { + return reject(error) + } + return resolve(resp.getJwt()) + }) + }) +} + +const getRequestMeta = (jwt: string) => { + return { authorization: `Bearer ${jwt}` } +} + +const EnvChecker = ({ children }) => { + const { + siteConfig: { customFields }, + } = useDocusaurusContext() + if (!customFields.EDU_API_URL || !customFields.EDU_EMAIL || !customFields.EDU_PW) { + return ( +Please configure your .env file to use the Educational LNS features
+
+
+
+
+ )
+}
+
+export const CreateDevice = () => (
+ Device Event Logger
*/} + {/*jwt: {jwt}
*/} + + {!events.length && ( +
+ setDevEui(event.target.value)}
+ />
+
+ )}
+
+ No events yet.
+
+ {events
+ .filter((event) => event.description !== 'log')
+ .map((event) => (
+
+
+ )
+}
+
+export const DeviceEventLogger = () => (
+
+
+ ))}
+
+
+ + {event.description === 'join' + ? '🔄 Joining' + : event.description === 'up' + ? '⬆️ Uplink' + : event.description === 'down' + ? '⬇️ Downlink' + : event.description === 'status' + ? '*️⃣ Status' + : `🛜 ${event.description}`} +
++ {new Date(event.time?.seconds! * 1000).toLocaleString()} +
+-
+ {event.propertiesMap.map(([key, value], index) => (
+
- + + {key === 'DR' + ? 'Data Rate' + : key === 'FCnt' + ? 'Frame Count' + : key === 'FPort' + ? 'Frame Port' + : key} + :{' '} + + {value} + + ))} +
+ +Behind the scenes, these keys are registered with a LoRaWAN Network Server (LNS). The Join EUI is +shared with the Helium Packet Router (HPR), which allows any Hotspot in the world to route messages +from this device to the correct LNS. The cryptographic keys ensure end-to-end encryption between the +device and the LNS. + +## Programming the Device + +The example below uses a [Heltec CubeCell](https://heltec.org/project/htcc-ab01/) development board +with PlatformIO. Copy the keys generated above into the `devEui`, `appEui`, and `appKey` variables: + +
+ +Once compiled and uploaded, the device will attempt to join the network and begin transmitting data. + +## Viewing Device Events + +When your device transmits, a Hotspot on the Helium Network receives the radio signal and forwards +it through the Packet Router to the LNS. The LNS then delivers the data here, to this page, in +real-time. + +
+ +If uplinks appear in the logger, you're seeing the complete data path in action. Your device +transmits, the Helium network routes, and your application receives. This same flow can deliver data +to any backend you build: a database, a dashboard, an alerting system, or an API. + +## Next Steps + +Once data reaches the LNS, it can be forwarded to your application using integrations such as HTTP +webhooks, MQTT, or cloud platforms like AWS IoT and Azure IoT Hub. See +[LoRaWAN Network Servers](/iot/lorawan-network-servers) for more information on available LNS +options. + +## Experiments + +Try modifying the device behavior to deepen your understanding: + +1. **Change the payload**: The device sends data in hexadecimal format. How would you transmit + "Hello, World!"? Tools like [asciitohex.com](https://www.asciitohex.com/) can help with + conversions. +2. **Use different ports**: LoRaWAN's `FPort` field allows you to separate data types. Send sensor + readings on one port and status updates (like battery level) on another. +3. **Adjust the transmission interval**: The device currently sends data every 30 seconds. Try + changing it to 10 seconds. Consider how this affects battery life and network usage. diff --git a/docs/network-iot/learn/build-a-device.module.css b/docs/network-iot/learn/build-a-device.module.css new file mode 100644 index 000000000..f1d1ed3ac --- /dev/null +++ b/docs/network-iot/learn/build-a-device.module.css @@ -0,0 +1,119 @@ +/*CreateDevice*/ +.DeviceKeys { + width: 100%; + padding: 0.5em; +} + +.keybox { + display: flex; + flex-direction: column; +} + +.keybox label { + font-weight: 500; + color: #53627c; + font-size: small; + background-color: #eaeff9; + line-height: 1em; + padding: 1em 1rem calc(1em + 6px); + border-radius: 8px 8px 0 0; +} + +.keybox input { + display: table; + background: white; + width: 100%; + table-layout: fixed; + border: none; + border-radius: 0 0 8px 8px; + padding: 1rem; + margin-top: -8px; + box-shadow: 0 3px 8px -3px rgba(0, 0, 0, 0.08); + font-size: 1rem; +} + +.keybox input:focus { + outline-color: rgb(47, 98, 192); +} + +.keybox input::placeholder { + color: #aaadb4; +} + +.keybox input:focus:placeholder { + outline: none; +} + +.createDeviceButton { + appearance: none; + cursor: pointer; + background-color: #fff; + border: none; + border-radius: 6px; + box-shadow: 0 3px 6px -3px #0000001a; + font-size: 1em; + margin-bottom: 1em; + padding: 0.5em; +} + +.createDeviceButton:disabled { + background-color: #e8e8e8; +} + +/*DeviceEventLogger*/ +.eventsContainer { + width: 100%; + max-height: 50vh; + overflow: scroll; + display: flex; + flex-direction: column; + padding: 2rem 1rem 1rem; + margin: -0.5rem; + scroll-snap-type: y proximity; +} + +.eventFrame { + background: white; + box-shadow: 0 3px 8px -3px rgba(0, 0, 0, 0.08); + border-radius: 0.5em; + overflow: scroll; + margin: 0 0.5rem 1rem; + flex: 0 0 auto; + scroll-snap-align: start; + scroll-snap-margin: 1rem; +} + +.eventHeader { + display: flex; + justify-content: space-between; + padding: 0.5em 1rem; + background: #eaeff9; +} + +.eventTime, +.eventType { + color: #53627c; + font-size: small; + padding: 0; + margin: 0; +} + +.eventType { + font-weight: 500; +} + +.eventTime { + color: #6a748c; +} + +.eventProperties { + list-style: none; + padding: 0.5rem 0 0.55rem; + margin: 0; + /* display: inline-flex; */ +} + +.eventProperties li { + margin-top: 0 !important; + padding: 0 1rem; +} diff --git a/docs/network-iot/learn/understanding-lorawan.mdx b/docs/network-iot/learn/understanding-lorawan.mdx new file mode 100644 index 000000000..4b2666d29 --- /dev/null +++ b/docs/network-iot/learn/understanding-lorawan.mdx @@ -0,0 +1,70 @@ +--- +id: understanding-lorawan +title: Understanding LoRaWAN +pagination_label: Understanding LoRaWAN +sidebar_label: Understanding LoRaWAN +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /network-iot/learn/understanding-lorawan +--- + +LoRaWAN is a wireless protocol built around a simple tradeoff: sacrifice bandwidth for range and +power efficiency. A LoRaWAN device can transmit small packets (sensor readings, GPS coordinates, +status updates) over several kilometers while running on a battery for years. + +This makes LoRaWAN ideal for applications where devices need to report data infrequently and operate +unattended: agricultural sensors, asset trackers, smart meters, environmental monitors. + +## How Data Flows + +A LoRaWAN device doesn't connect directly to the internet. Instead, it broadcasts a radio signal +that any nearby gateway can receive. The gateway forwards the message to a LoRaWAN Network Server +(LNS), which authenticates the device, decrypts the payload, and delivers it to your application. + +```mermaid +graph LR + device[Device] -->|LoRa radio| gateway[Gateway] + gateway -->|IP| lns[Network Server] + lns --> app[Your Application] +``` + +Multiple gateways can receive the same transmission. The network server deduplicates these messages +and selects the best one based on signal quality. This redundancy improves reliability without +requiring anything special from the device. + +## Device Keys + +Every LoRaWAN device is provisioned with cryptographic keys that authenticate it to the network and +encrypt its data. Every device, custom built or off the shelf, has three identifiers: + +**DevEUI**: A unique 64-bit address that identifies the device globally, similar to a MAC address. + +**JoinEUI**: Identifies which network server should handle the device's join request. On Helium, +this is how the Packet Router knows where to send your device's traffic. + +**AppKey**: A secret root key shared between the device and network server. During the join process, +both sides use this key to derive session keys for encrypting data. + +These keys ensure that even though your device's radio signals are received by public gateways, only +your network server can read the contents. + +## On the Helium Network + +Helium Hotspots are LoRaWAN gateways. When a device transmits, any Hotspot in range receives it and +forwards the packet to the [Helium Packet Router][hpr]. The router uses the JoinEUI to determine +which LNS should receive the data, then delivers it there. + +This architecture means a single device can roam across the entire Helium network without +configuration changes. Any Hotspot will pick up its signal and route it correctly. + +:::note + +For deeper technical details on LoRaWAN, see [The Things Network Learn][ttn-learn] or the [LoRa +Alliance LoRaWAN 1.0.2 Specification][lora-spec]. + +::: + +[hpr]: https://github.com/helium/helium-packet-router +[ttn-learn]: https://www.thethingsnetwork.org/docs/lorawan/ +[lora-spec]: + https://resources.lora-alliance.org/technical-specifications/lorawan-specification-v1-0-2 diff --git a/docs/network-iot/lorawan-network-servers/LorawanNetworkServers.jsx b/docs/network-iot/lorawan-network-servers/LorawanNetworkServers.jsx new file mode 100644 index 000000000..91ae3b055 --- /dev/null +++ b/docs/network-iot/lorawan-network-servers/LorawanNetworkServers.jsx @@ -0,0 +1,7 @@ +import useBaseUrl from '@docusaurus/useBaseUrl' + +export const LearnMore = () => ( + <> + Learn More
}){kind=icon}
+
+)
diff --git a/docs/network-iot/lorawan-network-servers/find-a-lns-provider.mdx b/docs/network-iot/lorawan-network-servers/find-a-lns-provider.mdx
new file mode 100644
index 000000000..f1e898e2c
--- /dev/null
+++ b/docs/network-iot/lorawan-network-servers/find-a-lns-provider.mdx
@@ -0,0 +1,31 @@
+---
+id: find-a-lns-provider
+title: Find A LoRaWAN Network Server Provider
+pagination_label: Find An LNS Provider
+sidebar_label: Find An LNS Provider
+description: Find A LoRaWAN Network Server Provider
+image: https://docs.helium.com/img/link-image.png
+slug: /iot/find-a-lns-provider
+---
+
+import LnsProvidersTable from './findAnLnsProvider'
+
+Professional hosting companies can provide support and immediate access to a ready-to-go
+connectivity platform. LNS Services will vary in price, support, and features depending on the
+company. Companies may offer public shared servers, and/or private servers.
+
+The following providers within the OpenLNS initiative offer multi-tenant and private instances to
+businesses and individuals.
+
+| + {column.render('Header')} + + {column.isSorted ? (column.isSortedDesc ? ' ▼' : ' ▲') : ''} + + | + ))} +
|---|
| {cell.render('Cell')} | + })} +
})
+
+A LoRaWAN Network Server (LNS) is a vital component of a LoRaWAN network responsible for device
+management, message routing, and integration with application servers. LoRaWAN Network Servers play
+a crucial role in ensuring the scalability, reliability, and interoperability of LoRaWAN networks.
+
+})
+
+
diff --git a/docs/network-iot/lorawan-on-helium.mdx b/docs/network-iot/lorawan-on-helium.mdx
new file mode 100644
index 000000000..645671b04
--- /dev/null
+++ b/docs/network-iot/lorawan-on-helium.mdx
@@ -0,0 +1,176 @@
+---
+id: lorawan-on-helium
+title: LoRaWAN On Helium
+pagination_label: LoRaWAN On Helium
+sidebar_label: LoRaWAN On Helium
+description: Helium Documentation
+image: https://docs.helium.com/img/link-image.png
+slug: /iot/lorawan-on-helium
+---
+
+import useBaseUrl from '@docusaurus/useBaseUrl'
+
+
+
+
+
+ Work with a Service Provider
+ + Professional LNS hosting companies can provide support and immediate access to a ready-to-go + connectivity platform. + + +
+
+ Self Host an LNS
+ + Comfortable setting up, configuring, and managing your servers? Hosting your own LNS could + be a good option. + + +
+
+## Overview
+
+The Helium Network has many points of distinction from a typical LoRaWAN network that are critical
+for understanding before deploying internet of things (IoT) applications on Helium.
+
+In conventional LoRaWAN networks, end devices, such as sensors or actuators, send LoRa wireless
+messages to physical gateway devices. These gateways, in turn, forward the messages from the end
+devices to central or regional LoRaWAN Network Servers (LNSs) which decompose the messages for
+processing in IoT applications. Typically, LoRaWAN networks are run by a central authority in either
+public or private configurations. In public configurations, the central authority allows multiple
+customers to leverage gateways and LNSs in developing end-to-end IoT applications. Conversely, in
+private configurations, a single entity uses the network and all of its networking components.
+
+The Helium Network takes a different approach with respect to LoRaWAN networks. Rather than have a
+centralized authority responsible for managing gateway devices (referred to as Hotspots in the
+Helium parlance) or LNSs that serves as a gatekeeper for deploying end devices, Helium allows for
+the decentralized operation of both Hotspots and LNSs with a completely permisionless architecture.
+In practice, this means that anybody can run a Hotspot device and provide LoRaWAN coverage to the
+Helium Network. Similarly, anybody can operate an LNS and provide cloud connectivity and
+configuration for end devices. In turn, end devices operating on the Helium Network are able to tap
+into the global network of LoRaWAN connectivity powered by community operated Hotspots and gain
+access to the largest LoRaWAN network ever created.
+
+In the remainder of this section, a high-level overview of the architecture of the Helium Network
+will be provided, in addition to a discussion on terminology of networking primitives.
+
+## High-Level Architecture
+
+Given the unique architecture of the Helium Network in comparison to typical LoRaWAN networks, it is
+helpful to understand how Helium manages a large, decentralized ecosystem of Hotspots and LNSs.
+
+In this regard, a first primary difference is that rather than having gateway devices directly
+communicate with LNSs, Helium introduces the concept of an intermediate routing service called
+[Helium Packet Router (HPR)](https://github.com/helium/helium-packet-router) that handles the
+connectivity between LNSs and Hotspots. As shown in the diagram below, end devices still send
+messages to Hotspots, but instead of the Hotspots subsequently forwarding the messages to directly
+to an LNS, the Hotspots send the messages to HPR. In doing so, HPR can identify the particular
+Hotspots that forwarded the message from the end device in order to properly credit the Hotspot with
+data transfer rewards on the Helium Network.
+
+A second primary difference is with the introduction of the
+[Helium IoT Config Service](https://github.com/helium/oracles/tree/main/iot_config) which serves as
+an interface for users for configuring routing rules relied on by HPR when determining where to
+forward messages from end devices to LNSs. Users can leverage tools including the
+[Helium Config Service CLI](https://github.com/helium/helium-config-service-cli) for providing
+routing rule configurations to the Config Service (and in turn HPR).
+
+```mermaid
+graph LR
+ dev[Device] --> gateway[Hotspot]
+ gateway --> hpr[Helium Packet Router]
+ hpr --> lns[LoRaWAN Network Server]
+ hpr <--> ics[Helium IoT Config Service]
+ lns --> ics
+ lns --> i[Integrations]
+```
+
++ +For a deeper understanding of the architecture of the Helium Network, users are encouraged to read +documentation and review the open-source code for HPR and IoT Config Service: + +- [HPR](https://github.com/helium/helium-packet-router) +- [Config Service](https://github.com/helium/oracles/tree/main/iot_config) + +## The OUI + +Each LNS on the Helium Network acquires an Organizationally Unique Identifier (OUI). This registers +the LNS with the blockchain and allocates two very important routing objects owned and maintained by +the OUI Operator: + +- one or more **slabs** of DevAddrs, reserving NwkAddr space for the OUI's devices on the Helium + Network + +A device defined by (AppEUI, DevEUI) can be allocated to any of the DevAddrs owned by the OUI. It is +even possible to multiplex many devices on the same DevAddr at the same time, using the Message +Integrity Check (MIC) to disambiguate. + +Starting in 2023, Helium will be utilizing an OpenLNS Initiative to allow more choice and increase +usability. You can read more about the OpenLNS Initiative at the [Helium Foundation +Blog][foundation-blog] or read more in the [Use Helium LoraWAN](/iot/lorawan-network-servers) +section. + +## 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. + +An OUI has some specificities related to LoRaWAN and packet routing, as +[documented above](/iot/lorawan-on-helium#the-oui), but with respect to the blockchain, what's +important is that +[only libp2p addresses registered as endpoints for the OUI](https://github.com/helium/proto/blob/master/src/blockchain_txn_oui_v1.proto#L6) +may open and close state channels on behalf of an OUI. + +For example, the account `13tyMLKRFYURNBQqLSqNJg9k41maP1A7Bh8QYxR13oWv7EnFooc` purchased the first +OUI on the Helium Blockchain. The address `112qB3YaH5bZkCnKA5uRH7tBtGNv2Y5B4smv1jsmvGUzgKT71QpE` +operates the OUI on behalf of the owner. + +OUIs are purchased and numbered in incrementing order. + +:::info + +Based on the latest benchmarking tests the upper limit for a Devaddr `1024` slab is approximately +5800 devices, but results still need to be replicated and bracketed. Community members are +encouraged to run their own benchmarking tests. Requires basic familiarity with Linux and Bash +command line. + +::: + +### Join Request Frames and Filters + +A Join Request frame has the following unencrypted header: + +```bash ++---------------------------------------------------------+ +| Size (octets) | 8 | 8 | 8 | ++------------------+------------+------------+------------+ +| Join Request | AppEUI | DevEUI | DevNonce | ++---------------------------------------------------------+ +``` + +From the gateway's perspective, the (AppEUI, DevEUI) may be used to figure out if one or more OUI's +are interested in the Join Request. + +This is done by querying every filter maintained and written to the blockchain by every OUI. The +filters themselves are _xorhash_ tables, thus the AppEui and DevEui cannot be extracted. Only with +the AppEui and DevEui in hand can the gateway run it through the table to see if it's there. + +In response to the Join Request, a Join Accept is sent down, assigning the NwkAddr. Due to the +multi-tenancy on the Helium Network, the LNS may only assign NwkAddrs within its DevAddr slab(s). + +### Data Frames and DevAddr Slabs + +Data packets have the following unencrypted header (FHDR): + +```bash ++----------------------------------------------------------------------+ +| Size (octets) | 4 | 1 | 2 | 0..15 | ++------------------+------------+------------+------------+------------+ +| FHDR | DevAddr | FCtrl | FCnt | FOpts | ++----------------------------------------------------------------------+ +``` + +Within DevAddr, there is the NwkAddr of a device: + +```bash ++------------------------------------------------+ +| DevAddr | ++------------------------+-----------------------+ +| NwkID (bits 31–25) | NwkAddr (bits 24–0) | ++-----------+--------------------+---------------+ +| Helium Network | allocated by slab | +|(‘H’ / 0b1001000 / 0x48)| to OUIs | ++-----------+--------------------+---------------+ +``` + +From the gateway's perspective, it can use DevAddr to determine the OUI of Data frames. A quick +query can say which OUI owns this DevAddr slab. This look-up and routing by DevAddr instead of by +\(AppEUI, DevEUI\) via _xorhash_ filters is generally much quicker. + +[foundation-blog]: + https://medium.com/helium-foundation/scaling-iot-growth-with-heliums-open-lns-initiative-c906e6953d6d diff --git a/docs/network-iot/lorawan-roaming.mdx b/docs/network-iot/lorawan-roaming.mdx new file mode 100644 index 000000000..baa624694 --- /dev/null +++ b/docs/network-iot/lorawan-roaming.mdx @@ -0,0 +1,151 @@ +--- +id: lorawan-roaming +title: LoRaWAN Roaming on Helium +pagination_label: Roaming +sidebar_label: Roaming +description: Helium Documentation +image: https://docs.helium.com/img/link-image.png +slug: /iot/lorawan-roaming +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +Before getting started, make sure to have the following: + +- Helium Network Organizationally Unique Identifier (OUI). +- Data Credits (>3.5M DC). +- A NetID issued by the LoRa Alliance. +- A roaming endpoint so your LNS can receive roaming traffic. +- [Helium Config Service CLI](https://github.com/helium/helium-config-service-cli) installed. + +For guidance on purchasing and funding an OUI, refer to the following guides: + +- [Buy an OUI](/iot/run-an-lns/buy-an-oui) +- [Fund an OUI](/iot/run-an-lns/fund-an-oui) + +## Roaming Quickstart + +While your roaming endpoint is up and running, you need to let the Helium config service know of its +existence. Initialization of some CLI environment variables will streamline the process: + +Run `helium-config-service-cli env init` + +1. Fill in the relative path of the delegate key pair file for `Keypair Location` +1. Fill in `Your Net ID` for `Net ID` +1. Fill in your assigned OUI for `Assigned OUI` +1. Fill in the number of `multi-buy` you want for `Default Max Copies` as a default for your + routes. +1. Export the environment variables. This needs to be done manually. The CLI will list values to be + exported. Add `export` to each line and run it. For instance, run `export HELIUM_MAX_COPIES=15` + to set the max_copies value in the session. Be sure not to put a space around the `=` sign + +```sh title="Setting environment variables in a terminal window." +export HELIUM_KEYPAIR_BIN=<./your/path/to/delegate/keypair.bin> +export HELIUM_NET_ID=00003C +export HELIUM_OUI=
})
+ + +Next, let's define the endpoint that you use for ingesting traffic. You can run: + +```bash +$ helium-config-service-cli route update server --host
To get a sense of traffic + and DC usage on the network, check out the full{' '} + + Dune Data Credit Dashboard + + . +
})
++ +Next, click the on the `Add API Key` button in the upper right hand portion of the screen. + +
})
++ +Finally, provide a name for the API key and click Submit. + +
})
++ +When complete, take note of the API key as it will not be provided again once you navigate away from +the page. + +## Identify Tenant ID Using the ChirpStack Console + +Still using the ChirpStack console, the `Tenant ID` can be found by found by clicking on `Dashboard` +under the `Tenant` header of the left side panel. The `Tenant ID` will then be found near the top +middle of the tenant dashboard page. + +
})
++ +Take note of the Tenant ID as it will be required when using the gRPC API. + +## Create a Device Profile via the gRPC API + +The Node.js file provided below demonstrates how to create a device profile via the ChirpStack gRPC +API using the JavaScript SDK. Please note that `
})
++
+ +From **Device Profiles** click on **Add device profile**. + +
})
++
+ +From here you can either create a new **device profile**, or select one from the **device-profile +templates** if they're available. + +
})
++
+ +Click **Submit** to add your new device profile. + +
})
++
+ +## Create Application + +### Applications -> Add Application + +From the **Applications** sidebar menu, click **Add Application**. + +
})
++
+ +Create the application with a name and description. + +
})
++
+ +## Create Device in Application {#add-device} + +### Application -> Application-Name -> Add Device + +
+ +Select your Application and click **Add Device**. + +
})
++
+ +Fill in your device details and select the device profile you made earlier. A Device EUI can be +entered from a pre-provisioned device, or pressing the **↻** button will generate a fresh EUI. +The AppKey will be shown in the next step, don't worry about finding it yet. + +
})
++
+ +Click **Submit** when done. + +
})
++
+ +Enter the application key or generate a new one by pressing the **↻** button. + +
})
++
+ +Click **Submit** once you enter the application key. + +
})
++
+ +Your device should be created and listed in the application. The **LoRaWAN frames** tab will display +a live view of payloads being delivered to the LNS. +Additional devices can be added to the existing Application. + +
})
+diff --git a/docs/network-iot/run-an-lns/advanced-configuration.mdx b/docs/network-iot/run-an-lns/advanced-configuration.mdx new file mode 100644 index 000000000..f08333e12 --- /dev/null +++ b/docs/network-iot/run-an-lns/advanced-configuration.mdx @@ -0,0 +1,216 @@ +--- +id: advanced-configuration +title: Advanced Configuration +pagination_label: Advanced Configuration +sidebar_label: Advanced Configuration +description: Advanced Configuration +image: https://docs.helium.com/img/link-image.png +slug: /iot/run-an-lns/advanced-configuration +--- + +import useBaseUrl from '@docusaurus/useBaseUrl' + +## Session Key Filter (SKF) {#session-key-filter} + +Session Key Filters (SKF) regulate device traffic on specific devAddrs by utilizing LoRaWAN device +session keys. They establish conditions to either permit or restrict data flow based on the +configured session keys. It essentially allows the LNS operators to accept and reject traffic on a +device (session) level. + +In this example scenario, consider two device addresses (devAddr) 1 and 2: + +- **Provided Session Key for devAddr 1 and "ignore empty skf" = false:** + Only allows traffic through devAddr 1 if it passes Message Integrity Code (MIC) checks. +- **No Session Key for devAddr 2 and "ignore empty skf" = false:** + All traffic is allowed through devAddr 2 without MIC checks. +- **No Session Key for devAddr 2 and "ignore empty skf" = true:** + All traffic through devAddr 2 is blocked. + +The SKF will regulate traffic based on session key availability and the "ignore empty skf" flag, +independently per devAddr. + +Check the SKF flag for a route by running + +```bash +helium-config-service-cli route get --route-id
+
+
+### 3. Install The Config Service CLI {#install-cli}
+
+The [Helium Config Service CLI](https://github.com/helium/helium-config-service-cli) will be used to
+generate the key pairs used for the OUI. Run the following commands to pull & build the config
+service CLI:
+
+```bash title="Copy the latest source code from GitHub."
+git clone https://github.com/helium/helium-config-service-cli.git
+```
+
+To build the copied code, the Rust compiler must be installed.
+
+```bash title="Install the Rust toolchain."
+curl https://sh.rustup.rs -sSf | sh
+```
+
+```bash title="Add Rust to path."
+source "$HOME/.cargo/env"
+```
+
+Add the protobuf library which will be used during the compile process.
+
+```bash title="Install protobuf (Mac)"
+brew update && brew install protobuf
+```
+
+```bash title="install protobuf (Ubuntu)"
+sudo apt update && sudo apt install protobuf-compiler
+```
+
+With the build toolchain installed, compile the CLI.
+
+```bash title="Enter the directory and compile the CLI"
+cd helium-config-service-cli && cargo build --release
+```
+
+The built binary file `helium-config-service-cli` can be found under `target/release/` inside the
+`helium-config-service-cli` directory.
+
+Now that we have the CLI binary, let's put a copy in the local bin folder for simplicity's sake.
+Just copy `helium-config-service-cli` into `/usr/local/bin`. Files added to the bin folder will
+automatically be available to your command line.
+
+```bash
+sudo cp target/release/helium-config-service-cli /usr/local/bin/
+```
+
+### 4. Generate OUI Keys {#generate-keys}
+
+Generate the key pairs you'll be using to authenticate your interactions with the config service.
+These keys are implemented such that only you can createm, modify, and delete routes.
+
+After this step you will have two key pairs:
+
+- **Delegate Key Pair**: The delegate key is actively used to create and manage routes. In case it
+ is ever compromised, it can be updated using the owner key. Note that an OUI can have multiple
+ delegate key pairs. Guidance on how to manage delegate key pairs can be found in the
+ [advanced configuration](/iot/run-an-lns/advanced-configuration).
+
+- **Owner Key Pair**: The owner key is irreplaceable and should be kept safe, secure, and private at
+ all times. If lost or compromised, you could lose your OUI. The owner key pair is used for
+ delegate key management.
+
+Run the generate key pair command twice. First for the owner key pair and second for the delegate
+key pair. Name the files accordingly.
+
+```bash title="Generate key pair"
+helium-config-service-cli env generate-keypair })
+ + +```bash +helium-config-service-cli route euis add --route-id