diff --git a/0053-5g-dao.md b/0053-5g-dao.md
index 86a81324b..2f173da2e 100644
--- a/0053-5g-dao.md
+++ b/0053-5g-dao.md
@@ -7,212 +7,273 @@
- Tracking Issue: https://github.com/helium/HIP/issues/345
- Status: In Discussion
-# Summary
-[summary]: #summary
+**Summary**
-[HIP 51: Helium DAO](https://github.com/helium/HIP/blob/main/0051-helium-dao.md) provides a general structure for onboarding new WNPs to the broader Helium Network, with mechanisms in place to ensure that protocol-specific attributes such as proof-of-coverage rules, data credits pricing, and block validation are within control of the emergent WNT DAO.
+[HIP 51: Helium DAOs](https://docs.google.com/document/d/1ibFE2DI8fkd4uOSnIT00C7JiRYsZExg164_KtDzz-YI/edit#) provides a general structure for onboarding new DNPs to the broader Helium Network, with mechanisms in place to ensure that protocol-specific attributes such as proof-of-coverage rules, data credits pricing, and block validation are within control of the emergent DNP DAO.
-In this proposal, we specify the implementation of the structure proposed through a detailed onboarding proposal for the 5G Network. We propose initial configurations of the 5G economics layer as well as governance mechanisms within the DAO through Mobile Network Token (MNT) token voting.
+Today all mobile networks are built top down by service providers such as AT&T and Verizon. Future networks will likely be a hybrid combination of **macro operators** and **crowdsourced 5G/Wi-Fi hotspots** due to the physics of how wireless works. More data on the wireless network requires higher frequency bands, which requires denser networks with more nodes, which further increases cost of site acquisition.
-# Stakeholders
-[stakeholders]: #stakeholders
+The crowdsourced model removes site acquisition costs from the equation. It is not realistic to blanket the world with Wi-Fi or CBRS in the near future and completely replace service providers altogether. Instead, we see service providers as a critical component of this ecosystem and design Helium Mobile DAO economics taking that critical tenet into account.
-This proposal impacts all current and future participants in the Helium Community.
+In this proposal, we specify the implementation of the structure proposed through a detailed onboarding proposal for the Mobile Network.
-# Detailed Description
-[detailed-description]: #detailed-description
+# **Mobile US subDAO core jobs-to-be-done**
-We proposed in HIP 51 that each WNP subDAO operate as a sovereign economics and governance layer. The 5G subDAO has five core functions
+We proposed in HIP 51 that each subDAO operate as a sovereign economics and governance layer. The Helium Mobile Network subDAO has seven core functions
-1. *Economics*
-The 5G subDAO handles all bonding curve operations, and by extension all MNT emissions to hotspots and purchases or sales from third-parties. The economic responsibilities around this involve parameter selection for the curve and all associated fees, as well as liquidity risk management.
+1. **Economic Players**
-2. *Network Participants*
-5G subDAO coordinates economic activity between a number of network participants with various functional roles. A single entity can implement one or more of these functional and economic roles. The economic responsibilities include definition of network participant roles, minimum stake amounts, and rewards for participation
+The Helium Mobile subDAO governs the interactions between a number of entities performing functional and economic roles, critical to mobile data offload use case.
-3. *Validator Operations*
-5G validators perform a number of roles, including consensus group work, settlement account with inbound roaming operators, and network ingress/egress relay. 5G subDAO responsibilities here include definition of validator software, minimum stake amounts, and rewards for participation.
+1. **Emissions Curve**
-4. *Proof-of-Coverage Mechanisms*
-The 5G network utilizes a Proof of Coverage work algorithm to verify on an ongoing basis that hotspots are accurately representing their location and the wireless network coverage they are creating from that location. Responsibilities here include Proof-of-Coverage challenge construction, target selection, reward scaling, and verification.
+The Helium Mobile Network subDAO handles all HCT emissions, mining rewards, and programmatic treasury operations. The economic responsibilities around this involve managing the token issuance and distribution.
-5. *Data Transfer Mechanism and Pricing*
-Data transfer across the network occurs via the process of procuring and burning data credits in the name of the hotspot or set of hotspots that provide coverage. Responsibilities here include Organizationally Unique Identifier (OUI) registration, state channel creation, and bandwidth capacity per data credit definition.
+1. **Treasury Reserve and Market Making Curve**
-6. *Governance*
-The 5G subDAO retains full control over all components of the network, and DAO members can propose and vote for changes to core parameters and mechanisms. Responsibilities here include specification of a formal on-chain voting process that is resistant to attacks.
+subDAOs have full control over the prices at which the subDAO treasury provides quotes to holders of HCT who wish to redeem their holdings for underlying HNT. This can be a flat bid or a more complex curve.
-## Economics Specification
+1. **Oracle Specification**
-In the notation provided below, P represents Price and S represents Supply. The quote currency is MNT (Mobile Network Token) and the base currency is HNT (Helium Token).
+Oracles perform work including verifying proof of coverage and data transfer. The oracles are also responsible for distributing DNT mining rewards to the appropriate parties. Responsibilities here include definition of oracle software, minimum stake amounts, and rewards for participation.
-We propose that the 5G bonding curves take the shape P = S^k where k = 1.1.
+1. **Data Transfer Mechanism and Pricing**
-
-
-
-
-For a given amount of HNT deposited to or withdrawn from the 5G bonding curve, the increase or decrease in MNT supply and price is given by the resulting change in the area under the curve. The integral is given by:
+Data transfer across subnetworks occurs via the process of procuring and burning data credits in the name of the hotspot or set of hotspots that provide coverage. Responsibilities here include Organizationally Unique Identifier (OUI) registration, state channel creation, and bandwidth capacity per data credit definition.
-
-
-
+1. **Proof-of-Coverage Mechanism**
-The curve looks as follows:
+Most subnetworks will utilize a Proof of Coverage algorithm to verify on an ongoing basis that hotspots are accurately representing their location and the wireless network coverage they are creating from that location. Responsibilities here include Proof-of-Coverage challenge construction, target selection, reward scaling, and verification. Note that subnetworks can choose to skip this mechanism, but must provide reasoning as to why it is not necessary for proper functioning of the subnetwork.
-
- 
-
+1. **Governance Structure**
-At the end of a given epoch, the L1 HNT emissions contract **performs a tally of the data credits** transferred across the 5G Network. The emissions contract subsequently distributes the determined amount of HNT **to the 5G subDAO multi-signature wallet**, the addresses of which comprise the set of validators of the 5G Network.
+subDAOs retain control over critical components of the network, and subDAO members can propose and vote for changes to core parameters and mechanisms. Responsibilities here include specification of a formal on-chain voting process that is resistant to attacks.
-
+The remainder of this proposal defines initial values for the subDAO given the aforementioned set of responsibilities.
-## Network Participants
+### *Economics Overview*
-There are several types of participants in the 5G DAO, which are defined by their functional and economic roles. A single entity can perform multiple functions at the same time.
+There are a number of real world physical entities that comprise the network and perform the following functional and economic roles:
+| Name | Functional Role | Economic Role |
+|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| Subscriber | Uses the network | Pays service providers to access data on the network |
+| Mapper | Runs a network mapping app on the phone or uses a dedicated mapper device to verify coverage provided by the hotspot hosts. Mappers are required to be a subscriber. | Receives HCT mining rewards for mapping networking coverage |
+| Service Provider | Promotes network service to subscribers and mappers Runs subscriber database and authenticates inbound subscribers and mappers into the network Records data transfer transactions to state channels by running session purchaser instance Issues sim cards to subscribers and mappers Maintains their flavor of the witnessing app Responds to subscriber and mapper support queries | Receives payments for data access from subscribers and mappers Burns HNT into Data Credits and settles data usage with hotspot hosts Stakes HCT to receive % of rewards from HCT Emissions contract |
+| Hotspot Host | Operates a hotspot (can be 5G or Wi-Fi) and pays for backhaul | Receives HCT mining rewards for providing coverage Receives HCT mining rewards for providing data access to subscribers |
+| Hotspot Vendor | Builds and sells hotspots Supports hotspot hosts Runs software to provide updates of hotspots Maintain integrations with service providers | Stakes HCT Receive % of rewards mined by hotspot hosts |
+| Oracles | Relay data to L1 emission contract Calculate incentive points for service providers and mappers | Stake HCT Receive % of rewards from emissions contract |
-| Participant | Functional Role | Economic Role |
-| ----------- | ----------- | ----------- |
-| Subscriber | Uses the network | Pays to access data on the network. |
-| Witness | Runs a witnessing app on the phone to verify coverage provided by the hotspot hosts. Witnesses are required to be a subscriber. | Receives MNT mining rewards for witnessing coverage. |
-| Witness App Vendor / Service Provider | Promotes network service to subscribers. Issues sim cards to witnesses. Maintains the witnessing app. Responds to witness support queries. | Receives payments for data access from subscribers. Pays Federation & Settlement validators for data on the Helium network. *Stakes MNT to receive % of witness rewards as a function of data sent to the network |
-| Hotspot Host | Operates a 5G hotspot and pays for backhaul. | Receives MNT mining rewards for providing coverage. Receives MNT mining rewards for providing data access to subscribers. |
-| Hotspot Vendor | Builds and sells hotspots. Supports hotspot hosts. Runs Magma Orchestrator to Facilitate OTA updates of hotspots. Operates onboarding server. | *Stakes HNT to receive % of MNT rewards mined by hotspot hosts, as a function of data sent through them. |
-| Federation & Settlement Validator | Authenticates inbound roaming sessions by running a Federation Gateway instance.Records data transfer transactions to state channels by running session purchaser instance. | Gets paid by the service provider. Stakes MNT to receive % of processed transactions. Pre-burns MNT to DC |
-| Consensus Validator |Runs a consensus validator node | Stakes MNT to receive % of consensus group tokens. |
+To operate on the network, service providers and hotspot vendors must control a respective NFT. Getting this NFT requires hotspot vendors and service providers to:
-We propose that the 5G DAO distributes MNT in the following proportion after minting the given number of tokens per epoch if the **Notional Value of Data Credits Transfer (X% of Hotspot emissions) across the WNP is Less than Market Value of MNT Tokens Allocated to Hotspots.**
+1. Stake a minimum of 50M HCT in the case of hotspot vendors, and 500M HCT in the case of service providers
+2. Obtain HCT DAO governance approval
-
+The initial set of service providers and hotspot vendors are voted in by the Helium community together with DAO with no staking requirement, but these actors are required to stake HCT 6 months following the DAO launch.
-*Note that all manufacturers within the network must stake a minimum of 10,000 MNT tokens in order to be whitelisted to receive rewards. If at any point, a manufacturer gives ownership of maintenance and firmware upgrades to a third party, all future manufacturer rewards flow to this new entity. The new hotspot onboarding fee and location assertion fee should be identical.*
+Rewards from the emissions contract are distributed between service providers, mappers and hotspot operators as a function of the incentive points earned during a period of time. Service providers are allowed (and encouraged) to use the pool of HCT emissions they get towards growing their subscriber base by either sharing HCT directly with subscribers for usage via a witnessing app or discounting data plans.
-## Validator Operations
+Hotspot vendors can adjust what % of HCT generated by the fleet of hotspots deployed by their customers is kicked back up to the hotspot vendors and pursue different deployment strategies, from giving out free/highly subsidized hotspots to passing 100% or rewards to hotspot operators, but charging higher $$ prices for hardware.
-5G validators perform the following functions:
-- Proxy 5G signaling traffic that allows inbound data offload operators to authenticate subscribers in the HSS database to attach to the Helium 5G hotspot nodes (aka host Magma Federation gateway nodes)
-- Confirm transactions and add blocks to the 5G L2 chain. They serve state data around Proof-of-Coverage challenges
-- Run cellular settlement infrastructure and session purchaser (as described in Data Credits and Pricing section below)
+Reward calculations that trigger distribution of tokens between service providers, mappers and and hotspot operators in the Helium Mobile DAO is performed by Oracles. At launch, network participants stake HCT to a genesis oracle for some predefined pro-rata share of emissions. Over time as new oracles onboard to the network, they are required to self-stake a minimum of 250M HCT in order to participate in rewards calculations, although the stake minimum is a parameter tunable by governance. Oracles continuously witness a stream of events coming from various DAO participants (such as mapper/hotspot attach events, data offload events, etc.) and perform reward distribution calculation. At the end of an epoch, Oracles come to consensus on proper distribution of HCT tokens based on events witnessed during the last epoch.
-Validation is performed by a set of rotating nodes known as the consensus group, which verifies transactions and ordering prior to forming a block and proposing it to the L2 chain. Consensus groups are elected once per epoch, and the number of members is given by the num_consensus_members chain variable (currently set at 40).
+Below is a high level visualization of the rewards flow from the emissions curve to economic participants of the DAO:
-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 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.
+Service providers will earn 20% of all HCT tokens minted by the DAO emissions curve, which will be distributed as a function of the number of incentive points accumulated by service provider participants during the given hour. Incentive points are issued using the following rules
-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.
+- Service Provider receives 1 point for each of the mappers that used a SIM from this service provider and witnessed the network
+- Service Provider receives 3 points for each $1 worth of DCs settled in state channels
-At the end of each epoch, mining rewards are distributed by the consensus group to the wallet addresses that have earned them.
+Sim Authentication sessions from mappers are proxied through Oracles (but initially just the Helium Foundation) so that a service provider can’t lie about the number of mapping sessions they authenticated. Points for DCs settled in state channels are derived from cellular settlement service, which can be run by service providers themselves. Details of the cellular settlement service and its interactions with the service provider infrastructure (such as OCS/PCRF etc.) [are described here.](https://github.com/magma/grants/issues/14)
-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.
+Individual hourly HCT earned by service provider during an epoch (initially 1 hour) is then calculated using the following formula:
+
+
+
+Mappers will earn 10% of all HCT tokens minted by the DAO emissions curve. Tokens will be distributed to mappers as a function of the number of incentive points accumulated by all mappers on the network during an epoch. Initially, incentive points are issued to mappers using a simple rule:
+
+- Mapper Receives 1 point each time it witnesses an eligible hotspot.
+
+Later, the point system for mappers can be adjusted through DAO voting to introduce more complex mapping algorithms with elements of gamification.
+
+Individual hourly HCT earned by a mapper is calculated using the following formula:
+
+
+
+Hotspot owners will earn 60% of all HCT tokens for proof of coverage (PoC) related events (staying eligible and getting mapped) and for burning Helium data credits.
+
+Total number of tokens distributed specifically for PoC events will vary from 20% to 60%, depending on the amount of data offloaded and number of tokens that went to data. PoC tokens PoC tokens are distributed to hotspot owners based on the number of incentive points accumulated by hotspot owners during a given epochhour. Incentive points are issued using the following rules:
+
+1. Hotspot receives 1 point for each 4 consecutive hours of remaining eligible
+2. Hotspot receives 3 points every time it was witnessed by a mapper
+
+ 
+
+
+Tokens related to data credit burn are distributed in direct proportion to the number of DCs burned and are a function of amount of data offloaded by a particular hotspot and price of DC set by the DAO. See Data Transfer Mechanism and Pricing section for more details.
+
+### *Emissions Curve*
+
+There will be a max supply of 200B HCT.
+
+The proposal is to have halvenings of HCT issuance every 2 years aligned with the HNT issuance halvenings. This requires a 1 year “stub” period from August 1, 2022 to August 1, 2023.
+
+We also propose that 10B HCT are pre-mined at the launch of the network, and distributed to the subDAO operations fund administered by the Helium Foundation. This allocation is distributed over the course of the stub period to live Mobile Network hotspots on an epochal basis in roughly equal proportion (akin to universal basic income).
+
+For clarity, the emission schedule is as follows:
+
+| Year | HCT at the start of the year | HCT minted | Hotspot PoC | Hotspot Data (excess to PoC) | Mappers | Service Providers | Oracles | veHNT Stakers | Operations Fund |
+|------|------------------------------|------------|--------------|------------------------------|---------|-------------------|---------|---------------|-----------------|
+| 1 | 10B | 65B | 20%* | 40%* | 10%* | 20%* | 4%* | 3%* | 3%* |
+| 2 | 70B | 32.5B | 20% | 40% | 10% | 20% | 4% | 3% | 3% |
+| 3 | 102.5B | 32.5B | 20% | 40% | 10% | 20% | 4% | 3% | 3% |
+| 4 | 135B | 16.25B | 20% | 40% | 10% | 20% | 4% | 3% | 3% |
+| 5 | 151.25B | 16.25B | 20% | 40% | 10% | 20% | 4% | 3% | 3% |
+| 6 | 167.5B | 8.125B | 20% | 40% | 10% | 20% | 4% | 3% | 3% |
+| 7 | 175.625B | 8.125B | 20% | 40% | 10% | 20% | 4% | 3% | 3% |
+
+*of post UBI reserve of yearly supply (65B - 10B) = 55B
+
+At the end of a given epoch, HCT oracles relay start balance, current balance, and total amount of HCT Data Credits created and relay to the L1 HNT emissions contract. The emissions contract subsequently distributes the determined amount of HNT as per the Protocol Score to the 5G subDAO multi-signature wallet, the addresses of which comprise the set of oracles of the 5G Network.
+
+The subDAO operations fund is intended to allow the DNP to perform bespoke operations to create and sustain network growth. The primary use case of the operations fund is to fund all state transition transaction fees to the L1, but can be deployed in any manner of ways as per subDAO governance. Such incentives could include
+
+1. Surge-pricing style dynamic multipliers based on data transfer activity for individual regions
+2. Bespoke incentives for oracles and manufacturers on the basis of changing network demands
+
+Once emissions are distributed to hotspots and oracles, HCT owners can either redeem their holdings for underlying HNT against the treasury reserve automatically, hold for redemptions at a later time, or lock up their HCT for veHCT in a process similar to the veHNT mechanism described in HIP 51.
+
+A user’s veHCT lockup power is determined by 1) the amount of HCT they lock up with, and 2) the amount of time they commit to locking up their HCT. The structure applies a linear multiplier of time to the amount of HNT locked up in the voting contract. For the maximum period of four years, users receive 100x the veHCT. For the minimum period of six months, users receive 1x the veHCT. Note that veHCT is **non-transferable**, and represented as a non-fungible coupon in the user’s HCT address.
+
+Users can choose to delegate their veHCT for three core purposes:
+
+1. Stakeholder Staking: Users are able to delegate veHCT in the name of:
+ 1. Specific hotspots in order to increase their hourly incentive points multiplier
+ 2. Specific service providers in order to increase their hourly incentive points multiplier
-## Proof-of-Coverage Specification
+Users are able to stake either “for” or “against” hotspots or service providers. At the end of each epoch, stakeholders have a net veHCT score in which “for” staked amounts are added, and “against” staked amounts are subtracted from the running total.
-The 5G subDAO is required to constantly interrogate 5G hotspots using the Proof-of-Coverage challenge mechanism to ensure that hotspots are representing their locations accurately. The results of each of these challenges are relayed to the Helium L1 after being validated by their respective consensus groups.
+Stakeholder veHCT scores are considered within a range of -10M and 10M. For the maximum amount of 10M veHCT staked, stakeholders receive 10x the incentive points multiplier. For the default amount of zero veHCT staked, stakeholders receive 1x the incentive points For the minimum amount of -10M, stakeholders receive zero incentive points. In either direction across zero from the y-axis, the incentive point multiplier varies linearly with the veHCT staked.
-PoC implementation proposed in the Helium LoRaWan sub-dao is based on wireless coverage being verified through LoRa hotspots issuing “challenges” to “challengees” and “witnessing” over the air interface. However, for the 5G wireless protocol, radios cannot both challenge and witness the packets over the air, as the 5G/LTE and other cellular protocols are designed for the radio to interact with a UE (such as cell phone) vs another radio. Moreover, because the use case we are pursuing is not to build a stand-alone network that will blanket the world (like in IoT case) but to create an offload network that can effectively complement macro network of an operator, the usefulness of the cell is determined by a) number of UEs in proximity that are capable of connecting to it; b) comparative RSSI of offload operator macro-cells in proximity. Usefulness should not be a function of location relative to another cell on the Helium network, as is the case with LoRa.
+Users that delegate veHCT to stakeholders receive 50% of any incremental earnings through increased incentive multiplier points.
-For 5G subDAO we propose to separate the challenge and witness function(s) for 5G PoC between the operator of a hotspot and an iOS/Android app (aka eSIM app), as follows:
+Stakeholders that are found to be gaming or cheating rewards are blacklisted from the network, and delegated veHCT is distributed as follows:
-- 5G hotspots on the network (regardless of wireless protocol) perform “the challenger” function by issuing randomly targeted challenges every N blocks
-- 5G Hotspot operators pick-up 5G challenges and cache them for N blocks until witness cell phones that attach to the hotspot
-- Cell phone owners with the witnessing app installed will “witness” that the hotspot is, indeed, active and radiating signal, and submit the confirmation back to the blockchain.
+
-Following the completion of the above, both the 5G hotspot operator and the cell phone owner with the eSIM app will receive their respective “challenge” and “witness” rewards.
+1. 50% of delegated veHCT is burned
+2. 50% of delegated veHCT is distributed to users who staked against the hotspot
-From the implementation standpoint, we’ll work to re-use the PoC mechanism implemented in LoRa DAO. Table below shows the mapping between steps in the current PoC mechanism and their cellular counterpart.
+For example, consider the following closed system with Stakeholder A, Stakeholder B, User X, and User Y.
-| | LoRa PoC | Cellular PoC |
-| ----------- | ----------- | ----------- |
-| 1. | Challenger, that can be any node on the network, writes a transaction on chain as a request. Currently happens once every 480 blocks. | A 5G gateway issues a cellular challenge every N blocks and writes challenge transaction to the 5G L2 chain.|
-| 2. | Challengee tries to decrypt all requests from chain and notices they’re being challenged. | 5G miner with cellular radio attached plays a role of Challengee and tries to decrypt all requests from chain and notices they’re being challenged. |
-| 3. | Challengee sends receipt to challenger via libp2p | Challengee waits for a period of N blocks for a phone with eSIM app to come in range and attempt to attach. When a witness phone attaches to the challengee cell, challenger cell sends a receipt to the challenger via gRPC and appends witness IMEI. |
-| 4. | Challengee sends beacon over radio. |Challengee accepts the attach request(s) from a witness phone running an eSIM app. Challengee sends the challenge packet to the witness over the air, immediately following the attach. |
-| 5. | Witness sees packet over radio | Witness phone with eSIM app receives packet from the challengee over radio. |
-| 6. | Witness finds matching “onion” in a recent request transaction. |eSIM app appends it’s IMEI, and witness key to the challenge packet. |
-| 7. | Witness sends receipt to challenger via libp2p. |eSIM app sends above data + receipt to challenger over gRPC, once it is no longer attached to the challengee cell. |
-| 8. | Challenger combines receipts and writes receipt on chain. |Same as Lora, challenger combines receipts and writes receipt on chain. |
+X delegates 1M veHCT “for” stakeholder A and 4M veHCT “against” stakeholder B.
-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.
-
-5G DAO will set its own variables, yet reuse the logic from HIP 15 and 17 for scaling rewards to 5G hotspots based on placement as per target density of hotspots in a given geographic area as well as number of witnesses to challenges participated in.
+Y delegates 5M veHCT “for” stakeholder A and 2M veHCT “for” stakeholder B.
-## Data Transfer and Pricing Specification
+Tallying both scores, we have a net score of 6M veHCT “for” stakeholder A and -2M veHCT “against” stakeholder B.
-Data Credits are utilized in asserting new hotspots and their location on the chain, registering Organizational Unique Identifiers (OUIs) and associated devices, and as payment for packet transfers.
+In this epoch, stakeholder A is expected to receive 6x the incentive multiplier under normal circumstances, and stakeholder B is expected to receive 0.8x the incentive multiplier it would be eligible for under normal circumstances.
-Helium 5G sub-dao will operate a set of 5G L2 chain variables that will dictate the conversion ratio between Data Credits and MNT tokens, denominated in oracle USD price. Changes to the conversion ratios will be conducted following Sub DAO governance specification.
+If stakeholder A were to receive 120K HCT through rewards in an epoch, we could expect that it would have received 20K HCT under normal circumstances. User X would receive 1/6 of the incremental amount (8.33K HCT) and the hotspot owner would receive 5/6 of the incremental amount (41.67K HCT).
-The initial set of DC conversion variables will be as follows:
-- Price to onboard a new 5G hotspot (aka register a new OUI)
-- Price to assert location of 5G hotspot
-- Price per GB of 5G data (denominated in $$ per 66 byte LTE packet)
+If hotspot B were convicted by governance of gaming rewards, 3M of the total veHCT would be sent to a burn address, whereas the underlying HCT within the 3M veHCT would be distributed to user X. If there were other users who staked against stakeholder B, this would be distributed pro-rata.
-Roaming agreements require settlements where the visited network exports the data records as measured at the SGW (running on the 5G miner) towards the offload operator. The offload operator may or maynot use a clearing house.
+Note that users also have the option of burning HCT in the name of stakeholders, in order to receive an equivalent pro-rata share of staking rewards in perpetuity.
-Without clearing house: The records as raised by the visited network translate into invoices at price per GB defined by the 5G DAO governance. The typical window for this is monthly settlements.
+1. Oracle Delegation: veHCT holders can delegate their holdings to oracles in order to earn future emissions.
+2. Governance: veHCT can be used to participate in subDAO proposals that impact core protocol parameters, mechanisms, and operating procedures. veHCT that is staked to a hotspot or to an oracle can still vote on governance proposals.
-With clearing house: The visited network raises records in a standard format like Transferred Account Procedure(TAP) which the clearing house rationalizes with billing records seen in the network of the offload operator based on some pre agreed rules. The settled data records are exposed to the visitor network typically on a monthly window.
+### *Treasury Reserve DNT Market Making Curve*
-Facilitating such settlements will require that an offload operator (or some 3rd party intermediary) run a validator instance that, in addition to acting as a member of consensus group, also operate the following infrastructure:
-- Session purchaser instance. Operators of 5G Session Purchaser will maintain a certain pool of data credits pre-burned from MNT tokens that can be used to facilitate traffic offloading. Pre-burn can happen either immediately pri to authorizing an offload section or some time in advance
-- Magma Federation Gateway instance that will proxy 5G signaling traffic that allows inbound data offload operators to authenticate subscribers in the HSS database to attach to the Helium 5G hotspot nodes
+The Mobile subDAO sets the programmatic treasury formula in order to provide quotes to holders of DNT who wish to redeem their holdings for underlying HNT. Note that at launch of the subnetwork prior to any HNT emissions from the minting contract as per the protocol score, the Helium Foundation will make a donation of HNT into the subDAO treasury reserve in order to collateralize the airdrop specified in the emissions section.
-The following diagrams describe the UE session attach, update and termination call flows between the following components of the system:
-- UE - a cell phone or any cellular device connecting to Helium 5G network
-- eNB - a 5G or LTE radio attached to the 5G hotspot
-- MME/SGW - components of Magma network core running on the 5G hotspot
-- Miner - code responsible for parsing/interacting with 5G L2 blockchain running on the 5G hotspot
-- Session Purchaser/ESB - a validator instance that also incorporates a session purchaser (as described above) that is run by either the offload operator or a 3rd party intermediary
-- State Channel, Blockchain
-- Home EPC - network core infrastructure (specifically HSS and OCS/PCRF) of the offload operator
+We propose a constant function market making formula for the 5G subDAO programmatic treasury defined as per the following specification.
-| **Fig.1 - Attach Call Flow**|
-|:--:|
-|  |
+
-| **Fig.2 - Update Call Flow**|
-|:--:|
-|  |
+At epoch T, we denote the value of H, S, and P as HT, ST, and PT. The programmatic treasury formula at epoch T is a function in two variables, HT, ST defined as follows:
+
+
+
+For example, consider at epoch #125, the total outstanding supply of tokens for the Mobile subDAO is 3.275B HCT and the total amount in the treasury reserve is 2M HNT. The programmatic treasury formula is given as follows
+
+
+
+This implies that at epoch #125, any number of HCT tokens can be redeemed at a unit price of 0.00061068702 HNT.
+
+Now consider at epoch #225, the total outstanding supply of tokens for the Mobile subDAO is 3.5B HCT and the total amount in the treasury reserve is 2.025M HNT. The programmatic treasury formula is given as follows
+
+
+
+This implies that at 100 epochs after #125 at #225, any number of HCT tokens can be redeemed at a unit price of 0.00057857142 HNT.
+
+In epoch #225, the total outstanding supply of HCT has increased, and given inflows to the treasury reserve in HNT the resulting unit price has decreased. If the rate at which HNT flows into the treasury reserve outpaces the emission of HCT tokens, the unit price of HCT increases.
+
+Between epoch #125 and #225, a similar repricing takes place in each individual epoch given the amount of HNT in the treasury reserve and the outstanding supply of HCT tokens.
+
+Clarifications:
+
+- The supply of HCT tokens for the purposes of calculating the HCT/HNT price includes all locked HCT tokens.
+- The subDAO updates the limit order price every epoch **before** any new HCT are distributed out to stakeholders for their activity during that epoch.
+
+## *Data Transfer and Pricing Specification*
+
+Data Credits are a universal unit of payment across all Helium DAOs and will be utilized by the Service Providers in the Helium Mobile DAO ecosystem as payment for packet transfers.
+
+Service Providers operating in the Helium Mobile DAO will be required to either directly run an instance of the cellular settlement service or contract a third party entity, approved by the DAO to run an instance of the service for them. Detailed specification of the cellular settlement service and its interaction with service provider infrastructure and the Helium blockchain are [described here.](https://github.com/magma/grants/issues/14)
+
+Helium Mobile Network Dao will operate a chain variable that will dictate the conversion ratio between Data Credits and HCT tokens, denominated in oracle USD price. Changes to the conversion ratios will be conducted following Sub DAO governance specification.
+
+The initial price per GB of Mobile Network data is suggested to be set at $0.5 per Gigabyte, which means that 1 Helium data credit, when used for data on Mobile Helium DAO will convert to $.00000003 per LTE packet of 66 bytes.
+
+## *Oracle Operations*
+
+Mobile Network oracles perform the following functions:
+
+1. Proxy mobile network signaling traffic that allows inbound data offload operators to authenticate subscribers in the HSS database to attach to the Helium Mobile Network hotspot nodes
+2. Confirm transactions and add blocks to the Mobile Network L2 chain. They serve state data around Proof-of-Coverage challenges
+3. Reward calculations that trigger distribution of tokens between service providers, mappers and and hotspot operators
+
+Validation is performed by a set of rotating nodes known as the consensus group, which verifies transactions and ordering prior to forming a block and proposing it to the L2 chain. Consensus groups are elected once per epoch, and the number of members is given by the num_consensus_members chain variable (currently set at 43).
+
+At launch, a single oracle operated by the Helium Foundation validates data transfer and proof-of-coverage across the Mobile Network. Over time, new oracles join the network while the subDAO defines consensus rules for the underlying protocol.
+
+At the end of each epoch, mining rewards are distributed by the consensus group to the wallet addresses that have earned them.
+
+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.
-| **Fig.3 - UE Termination Call Flow**|
-|:--:|
-|  |
+Proof-of-Coverage Specification
-| **Fig.4 - Network Termination Call Flow**|
-|:--:|
-|  |
+The Mobile Network subDAO is required to constantly interrogate Mobile Network hotspots using the Proof-of-Coverage mechanism to ensure that hotspots are representing their locations accurately and providing functional radio coverage.
-## Governance Specification
+PoC implementation proposed in the Helium Mobile Network sub-dao is based on wireless coverage being verified through LoRa hotspots issuing “challenges” to “challengees” and “witnessing” over the air interface. However, for the 5G wireless protocol, radios cannot both challenge and witness the packets over the air, as the 5G/LTE and other cellular protocols are designed for the radio to interact with a UE (such as cell phone) vs another radio..
-Every aspect of the 5G Network is under the control of the subDAO. All subDAO proposals must come attached with code to be approved.
+For Mobile Network subDAO we propose to separate the challenge and witness function(s) between the operator of a hotspot and a mapper device (such as a phone or a dedicated mapper) with a sim card that has been authorized to perform the witness function. During the launch stages of the DAO we propose a simplified approach to mapping coverage as follows:
-We propose the following governance mechanism borrowed from HIP-41 in order to impose enough of a cost on voting that only committed participants would vote to influence the direction of the network, while ensuring that the barrier to entry is low enough for all small holders to participate should they choose.
+The world is divided into hexes using the H3 geospatial [indexing system](https://h3geo.org/docs/). All hotspots exist as NFTs associated with their unique pub keys and will receive *Eligibility Rewards* and *Mapping Rewards*. All hotspots will receive eligibility rewards, hotspots mustas long as they meet the following minimum criteria:
-The core primitive of this proposal is “voting power”, the unit of support for either side in a given vote.
+1. Stay registered in a Spectrum Access System (SAS), as evidenced by the Domain Proxy software that’s operated by a hotspot vendor
+2. Meet minimum backhaul QoS of 100Mps on the downlink and 10Mps on the uplink, as evidenced by the randomized backhaul challenges run by the hotspot firmware
+3. Be located in a hex that’s been whitelisted for rewards
-Network participants can deposit MNT tokens to a “governance staking contract”, which are locked and delegated to one or many validators of their choosing. Users have control over the number of tokens they choose to stake, and the period they choose to stake them for.
+All hotspots that have remained eligible (i.e. received eligibility rewards) during the last 4 consecutive hours, will be eligible to receive mapper rewards.
-The minimum lockup period is **250,000** blocks and the maximum lockup period is **2,500,000** blocks (these values can be changed retroactively via this governance mechanism).
+Any device (first and foremost a phone) with the proper sim card can be a witnessing device on the network. To witness coverage a “mapper phone” must connect to a CBRS cell or Wi-Fi AP using sim based authentication with a sim card that has been granted mapping privileges by the service provider. Service providers will act as “validators of witness transactions” performed by mappers by authenticating mappers through their HSS via either s6a or sWx protocols.
-A user’s voting power is determined by 1) the amount of MNT they vote with, and 2) the amount of time they commit to locking up their tokens. The structure applies a linear multiplier of time to the amount of MNT locked up in the voting contract. For the maximum amount of 2,500,000 blocks, users receive 50x the voting power. For the minimum amount of a 250,000 block lockup, users receive 1x the voting power.
+During initial launch stages, when network density is low, to combat gaming, Helium Mobile DAO implements a simple limiting algorithm:
-As a simple example, let’s imagine Alice, Bob, and Charlie all have 100 MNT:
-1. Alice chooses to lock up her tokens for the minimum required 250,000 blocks, and thus her voting power is 100
-2. Bob commits to locking up his tokens for 1,375,000 blocks, and thus his voting power is 25 * 100 = 2,500
-3. Charlie commits to locking up his tokens for 2,500,000 blocks, and thus his voting power is 50 * 100 = 5,000
-
+1. Same mapper can witness the same hotspot no more than once every 4 hours
+2. Same cell can be witnessed by a maximum of 6 unique mappers every hour
-As the lockup burns down, so does the voting power. For example, if Charlie locked up his 100 tokens for 2,500,000 blocks and 1,125,000 blocks have passed then Charlie would have 2,500 vote power.
+During consequent launch stages, as the density of mappers grows, Helium Mobile DAO will look to implement a more robust algorithm, similar to Helium LoRa PoC, whereby only randomly challenged hotspots can be witnessed. Details of this mechanism along with analysis of various attack vectors have been previously published and discussed with the community in HIP37
-Governance proposals can be called to a formal vote with a minimum of **1,000,000** voting power (“vote minimum”), and users will be able to participate in each vote for a period of 7 days (“voting period”). These thresholds are placed to mitigate risk of DDoS attacks, but both parameters will be tunable by this same voting process at any time.
+### *Governance Specification*
-Note that the voting power used to call a vote is eligible to vote, so the user that calls for a proposal to be voted upon can allocate their stake to either side. At the end of the voting period, the governance staking contract looks at how many tokens a voter has and how long they are locked for. Voters can always extend their lockup period just prior to voting. Locked tokens can vote as many times as they want, and all earnings from staking are earned by voters as normal staking rewards.
+Mobile Network Network is under the control of the subDAO. All subDAO proposals must come attached with code to be approved.
-One of the challenges with the locking mechanism proposed here is that most participants will wait until the last minute to vote. This is because there is a cost—namely, giving up liquidity—to vote. As such, if a vote is going someone’s way, they may not want to participate and lock up tokens.
-In order to incentivize honest voting and maximal participation, we propose that 5G DAO governance adopt a commit-and-reveal scheme. With this feature, votes would be submitted in a concealed fashion. Upon the completion of the voting period, we propose a 3 day reveal period in which voters can review the results of the vote, including who voted.
+We propose that veHCT governance is constructed in a manner identical to veHNT governance as specified in HIP51.
-Commit-and-reveal can be implemented by having voters hash together their address, vote, and salt. Once the reveal period begins, voters can reveal their votes by publishing the unhashed data. If voters don’t reveal their vote before the reveal period, their vote is not counted.
+Users can choose to delegate their lockup power in veHCT to all Mobile Network DAO governance proposals. Proposals are assessed using majority and quorum thresholds defined in veHCT terms, initially proposed to be 67% and 100M HCT respectively.
-The result of this should be maximal participation for important decisions because voters won’t know whether their vote will matter or not.
+Note that only proposals with code attached can be voted on.