Proportional reward scheme for data transfers

[abhay]

Here's a proposal for a proportional reward scheme for data transfers based on conversations I've had with folks around the community.

Rendered view: https://github.com/helium/HIP/pull/31/files#diff-e355d9a98c1cc82cb2057ba677307e15

[rawrmaan]

I'd like to propose a change to the distribution presented. Instead of redistributing the "unclaimed" DC rewards to PoC, I think it would be beneficial to just not mint those tokens, and slightly modify the monthly token minting to be "up to" 5 million tokens per month. This has a couple of beneficial effects:

1. Reduces net inflation. Whereas in the current scheme (before this HIP), network participants are encouraged to pump data until 32.5% of the supply is burned, this change would automatically get us to the "ideal" situation of having that 32.5% act as deflationary pressure. The only way to mint more tokens would be to burn more tokens first.
2. Doesn't change the reward structure that has been debated for months. DC rewards would still receive 32.5% of the pie, increasing over a period of 19 years.

EDIT: I've scrapped the first part of my change. After discussion in the Discord #hip channel, it has become clear that this would create an undesirable ~50/50 split between PoC and securities if DC rewards were not claimed. The below portion still stands.

I propose this change along with changing the current HIP proposal to 1:1 DC to HNT reward ratio. This makes arbitrage impossible. I believe that if the goal of arbitrage is to encourage network usage in hopes of DC burn/deflation, then my proposed change accomplishes that in a cleaner way, without the in-between period where a bunch of people waste time and creative energy building sensor farms for arbitrage.

Another massive benefit of 1:1 is that if there's no arbitrage, there will be no incentive to push packets for pure arbitrage purposes. This means that it will always be possible to know the exact real network usage, as no actor will pay to use the network if it does not support a real use case.

[Jordyngracey]

Some people are concerned about the incentive to add new hotpots to the network. Specifically, hotspot owners need to be able to make their initial investment back in order for it to be viable for them to buy in.

I like rawrman's proposal but think it might be interesting to give a "sign-up" bonus to new hotspots. i.e. If there aren't enough DC transactions to warrant a full 32% of newly minted HNT, then some proportion of the remainder be prioritized in allocation as a bonus to new hotspots for their PoC challenges. Once the hotspot has witnessed N challenges, it becomes ineligible for participating in the bonus structure.

By definition, this bonus would only exist so long as there aren't sufficient DC transactions. This would also show that the team is promoting the interests of new adopters.

One concern is that this might create an incentive to just add a new mining node once the bonus is gone- but that isn't necessarily a bad thing as the is no competing incentive to take down old nodes so long as they are still productive.

I'm not sure this should be considered as part of the immediate solution to the arbitrage problem at hand. I haven't thought through all the competing incentives but it is worth considering as a longer term change to the mining distribution.

[AddressXception]

I like this mechanism in the short term because it rewards hotspots that transfer real value while also continuing to incentivize coverage growth.

[abhay]

Rebased and ready for merge as a Discussion phase (which has already started).

[federaa]

As an early adopter of Helium, I am opposed to this proposed change.

The network is entering a new phase, the focus needs to be around building value off real-world use cases, not over-compensating hotspot owners for providing coverage.

As business users begin to adopt Helium, having 90% coverage in a larger geographic region is worse than having 100% coverage in a smaller region. Anyone who owns a smartphone should intuitively understand this - you want great service where you are most often and will settle for poorer service in areas that are less important to you. Basing rewards off actual work done for the network incentivizes the deployment of new hotspots around the business use case centers.

As hard as it is to hear, value is created in population centers with density. 10% of the United State's entire GDP comes from New York/Newark, in spite of being 0.3% of its landmass.

As far as I see it, I have two proposals

1. Leave the rewards system largely as is, taking steps to reduce fraud, but not change the payout structure

2. Change payout to 1:1 but do not reallocate that additional HNT to PoC. Instead, set that HNT aside in a treasury, and administer grants to develop for Helium out of that treasury, the way many other blockchains do.

There's a lot of bad-faith arguments that talk about gaming DCs as the problem when in reality those users are complaining about a reduction in rewards. These are two separate issues and should not be conflated.

[zzordo]

I support the proposal to make arbitrage unprofitable, however, I echo the sentiments of some that are trying to actually grow the network. There are many large cities in the US that still have not had significant penetration, and the recent changes to rewards allocations completely removes the incentive to enter new markets. The minimum investment effectively becomes 3 hotspots instead of 1 to have any hope of making back your investment. That said, any investment does carry risk, and it is fair to assume hotspot owners will carry most of that risk. However, if the risk is too high, network growth will be slow and difficult.

I proposed an amendment to this HIP (see HIP 12) that does the following:

• allocate DC arbitrage from Data Transfer pool (until arbitrage phases out) to a Network Growth Rewards Pool
• Once arbitrage accounts for less than 1% of total rewards, begin phasing PoC rewards down to 18%. PoC is at 18% once arbitrage ends.
• Network Growth Rewards stays permanently at 1% of total rewards. Any unused Network Growth Rewards during a bonus cycle get reallocated to the total rewards pool (in HNT) over the next X number of blocks.
• Rewards Cycle for Network Growth Rewards would be every 6 months. First Rewards Cycle would begin on the first day of the first month following technical implementation go-live. Second Rewards Cycle would start 6 months later. Rewards Cycles would be fixed dates. (i.e. September 1 & March 1)
• Each Block, 1% of the Total Rewards is set aside into a Network Growth Rewards Account.
• Rewards Cycle would consist of 6 separate Rewards Months. ⅙th of the Network Growth Rewards Account balance is allocated to each month (Rewards Month Pool).

Eligibility: During a Rewards Month, a hotspot is eligible for a bonus as follows:

1. A hotspot must have mined HNT on at least 75% of the days of the month.
2. A hotspot must have mined no more than 14 HNT for the month.
3. A hotspot must have an asserted location at least 750 meters from another hotspot.
4. A hotspot must not have asserted a new location more than two times during the Rewards Cycle.

Payout: The Rewards Month Pool will be allocated as follows:

1. A hotspot can earn a bonus UP TO 100% of that hotspot's earnings for the month, with a progressive, even decline in bonus starting at 8 HNT, phasing out at 14 HNT. For example, if your hotspot earned 11 HNT on the month, the bonus it is eligible to earn would be up to 5.5 HNT. Need to verify that this structure won't reward someone who mined less in a way that puts their total reward for that month higher than someone who mined more
2. The maximum total bonus paid out for a Rewards Month across all eligible hotspots cannot exceed the total HNT available in the Rewards Month Pool. If total eligible bonus exceeds the Rewards Month Pool, each hotspot's share of the Rewards Month Pool will be reduced accordingly.