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

Personally I feel the flaw is not in this vote, but in the way RIP-018 was written. It had two fairly important details that each deserved a vote, but only included options for one and disregarded any opinion around the other. Then when you consider there was a sense of urgency to get the vote passed (and the inflation was the primary focus so nobody even really questioned the airdrop) it does seem to me this vote is reasonable. We can learn from it and be careful how future RIP are created.
Option #3 is the most forgiving for anyone who feels left out while still retaining the higher bond. I don’t see how committing to 2 years should be a problem for anyone serious about running a node. You can always deregister you just can’t keep the extra tokens. This is beneficial for the project as a whole.
That being said, this is an RFC and meant to decide how we will form the RIP. My opinion is just one and hopefully more fRens participate here so we can come up with the best options to put to a vote. Feel free to write out how you think they should look and others can comment.

Please comment with how you wish the options to be worded. But keep in mind that option #3 allows anyone to spin a node with 100k as long as they do it before the airdrop happens, they just will not be able to keep the 18k airdrop unless they stay registered for 2 years. This shouldn’t be any type of barrier or friction to someone serious about running a node.

So #3 or #4 are fRendly options to all it just depends on if we should put preference on either adjusting bonds to counteract inflation and preserve node value, or keep bonds at 100k for simplicity and more funding for treasury.

Generally agree that option #3 is the best. I would simply change its reference to option #1 to include long term DN operators that deregistered for a single epoch (that coincided with the RIP-00-018 snapshot), such that they would receive the same treatment as DNs that were registered at the time of the RIP-00-018 snapshot. I believe it’s only ~70 DNs or so, and again, many like me have been supporters of REN for a long time. DNs starting in Epoch 2, but REN holder back to the dark pool days.

So you are saying option #3 should be worded that darknodes that deregistered during the epoch just before RIP-018 should receive an airdrop with no vesting period as long as they are registered at time of airdrop?

I would invite comment on this from others.

Do you feel it unfair to require these nodes to have a vesting period? If they registered, received the airdrop, then deregistered within 2 years should they get to keep the airdrop? Personally I feel all nodes who receive the airdrop should have a 2 year vesting period, as it isn’t meant to be a reward but a solution to allow them to stay bonded without buying more. Only reason I didn’t apply it to the nodes who stayed registered is that I felt they would not vote for it and we would either have protest or low turnout.

1 Like

I think the vesting period is unnecessary complexity in the darknode registry contract. Contrary to “airdropping” into the registry, which is a manual action, and updating new bond size which is a simple parameter change, the vesting in DNR would require additional logic… which would likely warrant new audits ($$$)

For context, let’s remember this whole airdrop to people who were not registered at RIP-18 snapshot would apply only to a few hundreds DNs at best. Indeed, to keep in line with the “airdrop” allocation of RIP-18, the offer should be limited to the first 2000 darknodes anyway (otherwise some whales might bond it all and then all the mint could go to airdrop and none to foundation :stuck_out_tongue: )

There is already a “vesting” minimum of 3 epochs (1 for registration + 2 for deregistration), that’s enough imo.
Anyone making the effort to bond, setup a darknode, and taking the risk of bonding for 3 months is proof enough that they are interested in the project.
The growing DN fees should be interesting enough that people do not want to deregister, and if they do (not 100% of them) it’s still not such an issue as we already routinely go through ~100 deregistrations epochs these days.

2 Likes

I think what is not very clear in options 2 and 3 is if bonding will be lifted to 118K in Ren 2.0.

My suggestion in any of the cases is to keep bonding as 100K. The reasoning (besides I doubt will get close to 10K DN) is that small token holders that bought the required bond of 100K will not be eligible to the airdrop and will be affected and possible will not run a DN.

@martign0 Options 1-3 are all a vote to increase the bond to 118k

Both cowboy and Max believe it is not technically difficult to incorporate a vesting period into a contract.

If it is not difficult do you still feel the way you do?

My vote would be to proceed with option 3 minus the vesting period. I suspect the delta between the RIP-018 snapshot and 2.0 launch will be 100-200 DNs. I believe it’s less than 100 now, correct? In the event there is a vesting period, I would apply it to everyone, not just the DNs that registered between RIP-018 snapshot and 2.0 launch.

IIRC cowboy mentioned that implementing a vesting contract isn’t difficult (which is true there’s plenty boilerplate available for that), but I don’t think he was specifically mentioning this in the context of the darknode registry (perhaps in passing or related to investor tokens only).

Similarly I don’t think Max understood that the vesting cannot be implemented only in the “migration contract” - afaik it would have to be coded in the DNR since it would be part of the bond (ie. deregistering before the vesting does not give back the full 118k bond but only 100k… not sure also where the 18k end up in this case).

Regardless of above, implementing vesting specifically in the context of darknode bonds still requires some development (and testing!) that feels completely unnecessary to me at this point of the project and for a limited airdrop that still requires a minimum of 84 days registration/deregistration dance in order to even attempt to “game”.

Would rather focus development entirely on 2.0 launch and ignore the noise of a possible “airdrop dump” 3 epochs after relaunch… when we routinely have 100 deregistrations per epoch already.

TLDR:
The worst case of a limited number of people gaming the airdrop is a non-event.
But the worst case of implementing vesting is wasted precious development time AND critical contract security issue resulting from this last minute shoe-in.

I would prefer to apply it to everyone, so the treasury gets back those tokens from any DNO who leaves early. But I believe adding a vesting period to DN that voted in RIP-018 would get substantial protest. There are already some who feel we shouldn’t have this vote at all and stick with the original vote. A vesting period is sort of a compromise, as it rewards those who stayed committed throughout the process but those who registered after the announcement of an airdrop, or who derisked early, still get a chance to run a node with the original bond value. To avoid rewarding those wishing to game the system (we had around 50 nodes register from one individual when the airdrop was announced) they have to prove commitment.

We can always add additional options that replicate #2 and #3 but without vesting, but remember who is going to be doing the voting - registered DN, not those hoping to get in.

Good point relative to adding a vesting schedule to those that voted in RIP-018. Probably a non-starter. I generally agree with @sotashinokomata’s thinking in terms of messaging a no-vesting schedule option #2 and #3 to DN voters. Especially the points relative to 1.) keeping the team’s focus on the main thing (2.0), 2.) the potential impact of those looking to game the system being minimal relative to deregs we’ve seen in other epochs, and 3.) encouraging as many new DN regs as possible to support the launch of 2.0. There’s a lot of upside to that approach, with minimal downside.

1 Like

I was working on gathering some statistics to determine a sensible quorum for future votes. I can pick this back up but it was non-trivial (for me at least) to figure out the total voting power across all Darknodes at the time of a particular vote, as basing the quorum on voting power would be the natural thing to do. Quorum based on Darknode operator count would be much easier to figure out though. Happy to hear any thoughts or if someone can help out determining the voting power available at previous votes.
Either way I feel this is something that needs more discussion and thought and will delay this proposal.

As for voting type, ranked choice will work well. Don’t need any post-processing mumbojumbo because we have one (NO) and multiple (YES); whichever options is first wins.

Agree with this.

While votes are binding, it is also part of the process that subsequent votes can change the current state of affairs. This is only normal and logical as you need to be able to adapt to changes. Of course there is value in stability and we should try to refrain from changing prior decisions on a whim, but decisions are not written in stone never to be re-evaluated either. It cannot be denied that there was not much discussion about the “airdrop” priviously, and we are having that important decision now, that alone adds more value and will give more credence to the eventual outcome.

1 Like

Having a vesting schedule should not affect encouragement to register, what encourages registration is the chance to get in while you still only need 100k. Vesting on the other hand also encourages keeping nodes registered. Speaking in discord tech chat just now, it is a very simple thing to add, there are already audited contracts they can copy from. Knowing that, I see no downside to requiring a vesting schedule for nodes who did not register until after an airdrop was announced. It will encourage nodes to stay registered and committed, and any that leave before 2 years, the treasury receives their 18k tokens back to use towards project development.

With a 2000 node limit, we also don’t run the risk of filling those limited spots with bad actors and serious fRens get left out.

I can include options without vesting though in the vote, that’s no big deal.

1 Like

As a DNO who voted on RIP-000-018, I support Option 4 (dilution) if it helps Ren 2.0 stay competitive and incentivizes dApp development. Others worry about setting a precedent, but the RIP came together quickly, and we didn’t realize there were two separate issues. Given the competitive nature of cross-chain bridging, I support what’s best for Ren 2.0, even if it means a short-term hit. We should allocate funds to hire a DAO governance auditor in a future RIP to prevent similar issues (does such a position exist?).

I’ll support option #3 with or without the vesting schedule, but my preference would be without a vesting schedule. Maybe you include one option 3(a) with a vesting schedule and one option 3(b) without a vesting schedule, and utilize ranked choice voting. Option #1 seems terribly shortsighted, and if it takes a vesting schedule to persuade DN operators to avoid that option, so be it.

Were you eligible to vote in RIP-018?

Thinking more about this, what would we do if quorum in this RIP were not reached? Would we default to option #1? What if the votes that were cast were overwhelming in favor of any of #2 - #4? It would seem illogical to proceed with option #1.
If we even have a quorum it should be set quite low imo, we can’t expect more turnout than RIP-18 so it would have to be less. I asked mods in discord to tag “all” so we could have some more eyes on this, no one did, hopefully that will happen when the RIP gets posted.

No, that was the one epoch that I missed. Ran multiple DNs every epoch up to that point and every epoch since. REN holder a long time prior to epoch #1, going back to the dark pool days.

That aside, I think it stands on its own merits to incentivize DNs to register with this vote setting up the most robust DN network for 2.0 to build on. This is REN’s main (only?) competitive advantage over LayerZero at this point. Wormhole is trash tech but Jump provides a lot of ecosystem momentum. Still, not too worried about Wormhole as a LT competitive threat. LayerZero on the other hand is solid tech, composable, and also has significant ecosystem benefits because due to its investor syndicate that REN simply can’t match today. It’s going to be very difficult to compete with them, but one competitive dimension where REN can shine vs LayerZero is decentralization. Additionally, we need to grow the REN community. Ideally with long-term vocal members who can help bring attention to REN. This is the way we overcome the significant ecosystem advantages of both Wormhole and LayerZero. ‘If you build it, they will come’ is not going to cut it. Thus, for a number of reasons, I think it behooves the community to incentivize new DN operators with this vote.

I think you’re correct re: setting the quorum low. A ranked choice vote scheme, prioritizing 1st and 2nd choices should clearly indicate preference for prioritizing rewarding those in the RIP-018 snapshot versus prioritizing new DN registrations heading into 2.0.