-
Notifications
You must be signed in to change notification settings - Fork 407
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
HIP11: Usage based rewards proposal #33
Merged
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,45 @@ | ||
# Usage-based Data Transfer Rewards | ||
|
||
- Start Date: 2020/08/19 | ||
- HIP PR: HIP11 | ||
- Tracking Issue: [Link](https://github.com/helium/HIP/issues/34) | ||
- Author: @JMFayal | ||
|
||
|
||
# Summary | ||
[summary]: #summary | ||
Developing a DC reward system that combines a set reward per DC transmitted and a cap on total HNT per Epoch per hotspot continues to incentivize building the network around real world data usage, while still encouraging HNT burn and limiting the reward for extreme gamification. For the reward to have an impact it has to be significant enough to incentivize network building, which I believe is accomplished at setting the reward to $0.0001 per DC transfer or approximately 1000% the DC cost. | ||
|
||
# Stakeholders | ||
[stakeholders]: #stakeholders | ||
|
||
I plan to circulate this proposal in Discord #hips and on the Helium community Reddit. I will also solicit specific individuals for feedback, from both within the Helium community and other crypto and open-source projects. | ||
Specifically I would like to achieve rough consensus around this process with Hotspot owners, Helium Inc (as the primary developer of nearly all core Helium software), and the newly-formed DeWi Alliance, which plans to commit time & money to community governance in the Helium ecosystem. | ||
On-the-record comments should be made on this HIP's {{to be made}}. | ||
|
||
|
||
# Detailed Explanation | ||
[detailed-explanation]: #detailed-explanation | ||
|
||
## Adjusted Reward Structure | ||
There would be three components to the reward structure. Including establishing the maximum reward of $0.0001 per DC transmission (i.e. 1:10 reward), setting a per hotspot per epoch cap and redistributing the rewards. | ||
|
||
|
||
### Establishing a $0.0001 reward for DC transmission | ||
|
||
By establishing a set $0.0001 reward per DC transmitted by a hotspot, there is a significant incentive for companies and individuals to build networks around data usage or potential data usage. The total DC reward for the community would max out at the current 32.5% rate established in the initial whitepaper and reconfirmed over months of community discussion. Once total rewards hit the 32.5% the per DC reward would automatically adjust downward to maintain the 32.5% cap. | ||
|
||
Under this model, people building networks around legitimate data usage will not be penalized by people building around farmed data sources. It also gives the community a tool to incentivize the growth of the network by creating data transmission ‘centers’ in key industries and locales. I would personally be interested in contributing to such an effort to incentivize the growth of the network around the US highways system and in key industries like agriculture and energy. | ||
|
||
### Setting a per hotspot per epoch cap | ||
|
||
By establishing a 100,000 DC per epoch per hotspot cap on data rewards, it disincentives ‘extreme’ gaming of the system and puts a cap on the time and energy of developers working to optimize mining devices. It also reduces to total mining going to the top few percentile of DC mining units and allows for the redistribution of that HNT, while still incentivizing significant data usage in the system. As the value of per DC rewards come down, so will the total max reward as the ratio remains. | ||
|
||
### Redistribution of rewards | ||
|
||
Any HNT that would be mined above the cap can be redistributed to either the PoC community or evenly to any hotspot that transmits the data. They both have value but I would propose the redistribution to the hotspots transmitting data to over incentivize low DC transmitting use cases like Tabs, dog collars and most other current use cases. | ||
|
||
That provides an even great reward to companies building systems around their own data usage, even if the data amounts are small. In my opinion, the most important thing the community can incentivize at this time is building networks that fit the needs of real world use cases and this proposal over incentives said networks. | ||
|
||
Alternatively, redistributing the HNT to PoC witnesses and Challengees helps incentivize PoC growth regardless of real world application. Growth in hotspot numbers has value in itself. | ||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you cut the cap down to say 10-15k an epoch? And maybe adjust up as the arb variance decreases? That would be a significant drop for these problem hotspots.