HIP 10: Usage-based Data Transfer Rewards

[abhay]

This is for discussion of HIP 10.

Rendered HIP view: https://github.com/helium/HIP/blob/master/0010-usage-based-data-transfer-rewards.md

[Carniverous19]

I like the method of re-allocation and your first example (where DC throughput is very low) it seems appropriate yet doesn't overly reward challenge creation which is a concern for DIY (1% to ~1.4%).

Thoughts on a reward above 1:1:
We should put more thought into the 10% increase in reward beyond 1:1. Originally I thought that any arbitrage would cause extreme abuse but this may be low enough that gains are negligible.

One sample txn: CbJqCDWuuBIht-tWuHMPqK6XTZjXosOYFfwUef5UwDs the hotspot running the most amount of data (dapper-hickory-meerkat) sent 282,310 DC in a state channel (which I believe is 25 blocks long, roughly 1 epoch). This represents $2.82 in DC so other people performing a similar game as dapper-hickory-meerkat would be able to gain $0.28 per epoch per hotspot or $13.44/day, $408/week. This is a decent amount of money but not near the $21,000/week the gaming hotspot is currently earning and may not be motivation enough for others to implement such a sophisticated exploit (all other hotspots even with significant mining data are around 1/7th to 1/20th this volume of data). That said I am not sure what is gained by providing such a reward either.

Other Notes

• It will likely be years to hit the target HNT percentage allocation with this method, possibly many years. With the scheduled increase in data transfer allocation its possible target allocation will never be hit until it plateaus or unless there is a significant decrease in oracle price. hitting 32.5% requires Terabytes of data per month and hundreds of billions of packets per month. with LoraWAN being optimized for low payload size / low duty cycle this is unlikely to occur without hundreds of millions of devices.
• This effectively rolls back data transfer earnings as the rewards will be a fraction of a percent (effectively 0%). As the first example distribution example shows, DC rewards are nearly zero and even with 9,500,000,000 DC / month (6.5M/epoch) the allocation would only be 1%. Right now we see ~3.3M DC / epoch even with the massive amounts of mining data. So even if all mining traffic continues after this change the data transfer allocation would only be ~0.5%. The effect is the network would grow in a way to optimize for PoC + witness rewards and not necessarily around areas of traffic. I'm not sure this is a problem but something to note.

[jonathansimmons]

Upon first read I am in support of this as is. I think it creates opportunity for continued network growth in the US and EU while incentivizing the usage of DC to promote network usage.

I’m going to continue to read the discord discussion and will edit if my position changes.

[anthonyra]

I've also been thinking about this as a solution. It would indeed link network traffic to the reward for providing the network access to the traffic. (ie 1DC burnt to send data is earned by the hotspot who acquired the data packet to move) Which I feel is the intention of the DC Reward pool that's allocated each epoch. What I don't know is how having one of the chain variables being that fluid.

If a hotspot for whatever reason didn't get the updated value how does it know? What will happen if it can't be validated in time? I remember the team pushing the urgency of making sure the blockchain was up to date with the variables week(s) before implementation. We would be effectively doing the same but every 30 mins instead of a one time off event.

However, with the above proposal, it would mean that right now 14HNT would be distributed to the hotspots routing data. The one that brought this all to light would earn $145 worth of HNT which is the same amount spent on the DC themselves (if in fact, it's their own DC). The remaining allocation should indeed be pumped into Hotspot Structure Reward to return the focus to building the network out until network traffic really picks up (at which point the network should be there able and willing to provide the coverage)

An addition that might be noteworthy is having a hardware cap per hotspot. Based on 1DC per 400ms on one of the 8 channels would result in a hardware cap of ~$0.462 (46,200 DC) transferred per epoch. However, this would be also depending on how long an epoch is... whitepaper wants it to be 30 mins but for example right now is 38.5 mins. Which the above example is based on the 38.5 mins. If it was an ideal cap it would be 36,000 DC or $0.36 per epoch.
It would be the hardware cap governed by a software check.

This cap would also ensure that no hotspot transferring legitimate data would drop any because it could be illegitimate due to its traffic as if an arbitrary low cap was set. But the truth is it's in NYC park and there's a dog show occurring for example.

[Tommmy-D]

I am a strong supporter of leaving the system as is, or a completely different capping system. The network will correct. This HIP is a knee jerk reaction.

There's been an evolution of hotspot owners disproportionately mining tokens since day 1.

It all started with people who live in Austin. They raked in HNT as a group of just a couple hundred hotspots at the same 5M HNT/month as today. As the network grew to early adopters across the country, those who understood that being part of challenges was how to make the most HNT bought and arranged at least 3 HS and made a killing. Next it was the RF engineers that figured out that you could hide multiple hotspots in a closed location and spoof their locations. They made a killing. Next it was the social group that had lots of connections and were able to build expansive networks using personal and business contacts to place hotspots in many locations. They made a killing. Now, it's the coder / Arduino geeks that are leveraging the current token economics to turn DC purchases into HNT mining. They are making a killing.

All of these types of people are important in building a strong network and they should all have an opportunity to make a killing if they invest the time and effort. I would argue that incentivizing people to learn about LoRa, build sensing/communicating devices and load test the network is an extremely important part of expanding the utility of the network. How many new business ideas will spring forth once when more hotspot owners dig in and learn more about LoRa and sensing devices. There are many hotpot owners that bought them and have no clue what LoRa even is or how it works. They just know they can hook it up to their home network and it mines crypto currency.

From a capping standpoint, I am not in favor of changing the HNT payout ratios dynamically or staticly. Instead, I suggest maxing out the data credit transferred total for rewards to the total mined by the Nth highest uniquely-owned hotspot. 20 might be a good number. So if the top 20 hotspots range from 100K to 18K DC transferred in a epoch, they each receive HNT rewards as if they transferred 18K DCs. This prevents a few hotspots from taking the vast majority of HNT intended for data transfer, keeps the rewards system in place (changing makes the system seem unstable to the public), and, most importantly, continues to incentivize hotspot owners for investing their time and effort into LoRa devices.

[jmfayal]

I agree with Tommmy-D. I'm worried that we are overturning a key tenet of blockchain/programmatic rewards structures because there is some unease over a short term arbitrage. The community debated these points extensively earlier this year and it was largely determined that holding to the structure was a good precedent to maintain.

I do think that there is a considerable value that comes from large scale data transmission even if a significant portion of this isn't 'real' data. Over the last few weeks the system has been stress tested and improved massively as a result of the DC incentive. The incentive to dive into these issues is dramatically reduced with this current proposal and I think you'll see a corresponding reduction in the attention paid by the community to the underlying robustness of the network.

I am a proponent of a cap on per epoch per hotspot earnings of, something in the 10 HNT range. That provides plenty of incentive for data transmission while removing the edge cases like the Dapper hotspot. I'd combine this with redistributing the additional HNT over the cap evenly to all hotpsots that participate in any data transmission that epoch. Some basic modeling showed that would result in approx a 20X increase in rewards for the long tail of data transmitters and those units pushing the majority of the 'real' data. This will also incentivize the development and adoption of smaller DC transmitting real-world devices like tabs and dog collars because the even distribution of DCs over the cap will benefit these hotspots the most.

Furthermore, having a heavy DC incentive gives the community a wonderful tool for strategically promoting the development of key regions. I propose that there is a community-driven fund that places data transmitters in areas where we'd like to see development. That will encourage the rapid development of that city or area. I'd suggest this happens in key cities as well as along highways to promote the coverage of our roadways, which I believe is current weak point in the coverage mapping.

There are enough benefits to a heavy DC incentive that I think it is worth keeping those in place while controlling for the edges. There are issues with a cap system, but they do not become meaningful until DIY mining comes into place, which gives the community time to figure out how to confirm DIY hotspots, to confirm large scale cloud device mining. Even if that does occur, the arbitrage will quickly be worked out of the market anyways.

I strongly believe that the network will be better off keeping a controlled but aggressive DC transmission incentive. This was built into the initial framework with good reasoning that still holds. There are improvements that should occur, but I believe if we look past the next few months the system will be more robust by keeping the current incentive structure. In 5 years nobody will remember or care about this short blip on the map and I'd rather accelerate the development of the network in the meantime.

[Carniverous19]

If a hotspot for whatever reason didn't get the updated value how does it know? What will happen if it can't be validated in time? I remember the team pushing the urgency of making sure the blockchain was up to date with the variables week(s) before implementation. We would be effectively doing the same but every 30 mins instead of a one time off event.

Each hotspot doesnt know or care about this, its the consensus group that will calculate it when dividing up rewards so there is no risk of a hoptsot being confused because its a few blocks behind.

An addition that might be noteworthy is having a hardware cap per hotspot. Based on 1DC per 400ms on one of the 8 channels would result in a hardware cap of ~$0.462 (46,200 DC) transferred per epoch.

I am not sure that is accurate as a theoretical upper limit, first you can send a 242 byte payload in a LoRa packet which is 10DC worth. 242 bytes at SF7125K data rate will take ~400ms of on-air time so that may be where the 400ms comes from. So you could theoretically receive 10DC in 400ms = 25 DC / second per channel (45,000 DC / channel / epoch). So supposedly you could have 360,000 DC / epoch.

That being said I do like the idea of a DC cap because even this theoretical limit would be INSANE in any real-world application.

[anthonyra]

If a hotspot for whatever reason didn't get the updated value how does it know? What will happen if it can't be validated in time? I remember the team pushing the urgency of making sure the blockchain was up to date with the variables week(s) before implementation. We would be effectively doing the same but every 30 mins instead of a one time off event.

Each hotspot doesnt know or care about this, its the consensus group that will calculate it when dividing up rewards so there is no risk of a hoptsot being confused because its a few blocks behind.

An addition that might be noteworthy is having a hardware cap per hotspot. Based on 1DC per 400ms on one of the 8 channels would result in a hardware cap of ~$0.462 (46,200 DC) transferred per epoch.

I am not sure that is accurate as a theoretical upper limit, first you can send a 242 byte payload in a LoRa packet which is 10DC worth. 242 bytes at SF7125K data rate will take ~400ms of on-air time so that may be where the 400ms comes from. So you could theoretically receive 10DC in 400ms = 25 DC / second per channel (45,000 DC / channel / epoch). So supposedly you could have 360,000 DC / epoch.

That being said I do like the idea of a DC cap because even this theoretical limit would be INSANE in any real-world application.

I'm not that familiar with the hardware but I knew a limitation existed. When asked I was informed that you could at max based on LoRA transmit 242bytes of data every 400ms per channel. Reading the documentation yes 1DC is 24bytes so I can see where 10DC = 242bytes payload. But I think a cap wouldn't be necessary if the 1:1 is implemented. Now a flag could be in place to help with issues / concerns of future use.

[Carniverous19]

@anthonyra agreed 1:1 eliminates any advantage to running data through your hotspot so no need to cap.

Well there is a slight advantage if you assume HNT value will increase and you want to buy HNT for USD without going to a 3rd party exchange (I know, no talk of HNT markets but this is an important point). You an effectively buy HNT for USD by running data through your hotspot at the oracle price.

So there may still be some people choosing to run data through their hotspot solely for the purpose of mining if they feel the oracle price is low, either due to expected future growth or if there is a secondary market buyer at a price higher than oracle. If this HIP is implemented it will be interesting to see if this ever occurs, as secondary market pricing could cause a rapid spike in data traffic if oracle is slow to react (another arbitrage situation)

[Carniverous19]

The example table with low data usage seems wrong, the percentages add up to 80% not 100% should be:

	%	HNT
PoC Challengers	1.3819 2.073	69,093 103,635
PoC Witnesses	12.4367 18.654	931,325 932,710
Poc Challengees	26.1825 39.272	1,309,127 1,963,604
Consensus Group	6	300,000
Data Credits	0.0010	50
HST Holders	34	1,700,000
Total	100	5,000,000

[anthonyra]

I think the above redistribution needs some work. The reason is how each reward pool above is distributed.

Rural / Single Hotspot - Due to its location, it can't perform in PoC as a Challengee or Witness. These can be individuals that are trying to build out a hotspot for Agriculture or an individual that is investing in helium to claim their spot in the growing network.

Grouped Hotspot - They have 2 or more hotspots within RF range of their location. Allowing them to take part in all aspects of PoC.

Consensus Group - Are specific hotspots that are selected based on their score and geography. There are currently 4 groups consisting of 16 members each. https://developer.helium.com/blockchain/consensus-protocol

The tables are based on the following example:

• 10,000,000 DC are transferred across the network through various Hotspots. The HNT oracle price is $2. In this scenario the total HNT value of DC being transferred is 50 HNT (10,000,000 DC * $0.0001 DC fixed priced divided by the $2 oracle price). 50 HNT would be split proportionally to the Hotspots who did the work, and the remaining 1,624,950 HNT from the DC allocation would be distributed ratably among the Challengers, Witnesses, and Challengees.

Current Proposed Distribution: Per Month
| Reward Pool | % | HNT | Beneficiary
| --- | --- | --- |
| PoC Challengers | 2.0727 | 103,635 | Rural / Single Hotspot, Grouped Hotspot, Consensus Group |
| PoC Witnesses | 18.654 | 932,710 | Grouped Hotspot, Consensus Group |
| PoC Challengess | 39.272 | 1,963,604 | Grouped Hotspot, Consensus Group |
| Consensus Group | 6 | 300,000 | Consensus Group |
| Data Network Transfer | 0.0010 | 50 | Rural / Single Hotspot, Grouped Hotspot, Consensus Group |
| HST Holders | 34 | 1,700,000 | N/A |
| Total | 100 | 5,000,000 | --- |

The above distribution would incentives the abuse that some consider is occurring in Port Huron. It would also lower the incentive for new hotspots in areas that don't have coverage yet (which is currently active). In the US that would be mostly rural areas with agriculture, weather, or the like being the focus. However, when it comes to Europe there's a handful of cities that would fit that category for not having any hotspots. This isn't that big of a deal if you have companies or an individual that has the capital to start out the gate with the ideal number of hotspots to take part in all of the above PoC rewards. (2-3 hotspots) $1350 but probably not a hobbyist or individual looking at ROI.

The following proposal heavily relies on the following HIPs to be eventually be implemented. Ideally, HIP 10 will be first with the below distribution followed by HIP 5 and then finally with HIP 9.

HIP 5: https://github.com/helium/HIP/blob/master/0005-poc-fairness.md
HIP 9: https://github.com/helium/HIP/blob/7b715a0614d4c529144e1d6c0083ee8b38c05b29/0009-non-helium-hotspots.md

In regards to HIP 10 my proposal wants to redistribute the reward pool from Data Network Transfer to the PoC Challenger pool in preparation for my HIP 5 proposals. This distribution in the meantime before HIP 5 implementation (if implemented) would incentives the expansion of hotspots into virgin coverage areas while limiting the problem in Port Huron.

New HIP 10 Proposed Distribution: Per Month
| Reward Pool | % | HNT | Beneficiary
| --- | --- | --- |
| PoC Challengers | 33.45 | 1,672,500 | Rural / Single Hotspot, Grouped Hotspot |
| PoC Witnesses | 8.55 | 427,500 | Grouped Hotspot, Grouped Hotspot, Consensus Group |
| PoC Challengess | 18 | 1,963,604 | Grouped Hotspot, Consensus Group |
| Consensus Group | 6 | 300,000 | Consensus Group|
| Data Network Transfer | 0.0010 | 50 | Rural / Single Hotspot, Grouped Hotspot, Consensus Group |
| HST Holders | 34 | 1,700,000 | N/A |
| Total | 100 | 5,000,000 | --- |

My HIP 5 that builds off of the above redistribution scheme is as follows:

It suggests a change to the Beneficiary for that reward pool and applying a restriction to what a Rural / Single Hotspot should be considered and splitting the Consensus Group into two individual parties. It also recommends a change in the limitation on a hotspot in regards to being a challenger.

The current limitation for being a challenger is that each hotspot on the network can only be a challenger for a PoC proof once an epoch. Removing the grouped hotspots will drastically reduce the overall PoC proofs being submitted to the blockchain. To compensate I suggest allowing the Consensus Group Candidates (currently at 2528) the ability to fill in the rest.

For Example:
If there are only 1600 hotspots that now meet the new definition of Rural / Single Hotspots on the network they would only supply 1600 PoC proofs that epoch. The remaining 5400 proofs could come from the Consensus Group Candidates meaning most will average roughly 2 challenges created per epoch.

With the 33.45% each challenger will earn roughly 0.16 HNT per epoch.

This will provide virgin coverage area hotspots (Rural / Single Hotspots) better incentives than currently and also provide known good hotspots (Consensus group worthy hotspots an additional incentive for having a high S word)

New Definitions:
Rural / Single Hotspot: Are hotspots that have not successfully been a challengee or witness to any PoC proof before.
Consensus Group Candidate: Meets the requirements to be a Consensus Group Selectee but doesn't get selected for the current Consensus Group.
Consensus Group Selectee: One of the members of the Consensus Group.

New HIP 10 with HIP 5 Proposed Distribution: Per Month
| Reward Pool | % | HNT | Beneficiary
| --- | --- | --- |
| PoC Challengers | 33.45 | 1,672,500 | Rural / Single Hotspot, Consensus Group Candidate |
| PoC Witnesses | 8.55 | 427,500 | Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee |
| PoC Challengess | 18 | 1,963,604 | Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee |
| Consensus Group | 6 | 300,000 | Consensus Group Selectee |
| Data Network Transfer | 0.0010 | 50 | Rural / Single Hotspot, Grouped Hotspot, Consensus Group Candidate, Consensus Group Selectee |
| HST Holders | 34 | 1,700,000 | N/A |
| Total | 100 | 5,000,000 | --- |

With the HIP 10 distribution and the new limitation on the beneficiary per reward pool in regards to PoC the max a grouped hotspot could acquire per month is now at 24.55% instead of 58%. Consensus Group and Rural/Single hotspots will have an increased reward pool in the interim where network traffic hasn't reached its max at 32.5%. However, once data traffic does catch up than those rural hotspots will become useless in terms of minting HNT.

[jpharris1981]

The gamification incentivizes hotspot owners to learn to create end node devices, and helps provide data for the network. The problem will resolve itself once data usage is more widespread.