-
Notifications
You must be signed in to change notification settings - Fork 408
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 51: Helium DAO #336
Comments
Do you think the proposed HIP could support networks other than star topology? Does a mesh network could become a WNP ? Mesh Proof of coverage is slightly different than device to hotspot architecture of star networks. (Device to devices than to hotspot) |
These proposals are great ideas HIP 51, 52. There are some fundamentals that would build confidence in the expected target outcome:
In summary, how can we GUARANTEE HIP 51,52 will deliver... getting it half right with a long tail is not an option. How will execution risk be managed? How will you engage the community and leverage devs and commercials skills willing to help from the ecosystem. I may not be a Dev, but we are making a 'pigs ear' of such a great project which has so much more to give. |
Thank you very much for the team's update on programmatic treasury and protocol score on this HIP. My question is: what is the specific difference between programmatic treasury and the previous bonding curve? Are there any auxiliary documents that allow us to understand and learn more about programmatic treasury? I will appreciate it a lot for any explanation and help! |
I honestly believe that this HIP should be more along the lines of how a sub-DAO should interact with Helium. Helium could be a DAO or just an L1 blockchain in this context.
We should do this in the most minimalist and simplistic way. Helium shouldn't need to worry about how a sub-DAO governs itself nor tries to enforce it. However, there needs to be agreements on what that means in regards to rewards specifically PoC. Helium (L1) Structure:
Sub-DAO
My biggest concern is how sub-DAOs "connect" to the Helium blockchain. I would recommend that to establish a sub-DAO that sub-DAO would need to bond a certain amount of HNT as a license. With the bond transaction the sub-DAO sets the DC to DATA ratio for the sub-DAO. There's three ways to add HNT to sub-DAO - wallet contribution, PoC rewards, and Data Transfer rewards. ** The CURRENT Reward Pools should remain the same **
[1] The goal of this is to define the maturity of a wireless protocol. At what age, should it be kicked out of the house and fend for itself? At what income should it also meet the same fate? At the core the PoC rewards should be evenly split between protocols. So for example with LoRa and 5G being active they should get 50% of the current PoC rewards. These % are then adjusted based on the protocols age ratio'd to the maturity date of that protocol. The older the protocol gets the smaller the % would be. DC usage would also make the % smaller since the wireless protocol is established enough to feed the "flywheel" |
Updated 7:34PM helium#336
I'd like to consider the technical implementation of this HIP. There are various risks, rewards and opportunities depending on how we choose to proceed. Specifically, I want to consider what platform we could use. The HIP essentially describes a modular blockchain architecture. There is a central governing hub that communicates directly with connected Decentralised Network Protocols (DNPs). This approach makes sense; we can innovate within a DNP without concerns about how that might impact other DNPs. Each unit of the protocol is contained, yet all units are connected. This approach is well suited to the Cosmos SDK, a toolkit for building modular, interconnected blockchains. The Cosmos SDK provides out-of-the-box solutions for consensus, networking, data storage, inter-blockchain communication, smart contracts, and potentially inter-chain security (amongst others). It allows you to build you own blockchain without rebuilding the core components that most blockchains have in common. If we were to implement this HIP using the Cosmos SDK, we would have a central Helium Hub surrounded by Helium Zones. The Helium Hub performs the central economic and governance functions described by this HIP, while each Helium Zone is a unique DNP. Communication between the hub and zones would happen using Inter-Blockchain Communication (IBC), Cosmos's built-in cross-chain messaging and execution protocol. The primary benefit of using the Cosmos SDK is that we will be able to focus our efforts on things that make Helium unique while inheriting upstream development for things that most blockchains share in common. We could avoid continually reinventing the wheel while we attempt to solve problems in consensus, networking and interchain communication that have already been solved elsewhere. Additionally, we gain entry to the wider Cosmos ecosystem, giving us access to liquid AMMs (Osmosis), bridges, a pool of blockchain developers, wallets, explorers, etc. Cosmos is widely integrated with top-tier exchanges, including Binance, Coinbase, Kraken, etc., smoothing our way onto new exchanges. If we were to pursue this course of action, we may be able to transition to the Cosmos SDK in stages. The existing Helium blockchain could become the LoRa subDAO and a bridge could be built to the new Helium Hub. At a later stage, and by the consent of LoRa governance, we would be able to transition the LoRa subDAO to the Cosmos SDK entirely in order to fully reap the benefit of using a single SDK. |
This honestly has to be a joke! They need to fix what's wrong with everything and stop making all these changes. Its just getting worse |
Dawg every average HNT miner is getting shafted like an abused child, fix the current issues with your network rather than adding more sauce into the pot it's already overflowing come on, go watch an expert give his opinion https://youtu.be/d2wdlP3gDTo and subscribe |
Fix your network Nova Labs you have more funding then ever and aren't doing much. |
As I understand HIP 51 IOT Token and Mobile Token are backed by HNT Token. My question is what would the exchange rate be? 1:1? 2:1? Also how is that exchange rate managed. This is defined by the subdao HIPs Lastly will you exchange it in the app? |
The HIP has been approved via Helium Vote, with +96.94% voting For HIP 51. 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. |
The visio in this HIP suggests that 5G will operate as it's own DAO, rather than a subDAO. I've updated the visio, if someone with permission wants to update this. https://drive.google.com/file/d/1yGZARRzfx7EltcAGd4CsmHUcRF_wjjL5/view?usp=sharing |
This has been implemented. Please see contracts on the Solana blockchain or visit this Repo: https://github.com/helium/helium-program-library. |
Rendered view
Read the HIP:
https://github.com/helium/HIP/blob/master/0051-helium-dao.md
Summary
This proposal outlines economic and technical constructions with the aim of scaling the Helium Network to support new users, devices, and types of wireless network protocols.
We propose that each wireless network supported by Helium (LoRaWAN, Wifi, 5G — referred to as wireless network protocols or WNPs) has its own subDAO with its own token (referred to as wireless network tokens or WNTs). The key specifications of the WNT such as proof-of-coverage rules, data credits rewards, and consensus mechanisms are governed by each WNT DAO.
The aim is to create an economy such that the underlying HNT-Data Credit burn-and-mint equilibrium remains undisturbed, and Proof-of-Coverage rules and miner emission amounts are dictated by the corresponding wireless network’s sub-token.
The technical model requires that the entire Helium Network lives at some proposed base layer (L1). All accounts and transaction activity happens at this L1. All subDAOs operate as economic and governance layers (L2) with their respective WNTs acting as native tokens for this purpose. Each L2 also runs software to calculate WNP specific items (eg: all the proof of coverage code that exists on the current LoRaWAN network to determine hotspot rewards) and the L2 validators who have staked WNTs come to consensus on these calculations.
The text was updated successfully, but these errors were encountered: