RFC-000-051: Determining which darknodes will be protected from the increased bond size

I think we had what about 1700 dn at the vote? That would open up about 300 more, but maybe even more considering some won’t reregister at all. We should keep #1 as-is in case there is a greater number of dno who want to stick with terms of RIP-018 than we believe. So these 3 options sort of encompass the 3 prevalent opinions I’ve read - some want strict adherence to RIP-018 terms, some want to include others who may be getting the short end of the stick amidst the chaos of Alameda, and some desire simplicity, keeping bonds lower, and having more funds available to the treasury.

Speaking of this 3rd option, what do you think about taking the extra Ren that would have gone to darknodes and requesting the foundation burn it? Some have argued that they would not have voted for RIP-018 if they were gonna be diluted. But considering there really is no other option for survival of the protocol, their only argument then is they would have voted for less inflation had they not received compensation. So it may be worthwhile to either modify option #3, or introduce an option #4 that adds that the equivalent amount of Ren that would have gone to DNO (about 1700 x 18,000 = 30,600,000 Ren) gets burned immediately to lower the inflationary hit. I welcome opinions on this. It would contradict with the idea in #3 that more funds go to the treasury.

I don’t know how many DN we had at the vote. I didn’t realize it had dropped that far, but it’s probably a good reason to keep option 2.

Regarding option 3 and potentially including a burn of the “excess” REN, my preference would be to include something about keeping as much in the treasury as possible with the long term goal of burning all (or most) of the new REN once it is clear that our long term funding needs are being met via either the current tax type funding, using treasury DNs for funding, or something else. Actually, I think this applies to all options not just option 3. My thinking here is that we want to make sure we don’t run into any future funding needs (such as a second round of new REN) and then reduce total supply as much as possible to alleviate inflation.

You’re going to have a significant amount of DNs leave the network if they have to de/re register.

This is because they simply might not realize they need to add 18k tokens (aka they’re inactive), were too lazy too, or don’t want to spend more money.

I like the idea of grandfathering DNs that have existed since the last epoch before Ren 2.0 is released. Even if they earn less money than the new ones since they make up less of the staked tokens

There will be something dno will have to do to transition to 2.0, it will definitely not be an event they can sleep through. But if they have been running a node since before RIP-018, regardless of the outcome of the vote they will not have to purchase more tokens.

Yeah for sure. I just want to ensure we keep the DNs we still have since there are only 1,654 registered and falling (98 left last epoch which is almost -6%)

This is obviously coming from a someone who started their DN after 018 :joy:. I don’t have ~$2k right now to re-register if DNs need 18,000 more tokens to participate after 051 is voted on. I’d assume many others might be weary about it as well.

Obviously the 4 options OP suggested don’t involve buying more tokens/re-registering but thought I’d throw that out there.

I’m a little confused on the difference between 2 and 3 but I feel giving DNs some REN might be a good way to incentivize them to stay on/join the platform-especially vesting since the REN is forfeited if they de-register before 2 years.

I’d also be down to just increase the limit of DNs as it seems incredibly easier and there would be a lot less to exploit with regards to bad actors finding vulnerabilities

@PappyShappy That sounds good, I was just trying to represent those who are arguing they only voted the way they did in RIP-018 because they thought they would get an airdrop. So if option #3 is chosen, they would have voted for less inflation. The only way to represent them in the vote is to have a 4th option like #3, but with an “auto burn” or change #3 to include that (which imo is not a good idea and agree it should be understood we burn in time whatever is not needed).
So we have to decide to include this, or just ignore it and believe theirs is a minority opinion.

As I read the thread for this RPF, I think we are down to the following three options:

  1. Darknode bond increases to 118K. Only darknodes registered at the vote of RIP-018, and are registered prior to the activation of 2.0 (either continually registered or de-registered and re-registered), will receive the 18K airdrop, which will be subject to a 26 epoch (approx. 2 year) vesting period.

  2. Darknode bond increases to 118K. Any darknode registered prior to the activation of 2.0 (whether registered at the time of the RIP-018 vote or not), will receive the 18K airdrop, which will be subject to a 26 epoch vesting period. The maximum number of darknodes receiving the airdrop is limited to 2000, and all darknodes registered at the time of the vote or earlier will have priority in receiving the airdrop.

  3. Darknode bond stays at 100K and max (non-treasury) nodes of 10,000 is coded in.

I think options 1 and 2 represent those arguing that this is consistent with RIP-018 and the way they voted and option 3 represents the other camp. Rather than add another option that keeps the bond at 100K and increases the max number of nodes, I think it is cleaner to only allow more than 10,000 nodes if they are treasury nodes for the benefit of everyone. Of course, keeping a tax system or using treasury nodes would still need to be voted on, and more people may want to stay with the tax system, but this would allow that vote to take place without needing to amend the wording of an earlier RIP (which many seem to be objecting to).

If you agree, my offer still stands to help write up the RIP.

@PappyShappy Sounds good to me!

Anyone else have a comment on this?

@SethD @Thomm @sotashinokomata @o_O @martign0 @vikingksk @redcalibri @Amaguq623

You all posted here just asking for your blessing

@polo @Spinflight @Rhodehome @DryOracle @Maggie @BusinessLion @BlockchainBard

See above

1 Like

I see it either RIP for the way 18 was intended, or forgo it. No matter what happens, there will be animosity in providing any type of inflation adjustment due to the amount of uncertainty and lack of comms with developers on making the transition.

If we proceed with an inflation adjustment, it looks to me like it will be handled internally. Those wallets involved through the transition and still registered when 2.0 goes live will get 118k bond at the point of their dereg. Keeping the 100k for any new DNO that wants to come on board, thus keeping all nodes at 100k and avoiding a taxed airdrop at the outset. A vesting period seems to be a viable option on the developer side, although 2 years seems excessive to me, but whatever. I’m in it for the longer term BTC income and ren-wrapped yield.

Longer term, I feel no adjustment and keeping things equal with the value going into the project is the better option, so I’m still thinking #4, but it’s not a critical deal-breaker for me. Whatever gets the project moving along and securely back online is the overriding factor, regardless.

Please read this message regarding how the RIP will be written up, this is what we would like input on:

I am ok with PappyShappy’s proposal of voting options. But I would add a minimum quorum that equals the number of total votes of the RIP-018. If we don’t reach the quorum, then we leave the terms exactly as written in the RIP-018.

Because if we now do a RIP vote and e.g. let’s say get 10% of the votes of a previous RIP changing previously voted-on terms it sets a bad precedent.

I understand the thinking, but since there are less nodes even registered than there was at RIP-018, the standard should be lowered a bit. Also, one reason for this vote is to clear confusion over what happens to those who deregistered after RIP-018. Are they cut off or can they reregister?

Reading through everything I don’t disagree with what was newly proposed. My only critique would be the length of vesting time is a bit long. I think 4 epochs would be fine. (Over 100 days)

I am not sure as to why we need to limit nodes to 2000 as next epoch it seems we will be losing 2 nodes rather than gaining 346 to put us from 1,654 to 2,000. It would depend on when the vote is to take place I suppose. (Aka after the April 14th epoch or May 2nd)

I think #1 complicates things a bit as well and we could change it so that nodes registered at time of 018 (or before) can have access to airdropped funds immediately or with a smaller vesting time than nodes registered at time of/launch of 2.0 — However, I do understand that we want to incentivize those who participated in Ren earlier to come back in the most frictionless way possible as said earlier.

This would change the 3 options options to

  1. increased Ren per DN and give liquid airdrop to 018 DNs and vesting airdrops to those at time of 2.0 release

  2. increased Ren per DN and give vesting airdrop to all those at time of 2.0 release

  3. increase DN limit And keep 100,000 Ren per DN (with potential to limit the additional DNs to treasury nodes)

If you are sold on giving previously deregistered DNs an airdrop that could be a 4th voting option

As for my #3, I think we put somewhere in the details that there will be another vote on taxation vs treasury DNs and we can decide on the logistics during that vote. I think it’s a safe assumption to say we will not be getting over 8,000 DNs registered in the next few epochs if #3 is voted in and have time to make that decision in a few weeks.

Thanks for all your work on this @shiny. I’m on-board with @PappyShappy’s options.

Heading into the vote, I’ll note one last time that I think it would be a mistake for the community to reward OGs instead of promoting decentralization and community growth heading into 2.0 launch. Decentralization and community momentum are the two most important items REN needs to excel at moving forward in the face of an expanding and well funded competitor set.

2 Likes

#1 is written to be exactly what was written in RIP-018. RIP-018 stated the nodes registered at that time would be eligible, and that there would be a lock up period. The longer the lock up, the better it serves long term interests of the protocol as it encourages nodes to stay registered and contribute, and those that choose to leave early give their tokens back to treasury for protocol use. Several community members have communicated they feel the terms of RIP should be honored so this is an option keeping them as provided.

A 2000 node limit may not be needed, it is just a safeguard to make sure the treasury has a clear boundary of what it will pay out. Don’t want to get surprised if a rush of registrations happen.

I can dig it. When do you think a vote would be proposed?

I agree with this I hope to vote :+1::+1:

Personally I feel including a burn here would muddy the waters a bit for this option, and including different options would complicate things. How about we state that if this option wins we would have another vote to decide what to do with the tokens?

As for the options, I’m not completely sold yet on option (2). If we are going to prioritize DNs that were registered earlier, we might need to prioritize more than 2000 as there probably have been more than 2000 with some cycling through. How are we going to choose if there are more? Also, the remaining slots (if any) will probably go on first-come-first-serve basis. This needs to be decided and specified clearly before the option goes in to effect, and leads to some game theory effects that might not be ideal. For example it incentivizes new comers to join as soon as possible to get a potential slot, but they can still be pushed out again if an “OG” registers later on, which introduces uncertainty and potential disappointment.

I still feel more for an option that simply includes everyone before the FTX debacle started. However, I also get the desire to want to incentivize new comers before/when 2.0 launches. How about earmarking a max number of tokens that will be distributed amongst the newcomers (those registered at 2.0 but not eligible for the full drop) equally and with vesting?

I am OK with this to get an end on the topic… Options are simple to understand.

I just do not like to increase bonding that may affect people that already saved 100K to run a DN.