Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for an amendment to HIP 10 to add a network growth rewards pool #38

Closed
zzordo opened this issue Aug 20, 2020 · 4 comments
Closed
Labels

Comments

@zzordo
Copy link

zzordo commented Aug 20, 2020

It has been widely discussed that the recent rewards reallocation disincentivizes so-called "lone-wolf" hotspots from existing, as well as disincentivizes the Helium Network from growing into new markets. Many large cities in North America still have yet to see any hotspots come on line, and the now-current rewards structure, even with implementation of HIP 10 as-designed, makes it so that any new entrepreneur will need a minimum of 3 hotspots to effectively create a new market. Prior to August 2020, it was possible for new markets to grow organically around these lone-wolfs. This proposal intends to structure a Network Growth Rewards Pool so that the Helium Network can continue to effectively grow into new markets instead of stagnating around existing, established markets.

I propose an amendment to HIP 10 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.
@Carniverous19
Copy link
Contributor

Carniverous19 commented Aug 20, 2020

Following up on discussion in #24 about lone wolf hotspots that are more related to this HIP.

Sounds like there should be a validation check during the assert_location step that should check Frequency to suggested location placement.

How do yuo validate this? you can spoof GPS location with jailbroken android phones, and you can move hotspots after staking. without GPS (which is still easily spoofable in DIY) there is no good way to continually validate a hotspots location. Even legitimate staking doesnt work as you just drive around town staking at each block and bring all the hotspots back to your house.

Imagine if you are a newcomer to Helium and created a "lone wolf" hotspot. You see with my proposed distribution roughly
40HNT a week. That means an ROI of about 6.4 weeks for that first hotspot....

First 6 weeks is INSANE ROI on anything, that is waaay too high, anyway what this PoC suggests is better, giving a Bonus to low earning hotspots. Some lone wolfs will still be upset since 100% match to 0.2 HNT / month to 0.4HNT / month is still a pretty low but overall this HIP seems more reasonable than giving 30% of all minted HNT to hotspots with no verifiable coverage.

@jamiew jamiew changed the title HIP 12: A Proposal for an Amendment to HIP 10 to Add a Network Growth Rewards Pool A Proposal for an Amendment to HIP 10 to Add a Network Growth Rewards Pool Aug 26, 2020
@jamiew
Copy link
Contributor

jamiew commented Aug 26, 2020

@zzordo additionally, would you be willing to submit this as a HIP markdown file, using the template? More info here: https://github.com/helium/HIP/blob/master/0007-managing-hip-process.md – if you need help please let me know

@jamiew jamiew changed the title A Proposal for an Amendment to HIP 10 to Add a Network Growth Rewards Pool Proposal for an amendment to HIP 10 to add a network growth rewards pool Aug 26, 2020
@jamiew jamiew added the idea label Aug 26, 2020
@jamiew
Copy link
Contributor

jamiew commented Sep 29, 2020

@zzordo are you still actively lobbying for this proposal? Feel free to reply here or message me on Discord: @jamiedubs

@jamiew
Copy link
Contributor

jamiew commented Oct 8, 2020

Closing due to lack of discussion. Please chime in if you'd like to revisit

@jamiew jamiew closed this as completed Oct 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants