You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Establish a Roadmap driven process for future Helium protocol upgrades led by the core development team, Nova Labs.
Simplify protocol governance by establishing a veHNT-only voting system and HNT rewards for active governance participants.
Unlock existing veIOT and veMOBILE positions to allow holders to convert to HNT through network treasuries.
The Problem
The existing structure of the Helium network, with separate subnetwork voting mechanisms and a complicated DAO Utility Score, is difficult to explain, and difficult to understand. It creates multiple interlocking and conflicting incentives, and unnecessarily divides the community. Additionally, the current system of change management can introduce uncertainty for protocol developers, deployers, community members, and other participants due to the lack of a common roadmap.
Make It Simpler
When [HIP-138][hip-138] is implemented, HNT will return as the single economic focus of the Helium ecosystem, and holders of IOT and MOBILE can exchange their tokens for HNT. Therefore, veHNT becomes a natural expression of all governance. It’s important to note that no other changes to the intrinsic mechanisms of veHNT are being proposed, specifically no changes to lockup mechanisms including Landrush.
With the introduction of Proxy Voting through [HIP-110][hip-110], veHNT holders can assign their voting power to a trusted Proxy Acount. This allows all holders of veHNT to participate in governance with minimal effort, even if they are not familiar with the detailed operation of the IoT or Mobile subnetworks.
After the return to veHNT governance, Nova Labs, as Protocol Developers of the Helium ecosystem, will establish a Proxy Account in Helium Governance alongside other Proxy Voters. By delegating veHNT to this Proxy, veHNT holders may choose to align their voting power directly with the Protocol Developers.
The Protocol Developers will publish and maintain a detailed roadmap of planned upgrades to the protocol over the coming months. The roadmap will be updated through an open process including ongoing Community Calls, and will take input from the IoT and Mobile Working Groups.
Votes with Code
The Helium Community will vote with veHNT on a periodic basis (initially monthly) to approve upcoming protocol upgrades proposed by the Protocol Developers. This evolution of the HIP process may be characterized as a Helium Release Process. All changes under this process must come with audited and deployable code. Each Release Vote will be kicked off using the existing Helium Monthly Community Call, and will apply to new code deployed across the Helium network. Emergency or security-related deployments that are necessary for protocol safety, as well as bug fixes, may be deployed on an ad-hoc basis, but must be announced and ratified through subsequent Release Votes.
The text was updated successfully, but these errors were encountered:
hiptron
changed the title
HIP 146: Single-Token Governance and Helium Release Proposals
HIP 141: Single-Token Governance and Helium Release Proposals
Jan 15, 2025
Can we please clarify the situation of keeping the public documentation up to date with this new process too?
I believe it is impossible to keep the documentation in-sync with the code, unless it is done by the development team as a part of the development process.
As this HIP suggests that Nova plan for the development items and proceed with monthly releases, this is the right time to add the public documentation as an item to the DoD (Definition of Done). The release of a feature should not be complete without the update of the documentation. The release of a feature should update both the platform (let's say Oracles) as well as the documentation at the same time.
HIP 141: Single-Token Governance and Helium Release Proposals
Summary and Motivation
If approved and implemented, this proposal would:
The Problem
The existing structure of the Helium network, with separate subnetwork voting mechanisms and a complicated DAO Utility Score, is difficult to explain, and difficult to understand. It creates multiple interlocking and conflicting incentives, and unnecessarily divides the community. Additionally, the current system of change management can introduce uncertainty for protocol developers, deployers, community members, and other participants due to the lack of a common roadmap.
Make It Simpler
When [HIP-138][hip-138] is implemented, HNT will return as the single economic focus of the Helium ecosystem, and holders of IOT and MOBILE can exchange their tokens for HNT. Therefore, veHNT becomes a natural expression of all governance. It’s important to note that no other changes to the intrinsic mechanisms of veHNT are being proposed, specifically no changes to lockup mechanisms including Landrush.
With the introduction of Proxy Voting through [HIP-110][hip-110], veHNT holders can assign their voting power to a trusted Proxy Acount. This allows all holders of veHNT to participate in governance with minimal effort, even if they are not familiar with the detailed operation of the IoT or Mobile subnetworks.
After the return to veHNT governance, Nova Labs, as Protocol Developers of the Helium ecosystem, will establish a Proxy Account in Helium Governance alongside other Proxy Voters. By delegating veHNT to this Proxy, veHNT holders may choose to align their voting power directly with the Protocol Developers.
The Protocol Developers will publish and maintain a detailed roadmap of planned upgrades to the protocol over the coming months. The roadmap will be updated through an open process including ongoing Community Calls, and will take input from the IoT and Mobile Working Groups.
Votes with Code
The Helium Community will vote with veHNT on a periodic basis (initially monthly) to approve upcoming protocol upgrades proposed by the Protocol Developers. This evolution of the HIP process may be characterized as a Helium Release Process. All changes under this process must come with audited and deployable code. Each Release Vote will be kicked off using the existing Helium Monthly Community Call, and will apply to new code deployed across the Helium network. Emergency or security-related deployments that are necessary for protocol safety, as well as bug fixes, may be deployed on an ad-hoc basis, but must be announced and ratified through subsequent Release Votes.
Rendered View
https://github.com/helium/HIP/blob/main/0141-single-token-governance-and-release-proposals.md
The text was updated successfully, but these errors were encountered: