RIP-000-005: Launch a Community Ecosystem Fund

Name: Launch a Community Ecosystem Fund
Category: Treasury
Status: Final - Accepted
Scope: Launch a Community Ecosystem Fund governed by the Ren community, financed by RenVM fees, used for investing in the Ren ecosystem


The proposal builds on the discussions held here:

We propose to empower the Ren community to start growing the Ren ecosystem without the core team’s direct involvement, through the launch of a Community Ecosystem Fund. This fund would be governed and managed by the Ren community, and could be used for anything Ren related that the community deems important. The goal of the Community Ecosystem Fund should be to further the growth of the Ren ecosystem, such as promoting or sponsoring the development of integrations of RenVM or Ren-wrapped assets.

The funding for the Community Ecosystem Fund would come from the fees generated by RenVM, incentivizing the community to govern the Ecosystem Fund wisely such that it may grow the Ren ecosystem and hence increase the volume through RenVM. The target should be to over time return more than the funds spent on ecosystem growth, by influencing increased volume for RenVM, which increases the rewards to RenVM / the Darknode operators. In that way the Community Ecosystem Fund would over time start funding itself indirectly.


Currently, there is no community treasury to fund Ren ecosystem development. The most common way other crypto organisations fund ecosystem development, is through token inflation, or through fees. Given that all REN tokens are circulating, and that there are no plans to introduce inflation as it would affect the security design of RenVM, the way to finance a Community Ecosystem Fund would naturally be through claiming a small portion of the rewards being generated by the RenVM network. For instance, Yearn Finance has a 2% management fee on all vaults, and a 20% performance fee that is taken out of all the profits [source]. These go to the Yearn treasury, which pays for developer wages, audits, etc.

Note that this proposal does not suggest that these rewards would go to the Ren team, or that the Ren team should receive grants from the Community Ecosystem Fund, given that the Ren team already is funded, and can in the future also be funded by setting up Darknodes. The proposed Community Ecosystem Fund that will be financed by RenVM would be managed by the Ren community, which in turn should invest using the Fund in the Ren ecosystem, ultimately increasing the volume through RenVM, which benefits the Ren community and Darknode operators, and other ecosystem participants as well. These funds can be spent however deemed fit by the community (described below), but should not be spent on core protocol development, as this is already funded by the Ren core development team.


A new fee tracking program is being written (directly into RenVM) that, among other upgrades, includes a governable parameter for setting how much of the rewards could go to a Community Fund (this can be set at 0%). This parameter would be governable by the Ren community, and could be changed anytime through a proposal. We propose to initially set the reward percentage going to the Community Ecosystem Fund at 5%, for reasons discussed in the corresponding RFC thread, although in the Snapshot vote that is coming out after feedback has been received can and will include other options as well. Also keep in mind that any funds going to the Community Ecosystem Fund could be sent back to the Darknode operators if the community wishes to do so, through a proposal.

Custody of the rewards can be held by RenVM itself, which saves us the trouble of setting up a multisig (at least for the time being). Given that RenVM is in the process of decentralizing, the custody risk will diminish over time just as the custody risk for all assets held by RenVM will diminish over time.

We suggest to measure community sentiment for which proposals should get funding through Snapshot (or alternatively through Scattershot which is a 1:1 fork of Snapshot and allows distributing one’s voting power amongst multiple choices, which is also already live), which since RIP-004 is the official voting mechanism for community governance. The Snapshot/Scattershot tool only takes into account voting power from Darknodes, and squares the voting weight by how long a Darknode operating address has been registered.

We suggest to initially structure the grant-distributing activities of the Community Ecosystem Fund in a Gitcoin-like fashion, in this case with advertised funding rounds that occur quarterly (how often these rounds occur are governable by the community). In this way, the community gets time to come up with multiple good ideas and proposals before a funding round takes place, and then every Darknode operator has a chance to weighs-in on and together filter which proposals are the best of the best, using the quadratic funding model similarly to Gitcoin (we recommend reading Vitalik Buterin’s take on it: We believe this to be a fair mechanism which lets everyone have a say, without taking up much of everyone’s times, while also being less centralized than a committee.

After the funding round votes have taken place, the payments would flow from RenVM directly.

The exact details of how many proposals get to take part in the funding rounds, how to filter out spam or obviously bad/harmful proposals, and the duration and frequency of the funding rounds, are still to be decided by the community, but the proposal on the Community Ecosystem Fund itself can still go ahead before that.

In short, this is our proposed initial structure:

  • Funding is according to the quadratic funding model, i.e. multiple proposals compete for funding at once and funding success is determined by the voting distribution square rooted
  • Funding occurs quarterly
  • Funding requests must specify an Ethereum (or other supported chain) address to which RenVM will send funds
  • Funding requests must specify a target amount. If less than the target amount ends up being allocated to the request (in accordance with the quadratic funding), then the funds are returned and used for next quarter. If more than 200% of the target amount ends up being allocated to the request, any excess is returned and used for next quarter

Note that if the community wishes to change anything about this structure later or wishes to propose a vote that leverages capital in the Fund irrespective of these kinds of Gitcoin-like funding rounds, that is all possible through the regular governance process, i.e. by creating a proposal.


  1. Vote on the proposal
  2. Develop, test, and audit the new fee tracking program, and then migrate the Darknodes to it [wip]
  3. Plan and organize the first funding period [todo]

This would be great for funding community marketing efforts and helping spread awareness etc.

I think logically, the natural first step would be for the community to compile a list of solid use cases and examples of where such funds could be used. The community could even vote on their top 3 favourite suggestions etc. So when funds are allocated we have a clear vision of how to use them wisely.

Will the vote be held here or in the Command Centre? How do we ensure that those who vote are genuine members of the community and not just randomers creating new accounts on this site?


Using Snapshot! RIP-000-004: Add Snapshot as a signaling mechanism for RIPs

Only darknode owners can vote.

1 Like

For those wondering why there isn’t a vote for this proposal yet, is because now according to RIP 004, a proposal should be open for feedback on the forum for 3 days before posting the official vote for it.

So I will put up a Snapshot vote and share it here in 2 days unless a huge debate breaks out that needs to be solved :slight_smile:


Thanks Max, this looks like an impressive implementation!

I’ve spoken to RV and we’ve re-worked the suggestions thread for allocating funds:

Community members can submit their ideas there now :point_up:


Hi everyone!

First off, thanks for your work Max.

Although I do agree with all the details stated in this post, I think we should make some changes in the very near future to the specifics once it has been launched.

Here are two of the points I would change and why:

  1. Funding occurs monthly/bimonthly instead of quaterly - One of the problems of this space is that it moves too damn fast. No one could have predicted that BSC was going to become such a behemoth in such a short period of time. Having monthly or bimonthly funding would have allowed us to fund an integration or a rewards campaign much faster. For example, the 1inch BSC reward pool could have had $20k from 1inch, $20k from the Ren team, and $20k from the Ren Ecosystem Fund making it more attractive to bring in capital and bootstrap minting/burning.

  2. The rewards percentage for the community ecosystem fund should be 10%-20% instead of 5% - Again, because this industry moves so fast, we should be more aggressive in the collection of funds for our community. We will be funding lots of ideas and I believe we have already missed some crucial time. It is important to note that these funds can always be distributed back to darknode operators as stated by Max.

On another note, I also propose to add a “vote” tab under that directs you to Snapshot or Scattershot as soon as this is approved by the community.

Looking forward to launching the Community Ecosystem Fund ASAP




Agree on both points.

  1. Quarterly is just too much, we have to react fast, new projects popping out every few weeks. IMO we should sync it with epochs, so every 28 days would be perfect (2 epochs max).

  2. We could start with 10%-15% to push funding more ideas but I guess this number should be voted by operators before the launch.

1 Like

@JBMasterCrypto could you make a poll and see what the community in general thinks about how often it should occur?

And yes I believe we can implement a custom URL for our voting space!



Thanks for the RIP.

  • How much in USD would 5% be at the current numbers?
  • Is the decision snapshot or scattershor already taken?

The Snapshot/Scattershot tool only takes into account voting power from Darknodes, and squares the voting weight by how long a Darknode operating address has been registered.

  • Is there a max. voting weight after a DN was registered for time x? So that there is no difference between DN’s online for >3months vs >12months and only <3months gets less voting power?
  • I’m also in favor to have the rounds every month and increase the time window afterwards if neeeded.

Going by last epoch it is about 75k usd

1 Like

Can you explain how this works exactly? Are the funds at an address for which the private key is held by RenVM, and the team / graycore will be able to move these funds at the conclusion of the community vote?

Is there a way for RenVM to deploy the collected assets into lending protocols? We have the new Rari RenVM pool, and as Ren assets get added to more lending platforms, we could spread the assets out.

Wholeheartedly agree with both of these points, quarterly is too slow.

1 Like

Pinging @loong for some details

1 Like

Yes. Particularly getting some treasury funds into the Rari pool would be a very good use-case that would bootstrap liquidity for the pool and even earn yield from borrowers, so it’s an obvious winner imo.


I don’t mind either option on point 1, I agree that quarterly is the rational way forward but I also recognize the anxiety waiting times can create in a community, we still want the community to remain as active as possible and this is a fast moving space.

EDIT: thinking more about this I think frequency of rounds should be higher during bullruns (monthly/bimonthly) and then lower frequency to quarterly when people calm down a bit during bear runs. We see how fast the space moves and many communities do amazing things, I see a lot of potential in this community with really cool members and would like to see it unleash the potential at max capacity hehe

As to increasing the 5%, more money does not equal more success, I see no rush in increasing this until we see great proposals having insufficient funds. Keep in mind, governance can always increase the % later, and as enthusiastic community is I feel it would be prudent to take things step by step to show respect to node operators (since they pay)


Just to understand this process a bit better, will the discussions/proposals be on the forum? Where and how are funding rounds structured? My assumption was discussions in forum that lead to RFC → RIP → SnapShot/ScatterShot but now I’m slightly confused how that will work with “rounds” :slight_smile:

If discussions start in forum that eventually lead to RIP I find it hard to believe there will be any spam to be honest, it’s quite a bit of work to present a well structured RIP (and thanks Max for setting a good standard, the effort is recognized).

In regards to how many proposals I’m having difficultty understanding why there should be a limit, hmm… Was thinking any RIP will go to vote and either get rejected or funded according to the quadratic model as described, either way a proposal cannot get more than 200% funded. And I’m assuming an underfunded proposal could have another round of voting through a second RIP, especially if idea is good but timing wasnt good first time.

Sorry if this discussion is a bit premature, I’m trying to keep up with the pace things are moving now lol, great to see the activity picking up in the community!!

Yes agree and this is a good example of a scenario where I think community could get frustrated with waiting 2-3 months to get the funding out to the Rari pool, it’s a quite straightforward proposal that I imagine won’t have/need too much discussion around. If the community agrees within 1 week and then have to wait 2.5 months I could see a lot of nonsense fud arise. Just my 2 sats

1 Like

Anything that can be done with crypto-assets can be done by RenVM with these funds. IMO, I see deploying capital to liquidity pools (and earning the interest) — as well as setting up liquidity mining programs — as a major use case for these funds.


The funds will be within RenVM itself. The way the new fee system will work is that the fees will no longer be placed into an Ethereum smart contract. Instead, they’ll be minted nowhere and placed into a RenVM smart contract (which, tbh, is also awesome that we can do this now with v0.4). So if someone mints 1 BTC on Ethereum, 0.0025 BTC will be placed into a special smart contract within RenVM and minted nowhere.

When governance decides what (and where) it wants to deploy these fees, RenVM can mint the fees wherever it is being instructed to do so by governance. In the same way as normal minting works. This means it is also capable of directly calling smart contracts on other chains!

Interestingly enough, what we will end up with is a decentralised community fund (as in hedge/quant/VC fund, not just lump of money fund) that can do anything a centrally controlled fund can do. It’s more powerful than a “traditional DAO” because it has a private key in its control and can access lots of different chains.