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

HIP 134: Reward MOBILE Carrier Beta Hotspots #1091

Merged
merged 4 commits into from
Oct 8, 2024

Conversation

jhella
Copy link
Contributor

@jhella jhella commented Sep 23, 2024

This was drafted based on discussion during the 9/19 MWG Meeting.

@WorkingTitle-Helium
Copy link

If there's a way to know how many connections a hotspot gets AND if that can be a variable used to modify rewards a simple modifier based on connections is cleaner I think.

"A hotspot serving unique connections will receive an additional 0.01 modifier per connection up to 100 connections." That way connections are the incentive, no need to track paid or unpaid data. Goal is to incentivize new hotspots being deployed in high traffic areas. You can drop the bump to 1.0 for hotspots in 103 modified areas as unique connections will drive what they should be rewarded. Cap it at 100, either daily or rolling weekly, whichever is simpler.

@jhella
Copy link
Contributor Author

jhella commented Sep 23, 2024

If there's a way to know how many connections a hotspot gets AND if that can be a variable used to modify rewards a simple modifier based on connections is cleaner I think.

"A hotspot serving unique connections will receive an additional 0.01 modifier per connection up to 100 connections." That way connections are the incentive, no need to track paid or unpaid data. Goal is to incentivize new hotspots being deployed in high traffic areas. You can drop the bump to 1.0 for hotspots in 103 modified areas as unique connections will drive what they should be rewarded. Cap it at 100, either daily or rolling weekly, whichever is simpler.

Nova knows how many connections a hotspot is getting, but need to discuss with them how easy is it would be to use it as a variable like you suggested. Was hoping to get some feedback on this in the next MWG.

I like the idea of 0.01 modifier up to 100 connections if it's easy to implement. I do think data transferred is important. I could set-up my hotspot on top of a busy highway and get a lot of connections, but I probably won't transfer a lot of data. We want high footfall areas with long dwell times. Plus rewarded data means someone paid for it and results in HNT burn which is good for the ecosystem flywheel.

@WorkingTitle-Helium
Copy link

WorkingTitle-Helium commented Sep 23, 2024

Easy to implement is something I have no information on. Up to the devs to let you know. I’d offer run the modified subscriber multiplier the following epoch. I.e. Monday’s connections modify Tuesday rewards just to smooth compute cycles.

Requiring data thresholds gives an incentive to artificially use carrier plans to get rewards. Consider what that will look like.

@waveform06 waveform06 added technical Technical HIPs economic Economic HIP MOBILE labels Sep 24, 2024
@WorkingTitle-Helium
Copy link

Back to the importance of number of connections visibility, if it's possible for that number to be shared and even used in rewards calculations.

Just had a conversation with a host asking if I could tell them how many unique phones connected, seems they have an interest in near real time hard data about foot traffic.

@madninja
Copy link
Member

Back to the importance of number of connections visibility, if it's possible for that number to be shared and even used in rewards calculations.

Just had a conversation with a host asking if I could tell them how many unique phones connected, seems they have an interest in near real time hard data about foot traffic.

Remember that carriers don't pay for unique connections, but pay for data over connections, so rewarding per connection may not be the right way to incentivize deployments. I suggest that unique connections are useful from a planning perspective (and in fact planner has a layer showing just that) and could count as an eligibility criteria for rewards instead.

@zer0tweets
Copy link
Contributor

@WorkingTitle-Helium I am concerned that introducing some linear rewards accelerator as a function of connections / data served could be a recipe for gaming. My suggestion is to keep it binary. I.e. we agree on a threshold, like 25 unique connections in the last day and, if you met the threshold - you are excused from CDR and maybe some other requirements. If you didn't - then you are not.

@WorkingTitle-Helium
Copy link

@zer0tweets My thoughts were around carrier offload is something Nova could disable if a hotspot was somehow selected and gaming, just update the hotspot in question to a non-carrier version and all the 131 requirements are in place. Also my inclination is hotspots in high traffic areas that get 100+ connections a day should be rewarded more than non-carrier hotspots and hotspots with even 25 connections. I see that as encouraging the community to deploy in commercial locations. I am not a fan of any data transfer benchmark as most data is now paid and that's enough of a reward. Looking forward to discussing this in a HIP channel.

@hiptron hiptron changed the title Add HIP draft for HIP-####-reward-MOBILE-carrier-beta-hotspots HIP 134: Reward MOBILE Carrier Beta Hotspots Oct 8, 2024
@hiptron hiptron merged commit 05e68d0 into helium:main Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
economic Economic HIP MOBILE technical Technical HIPs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants