RFC-000-046: Transitioning to Ren 2.0

Thank you Max,

  1. I think is time to put a target date when proposals will be ready for voting (RCF45, 46, 47), as well as rules to normalize the proposals.
  2. What is the timeline for Ren Foundation? what is needed from the community? What are we waiting for, at least, to start coordination. I understand that funding needs to be decided for this, but we could begin coordination.

My issue is DAO is not formalized, no clear structure, so, everybody is waiting for others to complete tasks.


Fully agree. The only reasonable path to take is the one proposed in this RFC (046):

  • 12.5% inflation under DAO control
  • Spin up Ren 2.0 in the shortest amount of time
  • Fund grants for developer on Ren 2.0’

Is the team able to write a RIP with as much details as possible ASAP?


Please inflate away, we need to transition as quickly as possible. Darknode Operators should get some form of vested compensation.


Have simple 12.5% inflation or more + compensate darknode holders

Done. Let’s vote already

The other RFCs for funding are stupid and complicated when funds are already running out.


How do we get the vote rolling for the RFC on the table here?

If there is a motion to vote, I’ll be more than happy to second it and get this moving along.


Agreed. I am in support of holding the vote as well.

1 Like

Im sorry if my idea has been proposed already before. I didnt read all comments yet. Heres my take:

  1. Ren dev team should sum up needed funds
  2. Ren team loans this amount from 3rd party with interesting interest fee.
  3. Ren keeps percentage of darknode income and uses this to repay the loan.

This way we dont have to mess with the tokenomics. The devs must be paid, there is no free lunch so this is the most straight forward way.
We should all be able to see the operating costs and the percentage held of the darknode should be dynamic; no more then to cover costs.

Where can we get this loan you will ask?
If we have a clear picture of the needed funds and roadmap, the lender can be paying for the few months until launch. I cant imagine this amount to be extraordinarily high, as its just a few months of dev work. For the future we can be settled by the solution stated before. I can provide funding like this if the majority and devs are aboard.

1 Like

A few updated thoughts.

My goal in the last few weeks has been to make sure the community exhausts all of its options and makes the most informed decision possible. Since inflation is within our control, it has always been the easiest option to execute and fall back on, so it made sense to do proper diligence on all of our options. Now that we have, it’s clear that a modified version of RFC 046 is the best way forward.

Labs’ risk tolerance is simply too low at the moment to entertain or help with a fundraise for a new token. There’s no Foundation yet, and the DAO in its current form couldn’t legally or practically lead a fundraise, let alone in a few weeks. While layered security would unlock the most secure versions of RenEVM and RenBridge and would not have delayed 2.0 at a technical level, fundraising on the premise of it would have. But the enthusiasm for it as a feature — independent of RFC 047 — makes me hopeful that it’ll be supported as a security option for RenEVM apps in the future.

If RFC 046 turns into a fundraise around Labs’ token grant (which is a new development and not part of this RFC) in conjunction with operators receiving their proportion of inflation and increasing the bond size for future nodes, that would be a winning proposal. The DAO should stipulate that any tokens sold to investors be subject to long-term, on-chain vesting with a one year cliff. Those tokens would need to be sold at a discount, so on-chain vesting with a cliff would verifiably prevent arbitrage and short-term selling and align us with longer-term investors. It may be better for Labs to do that upfront all at once than for the Foundation to provide quarterly grants, because those would each need to be sold off to fund operations, while on-chain vesting with a cliff could raise cash without creating short/medium-term sell pressure. It is worth confirming if the Ren Foundation were able to custody the funds raised and still provide quarterly grants to Labs in USD.

Operators would need to vote to receive their proportion of inflation to offset REN dilution and to increase the bond size for new nodes to offset revenue dilution. Without both, operators would be diluted of REN and/or their revenue.

Since we’re starting with ~2k nodes, the new bond size would need to be increased by slightly more than the inflation rate for operators to not be diluted. For example, based on a 12.5% token print, then if the bond size were increased to 112.5k REN with a 1.125b supply and exactly 2k existing nodes, there would be a maximum of 10,222 nodes, which would be slightly dilutive.

((1.125b - 200m) REN / 112.5k bond) + 2k existing nodes = 10,222 nodes

To enforce a maximum of 10k nodes, the bond size would need to be 115,625 REN:

((1.125b - 200m) REN / 8k new nodes) = 115,625 REN

Thanks to everyone for participating these last few weeks. Now let’s get 2.0 out. :tools:


Great recap of the concerns. Agree with your points.

Would like to also ensure a rough $ target for the raise and a rough budget to be stated in the proposal, so we know how much runway the raise will provide and clear out concerns about “discount” (if any!).

1 Like

When the requirements for running a node in 2.0 come out, there will likely be a bit more expertise and cost involved and we will probably have a smaller total node count

1 Like

While I agree with the overall premise of introducing inflation to fund the next phase of development, I disagree with the mechanic of requiring a manual vote for DNOs to have their REN bonds adjusted. This would be unfairly dilutive of DNOs who may have funds in transit, are unaware of the vote requirement, or have already withdrawn their bonds in anticipation of REN 2.0.

I think a better mechanic would be an automated airdrop to wallet addresses that have a) been bonded to a darknodes for 2 of the past 6 months and b) currently hold at least 100,000 REN. The full balance of said addresses should be adjusted by the inflation percentage.

This airdrop would ideally take place after the REN 1.0 sunset is complete and all DNOs have had a chance to withdraw, but before the REN 2.0 launch.

This would reward DNOs who have been recently active and who demonstrate continued intent to support the network by having not sold off their REN.


double air-drop for those over a year :grin:

what would be good to know – if I could stack on a couple more nodes, would it be more beneficial before the 1.0 sunset or after? My exchange holds for a week before I can transfer. So if I could hit the next epoch, would it be worth it to bond some more at 1.0?

Anything we can do to automate would be beneficial for owners.

Like the above proposal, but want to avoid a situation where a loyal DN 1.0 operator cannot afford a DN 2.0. Let’s say everyone is short just a few % to build their next DN2.0. This creates short term price spikes as we rush to buy REN esp now that there is less exchange liquidity to buy REN.

Achieving DN1.0–>DN2.0 parity (perhaps an easy migration tool or smartcontract?) might be best. Any inflation just increases the amount required to setup new nodes for future owners. (But DN 1.0 ->2.0 nodes don’t require buying more REN to top off.)

BTW is there an easy way to make a new Darknode DNT token? 1 token = xxxxxx REN fully bonded. Maybe this could help migration somehow? It could have other uses for 2.0 as well … :slight_smile:

I think Max already relayed the DNO process would essentially be automatic.
You don’t need to deregister, buy new Ren2.0, and then register new nodes.

What would be cool is the existing nodes getting an inflation adjusted airdrop to maintain percentages (or an option for adding ‘free’ node).

Is there some technical reason I’m missing for why we want to shield the operators from any dilution?

At the end of the day, if we go this route, then we choose to generate capital from all holders by diluting the supply, basically levying a tax on all through inflation. Usually a characteristic of inflation is that it hits everybody equally, sharing the burden equally so to say. If we selectively exclude one demographic, then the other side of the coin is that we actively select another demographic to carry a larger burden. The kicker of course is that the token holders do not even get to have a say in this, so it will be the operators choosing to dilute the token holders. Not only will they get diluted, those saving up for nodes will be hit by a double whammy because now they will also need more tokens to run nodes in the future. This just leaves a bad taste for me, and I don’t really see the point except pure self preservation from operators, unless I’m missing something.

Also it just feels odd to now require an odd amount of tokens for a bond (e.g. 115,625 REN). How will this work with the burn mechanisms that have been suggested, do we decrease the bond again?

The 10,000 nodes was always just a magic number that felt like the right ballpark as explained by the founders. A much more elegant approach seems to be to keep the bond at 100k, do not compensate operators for dilution as this would dilute the supply even more, and simply allow there to be slightly more nodes in the future. Would it really be a problem if there are 10-15% more potential max nodes? Only about ~20% of possible nodes are ever online anyways, this means operator profits will already be diluted less than token value.

Last point, did we consider potential negative side effects of airdropping tokens to a subset of the holders? To me airdrops always seem to have negative externalities in that you get a tragedy of the commons type situation where it will be in your interest to dump the airdropped tokens on the market before the inflation is fully priced in. I suppose this is counteracted by the fact that there can be a lock-up period, and operators will need these tokens to keep running their nodes, but this too just feels like unnecessary complexity without much benefit to the project.


Honestly this reasoning does not fully cut it for me @Arviee, if we believe in the continued success of the project and the team then we should be willing to fund it. Not choose others to fund it for us.

Using this reasoning it should not matter that operators would be inflated, right? Lets keep it simply, inflate everyone equally and get it over with. Not need for additional complexities such as airdrops, bond adjustments, lock up periods etc…

I’m coming around to your reasoning Thomm. If anyone gets diluted, EVERYONE should get diluted.

Otherwise you get the faint smell of greed disguised as “rewarding the loyal…”

As if anyone still holding a large stack of REN right now is just in it for speculation. This will anger a lot of community members who get left out.

1 Like

I think anyone who wants the airdrop should commit to running a node for a year, regardless if they are currently running one or it’s a new registration. Airdrop in 30 days. If you don’t want to commit then pay the extra.

Alternately, I suggested in Discord we still limit total darknode count to 10,000, bonds are still 100k, and the extra tokens not allocated to nodes will just offset the added demand inflation will have on the protocol. Either we devise a method to burn them over time, or by the time they are all in circulation the ecosystem should be healthy with a strong need for gas and many holding Ren simply for gas and investment.

Then become a DNO and vote for it :wink:

Have been since epoch 6 bro