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 52: LoRaWAN subDAO #338

Closed
hiptron opened this issue Jan 27, 2022 · 7 comments
Closed

HIP 52: LoRaWAN subDAO #338

hiptron opened this issue Jan 27, 2022 · 7 comments

Comments

@hiptron
Copy link
Collaborator

hiptron commented Jan 27, 2022

Rendered view

Read the HIP:

https://github.com/helium/HIP/blob/main/0052-iot-dao.md

Summary

This proposal includes a specification of the LoRaWAN Wireless Network Protocol as per the DAO model and L2 implementation outlined in HIP 50.
Summary

In HIP 50: Helium DAOs, we provide a general structure for onboarding new WNPs to the broader Helium Network, with mechanisms in place to ensure that protocol-specific attributes such as proof-of-coverage rules, data credits pricing, and block validation are within control of the emergent WNT DAO.

In this proposal, we specify the implementation of the structure proposed through a detailed onboarding proposal for the LoRaWAN Network. We propose initial configurations of the LoRaWAN economics layer as well as governance mechanisms within the DAO through LoRaWAN (LRW) token voting.

shayons297 added a commit to shayons297/HIP that referenced this issue Feb 4, 2022
jamiew pushed a commit that referenced this issue Feb 5, 2022
shayons297 added a commit to shayons297/HIP that referenced this issue Feb 23, 2022
@shayons297 shayons297 mentioned this issue Feb 23, 2022
shayons297 added a commit to shayons297/HIP that referenced this issue Feb 23, 2022
jamiew pushed a commit that referenced this issue Feb 24, 2022
shayons297 added a commit to shayons297/HIP that referenced this issue Apr 28, 2022
shayons297 added a commit to shayons297/HIP that referenced this issue Apr 28, 2022
@shayons297 shayons297 mentioned this issue Apr 28, 2022
shayons297 added a commit to shayons297/HIP that referenced this issue May 3, 2022
jamiew pushed a commit that referenced this issue May 4, 2022
@shawaj
Copy link
Contributor

shawaj commented Jun 13, 2022

In #53 for 5G subDAO we have a mechanism for hotspot vendors to get paid for their support / updates / deployment strategies as follows:

Hotspot vendors can adjust what % of MOBILE generated by the fleet of hotspots deployed by their customers is kicked back up to the hotspot vendors and pursue different deployment strategies, from giving out free/highly subsidized hotspots to passing 100% or rewards to hotspot operators, but charging higher $$ prices for hardware.

It seems to make sense that this functionality should be built into the network mechanics of all subDAOs, and certainly for the IOT / LoRaWAN one.

Currently, hotspot vendors are expected to provide a significant amount of infrastructure for a one off flat fee per piece of hardware. Whilst this, on the surface, appears to be good for end customers, it ignores a pretty major flaw that after some period a lot of these devices could potentially become unsupported with updates due to their being no ongoing financial compensation for the infrastructure and engineering work to deliver continuous updates.

It seems very wrong to me that currently hotspot vendors, despite being one of the core members of the Helium ecosystem, are not rewarded for this activity when practically all other network participants with ongoing engineering and infrastructure costs are rewarded in some way.

This seems to be a bit of an oversight currently and it seems to me that the transition to IOT token would be a great time to fix this.

As a side note, having spoken to quite a few other vendors there is, as far as I can tell, broad support for this. Don't want to name any names without permission so I won't at this point but thought it was worth mentioning.

@shawaj
Copy link
Contributor

shawaj commented Jun 13, 2022

Another added benefit this could bring is that Helium Foundation/subDAO could perhaps have some sort of control over a mechanism for other parties to take over firmware updates for hotspots should a vendor disappear or similar. And there would be an incentive for community members or other vendors to actually take this on.

@curiousfokker
Copy link

The link to the HIP is broken.

@shawaj
Copy link
Contributor

shawaj commented Jun 15, 2022

@Snipper88
Copy link

This extract appears confused about oracles / validators to me:

„ _At launch of the IoT subnetwork, 2.5% of the total supply of IOT tokens (5B tokens) are issued and airdropped to oracles and hotspots on the existing IoT network. This airdrop is intended to bootstrap the network, and is distributed to oracles and validators in the following proportion:

Oracles: 50% of 5B tokens, distributed in proportion to HNT staked at the snapshot“_

so the intent is 50% of the airdrop will go to existing stakes in existing validators? If so this should be clearer:

„ _At launch of the IoT subnetwork, 2.5% of the total supply of IOT tokens (5B tokens) are issued and airdropped to validators and hotspots on the existing IoT network. This airdrop is intended to bootstrap the network, and is distributed to oracles and validators in the following proportion:

Validators: 50% of 5B tokens, distributed in proportion to HNT staked at the snapshot“_

@edakturk14
Copy link
Contributor

The HIP has been approved via heliumvote, with +95% voting For HIP 52.

On behalf of Helium Foundation, the HIP Editors, and the wider Helium community, I am marking this proposal as approved and recommending that the coredev team implement the necessary changes as soon as reasonably possible.

@vincenzospaghetti
Copy link
Contributor

This has been implemented. Please see contracts on the Solana blockchain or visit this Repo: https://github.com/helium/helium-program-library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants