HIP25: Validators about hip

[jamiew]

Following the discussions here, on Discord, and on the monthly community call, I am pleased to recognize rough consensus on building and testing phase 1 of validators for the Helium network. I'll be marking this HIP Approved in a separate pull request.

While there are a number of questions about the details of phase 2 mechanics like overstaking, delegation, slashing, and even the size of the stake, everyone agrees that maintaining efficient block production by moving it off the radio miners is critical.

I kindly request that the core development team begin work as soon as reasonably possible.

• Discord straw poll (34 yes, 0 no, 0 needs-work): https://user-images.githubusercontent.com/1903/106323602-af679a00-6245-11eb-8e12-0642b0677169.png
• Notes from community call: https://docs.google.com/document/d/1bMm2alBigBj3detA775Dn0Gz9UM5XczAeK9vnjBB3l0/edit#heading=h.8jsmkeqnkzhu

[philknows]

I'm curious to know where 10k HNT for stake and 5 month cooldown period numbers came from... comparing these metrics to Eth2, at current prices it is cheaper to run an full Eth2 validator ($110k vs $160k) and more liquid on Eth2 with the cooldown period of 2^8 epochs (~27 hours) vs 250,000 Helium blocks (~5 months). This seems very prohibitive even if we're trying to keep amateur (non-professional) stakers out. It is arguably more attractive at this point to run an Eth2 validator than locking up capital as an HNT staker. Can we better align these numbers to attract more stakers to secure the network?

[philknows]

Thanks for the context @cvolkernick. I'm new to the governance aspect of Helium, but have been following the project based on the ethos of what we're trying to do here. Telcos have basically created oligopolies of wireless connectivity, especially here in North America, so I would think that we all have a similar viewpoint here about wanting to democratize and decentralize connectivity access not just through setting up miners, but through staking as well. Isn't the basis of this project trying to make data access more "fair"?

Closest thing to a reason I've seen is @amirhaleem stating "increasing value of the network merits likewise increasing cost to secure the network"

I get that the minimum should be prohibitively high enough to ensure the network is sufficiently guarded as the value of the network increases. However, the current numbers (due to the rise of HNT vs USD$ in the last few months) require more upfront capital to secure than the #2 crypto network securing billions more in value than Helium. I also don't understand the 250,000 block cooldown period rationale. Is there a technical reason why the cooldown period is prohibitively long? Even if you are slashed on Eth2, your stake is released in ~36 days. No investor that I've encountered would agree to a no-interest bearing 5 month lockup period on their capital after an intention to unstake.

A lot of what we're trying to do here depends on network effects and the power of people being able to easily participate and contribute to the network, including security. The network can't function with a couple of antennas, it requires a network of antennas. Taking this concept to staking I would think we'd also want to attract a larger network of independent stakers? Not just entrusting a few staking pools to manage a large amount of small stakes? Isn't this network supposed to be as decentralized as the independent operators putting up infrastructure for Helium?

The "it's not intended to be fair" rationale seems to be a poor argument for a network that is built on making wireless connectivity more fair. In contrast, we also need to base values such as minimum stake & cooldown period based on justifiable data and evidence. Not arbitrary numbers with no backing - especially if it doesn't make sense comparatively to the network which has the most at stake: Eth2.

[lthiery]

I'm curious to know where 10k HNT for stake and 5 month cool-down period numbers came from

@philknows It is my understanding that both numbers were relatively arbitrary to start. However, you'll notice this HIP dates back to Jan 11, so the price was quite different at the time. Since then, there has not been a well-argued reason to change it from one arbitrary number to another.

I think a detailed analysis of other chains, Ethereum as one of many, could provide a good footing for a change in policy. However, I would not find a single comparison to of a single metric to a single other network to be that. For example, the economic of "USD value of stake" falls apart as soon as you realize only 6% of the block rewards go to validators, for example. And why not consider minimum stake as a percentage of circulating supply? Moreover, who is to say that what ETH plans to do is even successful?

So in my opinion, the numbers are what they are and, I agree, they seem rather prohibitive at this time. However, I also believe that should they be too prohibitive, it will be much easier to relax the numbers than to ever tighten them up. Therefore, without someone doing the work of writing a compelling economic analysis of many other projects and their staking mechanisms and using that as a better way to guide our policy (if someone has done this and I have missed it, I apologize), I think launching with what we have and adjusting it based on performance is satisfactory to me.

@cvolkernick I think if you'll find that its easier to have influence in a community if you pull back on accusing people of being "intellectually lazy" and of "paying lip-service". If you reduced the divisive rhetoric and put the work into proposing, developing support for and implementing an alternate form of gathering community consensus, perhaps you could be change you want to see.

[lthiery]

is it fair to state that so far my analysis comparing the two has the most merit out of the arbitrary numbers of 10,000 HNT and 5 month cooldown?

I wouldn't say that's fair because I don't think your analysis goes deep enough at all. We can't just take the USD value of the Eth2 stake and say, "We've adopted the same staking economics philosophy as Eth2". We need to look at how and why that stake was derived and without that, just taking that conclusion in isolation is no better than any other arbitrary measure in my book.

I would highly suggest the same for Helium going forward and for the foundation/company to fund some deeper analysis into this so Staking v2 rules can be better aligned with network security goals.

I think this is a good suggestion, but we also have to acknowledge: Eth is at a very different stage than Helium, and as such, has very different resourcing. I think we'd love to have a working group focused on economics and to fund research focused on tokenomics. DeWi has a grant program that you or anyone can propose such initiatives to.

After Q2 when this is finally released, it completely changes the game and without proper analysis done before implementation, it puts all the work achieved so far at stake. We will very likely see the flaws of v1 variables soon and we should be ready to fix the incentives with v2 shortly after.

I am personally comfortable with the knobs that are in place (ie: chain vars) to make these adjustments, should they need to be quickly adjusted.

I haven't found even remotely close with any other networks I've researched for staking

I'm comfortable with Helium not being yet another Eth-killer or DeFi project. That isn't to say that we shouldn't be looking at other projects and following their examples, but I personally don't think being different in itself is a problem.

I'm looking at this as a capital allocator and if the incentives are aligned for me to go elsewhere rather than stake with HNT, we will have a problem competing for capital to secure this network.

And the Helium blockchain being so different in its objectives is where I think focusing too much on making the "staking product" look like an apple-to-apples with other chains is misplaced. It doesn't have to be. In my opinion, it's fine if early adopters and stakers are more focused on the uniqueness of the project rather than how it stacks up against every other chain on staking metrics in isolation.

@philknows Please don't take my responses as some general "Helium response" either. I am just a community member like many others and my opinions above don't reflect some general consensus of the community but rather my own opinions and responses to your feedback. I appreciate your feedback on the project and I hope we hear more of it moving forward.

[cvolkernick]

Since then, there has not been a well-argued reason to change it from one arbitrary number to another.

I've posed the idea of pegging to DC rather than HNT stake, but the number would admittedly at this point still be semi arbitrary. If the team was okay with the 10K number on Jan 11, that would have put the price at 1.50 USD (150,000 DC), meaning the 10K HNT stake would have been approximately 15K USD (1,500,000,000 DC). Maybe we could start there and peg the stake requirement proportionally to the # of DC used on the network (net emissions?).

For what it's worth, @lthiery, I have put quite a good deal of time into these specific topics (#128), which essentially was superseded by this HIP. I hope you can empathize with the frustration when people such as myself put a great deal of time and thought into these proposals along with plenty of well-meaning intent, and summarily are more or less dismissed or fall by the wayside. I'd ask that you forgive the edge in my tone, that is where it's coming from. I've respectfully also asked for guidance regarding how the latter HIP could/should be extended from validators v1 here: #128 (comment) without a reply.

I hear your feedback on the tone and demeanor, so I'm not trying to dismiss that. Simply pointing out I and others have raised these concerns previously to no avail (yet).

[jthiller]

When a validator is decommissioned, could and should it be made practical for HNT to be immediately available for use in staking a new validator?

Validator stakes are transferrable. This functionality handles your scenario.

[abhay]

Propose closing this HIP as Deployed, @jamiew?

[evanmcc]

some thoughts on the linear vs. diminishing returns to overstake:
https://gist.github.com/evanmcc/3249c4eb79cca4ba09c2632c95f6a99f

[evanmcc]

countingTillIDie on Discord suggests that people be able to accelerate their unstaking via some sort of haircut mechanism (i.e. shorter period paid for with stake). It's unclear where the best place for the stake to go is.

[evanmcc]

• concerns raised about the initial stake being too low
• overstake cap suggested to avoid a big spender being able to totally dominate the group
• concerns voiced about the lack of slashing in the proposal
• correlated slashing proposed to punish poor placement (all in 1 az, etc)

[arul-1111i]

Proposal to limit validators to hotspot miners
https://docs.google.com/document/d/1qwAX7wcde63fMPKNzB6rmxuwpb3_5jgythHnvtBt7K4/edit?usp=sharing

[cvolkernick]

Agree with you @philknows been making this point since the conversation on staking/validators started back when....to which the pushback was essentially "it's not intended to be fair". I don't think "access-prohibitive" is really being considered as a significant point of contention; the counterpoint basically boils down to "larger entities will enable pooling". All well and good minus the fact that said entities are then taking a cut of proceeds which...objectively isn't the same thing as being able to run yourself and keep proceeds. So here we are again with large cap entities having a leg up on less capitalized individuals.

The argument that we want to "keep out amateurs" seems intellectually lazy to me, considering as far as I'm able to think there are likely performance metric-based mechanisms that are able to weed out poor performing validator nodes rather than throwing up an arbitrary gatekeeping fee. But I digress.

Not really sure why the cost of entry wasn't pegged to DC rather than HNT. Closest thing to a reason I've seen is @amirhaleem stating "increasing value of the network merits likewise increasing cost to secure the network", or something along those lines.

In fairness and consideration of the alternative side of the argument, this doesn't necessarily have to be a validators v1 issue...I would assume there is room to further refine the system later down the road (things such as overstaking etc have been touched on in the past, so perhaps this can be addressed in some capacity in a later iteration of staking).

[cvolkernick]

The problem lies within the fact that the people with the vast majority of the control & authority to make said decisions currently are Helium, Inc. developers, so they are thinking about things and making decisions based on a technical/developer-oriented focus. There is not much "social justice" for lack of a better terminology going into the thought process, from what I can tell. I realize this tends to rub the Helium team the wrong way, but it's frankly just the reality of the situation. They will argue (and have) that the community has every opportunity to provide input and come to "rough consensus" -- which is true to an extent -- but the fact is that has absolutely zero teeth as it's an entirely informal process still ultimately rubber stamped by Helium / DeWi. That is not true power...it's lip service.

That said, not to take away from the efforts of the development team, as they've been doing an amazing job to date. I just personally believe the pool of stakeholders and controlling parties needs to be extended further into the broader community to exert due influence to a reasonable extent. I'm not proposing a total network takeover by individuals and total disregard to qualified developer consultation and advice, only to level the influence a little more in an official capacity.

[lthiery]

Yes, I recall this idea. It seems equally arbitrary and much more difficult to implement than the currently accepted proposal.

[lthiery]

@cvolkernick First off, it's difficult to have a discussion when you're editing your comment after its been replied to.

Anyway, regarding the topic at hand: what exactly is the nature of your complaint around HIP23 being superceded by HIP25? In my opinion, a simpler definition was proposed by someone who could put the implementation work in. I don't understand how the project moving forward in that way is some personal offense to you?

This has been the way of many HIPs that have been adopted: they started out quite complicated, debate happened, and eventually were reduced to pushing one foundational step forward and leaving further elaboration as the subject of futures HIPs. HIP27 in particular comes to mind as an example.

I have also been laboring on passing HIP22 since before your own HIP23, so, yes I can know what it's like. I hope that fact, plus the fact that I work for Helium, where you claim "control & authority to make said decisions" lies (something which I disagree with), helps you put to rest that idea that this is all a personal sleight against you.

I believe we have seen largely that HIPs have largely passed due to their merit: how do they improve the network and how complicated is their implementation and/or is the implementation actually attached to to the HIP itself? There are ideas in your HIP23 that I do think would benefit the network, but if you are unable to implement them, then I would suggest you simplify and streamline the ideas so that you may garner some support for them.

Your own HIP about payment notes is a great example; it was simple and added value to the network, so it was approved and development work was eventually committed to it.

[maco2035]

I aggree with @cvolkernick that the amount of validators should be pegged to a value based around the dollar. Like 100k dollars of hnt at a time to lock up. This can be done, and yes it takes work and time. But allows an equal playing field for everyone who starts. $X to get a node. I suggest it to be $5k per validator

Then the next thing is the cool down period. Why is it so high? And why don't you earn when you are pulling out?

This makes no sense. A week or two is way more reasonable. I know people who scoff of having it for long periods of lock outs me included. The counter argument is more hnt for people who have it then. Well is that good? The whole point is more network participation right? It really doesnt make any sense, why make it less attractive for more participates? You can't have it both ways.

In conclusion I recommend 2 thing for changes. Peg the hnt lockup to a dollar value, and lower the lock up period.

[lthiery]

@maco2035 This feels like a very low-effort contribution given the discussion that's happened here today.

Like 100k dollars of hnt at a time to lock up.

I suggest it to be $5k per validator

A week or two is way more reasonable.

You're proposing arbitrary numbers swapped for arbitrary numbers based on personal feelings. As I mentioned just earlier today, if someone did an in-depth economic analysis of staking on different chains, we might get somewhere, but I really don't understand how anyone will be swayed by this idle opinionating.

But by all means, if this is the you choose to pursue community consensus and change, have at it.

[philknows]

It is my understanding that both numbers were relatively arbitrary to start. However, you'll notice this HIP dates back to Jan 11, so the price was quite different at the time. Since then, there has not been a well-argued reason to change it from one arbitrary number to another.

So based on my analysis above comparing the minimum requirement and cooldown variables of staking HNT vs staking of Eth2, is it fair to state that so far my analysis comparing the two has the most merit out of the arbitrary numbers of 10,000 HNT and 5 month cooldown? Agreed it's not an accurate apples to apples comparison to Eth2 because it has different reward rates, but so far it's all we have to compare and the most established PoS system to compare to. I'm looking at this as a capital allocator and if the incentives are aligned for me to go elsewhere rather than stake with HNT, we will have a problem competing for capital to secure this network.

And why not consider minimum stake as a percentage of circulating supply? Moreover, who is to say that what ETH plans to do is even successful?

I'm no academic economist nor do I model cryptoeconomic mechanisms. However, I am very supportive of utilizing research and implementations that already do exist and have been thoroughly vetted/peer-reviewed by many people much smarter than me at EthResear.ch. Based on those steps alone taken by improvement proposers, it is likelier that Eth2's plans will achieve the goals of securing its network more so than Helium staking with the arbitrary numbers we are throwing at this right now. Eth2's development and even their proposed changes in economic mechanisms have always been backed by some sort of academic paper analyzing their implementations. I would highly suggest the same for Helium going forward and for the foundation/company to fund some deeper analysis into this so Staking v2 rules can be better aligned with network security goals. We all know arbitrary numbers will create unintended effects which may actually hurt the network in the long run. A few that come to mind are concentrations of funds to a small group of whales, centralization of infrastructure (e.g. AWS) and "miner extractable value" from staking pools.

So in my opinion, the numbers are what they are and, I agree, they seem rather prohibitive at this time. However, I also believe that should they be too prohibitive, it will be much easier to relax the numbers than to ever tighten them up.

This is a fair point and I would agree with the conservatism for v1 without a proper economical analysis completed, but this should be a priority as it deals with network security. After Q2 when this is finally released, it completely changes the game and without proper analysis done before implementation, it puts all the work achieved so far at stake. We will very likely see the flaws of v1 variables soon and we should be ready to fix the incentives with v2 shortly after. For example, I'm still trying to wrap my head around a 5 month no-interest bearing cooldown period which is an overly prohibitive mechanism that I haven't found even remotely close with any other networks I've researched for staking.

[abhay]

As we approach enabling staking for Validators and Consensus Group elections from Validators, the core devs have proposed a few changes to HIP 25.

This change to HIP 25 has three goals:

1. Clarify actually implemented transactions and chain variables.
2. Describe the process between landing code that supports validators, enabling staking, and enabling election of validators.
3. Recommend that we reduce the withdrawal period to 125,000 blocks (approximately 86 days) from initially proposed 250k blocks. (ed: retracted)

We believe that these updates are in line with the spirit of the original HIP approved by the community. The clarifications serve as an update for documentation. Although the code that supports the chain variables will land soon, the initial chain variable transactions will not be issued until after all downstream miners, routers, nodes and other blockchain participants have a chance to update.

[jthiller]

Updated rendered view:
https://github.com/helium/HIP/blob/ak/validators-update/0025-validators.md

[mrfizzy99]

Newb here, and forgive any this if this sound disrespectful.

But why does the first 2 'goals' sound fluff to sneak in the 3rd? Someone please do explain how halving the withdraw period is "in line with the spirit of the original HIP". If you can indeed prove this is in line with the spirit of the original HIP approved by the community, then one could say that halving the amount of HNT one needs to hold to be a Validator should be too, right?

[abhay]

But why does the first 2 'goals' sound fluff to sneak in the 3rd?

It's hardly fluff if parts of the initial HIP weren't implemented. The original HIP infers that there is flexibility in amount of stake and that there needs to be an operational chain var that controls release at exactly 100 validators staked. Neither of those things have been implemented. Instead, there's a fixed stake amount and there's manual activation at validator_version = 2. Curious why the clarifications weren't necessary?

Someone please do explain how halving the withdraw period is "in line with the spirit of the original HIP". If you can indeed prove this is in line with the spirit of the original HIP approved by the community, then one could say that halving the amount of HNT one needs to hold to be a Validator should be too, right?

That's a fair opinion but fails to take into account the reason for the new blockchain participant being introduced with this network upgrade. It's important to read the rationale of the HIP since you've self identified as new to the project.

[GP-Colorado]

What benefits to the net derive from not permitting HNT in its cooldown state to be re-used for staking?

When a validator is decommissioned, could and should it be made practical for HNT to be immediately available for use in staking a new validator?

e.g. Hermione and Moaning Myrtle pool their HNT to stake a validator. Later, Hermione decides she'd rather participate in a validator being set up by Ron and Harry and Myrtle is offered a sweet deal to join with Snape.

Should the HNT that staked Hermione and Myrtle's validator be unavailable for re-use for about 3 months?

Note- I am not arguing the point, just curious about the reasoning.

[mrfizzy99]

That's a fair opinion but fails to take into account the reason for the new blockchain participant being introduced with this network upgrade. It's important to read the rationale of the HIP since you've self identified as new to the project.

Sir, this is not proving. This is deflecting with a fact that was mentioned in my first 2 words. But it's cool if you want to be like "Newb, go read and stay out of our way" but in a smart way, I get it. ;)

Rationale is a matter of perspective. The mechanism of the withdraw period and one of the main goals in this validation proposal was to lock up HNT. You can go on endlessly about all the examples of how you can transfer from x to y to z validators all day long.
But lets get that perspective and scroll allll the way back not to long ago to when there was a nice chat about how becoming a validator was to, in my own describing words, exclusive due to market value. And that all these numbers were just arbitrary. Did these discussions get lost in the past 20 days? Was there a disconnect between the devs that are recommending this and what the community thinks?
Halving withdrawal period essentially in my eyes, is giving the whales that are validating get more liquidity, is that a good thing for the network? How many devs are whales now?

Just going to leave this loveably quote here, cuz I like philknows thinking and comments thus far on this thread:
"In contrast, we also need to base values such as minimum stake & cooldown period based on justifiable data and evidence. Not arbitrary numbers with no backing - especially if it doesn't make sense comparatively to the network which has the most at stake: Eth2."

[erik1029]

I'm curious as to the reasoning why the ~86 days is materially different vs. the 5 month cool down to warrant the change, especially at launch (before the exact # of validators is known). I don't necessarily support longer or shorter since each seem like substantial periods of time. Project X or Y has a shorter unbonding period doesn't really seem like a valid argument. I intend to stake for the long haul though and would like to see other validators with a similar long-term mindset. If the goals are to increase the # of validators, there are other levers to pull as well.

[wolfenhawke]

I also intend to stake for the long haul. I am ok with the current figures but have the following thoughts:

1. reducing the stake amount AND the cool down (eg. $5k and 2weeks) just opens validator participation to churn as people decide in 2 weeks that there's a better shiny over there, no there, maybe here. Pick one, if you must, but not both.
2. pegging staking amount to a high $ amount is a way to level the playing field for stakers in the future. Otherwise, possible rising HNT value makes it more and more difficult to get in. An example would be maybe a pizza to stake BTC in the early days, now - out of reach for those who enjoy pizza. [To spell this out, I AM alluding to the 10k BTC for pizza, and now the out-of-reach value of 10k BTC.]
3. It would seem leaning towards longer term stability is more the point of validation than merely ROI for the staker. This is ultimately the intent of staking.
4. I think it is fair if a validator goes down, that those staking HNT can immediately move to another already established legitimate validator without a cool down. There's precedent here from the stock market where you can sell, and trade on unsettled cash (to a point). Also, it alleviates an attack that takes down many validators and prevents stakers from shoring up the network by moving to another validator.

[GP-Colorado]

When a validator is decommissioned, could and should it be made practical for HNT to be immediately available for use in staking a new validator?

Validator stakes are transferrable. This functionality handles your scenario.

So the process would be:

1. unstake_validator_v1: disables the Hermione/Myrtle validator's ability to participate

followed immediately by

2. transfer_validator_stake_v1 : two transactions- One for transferring part of the existing stake from the now disabled Hermione/Myrtle validator to the new Hermione/Ron/Harry validator, followed by a transfer of the balance of the stake from the old Hermione/Myrtle validator to the new Snape/Myrtle validator.

Am I understanding the process correctly?

Yeah, that would certainly handle the scenario.

Thanks,
GP

[cvolkernick]

I've seen the argument a few times that lowering the stake threshold will somehow diminish the quality of the consensus group, and I'm still failing to see how that is the case. If a standard of performance is set with a metric-based approach rather than an arbitrary time committment one, then whether you're participating in the pool of validators for 1 round or 1M should be entirely irrelevant. If a given validator is performing up to the spec that has been set as core requirement, then it really should not matter how long someone is in the pool, and it seems unfounded to associate length of time in the pool with the quality of service provided.

Having a high stake is really only serving the purpose of gatekeeping small money out of the pool and promoting the establishment of large centralized pooling services; if this is the case, then the actual validators deployed are largely centralized; the delegation via pooling is not in control, it's in rewards / profits. For validators to be most secure, the control itself needs to be delegated (operation of the validators), not only the rewards earned from validating (validator pooling by proxy).

[cvolkernick]

I am not familiar enough with the low-level technicals involved with validators to know specifically what these are, but if I had to guess I would assume there are metrics on things that technically are used to meter performance of cloud / server farms...e.g. up/downtime, Network connection quality, success rate actually participating in distributed key generation, etc.

The current approach seems to be no more enforcing of the quality of service than "pay the entry fee and go nuts". I'm open to being corrected that that is the case. Appreciate the consideration of thoughts.

[abhay]

Earlier today changes were proposed to HIP 25 to clarify what was implemented and adjust the value of the Mainnet withdrawal or “cooldown” period (from 250,000 to 125,000 blocks) based on feedback from the community during the Testnet phase. Since then a variety of sources (Github, Discord, and direct conversations with community members) voiced strong feedback that this type of proposal should not be made without a more public governance process.

This particular chain variable proposal will be retracted (the Pull Request and prior communications will be updated) and the withdrawal period approved by the community in the original HIP (250,000 blocks) will remain unchanged.

As the governance process for Helium continues to evolve, the network will require more clarity around how these kinds of updates are approved by the community and the newly proposed HIP 31 offers one interesting evolution of the current approach.

The entire community is excited about the imminent launch for Validators and more details will be shared soon. Big thanks to the community for being so aligned with the long-term vision of the Helium Network!

[maco2035]

I do not mind this change, however, I would like the change to be more governed by the community not just helium.

[GP-Colorado]

As I understand that the proposal to adjust the withdrawal period to 125,000 blocks was retracted due to this forum being felt inadequate for community discussion of the change, and HIP25 has been archived, where should I expect to see the conversation, should the proponents wish to pursue it?

I note that the approved HIP may be read as being ambiguous, perhaps leaving open the possibility that the value was not yet firmly set. Would an entirely new HIP process need to be initiated?

Proposed initial value is 250,000 blocks, approximately 5 months.

I have no firm opinion on the issue but would like to see it discussed.

[maco2035]

@GP-Colorado I aggree that this hip was not given any direct structure and with loose framework, it only contributes to a issue of who wants to implent it and how.

[abhay]

@GP-Colorado @maco2035 here's a proposed structure for governance of chain variables: https://github.com/helium/HIP/blob/master/0031-governance-by-token-burn.md

[maco2035]

@abhay Will there be a wait until that hip is voted on and implemented?

[GP-Colorado]

@GP-Colorado @maco2035 here's a proposed structure for governance of chain variables: https://github.com/helium/HIP/blob/master/0031-governance-by-token-burn.md

I just read HIP31. I found it confusing and from what I think that I did understand, quite unappealing. Conceivably it might seem less so after some revision. But for now, no thank you!

[jamiew]

@hashc0de is there a relevant final PR or txn hash/approvals for chain activation?

[vincenzospaghetti]

This HIP has been deployed, and we are closing this issue! Congrats!