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

Requests For Comment | RFC
42

Thank you Shiny for getting this started and thanks to all the great contributions to this important issue.

Even after reading through all of the comments I am still struggling with parts of the logic in the options as originally posted. As requested, I will suggest some alternate wording, but first I want to raise a minor issue I haven’t seem (or missed) in this thread. The minor issue is defining the vesting period in years instead of epochs. Any smart contract that would release a vesting period based on years (or months) would expire within an epoch so in actuality the time would always be a bit longer than years or months. Minor point that I could live with. I will use epochs in my further comments, but you could easily convert back to years or months if that is just as easy to code.

First, epoch 35 (the last with income) ended Dec 13 and RIP-018 was posted on Dec 14, so the vote was concluded during epoch 36. Changing the wording in option 1 from “registered during the vote for RIP-018” to “registered during epoch 35” seems like a logical change, especially if the intent is to exclude anyone that “abandoned” the project as soon as possible after epoch 35. In conjunction with option 2, the logic for adding a vesting period for anyone that deregistered after epoch 35 seems to be that they are not as committed as those that stayed registered. Since there are logical business reasons to deregister while waiting for 2.0 to be spun up (like saving money while not earning money), the logic of this penalty seems very harsh to me.

For option 3, the logic seems to be that anyone that spins up a brand new DN (and didn’t have a DN in epoch 35 or 36), can still get the same vesting terms as someone that may have had a DN for many epochs but was just trying to save money while fully supporting the project.

I appreciate the logic of excluding a vesting period for option 1 as a compromise, but this assumes that everyone that qualifies for option 1 has been supporting the project for many epochs. I don’t know how many DNs we had at epoch 1, but it is certainly much less than the approx. 2000 we had on epoch 35. Thus, among those that qualify for option 1 there are certainly some (although it could be a small number) that only had a DN for one or a very few epochs. Thus, not having a vesting period for option 1 gives those people the “lottery ticket” we are trying to avoid with the vesting period in options 2 and 3.

The last logic question I have is how to define the vesting period. Is it all or nothing, meaning if you deregister at 1 year and 11 months you lose all of the airdrop? Or, is there a pro rata vesting meaning you earn the airdrop over the 2 years? There can be logic to either option, but I think we need to spell this out in the final RIP. I’m suggesting the pro rata option below, but that can be changed if I’m in the minority.

To help reconcile these logic issues, I suggest condensing the four options into two and added a new third option, which I think others have already mentioned.

  • All DNs registered when we start up 2.0 will receive an airdrop of 18K REN and that 18K REN will be subject to a 26 epoch vesting period. The vesting period will accrue a pro rata share of the airdrop over the vesting period (i.e., 1/26 share per epoch) and all unearned airdrop will be forfeited to the treasury if deregistered before the end of the vesting period. All DNs registered on epoch 35 or earlier will earn vesting periods in proportion to how many epochs they were active – e.g., any DN registered since epoch 9 or earlier will earn 26 credits and be fully vested and a DN only registered since epoch 35 will earn 1 credit and need 25 epochs to fully vest.
  • Darknode bond should remain at 100K and the darknode limit will increase to 11,800.
  • Darknode bond should remain at 100K and the darknode limit should stay at 10,000.

With these new options, I think we should include a comment that we will give everyone as much lead time as possible to re-registered since these options recognize that we would not be forcing DNs to stay active while we all wait to spin up 2.0. We may also want to clarify that you will need to re-register with the same wallet as you used in epoch 35 or earlier to make sure you get the credits for prior support of the network.

While I think these options solve many issues, the one potential problem I see with this is that now all DNs could deregister and wait for 2.0 to restart. Of course, you lose voting power when you deregister but I suspect the bigger issue is that having zero DNs running would absolutely kill all BTC still locked by our partners. I think this would be a terrible thing so I think we should encourage all DNOs with multiple DNs to keep a minimum of 1 running while we wait until 2.0. In fact, if technically possible I think we want to let our partners know that all locked tokens will seamlessly transition to 2.0 they are more willing to keep using REN (and not switch while they wait). Of course, we probably also want to avoid concentration of voting power (and network bandwidth) in one large DNO that keeps all of their DNs active. Not saying this would happen, just that it is good risk management practice to keep many small DNs active. Perhaps we should consider changing future votes to one per DNO instead of one per DN?

Regarding the idea of setting a limit for the number of DNs without a vesting period, I think that is a bad idea for the many reasons already expressed and it essentially exaggerates many of the logic issues I noted above. Besides, I think my suggested options makes adding a maximum unnecessary.

While I think my suggested new option 1 is a reasonable interpretation of RIP-018, and hopefully satisfies everyone pushing for this option, my personal feeling is that new option 3 is the best option for the many reasons elegantly described by Blockchainbard and others. In addition, I think it responds to those that have commented that they would have voted differently if the airdrop was not included in RIP-018. Would you have voted to not save the project? Or just voted for fewer airdrop tokens? It seems to me that the main (justified) fear here is the long-term dilution of DN earnings with more DNs possible. Since the long-term value of REN is based on the earnings of a DN, I think dilution of REN tokens becomes a non-issue with option 3.

Finally, I would note that I think we should make it a long-term goal to buy back and burn all of the new 180M REN (we may not get there but it is still a stretch goal) so new options 1 and 2 would make that more difficult or impossible.

While I think it is outside the scope of this discussion (so we can get resolution and move on), I think the next topic should be how to best use the treasury and keep funding long-term growth so that we never need to face another airdrop situation.

1 Like
43

Just to clarify this comment, if we change to one vote per DNO it would only be until we start up 2.0 and then revert back to one vote per DN.

44

Sorry @shiny and @BlockchainBard, I forgot to set up the connections to your usernames so that you would be flagged that I added some new comments above.

45

Was about to reply to you on this one but I think that @PappyShappy has laid it out very elegantly and gets to the heart of what I was trying to say (cheers!).

For completeness sake we could add an additional “airdrop” option with no pro-rata and/or credits, as a way to have an airdrop option which keeps things simple for simplicity sake.

I also agree with taking one option for the eligibility date, and choosing this as favorable as possible while staying true to the intent as noted earlier. I think the proposal by Pappy to change eligibility to “registered at epoch 35” satisfies this. I do want to clarify though what we mean with “registered” here. This would also include nodes which have started the deregistration but are still part of the network because registration is still pending. In that case long term supporters who deregistered once the true extent of the FTX fallout became clear would be included. If that is not what is meant by “registered” then I would argue for epoch 33 to include the epoch before the drama started and funding was not safu.

46

Hi @Thomm. Thanks for the kind words.
To clarify, are you suggesting that we include a new option two that duplicates my option one, EXCEPT that the second line is replaced with “The vesting period is all or nothing, meaning that if the DN stays registered for the entire vesting period then the airdrop is fully earned, but if they deregister before the end of the vesting period then 100% of the airdrop is returned to the treasury.”? If so, then I would suggest moving the second sentences to the end and perhaps making them 1A and 1B so the rest is not repeated. I could support that.
In response to your question about defining “Registered”, I suggest it means “stays registered to the end of the epoch and rewards are fully earned.” and “Deregistered” means “starting the deregistration process any time during an epoch so that rewards are not earned.”
I’m not sure why you suggest moving the ending epoch from 35 to 33? Yes, there was more uncertainty after epoch 33, but as my wording currently reads, a DN that was registered from epoch 7 to 33 would still earn the full 26 credits. This raises another issue I hadn’t thought of before, which is how should we treat DNs that were registered from say epoch 1 to 9 or even 26 and then deregistered. In this case one could argue that they abandoned the project and should not really get the lottery ticket option of spinning up a DN, get the airdrop and cash out. I think we still want to encourage them to come back, so perhaps the solution to this issue is to only count epochs 9 to 35, or maybe grant a little latitude and only count epochs 7 to 35, so there is a window of 28 epochs to earn the 26 credits?

47

Hi thanks for the time you took to think this through and offer options and input.

For the vesting period, yeah to be technically accurate it would be 26 epochs not 2 years, as long as epochs remain the same period in 2.0. For the RIP we can specify it will be the equivalent of 2 years in epoch terms.

I intended the vesting period to be all or nothing. I get the reasoning behind weighting it according to vote power/time in, but really, I am in favor of making this as simple as possible. Some people may get a little upset, but the point of all this is to allow DNO the ability to remain bonded, or with this vote, potentially let those not included in the RIP fire up a node with the 100K they already saved up. There should be no issues with a vesting period for those who plan on running long term.

Having an option to keep bonds at 100K and limit max nodes to 10K is a good idea, might be better just to have that one option. Since Ren will also be used as a gas token, it will still have utility if we ever max out, but also because it will be a gas token I’m not sure we will ever get there anyway.

These are just my opinions, i invite further comments by others. Pappy, i am curious, did you vote in RIP-018, or were you eligible? If so, have you kept your node(s) bonded?

48

Hi Shiny,
I get your desire to keep it simple, but to avoid the issue of letting someone with a DN only active for a month or two getting the airdrop and just cashing out, I would suggest that the compromise for your original option 1 should be half of the vesting period for the other options not zero. I think all long-term DNOs would not mind that compromise and even understand the logic of including it. I wouldn’t mind it.
Since it is hard to really gauge sentiment of all DNOs without voting, perhaps we could add my new options to your original (as modified based on feedback in this RFP) options and then use a two stage vote. In stage one, vote 1 to X for each option so that in stage two you narrow the list to the top two and then we have the final vote?
I’ve seen snippets of REN being used as Gas in 2.0, but I am not familiar with how that would work. I think this is an important issue for all to understand since voting on airdrop options will definitely impact that in the sense of how much REN is left for Gas, how Gas is distributed, etc. If there are details I need to read someplace, please point me to them. Otherwise, would it make sense to create a separate RFP on how the Gas functionality would work?
Regarding your final question, I have been a DNO since epoch 5 or 6 and I did vote in RIP-018. Like others have expressed, I did not view the airdrop portion as set in stone, but rather as a promise to find a solution that is fairest to all current DNOs and the best option for the long term success of the project. Because of the confusion (at least for me) on how to best prepare for 2.0, and because I use Digital Ocean and must transition to new droplet API tokens, I have since deregistered all of my DNs but they are all still bonded. Whichever way this vote goes I will be re-registering all of my DNs when 2.0 is ready to go.

49

As a side issue on your last question and my response, I mistakenly thought that voting depended on keeping REN bonded and didn’t realize that once the deregistration process starts I can no longer vote. It’s unfortunate but I will live with it. It is a personal reason why I thought the difference between your options 1 and 2 was harsh, but for me adding a vesting period will not deter me from re-registering all my DNs if the voting goes that way. On the other hand, I am encouraged by the wording in your options because with any option it looks like I can unbond all of my DNs so I can shut off the Digital Ocean droplets until we are ready to start 2.0, and then just re-register one DN for now so I am eligible to vote again (not as much voting power, but one vote is better than none). Do you see any downside in unbonding all my REN and then re-registering one DN for now while waiting for 2.0 (other than less voting power)?

50

Yes exactly.

I suppose I did not fully appreciate how the credits in your proposal were earned in this situation, but as long as long term supporters who de-risked when FTX collapse started are eligible then that satisfies what I was going for.
As for the “simple option”, I suppose this would entail no pro-rata and no credits, so here I would propose the hard cut-off to simply be at epoch 33.

However, all of this still sounds sub-optimal to me. It feels bad to leave out anyone who (became) registered after epoch 33. If there is going to be a long vesting schedule, maybe we should just include them too?

51

I mostly just read the comments because I am a supporter of Ren and leave it up to others smarter than me to provide direction. But if i understand this to some degree, Ren was put into this predicament because of the FTX and Alemada debacle. Until that moment, all DNO believed that REN was doing ok. So why not just take a snapshot of all DNO at that time before the FTX announcement and include all waiting to register DNO for the airdrop at the same snapshot. I agree with the 2 yr vesting (all or nothing) as it is being given to maintain the bonding amount. If someone leaves early, they still have their original 100k that they invested. The inflation was necessary for Ren’s survival and if a DNO cannot commit the full 2 yrs or equivalent epochs, they do get to earn rewards during that time and so they still benefit from the airdrop but funds return to the treasury

52

Option 1 - Retain original terms as set in RIP-018, had to have remained registered until airdrop or else it makes no sense (why do some get to deregister and others not)

Option 2 - First 2000 nodes registered at start of 2.0 receive airdrop with a 2 year all-or-nothing vesting period

Option 3 - Bonds stay at 100k, max 10,000 nodes coded in

This is what I would like to see, simple and fair, not saying that’s how it will be worded but just my personal preference. Would really rather not have option #1 at all but since already voted it should be in there. Hopefully current DNO see the error in this line of thinking.

53

I’m not sure, depends how the vote goes. I don’t like the idea of 2 votes but if we can’t narrow these down with an obvious consensus then maybe we do need to have a vote with several options, with the terms that if there is not a clear winner (some % needed) then the top 3 or so votes go to a final vote?

But I just posted what I would personally like, and it sort of encompasses how I understand the prevalent opinions. Some want to keep terms of RIP-018, some want to keep bonds at 100k, and some want to change bonds to 118k but include committed fRens, and keep out those who will leave and sell early (regardless of when they registered - “past performance does not always predict future success” )

54

David in discord brought up an important point just now in the foundation channel. Once the foundation is formed, to remain a separate legal entity from the DAO, it is not required to act exactly as the DAO wishes on every issue brought up. (Paraphrasing here) So when this RFC eventually goes to RIP and is voted on, be aware that the foundation can choose an option not the most popular.
To quote him “the safest bet is to be registered” since we don’t know ultimately what the foundation will decide regarding this subject.

55

I’m sorry, but the wording of RIP-018 only states “currently registered” (at the time of the vote) and does not mention a requirement to remain registered. In addition, under the “Token Lockups” section is it recommended that all allocations, including to DNs, should include lockup conditions. Finally, the number 2000 is only noted as an approximation of the currently registered nodes.

Thus, if you really think that RIP-018 should be adhered to, then I suggest option 1 should be:

  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.

Since there is no maximum specified in RIP-018, I suggest option 2 should be:

  1. 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.

Option 3 could be my first suggestion above and renumber 3 to 4:

  1. Darknode bond increases to 118K. Any darknode registered prior to the activation of 2.0 will receive the 18K airdrop, which will be subject to a maximum 26 epoch vesting period. All DNs registered on epoch 35 or earlier will earn vesting periods in proportion to how many epochs they were active – e.g., any DN registered since epoch 9 or earlier will earn 26 credits and be fully vested and a DN only registered since epoch 35 will earn 1 credit and need 25 epochs to fully vest.

  2. Darknode bond stays at 100K and max nodes of 10,000 is coded in.

I think these 4 options keep it simple and consistent with the discussions in this RFP. For option 1, I think we can flip the question around and ask why should someone that stays registered get a benefit others do not? I suppose a compromise could be to use a 13 epoch vesting period for option 1, but to exclude a vesting period altogether is ignoring the wording in RIP-018 and allowing any DN registered at the vote to win the airdrop lottery by cashing out.

For all options, we should include a comment on whether the vesting period should be all or nothing, or earned over the 26 epochs. I can live with either, but we should clarify though and if we think there is a lot of controversy about this then there could be a secondary vote on how to apply the vesting.

Earlier, I have seen references to REN being used as Gas in 2.0. Depending on how this is implemented, I think this could be a good thing, but I also think it could have a significant impact on how people vote for these options. Thus, we either need to point people to the details of how this will work or have a separate discussion on how this would work.

2 Likes
56

What is this “token lockups” section you are referring to?

Also the 2000 node limit was gathered from the approximate max nodes ever registered. I feel some limit to what the treasury pays out should be given.

57

The “Token lockups” is part of the RIP-000-018 write up for the vote. It is the section after the “Vote options” section.

I understand your desire to cap the airdrop to 2000 DNs. In that case, I would suggest only adding a 2000 DN cap to my option 2 above. AND I strongly feel that with a cap, absolute priority should be given to all DNs active prior to the vote so that any DN not registered prior to the vote would only get the airdrop after all DNs wanting to continue with the airdrop get a chance to receive the airdrop first. Reworded option 2 would look something this this:

  1. 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.

Personally, I think your reasoning for including the cap of 2000 is a better argument for option 4, but we will see when we get this to a vote.

58

@PappyShappy Whoa, good catch I never noticed that. I am happy to see that, and it does cause me to reconsider some things a little.

I am fine with option 1 as you worded it, especially since a vest is mandatory under RIP-018.

Option 2 can be re-worded to simply state all darknodes registered at activation of 2.0 will receive it, with a maximum allocation to 2000 darknodes with priority given to nodes registered at RIP-018 and then earlier. We can discuss further if it should be 1800 or 1900, etc. 2000 was originally suggested by @sotashinokomata and is a nice round number.

IMO option 3 is not needed, everyone who gets the handout should vest for 2 years regardless of how long they have been active, this is for the future and not celebrating the past, and this will reduce chances of splitting votes between 2&3 which are similar outcomes.

As Ren 2.0 will act like an Eth chain with transactions needing gas to avoid spamming the network (not all transactions will involve minting and burning) , Ren will also be used for gas. If Ren is needed for gas, it will have a demand and scarcity greater than when its only use was for dn bonds. So it will be more difficult to approach the max node limit with more Ren being used in tx’s and held by users needing it to transact. This will make darknodes more rare, and more valuable, unless the 100k option is selected in which they will just become more equal to what they were before gas was a factor.

59

If we use my reworded option 2 and keep the 2 year vest for option 1, then it seems to me that they are essentially the same so we could eliminate my option 1. My option 3 would then be a compromise for anyone that feels there should not be a vesting period for long term DNs. I like that this still keeps it simple. It could also help avoid any controversy about not having a middle ground between my options 2 and 4.

If this makes sense, I am happy to be part of a group that writes up the final RIP so we can move it to a vote.

60

Option 1 only includes nodes registered at the vote of RIP-018. It honors the original terms of RIP-018.

Option 2 includes all nodes registered at activation of 2.0, with a 2000 limit prioritizing nodes registered before the drop was announced. These are very different options. #2 includes nodes not voting on RIP-018.

Since RIP-018 explicitly stated there should be a lock period for any allocations of tokens, including darknodes, there should be no problem requiring a vesting period, and introducing a graduated system only introduces a complexity that does not benefit the protocol. A node that leaves after 3 months is a node that leaves after 3 months regardless of how long it was registered in the past.

@PappyShappy sorry I keep hitting the wrong reply button :slight_smile:

1 Like
61

I understand that options 1 and 2 are different. My thought process, although not explained, is that if there are close to 2000 DNs that are part of option 1 and option 2 gives them priority, then the main difference between the two is the few extra DNs that could get the airdrop under option 2 compared to option 1, including a few that could get in if not all of the DNs from option 1 don’t follow through. That said, I don’t have any issue keeping both options in the RIP.

Likewise, I was mainly trying to avoid controversy with option 3, but you make a good point on the added complexity so I have no issue dropping it.

No worries on your replies, that is how we move this forward.

Still happy to help with the final RIP if needed.