RIP-000-018: Ren 2.0 funding and Ren Foundation

Name: Ren 2.0 funding and Ren Foundation
Category: Governance, funding
Status: Proposed
Scope: Set up a Ren Foundation and mint new Ren tokens to it, such that the Foundation can fund Ren 2.0 development and its ecosystem growth


After discussions within the Ren community held in RFC 37, 45, 46 and 47, and the Ren Discord server, there is currently a rough consensus on how to move forward with funding and transitioning to Ren 2.0, and providing a way to incentivize Ren ecosystem growth. In this proposal, a vote is put up to decide whether to set up a Ren Foundation and mint new REN tokens to it. To maintain the 10,000 darknode limit, the darknode bond would need to be increased in line with how much REN is minted, and a portion of the minted REN would then go to current registered darknodes to allow those bonds to be carried over to the Ren 2.0 network. After the Foundation is set up and the token contract is redeployed with tokens allocated to the Foundation, the DAO and the Foundation would need to allocate a portion of the tokens to continue funding Ren 2.0 development.


For information on the need to transition to Ren 2.0, please review the announcement regarding Moving on from Alameda. For background on early discussions on the topic of incentivizing Ren ecosystem growth, please review RFC-000-037.

For background on the three recent funding proposals:


The proposal is that the Ren DAO will vote on whether to mint new REN tokens to the Ren Foundation, and decide how much to be minted in that case, to be used for funding development and ecosystem growth. To avoid introducing changes to the current darknode limit of 10,000 nodes, the darknode bond would need to be increased in line with the new total supply. Therefore it is also proposed that current registered darknodes (roughly 2,000 at the time of this proposal) are not diluted, by receiving the amount of REN needed to roll over their current node bonds to the new network.

Vote options

For the vote, five options are presented for how much new REN would be minted to the Ren Foundation, to cover current and future funding needs:

A) 50M
B) 100M
C) 150M
D) 200M
E) Reject

The darknode portion of these numbers are included, meaning that if for example 100M REN is the final result, each darknode would receive 10,000 REN (100M / 10,000 node limit), and the total amount going to the Ren Foundation would be 100M - (2,000 nodes * 10,000) = 80M.

The weighted average of the voting power allocated towards options A) to D) will be the final amount to be minted to the Ren Foundation, meaning that each vote influences the final decision, and that the amount can be a non-round number such as 123.45M. If more than 50% of the voting power select option E), the proposal is rejected.

Token lockups

It is proposed that the tokens minted to the Ren Foundation are not locked, to give the Foundation the flexibility to impose lockups when it is doing fundraising or grant payouts with the community’s best interest in mind. It is, however, recommended that the Foundation imposes lockup conditions on all allocations, whether to darknodes, investors, or the development team.

Token swap

The safest way for the Ren community to switch to a new REN contract is for there to be a one-way token swap contract deployed at the same time as the new REN contract is deployed, that could be used at any time by anyone to swap current REN tokens to the new REN token, without any time limits. This ensures that users as well as exchanges and DeFi projects which have integrated the REN token are not being rushed to migrate to the new token, so that there are no risks of funds being lost.

Setting up the Ren Foundation

Given that setting up the Foundation is an “off-chain” event, members of the DAO who wish to partake and potentially be part of the Ren Foundation would need to come forward and begin organizing as to who and how the Foundation should be set up. It is suggested that the community forms a working group or something similar to be able to accomplish this task in a timely manner. The DAO can get support from the development team as to how to get started on the practicalities.

The rough cost for setting up a Swiss Foundation is 100,000 CHF in total, which is roughly $107,000 at current rates.

Funding Ren 2.0 development

Following the legal set up of the Ren Foundation, it would likely need to conduct a raise to fund continued development of Ren 2.0. This could involve a portion of the inflated tokens being sold at a discount to investors. The Foundation and the DAO will be the only entities that decide how much and when to fund Ren 2.0 development, not the development team. Funding and budgetary considerations would need to be discussed and negotiated at the earliest opportunity.


  • Vote here: Link
  • If approved, the DAO would formally start the process for setting up the Foundation
  • REN token contract redeployed
  • Foundation to fund continued development of Ren 2.0

Voting link

Snapshot: Snapshot

  • what is the time estimated to have the foundation set and running?
  • Can be please shared whatever work has been done already on the most recommended structure to be implemented?
  • Has been any legal recommendation?
  • I assume that tokens will not be printed until foundation is set? Can you please confirm?

This would depend on us for the most part. We’d need to write a RIP, arrange voting for the Foundation members, write foundation’s statutes, goals etc. Then comes the registration stuff…

And regarding registration and all that legal stuff, setting up with all papers ready can take less than a month (I’ve seen info stating 1-3 weeks).


i think i am for given the time constraints. my critique is that redeploying ren as another erc20 in the big picture doesnt make complete sense if it will then need to move again to be the native token of its own l1 later too. i wanted the bridge to stay token capped and deploy a new erc20 or native gas token for the l1 which couldve been used for funding, but i realize this contract couldnt even be ready in time even if people did like the idea. so for this reason i think this proposal is reasonable giving the sudden and shocking liquidity crunch no one saw coming.

We need to know the development costs to make any decision. Only you and the team know how much money you need to achieve milestone 1,2,3,4,… etc.
We don’t know how much people are working on it, what their salary is and which external contracts we have to pay.
Please provide us with your planned budget to fund the REN development in the current state and a range to hire more devs. Like +2 devs = 2x120k$ per year


I take issue with the “current registered darknodes” stipulation. In the chaos that followed the announcement that Ren 1.0 would be sunset and that the new network would take its place at some point in the future, some long-term node operators (like myself) may have begun to deregister nodes. Some days later we learn in this proposal that our bonds will be inflated down for not remaining active in a lame-duck network.

It was only natural to assume that we would unbond our ren from the first network at some point and then bond again to the new and upcoming network. And now getting a head start on that will cause some of us to have to go buy more ren to participate?

I would also like to see a budget from the developers and proposed payroll going forward.


Thanks @MaxRoszko for the RFC
I personally think this is the right way to go and we should have at least 15-20% inflation for the following things.

  • Incentives for 3 developers

  • Increase the team significantly with very talented developers. So that development speed really picks up in all areas.
    The competition does not sleep and comes up with interesting solutions in all areas.
    In the end, network effects count and we absolutely have to get them with the first mover advantage.

  • All future node operators should get an AirDrop at the beginning of Ren 2.0 when it is still all on the test network and also at the beginning of the mainnet as an incentive because at the beginning the volume will not be so high.

  • I definitely want only the best for Ren 2.0 and would like Ren 2.0 to become the main solution for all large and important cross chain applications.

Stay all strong and healthy :heart:

1 Like

Agreed. More generally I take some issue with shielding operators from inflation at all. I feel like we should all be willing to share the burden to fund the team. Some more on my thought process in the post linked below and I welcome others to chime in too.

@MaxRoszko scanning the different proposals there are still a lot of questions unanswered. Can we have a live Q&A to answer the questions of the community before we move forward and conclude voting on this proposal? Seems like the least we can do on such an important inflection point.


With deregistering nodes, you were willingly abandoning voting rights.


Yes well, at the time it was beginning to look like voting rights on V1 would no longer matter.

I seconds this:

It should be clearly stated that

  1. The additional tokens go to the Ren Foundation (not the team!), which should decide upon how they’re gonna spend the fund in accordance to the long-term outlook for the project.

  2. Hence some sort of budget proposal would help us decide how much would be needed to pay for

  • current operational cost
  • Ren 2.0 development

Any further expenses should be decided by the community on an individual basis. (Including grants for expanding the eco system, once deployed)

Without some actual numbers, it’s quite hart to gauge which level of funding is actually needed/reasonable.


true. i was kind of surprised all options had it for dno.

Although some have already voted, can we make this a simple vote for funding through inflation, and then later have a vote on how to deal with tokenomics such as total node count, airdrops to dn holders, deflation, etc.?


Following my “budget” question:

Could you give us some rough outline on what kind of benefits/perks each tier has? How many more developers, for example?

Also: I’d like to see some additional detail on how this minting event will be done.

Could we spread out token creation instead of one big minting event? (which will most likely lead to a big price dump; preferably tied to reaching milestones)

1 Like

It’s not “tiers” in that sense. Regardless if say 100M or 200M is minted, hypothetically the Foundation might only be willing to provide 50M for Ren 2.0 development initially after a budget proposal is presented.

The allocation to the Foundation is meant to sustain itself for many years to come, and should definitely not all be spent on development.


I believe in the inflation shielding for DN ops, but should it be a lump sum? Or maybe we reward $REN to Ren node operators and spread this allocation slowly over years.

If funds are minted with the creation of the foundation, we can chose how dev is funded as a next step.

We should mint a full 20%, this gives the DAO the most flexibility on how to move forward and it’s enough we don’t ever need to consider this again. we can always chose to burn later.

1 Like

I think that’s the completely right approach.

Especially with the point for the AirDrop that we distribute it gradually to the dnos. So that everyone continues to run dnos for as long as possible.
In the end, it can make a big difference if we are one of the most decentralized platforms.

Without the lump sum, DN owners may not have or want to risk the additional funds to establish the DN on the new network

1 Like

Yes but we also need to put conditions on it like vesting periods so that we can make sure that there are enough dnos from the launch of Ren 2.0.
This is extremely important that we are very decentralized so that developers will build on Ren 2.0 at all.

It isn’t clear in proposal if the new token contract will allow future mints.

I would suggest to ensure the new token contract does not allow mint (even with a multisig/foundation setup).

This would solidify the fact this mint is a one time event due to Alameda collapse and will improve 2.0 security (no mint bug risk, no price discount due to unclear/uncapped max supply).

Even better if the contract is fully immutable overall (no admin controls! would be a centralization risk).