RFC-000-018: 'Fast Lane' Community Ecosystem Fund

[Sabobi]

Name: ‘Fast Lane’ Community Ecosystem Fund
Category: Treasury
Status: Draft
Scope: Launch a fast lane grant system for the Community Ecosystem Fund

Overview

This RFC should be seen as an extension of RIP-000-005 and a discussion board to iron out details over the possibily of having a fast lane for proposals to Community Ecosystem Fund where no extensive discussion is needed and the community quickly can deploy funds.

The following description goes under the assumption that you have already read through RFC-000-016 and RIP-000-005, this RFC should be focused on the structure of the fast lane and what parameters to be set when deployed.

Background

There is now a general agreement over the structure and purpose of the Community Ecosystem Fund as proposed and discussed in RIP-000-005 which the ren team is now working on and will deploy in combination with the launch of RenVM v0.4 (which can be expected in May). Together with this Snapshot there is now more clarity over the structure of the Fund and how many % of the DN rewards that should be allocated.

For proposals to have enough time to go through discussions, vetting process and allow the quadratic voting model to give reasonable results and accrue enough funding the frequency of quarterly funding will be implemented initially.

One interesting point that came up in the discussions was the frequency of the funding and its limitations, which raises concerns for proposals such as bootstrapping liquidity to pools such as Rari where no extensive discussion is needed to come to a conclusion but rather a general/simple voting process where community decides details (eg. amount, length of process etc).

In light of this the suggestion of having a “fast lane” came up with the intention to address proposals which could be deployed faster to increase efficiency and impact. The ideas in here will need to be ironed out and later refined into a RIP before implementation, discussions and suggestions are therefore highly appreciated to speed up the process.

Details

The main component to understand is the structure of the Community Ecosystem Fund which can be reviewed in RIP-000-005, also suggest reading this post by Loong to understand the technical details around where the funds will be stored. In essence the revenue allocated to the Community Ecosystem Fund will not be minted anywhere but stored on renVM smart contracts until the community decides to spend from the fund which then can be done on any chain connected to renVM.

My understanding is that this fast lane grant system will have its own structure and will be separate from the “main” Ecosystem Fund where quadratic voting and quarterly frequency applies, appreciate if the Ren Team can correct me here in case I am misunderstanding.

As this RFC should be considered a draft it is important that the community clearly communicates in the responses exactly what they feel should be changed and how the proposed change should look like. The faster we can come to an agreement the more time and earlier possibility for the Ren Team to deploy.

I personally see following key components that should be agreed upon before this RFC can even begin to evolve into an RIP and from there a Snapshot could be setup to vote for final shape/structure:

• The frequency of fund deployment (weekly/bi-weekly/monthly/bi-monthly or other suggestions)
• The % of Community Ecosystem Fund that should be deployed to this fast lane (25%/50%/75%)
• Conditions or restrictions the fast lane should have (eg. funds should not be used to fund big projects or proposals that require extensive discussions, in essence this should not be a method to avoid the quarterly process, there should be rules of what kind of proposals that qualify for the fast lane)
• Voting strucure (should quadratic funding model be used on the fast lane as well?)

I will try to post a brief summary of what has been discussed in this RFC after approx. 1 week and possibly setup an informal vote which can lay the groundwork for the RIP.

Implementation

1. Discuss details and agree on structure and parameters
2. Informal vote to gather sentiment over parameters and details
3. Open a RIP with final details and implementation model
4. Setup a Snapshot vote
5. Ren Team work their magic

[DeFiFrog]

I suggest we brainstorm as a community the different categories/respective allocations of these categories to create a budget. Let’s think on what we’ll use the money for as we add structure.

What do we have in mind for a fast lane fund? I personally don’t find many things super urgent that requires a fast lane other than deploying a % of the fund towards, for example, new farms to generate a treasury.

Most other options I think fit fine under the normal governance procedure.

[martign0]

I suggest a board to take the decisions for the fast lane fund. The board would represent the community and only the agreed proposals approved by the board would be executed. This would make the process much quicker, which I think is important in crypto. Candidates could post its interest to be part of the board thru RFC and final members be selected by the community thru RIP

[Khattab]

I definitely agree with the general objective here. The quick pace of crypto in general, and the even faster pace of DeFi, really makes it critical for us to react quickly to emerging opportunities. Time is of the essence. A Fast Track program is something I would love to see. Agree that a smaller group of trusted individuals, represented by senior team leaders and trusted members of the Rari community, could be entrusted to make these decisions. We would need clear guidelines on criteria and scope of decision-making, which i believe is also being proposed here.

[DeFiderek]

@Sabobi

• The frequency of fund deployment (weekly/bi-weekly/monthly/bi-monthly or other suggestions)
• The % of Community Ecosystem Fund that should be deployed to this fast lane (25%/50%/75%)
• Conditions or restrictions the fast lane should have (eg. funds should not be used to fund big projects or proposals that require extensive discussions, in essence this should not be a method to avoid the quarterly process, there should be rules of what kind of proposals that qualify for the fast lane)
• Voting strucure (should quadratic funding model be used on the fast lane as well?)

Monthly I think would be suitable for the fast lane fund. I don’t think anything needs to be super fast even supplying liquidity or liquidity mining rewards don’t need to be any quicker than a month and that will most likely coincide with how the rewards may be shared from the pools and when they would finish. So at the end of the month we decide do we keep funding x pool with rewards or do we add funds to another pool for the next month.

I think initially we could go with a higher weighting for the first few months like 50% deployed to the fast lane but then reduce this down to 25%. I am conscious about not too much of the fund being used for liquidity mining and more being used for the quarterly projects/ dapps being built as I think this is going to benefit the ecosystem more. So the more the rewards increase the smaller the allocation should get.

I think the main things the fast lane fund could be used for are bootstrapping liquidity where needed for example rari capital cross chain pool supplying stablecoins so people can get loans, or liquidity mining rewards for Ren asset pools. I can’t really see many other reasons why we would need a fast lane as I think apeing in to new project/dapp ideas monthly is risky. We need more considered time to get proper proposals from developers.

Happy with the quadratic voting system.

[BlockchainBard]

Brainstorm ideas for Darknode Community Fund

I am in favor of governance capture. I do think there’s some things to consider though: Approach: how much governance should we capture? A simple vote initiation isn’t much. So to me it seems a protocol like bancor would demand a huge amount of capital purchased at full price for a small percentage of say. Trust: how sure are we that the governance token controls the protocol? In most cases governance tokens are primarily profit shares and secondarily governance control. At the end of th…

Have you checked out this thread? There’s some interesting discussions happening here regarding fund allocation and uses etc.

[Supremacy141]

Just adding thoughts here but I think if we are considering fast tracking - rebuying REN in the open market when there are irrational price drops & APY rises above a certain threshold (maybe +12-15% APY?) should be seriously considered at least for a portion of community funds. (Maybe 10%?)

Not to retire/burn REN but just to add to treasury to deploy in the future. Mr. market can be irrational at times so we should take advantage of that. (Would need to figure out how we calc specific threshold but fast tracking makes sense so it happens seamlessly without short term traders front running)

honestly that APY should be our required return hurdle to deploy capital to new projects and would like to see at least an attempt to provide est ROI for new projects (est new run rate volume by end of yr 1 x mint+burn fee / total costs?)

I’m sure there are lots of projects out there that offer +20% potential returns and all for spending money on them but want to make sure we are spending $ wisely.

[Alexander]

@Sabobi

For proposals to have enough time to go through discussions, vetting process and allow the quadratic voting model to give reasonable results and accrue enough funding the frequency of quarterly funding will be implemented initially.

When writing a RFC mentioning a RIP that has yet to be decided, please refrain from making assumptions. The funding frequency has yet to be decided. It is highly likely another vote will be launched where we settle the matter of funding frequency.

The specifics for a fast lane depends on what funding frequency we settle on.

Assuming a long funding frequency, I will give my opinion on the parameters you suggest.

@Sabobi

• The % of Community Ecosystem Fund that should be deployed to this fast lane (25%/50%/75%)

From my point of view, the fast lane should be a way for a single project to circumvent the larger funding mechanism. Thus a certain percentage of the total ecosystem fund is not the way to do it.
It should instead be possible to acquire as much funding as is needed. (Within reason of course)

@Sabobi

• Conditions or restrictions the fast lane should have (eg. funds should not be used to fund big projects or proposals that require extensive discussions, in essence this should not be a method to avoid the quarterly process, there should be rules of what kind of proposals that qualify for the fast lane)

A project applying for the fast lane, should set their needed funding amount, e.g: $20000.

@Sabobi

Voting strucure (should quadratic funding model be used on the fast lane as well?)

Via setting a fixed amount of funding, it is possible for the community to either decide for or against funding it. Either you get nothing or your wanted amount.
Quadratic funding does not work in the presence of no other projects.

To ensure quick and semi-secure acceptance of projects, a super majority system could be used instead of a %quorum. That would allow for one wealth darknode hoster to shutdown the project immediately.

[Thomm]

Nice one getting the ball rolling on this one @Sabobi!

---

@Sabobi

The frequency of fund deployment (weekly/bi-weekly/monthly/bi-monthly or other suggestions)

I would suggest to not have a set frequency at all, but instead allow any proposal at any time. If there are two great proposals to incentivize a farm within a certain time period, it should be up to the discretion of the community to accept both of them.

On the other hand, I can understand that for process reasons we might want a fixed cadence, in that case I would be in favor of the shorter frequency: 1 week.

@Sabobi

The % of Community Ecosystem Fund that should be deployed to this fast lane (25%/50%/75%)

I agree with what others have said above, that it should not be required to have a separate allocation to the fast lane. It can just come out of the main fund at the discretion of the community.

That being said, I agree with the following:

@Sabobi

Conditions or restrictions the fast lane should have (…) in essence this should not be a method to avoid the quarterly process (…)

There should be some strict rules to prevent every proposal to simply try the fast lane first before applying for the regular process.

As pointed out by others, we have not been able to come up with a big list of usecase that would qualify for the fast lane, so a simple list of allowed proposals could work here. The list can start out small, e.g. only allowing the incentivization of farms. This can of course be extended later through an RIP.

[Thomm]

@martign0

I suggest a board to take the decisions for the fast lane fund. The board would represent the community and only the agreed proposals approved by the board would be executed.

Personally I feel every proposal should be put in front of the community. We should however factor in the time it takes to vote, when deciding the cadence of the fast lane.
Hence I argued above for a very quick cadence (one week) or no fixed cadence at all.
According to our goverance rules, a proposal should be up for 3 days, and snapshot vote takes 5 days, on a weekly ‘fast lane’ cadence the whole process would take at most 2 weeks. Which should be quick enough in my opinion.

If it takes much longer, it might be sign that the proposal does not belong in the fast lane at all. Either its too complex, community cannot come to sensible parameters in time etc.

[Thomm]

@Alexander

A project applying for the fast lane, should set their needed funding amount, e.g: $20000.

(…)

Via setting a fixed amount of funding, it is possible for the community to either decide for or against funding it. Either you get nothing or your wanted amount.

Agreed, just just like regular proposals contain a funding amount:

@MaxRoszko

• 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.

This does beg the question, how do we deal with situations where a majority of the community is in favor of allocating funds to a proposal, but there is no majority for the specified amount of funds that the proposal is asking for?

The current situation on the snapshot vote for the funding allocation on RIP-000-005, is an example:

Multiple voting rounds can be a solution, but might not be the right fit for the fast lane.

[MaxRoszko]

Here’s my take on things:

@Sabobi

• The frequency of fund deployment (weekly/bi-weekly/monthly/bi-monthly or other suggestions)

We could perhaps weekly summarize/list proposals that can and are under consideration, and perhaps only vote weekly at set times (obviously skipping out on weeks where there isn’t anything to vote on), to have a kind of regular structure Darknode operators could get used to, a ‘governance heartbeat’.

I’ve never encountered a situation where there has been less than 7 days of notice to deploy funds somewhere to accomplish something (ignoring investing/buying tokens). But also don’t see a point of having a fast lane that isn’t able to act within 7-14 days.

A weekly heartbeat would be easy to follow and could coincide with a weekly email report or something.

@Sabobi

• The % of Community Ecosystem Fund that should be deployed to this fast lane (25%/50%/75%)

I think it’s wise to start with some budgeting rules simply so we don’t end up eating up all the rewards too quickly and not having anything for the large funding rounds which are better able to fund stuff like development of new applications/projects. And we could at anytime shuffle funds within the two different budgets and vote to change the distribution, so 50% would be a safe bet which we can adjust later.

@Sabobi

• Conditions or restrictions the fast lane should have (eg. funds should not be used to fund big projects or proposals that require extensive discussions, in essence this should not be a method to avoid the quarterly process, there should be rules of what kind of proposals that qualify for the fast lane)

The point of the fast lane is to capture opportunities that are time-sensitive, that’s the major guiding principle I think. If the idea is to fund the development of a new application, that might as well for example wait 1 month for the next quadratic funding round, a request for the fast lane should be declined imo. But of course if something could immediately provide more value to RenVM, it might make sense to fund it immediately.

@Sabobi

• Voting strucure (should quadratic funding model be used on the fast lane as well?)

The voting structure couldn’t be quadratic if there only is one option, so my initial thinking is to simply keep each proposal separate, as I can’t imagine us regularly having 2 or more time-sensitive proposals per week. So having a ‘yes/no’ with a set amount requested seems simple enough, but I’m open to suggestions of course.

[Sabobi]

@Alexander

From my point of view, the fast lane should be a way for a single project to circumvent the larger funding mechanism. Thus a certain percentage of the total ecosystem fund is not the way to do it.
It should instead be possible to acquire as much funding as is needed. (Within reason of course)

I’m not sure this will be technically feasible, for the quadratic voting on the “main” community fund to work properly you can’t have the pot getting drained while the voting is in play. If the main community fund will have quarterly funding then you can’t remove liquidity from that fund while different proposals are being voted on.

It would therefore make sense that the fast lane is a separate pool from the “main” community fund. For that reason I think we have to set a percentage so the ren team can program the parameters at which rate the two community funds are funded.

@Alexander

Via setting a fixed amount of funding, it is possible for the community to either decide for or against funding it. Either you get nothing or your wanted amount.

I personally agree with this

[Sabobi]

@Thomm

I would suggest to not have a set frequency at all, but instead allow any proposal at any time.

This is an interesting point imo, wonder if there will be any technical setbacks with this approach? I can’t think of any if the fast lane fund is completely separate from the main community fund. Would love to hear opinions from other community members on this point actually.

@Thomm

I agree with what others have said above, that it should not be required to have a separate allocation to the fast lane. It can just come out of the main fund at the discretion of the community.

I saw @Alexander mention this as well, I would love to understand in more detail how this would work? Let’s say you have only one fund, there are some projects on that fund waiting for the quadratic voting to take place, as that is taking place you will have a ‘fast lane’ vote which will drain the community fund while another projects vote is taking place.

I must be missing something cause this to me seems like every proposal will aim for the ‘fast lane’ option to achieve funding as soon as possible and at the same time more serious proposals with longer voting times and longer discussions might suddenly face lack of funds if the fast lane votes have approved other projects in the meantime and drained the community fund.

@Thomm

so a simple list of allowed proposals could work here. The list can start out small, e.g. only allowing the incentivization of farms. This can of course be extended later through an RIP.

I feel this is a good approach

[Sabobi]

@MaxRoszko

to have a kind of regular structure Darknode operators could get used to, a ‘governance heartbeat’

I think this is a reasonable approach if we decide on fixed frequency, could also incentivize DN operators to be more active in general.

[Alexander]

@Sabobi

I saw @Alexander mention this as well, I would love to understand in more detail how this would work? Let’s say you have only one fund, there are some projects on that fund waiting for the quadratic voting to take place, as that is taking place you will have a ‘fast lane’ vote which will drain the community fund while another projects vote is taking place.

The reason we are discussing a fast lane is because of the volatile nature of DeFi. Allocating a certain amount of funding to the fast lanes, creates the idea that the volatility is already known.

Because of that, I am strongly against allocating a certain percentage of the funds to the fast lane. Funding should instead be on case per case basis.
This is a more effecient allocation of funds as in cases of high volatility, the quadratic voting scheme (and lets be real) is more focused on funding long term time-independent projects. When the market is fast moving, these projects are often not appreciated to the same degree which our treasure should reflect.

When a project choose the fast lane, the outcomes are known ahead of time. It is either nothing or a fixed allocation. This can be anticipated ahead of time by projects participating in funding rounds.

The alternative also means spending 100% of the community treasure every funding round, which I am not sure we have agreed on.

@Sabobi

I must be missing something cause this to me seems like every proposal will aim for the ‘fast lane’ option to achieve funding as soon as possible and at the same time more serious proposals with longer voting times and longer discussions might suddenly face lack of funds if the fast lane votes have approved other projects in the meantime and drained the community fund.

If we set a requirement for the fast lane to be super majority (2/3 or 3/4) agreement, the fast lane only becomes feasible for known good projects. This also gives wealthy darknode holders the ability to (almost) veto any fast lane project. This makes the fast lane a much more difficult way to get funding.

When choosing between the fast lane and the funding rounds a project also have to consider the risk/reawrd associated with asking for a specific amount of funding. If they need $20000, but $40000 would provide a lot of value, asking for $40000 through the fast lane in more risky than applying for $20000 via a funding round and acheiving $40000.

Summary

If you have a popular project that could benefit from extra funding apply via a funding round.
If you have a small project applying via a funding round is less risky than the fast lane.
If your project is unpopular with a small portion of the ren community apply via a funding round

If your project is time sensitive apply via the fast lane.

[Sabobi]

@Alexander

Because of that, I am strongly against allocating a certain percentage of the funds to the fast lane. Funding should instead be on case per case basis.
This is a more effecient allocation of funds as in cases of high volatility, the quadratic voting scheme (and lets be real) is more focused on funding long term time-independent projects. When the market is fast moving, these projects are often not appreciated to the same degree which our treasure should reflect.

I could be very wrong of course but my impression was that the quadratic voting structure for the community fund has gone through RIP005 and is being implemented. For that reason we have to allocate fast lane funds separately, no?

Maybe @MaxRoszko could correct me if I didn’t understand the situation incorrectly…

@Alexander

The alternative also means spending 100% of the community treasure every funding round, which I am not sure we have agreed on.

Im not sure why you think this means 100% of fast lane funds have to be spent. Fast lane fund can have same structure as main community fund with the exception of quadratic voting not being needed. So there is definitely no need to spend 100%…

[MaxRoszko]

@Sabobi

I could be very wrong of course but my impression was that the quadratic voting structure for the community fund has gone through RIP005 and is being implemented. For that reason we have to allocate fast lane funds separately, no?

Im not sure why you think this means 100% of fast lane funds have to be spent. Fast lane fund can have same structure as main community fund with the exception of quadratic voting not being needed. So there is definitely no need to spend 100%…

We have established that there will be a community fund, and that there will be quadratic funding rounds, but governance has not established how much of the capital in the community fund should be spent on the funding rounds.

We definitely do not have to spend 100% of the community fund on the quadratic funding rounds, there can and perhaps should be limits. At least everyone should know where we stand on it.

Likewise if a fast lane grant system is implemented, it makes sense to know what our limits if any are. Whether this limit should be independent of the currently undecided limit for the quadratic funding rounds, or the limits should be decided upon jointly, is up for debate. I personally do not have a strong opinion on this at the moment.

[Sabobi]

This RFC has now been up since April 22, feels like 3 weeks should be enough to gather comments. I will try to post a brief of the discussions so we can take this further to a RIP stage.

• Suggestion to form a board who would represent the community where only proposals approved by this board would go through. This would probably need a separate RFC to decide rules as well as form an election process and nominate members of the board through a RIP.

• There should be a strict vetting process to ensure fast lane serves the purpose of time-sensitive proposals. Certain rules to be set, such as only allowing certain purposes for applications through fast lane fund (eg. incentivization of farms, LP’ing to bootstrap new integrations etc).

• Proposals in fast lane will put forth their needed funding in fixed amounts (eg. $20,000) and governance will through off-chain voting (Snapshot) decide with simple yes/no options, all or nothing.
  The quadratic model will be applied to main community fund (RIP005) where quarterly rounds ensure enough discussion ahead of decisions, time-sensitive proposals should be directed to fast lane.

• Two main models for fast lane fund structure:

1. No specific % or frequency is set, as long as the funds applied for in fast lane do not exceed funds reserved for in the regular quadratic funding rounds this model should work fine.
2. A specific “limit” is set in % to cap expenditure through the fast lane (majority leaning towards 50%) with a weekly frequency (monthly also suggested).

• Two models for voting structure:

1. Regular 50/50 model with yes/no options and simple 51% majority sufficient to get proposals through.
2. A super-majority required (2/3 or 3/4) to disincentivize attempts to circumvent the regular quadratic voting structure on a quarterly basis, only clear and time-sensitive proposals should go through fast lane. This way proposals for bigger amounts benefit more from the quadratic quarterly model (h/t to @Alexander for this novel solution).

Please let me know if anything is misrepresented and I’ll be happy to adjust the summary. Maybe also worth putting up a small poll to agree on fast lane and voting structure (two last points)? I don’t mind setting up the poll if community finds it useful. If not then I will just include both options to be decided upon in the RIP.

I will leave this open for comments until next week, if no objections then I can put forth a RIP to get the ball rolling as we slowly approach the launch of Community Fund.

[shiny]

I am in favor of some degree of fast lane allowance. Time sensitive opportunities should be available to take advantage of.