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

Me neither, let’s hope #2 or #3 win to help build our community quickly.

Hmm…. I was sort of thinking we wouldn’t even hit 2000 but I suppose you are right, we need to have a plan in case this is more popular than that.

We could just make it simply first come first serve. Those that are paying attention now will have the highest chance to get in. That may be the best anyway. We could have current active members in the chats who haven’t run a node yet, why should they get beat out by some OG who hasn’t been around for months?

Yes that might work better, less variables and sounds more fair. Still don’t really like the “race” aspect this introduces but I suppose there is still quite some room right now and thus opportunity to get the word out and give people a chance to register. Maybe to make it even fairer we can up the limit a bit to e.g. 2200, will cost the foundation a bit more but then again it also increases decentralization, if we hit it we will start the network with a higher node count than 1.0 ever had, which already gets me excited haha

How about this as a re-write of option 2:

  1. Darknode bond increases to 118K. Only darknodes registered at or prior to 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 vesting period. In addition, the first 200 darknodes registered prior to the activation of 2.0, but not registered at or prior to the vote of RIP-018 will also receive the airdrop, which is subject to a 26 epoch vesting period.

I think this is similar to the earlier version, yet clears up any prioritization issues and potential problems with old DNs registering and knocking out a newcomer.

Hold the phone- we should NOT have an option that would require de/re-registration (in my opinion). Aka not airdropping nodes registered prior to 2.0 but after 018. We are already losing a multitude of nodes and those that have registered since 018 may not come back (unless there are fewer than the 200 spots allocated which could be an option suggested in an above post).

Is grandfathering DNs without airdropping still an option or we’ve completely nixed that.

I think to find the best answer we have to remember what the issue is here, why we are even voting. We voted in RIP-018 to print some additional tokens to fund the next chapter of Ren, and to keep the node count at 10,000 darknodes we would have to increase the bond accordingly. So we have to get used to the fact that if option #1 or #2 is the most popular, then a node will now cost 118,000 Ren. Just the way it is. The airdrop was designed to keep currently registered nodes from having to go buy more Ren just to stay running. Then we had some folks in discord complain that they either just unregistered or hadn’t registered yet because of the uncertainty of the future. That is understandable so option #2 is there to assist these folks, this RFC wasn’t really meant to go beyond that. I think even 2000 nodes is too high of a max, but a nice round number is good, and if we get a nice healthy node count to start 2.0 that’s good too. But our treasury isn’t gonna be huge, we should be a bit frugal with it, and try to stay close to the reasoning of RIP-018. Stray too far and we may even risk having some fence riders vote for #1

The wording sounds good to me @PappyShappy. I think once we get well into 2.0, we can revisit the discussion of how to prevent confusion in future RIPs, like separating the “What” from the “How”.

Hi it has been 2 weeks, I think we are ready to write this up. Only question left is quorum, and voting style ranked choice sounds best :

Ranked choice voting (Instant Runoff Voting)

Each user has to rank all choices in a desired order.

In the first step votes are counted for each voter’s number one choice. If a choice receives more than 50% votes (cast on number one choices of each user), that choice wins. The result will show the percentages reflecting how users voted for their first choice only .

In the second step if the first-choice candidate doesn’t get over 50% of the total votes the choice with the fewest number one votes is eliminated . Voters who had chosen the defeated choice as number one now have their number two choice counted as their number one choice.

The process continues over multiple rounds until a choice has more than half (> 50%) of the total votes.

If we’re only doing three options I am not sure ranked choice is necessary- but I trust your judgment more than mine as I haven’t participated in a vote thus far.

I don’t disagree with anything you’ve been saying- just putting different ideas out there to prompt deeper thought into this vote as it is a pivotal one. So I’ll propose just one more.

Set a maximum of 1,700 currently registered DNs to receive an airdrop prioritized by the longest registered. There are 1,654 currently registered DNs and 8 to leave the next epoch (with1 coming in)

We would prioritize based on nodes who registered the earliest and continuously stayed registered, then who registered the earliest, de-registered, then re-registered before 018 or the 2.0 release, and lastly those who registered before the 2.0 release.

Again just attempting to provoke thought for alternative yet plausible ideas. I feel like this one encapsulates a lot of what we talked about earlier while still prioritizing long-term participants. I get wanting to close this discussion and just publish a vote so don’t stress too hard about it.

I see what you are saying about ranked choice. The reason I think it may be good is that some may be in favor of #1 or #2 but absolutely against #3, and others may be in favor of #2 or #3 but really against #1. The ranked choice will help them get at least one of their favorite options won in case there is a split, if I am understanding correctly how it works. If you have a different view please offer. I’m just trying to prevent having a split between two popular choices end up hurting them and the least popular wins?

For your other suggestion, yeah honestly I’m just wanting to get this over with. It sort of sounds like #2 but with a lower max and some hierarchy added. It might be great idea but it’s been 2 weeks I kind of want to move in with it. Of course if others chime in and want it in that’s cool.

Yeah I think ranked should be fine.

I agree. I’d say let’s write it up since no one’s responded in 10 hours. Let me know if you need any help

I’ll try to get to it in next couple days, but you are welcome to pitch in and @PappyShappy you too

Sure- how would we go about collaborating on a doc together?

I’m not sure, never wrote up an RIP but I suppose step one is getting title and headings, summaries down. Then have to compose the body, and finally create the vote and somehow link it to snapshot.

1 Like

I’d recommend collaborating here- better than google docs as it’s encrypted and uses web3.

edit: y’all add me on telegram and we can chat more about it and I can add your email to the collaboration

Yes you are right, I was veering a bit from the goals as originally stated. So that leaves us with first-come-first-serve for option 2? It still leaves a bit of a bad taste for me but I think we have gamed it out quite well and it caters nicely to both committed old timers as well as newer community members, so I can get behind that formulation for this option.

In my experience, “best” and even “better” are often the enemy of “good enough.” Occam’s razor… KISS… etc, etc. Keep the bond @ 100k. If this project has the potential that I think it does, a few more DNs isn’t gonna make/break anyone’s fortune. Just my (uneducated) $0.02.

1 Like

@Jeff Be sure to post this under the RIP, best place to make our cases

I agree with this but I would not put option1 with a vesting period @shiny or vesting period is too long.


I believe there should be one, and RIP-018 stated there will be one, but how long do you think it should be and why?