RFC-000-026: Creation of a Ren Treasury Committee

Creation of a Ren Treasury Committee

Name: Ren Treasury Committee
Category: Governance, Treasury
Status: Draft
Scope: I propose we create a Treasury Committee to help guide the community on Treasury related issues, introduce Treasury related RFCs, implement Treasury related RIPs voted on by darknode operators, and provide timely reporting on the Ren Treasury to better inform the Ren community.

Definition of Terms

Just to avoid confusion, I think it’s important to clearly define the terms I will use in this RFC to minimize confusion or ambiguity:

RenVM or Ren. This is the network of darknode operators that make up RenVM, and who ultimately control the network. This post is on the Ren forum, for example. Note that RenVM can refer to both the collection of darknode operators and the actual network (blockchain) itself.

REN token holders. Anyone who owns REN tokens, whether they are locked in a darknode or not. Obviously all darknode operators are also REN token holders, but not all REN token holders are darknode operators.

Ren community. Anyone who is active in supporting Ren, interested stakeholders, partners, etc. You do not necessarily need to run a darknode or hold REN tokens to be part of our community.

Ren Labs. A separate entity under Alameda Research that serves as a service organization to Ren, provides continued maintenance and development of RenVM, builds applications that will run on RenVM to generate more income., etc. More on Ren Labs here.

Core Team. A group of developers, business professionals, admin, etc. that are part of Ren Labs, working within Alameda Research. Individual Core Team members may also be part of Ren through their operation of darknodes, but the Core Team is not under the direction of Ren governance, not paid by Ren, etc.

Ren Treasury. While there is no formal Ren Treasury, I will define it as all the money Ren has under its direct control to finance operations. Currently, that consists of one fund: the Community Ecosystem Fund.

Treasury Management. The structure, processes, people, etc. in place to manage the Ren Treasury.

Community Ecosystem Fund. Details here. This fund makes up the entirety of the Ren Treasury, currently 3.913 BTC at the conclusion of epoch 20, approximately 240k USD. There are no other funds under the direct control of Ren.

Fast Lane. Details here. An RFC discussing ways to make faster decisions about how and where assets in the Community Ecosystem Fund can be spent. As part of this RFC, I propose the Treasury Committee address the Fast Lane fund as part of the overall vision for our Treasury, not in an ad hoc fashion. More on that below.

Overview

What issues am I addressing with this RFC?

Having a well funded and professionally managed Treasury is critical for the long term success of Ren. We took our first steps with this with the passing of RIP-000-005, the Community Ecosystem Fund. As this is our only source of funds, the Community Ecosystem Fund today is our de facto Treasury. However, I believe there are challenges to our existing approach of using an “Ecosystem” fund as our primary Treasury, and the lack of a more formalized Treasury Management strategy within Ren, specifically:

  1. Is one “Ecosystem” fund the right approach? As noted, the entirety of our Treasury is one fund: the Community Ecosystem Fund. By its very name, this fund should focus on investments to develop a strong ecosystem of partners and solutions, typically complimentary to the scope of work performed by Ren Labs. And its quadratic funding mechanism is find for this purpose. But I don’t believe it was not designed to be the Ren Treasury per se, financing all of our operational needs across multiple categories (financial investments, RenVM marketing, community rewards, ecosystem funding, etc.). So either we expand the definition of this fund to include “anything that is beneficial to Ren,” making it our Treasury, or we move it under our Treasury, and determine what percentage of total Treasury funds should be allocated to community developmental projects. I prefer the latter option, but that is something a Treasury Committee should address with specific recommendations, and then darknode operators can discuss and eventually resolve through formal voting.

  2. What about implementation? We have discussed many issues related to Treasury Management or the need to fund various initiatives. We have passed one RIP to collect funds, and a number of RFCs touch upon Treasury. Examples include the “Fast Lane” fund, and the Incentives for Community Participation. And of course there are regular discussions about fee strategy, some of which have resulted in RIPs. There are many more issues, however, that have been discussed with no action, or simply haven’t yet been discussed through RFCs: investment strategies to generate yield on our existing Treasury assets, determining an optimal asset allocation strategy (currently almost all in just one asset, BTC, which is incredibly risky), preparing regular budgets, etc. A Treasury Committee could take ownership of these issues, facilitate community discussion, expedite voting, drive implementation, etc.

  3. How do we monitor performance of the money we are spending or investing? As we grow our Treasury, invest excess funds, create budgets, reward contributors, etc., shouldn’t we have timely performance reports? Isn’t this especially true as we approve grants to 3rd parties through our existing Community Ecosystem Fund, where we should expect progress reports, and ideally release funding based on specific milestones? A dedicated Treasury Committee could help with reporting, summarize the state of the Treasury on monthly community calls, etc.

  4. Aren’t we still overly dependent on the Core Team to push new Ren initiatives forward? I’m not just talking about issues related to Treasury. The current process seems to involve a Core Team member, usually @MaxRoszko, listening to community feedback on various issues (through Discord, Telegram, community calls, etc.), then finding someone to craft an RFC or RIP to address the issue, lead the discussion, etc. This is because we have limited structure to manage it ourselves, and hence become overly dependent on the Core Team to drive the agenda. While I appreciate all that @MaxRoszko is doing in this regard, I believe his role should be more as a liaison between Ren and Ren Labs. Treasury related issues are just part of that, but a critical part: without money to finance the many things we want to do, it’s difficult to maintain community focus, allocate resources, etc. So we are overly dependent on the Core Team.

We are beginning to create Treasury Management functionality within Ren in an ad hoc fashion, and the Community Ecosystem Fund is an example of that. While I think this fund is an excellent initiative, I believe its original scope falls short of what we need to do, even though it’s an excellent start.

I believe a visual representation of the current state of Treasury Management within Ren can be summarized as follows:

The recent Ren Labs announcement has, I believe, created an opportunity for the Ren community, and especially Ren darknode operators, to take more operational responsibility for Ren. The creation of a Ren Treasury Committee is a key step to properly finance those activities, long term.

What am I proposing?

I propose the creation of a Ren Treasury Committee composed of 5 Ren Community members, elected by Ren darknode operators. The initial committee should serve a limited time have have limited scope, with three primary functions:

  1. Develop a vision document for the Ren Treasury and Treasury Committee in the form of an RFC. This should include details on how we will manage our Treasury, budgeting process, reporting, how we will pay contributors, how we determine asset allocation, how to invest short and long term, etc. Also, what is the current regulatory environment, and how will that impact how we manage our Treasury?

  2. Review all existing RFCs that pertain to Treasury, and prepare RIPs as required to move forward and implement. This should include as a minimum the following RFCs:

a - RFC-000-018: ‘Fast Lane’ Community Ecosystem Fund - Requests For Comment | RFC - Ren Forum I believe the need to create a “Fast Lane” fund within the Community Ecosystem Fund is the result of not having a comprehensive Treasury Management framework in place. Instead of more ad hoc RIPs, I would prefer to see this functionality built into the larger vision for the Ren Treasury.

b - RFC-000-025: Incentives for Community participation - Requests For Comment | RFC - Ren Forum This recent RFC is, I believe, a critical component of Treasury Management. Specifically, I believe we need to reward community members who dedicate their time to advance Ren. And this should be part of our overall Treasury strategy, included in budgets, reported on regularly, etc. Having smaller teams or committees with budgets and clear scope of work will allow us to execute in a much faster way, and not just on Treasury related issues, but anything Ren darknode holders seek to build, budget, monitor, etc. But to summarize, I believe committee members should be paid from our Treasury, amounts of which should be approved by darknode operators as part of an larger vision.

  1. Create an RIP to implement the Treasury vision developed as part of the Treasury Committee’s initial scope of work. Once this is complete, the Committee should be disbanded and a new Treasury Committee formed, based on the vision outlined in the RIP, assuming it passes.

I believe the 3 items above can be completed within 3 months, with monthly update calls to the community to monitor progress. As part of their work, if the community believes some issues cannot wait, then the Treasury Committee should propose RIPs to address critical issues. For example, the need to diversify the treasury, or a solution to the “Fast Lane” issue already raised, if seen as critical.

To be clear, the ultimate control of all funds should, in my opinion, reside with Ren darknode operators. The Treasury Committee’s role should be to facilitate, inform, implement, and report on Treasury related issues to Ren darknode operators. As was noted in Aave’s own Treasury vision document, developed with the help of Llama:

The standard ARC and AIP process will be followed for all treasury management-related actions. Any code developed for managing the parts of the treasury will need to go through a review cycle before being implemented. Snapshot is to be used as a tool to gauge community sentiment towards particular ideas. This means that the Treasury Committee will have no direct execution power; the committee’s role would be purely advisory in nature and it is Llama’s intent that the committee becomes a trusted first point of contact for the community in all matters related to treasury management.

If the Treasury Committee has the power to spend, it should be within clear limits imposed on it by Ren darknode operators, who are the ultimate arbiters of the Ren Treasury.

One possible vision for the Ren Treasury could be the following:

In this vision, the Ren Treasury is where all rewards are collected to be distributed to other funds, committees, etc., as mandated by darknode operators. The Core Team is no longer driving most initiatives, but is working as part of the Ren community. In addition, one Core Team member is part of the 5-member Treasury Committee.

Again, this is just one possible vision, it’s up to the Treasury Committee to propose the actual structure based on community feedback, and Ren darknode operators to approve. I am only giving this specific example to stimulate discussion.

Next Steps

The most important next step is to create the Treasury Committee. I would propose a 5-member group for the initial committee, and as part of their mandate they can propose whatever number they want for future committees.

I propose four members should be voted onto the committee by darknode operators, and one member should be selected by the Core Team. Again, this is just for the initial committee, and future Treasury Committee composition can be changed as part of the overall vision approved by darknode operators. But we need to start with something.

We can create a separate RFC for Ren community members interested in being part of the initial Treasury Committee. Interested participants can post why they would like to be on the committee, relevant info, qualifications, etc., whatever they believe is important to disclose. Darknodes operators could then vote. The entire process should not take more than 4-6 weeks, and then the committee can immediately start work. Compensation for participation in the Treasury Committee could be voted on retroactively by darknode operators, if applicable.

Reference Material to Aid Discussion

Some may find the info below helpful as it relates to Treasury Management in general, plus community governance, including committee management. We don’t need to reinvent the wheel here, and should build on the work of other DAOs and protocols.

Treasury Functionality

The primary reasons for having a DAO Treasury, and how each relate to Ren, are summarized below. Much of this was taken from Llama, who specialize in Treasury Management for DAOs.

There are four major functions of a DAO Treasury:

  1. Spending. All of the fun things we want to do in order to grow Ren must be financed through our Treasury. This currently includes just one fund, the Community Ecosystem Fund. But while this fund began as a way to finance ecosystem projects that can benefit Ren, the discussion about how the money should be used quickly expanded into many other directions. Which is not surprising.

  2. Asset Allocation. Our current Treasury is mainly composed of one asset: BTC. While that has done well of late against the dollar, there are no guarantees BTC’s rise will continue. Typically a Treasury should be well diversified, with a mix of tokens, ideally structured in a way to support short term needs (finance grants, committees, etc.) and long term survival. Once host-to-host goes live, Ren should start to earn a much wider mix of assets. However, because Bitcoin will likely dominate our total asset mix for some time, we may want to consider ways of limiting our reliance on BTC. Asset Allocation also involves maximizing yields on existing assets, determine how much money should be allocated to strategic initiatives such as partner integrations, acquisitions, etc. Even purchasing insurance as part of our investment strategies. Lots of options about how we should deploy a well balanced Treasury to grow our assets and support RenVM long term.

  3. Borrowing. While is this not really utilized much (yet) within crypto, our large BTC allocation does give us some creative options to collateralize our primary Treasury asset for short term operational needs. This should be explored as part of a larger, Treasury Management strategy.

  4. Reporting. A critical component of Treasury Management. We should regularly update the community on the status of the Ren Treasury, and this should be reviewed on community calls. The Treasury Committee should also prepare annual and perhaps quarterly or monthly budgets for approval by darknode operators. The committee should also monitor the progress of grants and ideally release funds based on measurable progress, whenever possible.

The Community Ecosystem Fund partially addresses item 1, Spending. Over 95% of our assets are in one token: BTC. We are not earning yield on our assets, and reporting is quite basic. Currently we only track the total amount of the fund at the end of the previous epoch. Although to be fair, there is not yet much to report.

Further reading on Treasury Management and Governance

This is by no means a comprehensive list, but here are some interesting initiatives happening in crypto, as more DAOs start to think about what to do with their growing treasuries.

Badgers In the Sett: A DAO Treasury Retrospective (Volume 01) | by Mason Vollum | BadgerDAO | Medium Badger is, I believe, one of the best managed DAOs in crypto, and so it’s no surprise they are well advanced with their Treasury Management strategy, including reporting.

Llama - a hub for crypto community treasuries Still in its infancy, but Llama hopes to develop a comprehensive hub to monitor Treasuries across many protocols, develop best practices, etc.

Ryan Sean Adams: How DAOs should approach treasury management Great summary from Bankless on how DAOs should manage their Treasuries. This was also referenced above.

YIP-61: Governance 2.0 - YIPs - yearn.finance Yearn governance 2.0, an excellent model for delegating responsibility to smaller groups with clear scope, boundaries, etc., something similar to what I’m proposing for the Treasury Committee (and perhaps other teams, groups, etc. to follow).

8 Likes

Thanks for putting together such a thorough, and detailed RFC regarding the possible implementation of a treasury committee. Could we have a TL;DR version for those who may not have the time to sit and read through the entire proposal?

Just to add my personal thoughts to this, I’m naturally suspicious about the concept of ‘comittees’ and ‘councils’ due to the increasing centralisation with regards to decision making etc. Especially as we are trying to build a decentralised autonomous organisation. 5 people (even with limited powers) can be targetted, doxxed, susceptible to bribery/coersion for what power/influence they might have (not to mention risk of collusion etc.)

I know that I’m playing devil’s advocate here, but if five people are going to possibly be given elevated responsibility/authority over DNOs for treasury management/allocation - then a convincing, comprehensive list of exactly what such a committee CAN and CANNOT do would be ideal; a comittee ‘constitution’ if you will.

  • Who gets to decide on the diversifaction of assets?
  • Who gets to decide on strategies for growing the funds?
  • Who gets to decide the length of terms for elected committee members?
  • If the community wants one thing, can the committee potentially override them/us?

Regular reporting is a fantastic idea via the community call, and I was thinking that an online UI like the CC which could display all the treasury metrtics (spending, diversification etc.) would be great to look at now and then.

The road to treasury management will no doubt take a lot of time, ironing out, and voting etc. But this post has laid a solid vision of how this would look from the perspective of a committee implementation.

Great job and well written, thanks Defi Whiskey :+1:

2 Likes

This is a great RFC Defi Whiskey

I am in agreement specially because of, even the nature of a DAO is to coordinate decentralization activities, I do believe “this decentralization” shall come over time as we mature. At this point, some level of centralization is needed to kick off efficiently for good and stablish a good foundation for the years to come.

Transparency needs to be the first pillar of this treasury committee, as BlockchainBard already highlighted. There must be clear definition of what the committee can do and cannot, and approved by DNO.

1 Like

Fantastic work here @DeFi_Whiskey and thank you for putting in the time and effort.

I agree that a treasury committee is a good idea. However I think there are some other even more fundamental organizational pieces that would also need to be put in place so that this committee is in the best position to work for the highest and best interest of REN.

  1. I recommend that the committee we elect should have a mandate to follow that gives them the ability to act somewhat nimbly, yet limits the scope of their decision-making to a referendum-approved framework (Ie. a “charter” or “constitution”)
  2. I think committee members should be paid something for their time. Not an exorbitant salary but enough to compensate for the burden of extra responsibility
  3. Committee members should be verified DNOs and should be removed if they come to no longer operate any darknodes
  4. We should, in general, discuss if there should be other committees and how Treasury might fit into the mix.
  5. Treasury members should face regular windows within which a spontaneous vote by DNOs can remove or replace them.

We certainly want to avoid things that centralize control and in the spirit of the DAO, I think my main point is that we should be relying on a Treasury Committee for its loyalty and sound keeping with the best interest of REN. So I think the first step is really to build a solid mandate for said treasury to follow, so we don’t get any cowboys in there thinking we elected them to shoot from the hip and buy a bunch of $SHIB.

1 Like

Thanks for your feedback. I, too, am skeptical of groups and committees. We should tread carefully.

Decentralization is great, having such a large and active community is an advantage, but clearly some things can be accomplished more effectively in smaller groups. I suppose it’s all about finding the right balance.

And just to be clear, I am not suggesting we put the Treasury under the control of 5 people! As I noted above, I would view this committee as a facilitator. A way to move things forward faster. But all decisions should be voted on by darknode operators.

To give one example, if we are talking about asset allocation, I would see the role of the committee to provide recommendations (and reasons for those recommendations) to the larger Ren community, plus facilitate discussion in the form of an RFC, so we can all discuss, debate, etc. After discussion, the committee could prepare an RIP based on feedback. This would then be voted on by darknode operators. If passed, the committee would manage implementation, and later report on progress.

I could also see committees or smaller teams that have a mandate from darknode operators to manage a predefined budget for a specific purpose. So perhaps we have a “Community Rewards” team that has a budget to support and encourage community contributions. The quarterly or annual budget and scope can be approved by DN operators, but it’s silly for DN operators to approve every 10 USD allocation of REN tokens (if that is what we decide to reward) for each insightful post on the Forums or great comment in Discord or whatever…

  • If the community wants one thing, can the committee potentially override them/us?

In my opinion, the committee should have no power other than what darknode operators (note: not the community, but darknode operators) delegate to the committee. Under no circumstances should any committee (Treasury or whatever) have the power to override darknode operators.

3 Likes

Agree with all of this, with one exception. I don’t think committee membership should be limited to DN operators. I think the entire community should be eligible to participate, provided they are voted into the role by DN operators.

I think we have community members who want to do more, and working on a committee or team or group is an excellent way to contribute. Not everyone has the resources to own a darknode, but we can all contribute our time, effort, etc. to help Ren.

The only condition I would impose is each member should be voted into the role by DN operators. So long as they can get the votes, I’m totally fine with anyone serving on Ren committees.

2 Likes

This is where we can (respectfully) disagree. I am of the mindset that anyone elected to manage parts of the protocol/DAO should have a vested interest to the point where acting counter to the aims of RenVM and the DAO carry real and measurable risk. In other words, I feel safest when those who carry my delegated vote have as much to lose as I do.

1 Like

This is an excellent and timely article on Treasury Management.. It highlights some of the issues I tried to describe in my (unfortunately lengthly) initial post.

Interestingly, one of the main issues this article focuses on is the problem of native tokens. Specifically, most DeFi protocols have the vast majority of their Treasury assets in their native token. Funnily enough, we have the exact opposite problem: we have no REN tokens in our Treasury! That’s a bit crazy if you think about it, but it’s true. Ren holds zero $REN! :grin:

That is something we should probably fix as part of an asset allocation strategy. We should want to hold REN to use as rewards, for example. We should also be buying REN if we believe it’s undervalued relative to our existing assets, which in our case is primarily BTC. But again, only as part of a comprehensive strategy. If buying more REN dramatically raises risk, or impedes our ability to finance development of our ecosystem, we should avoid.

We are also in a unique situation regarding expenses, as the Core Team is not paid through the Ren Treasury, but by Ren Labs (which is not part of Ren). Yes, we are partners, our success is linked to them, their success is linked to us. Which is why as part of a Ren Treasury strategy we should ask for more info on their Treasury strategy, and we should coordinate closely with them. This is why I suggested having one Core Team member on our Treasury Committee. Can Ren Labs operate in a multi-year bear market? I hope the answer to that is yes, as the future of RenVM may depend on it. :scream: More details would definitely be welcome.

2 Likes

This proposal sounds very inclusive. Will have a thorough look. :+1:

Great to see such a well thought out proposal, thanks for putting this together @Defi_Whiskey!

It took me some time to digest all of this and do the required background reading, and all I can say is that I wholeheartedly agree with this proposal. I don’t agree with the fear that has been voiced here and in Discord about centralization. We need dedicated members driving a particular work item or proposal, be it elected or otherwise, to drive them to completion successfully and do the required legwork to come to the best decision/outcome.

This proposal does raise some questions on how the community governance over Ren is supposed to work, now and in the future, in conjunction with the Ren core team and Ren Labs which is apparently bankrolled by Alameda.

To me it seemed like the simple Community Ecosystem Fund was set up as a way for the community to get some play money, get our toes wet with regards to DAO governance and the funding of cummunity/3rd party initiatives. This proposal for a comprehensive treasury management strategy leapfrogs this entirely, that does not have to be a bad thing of course, as long as we are not putting the cart in front of the horse that is.

That being said, we cannot start soon enough thinking about our treasury vision, and above all the risk allocation.

2 Likes

The fact that we do not have any REN in our treasury is an interesting conundrum indeed.

I’ve been breaking my head a little already thinking about this. Since the whole point of the treasury is to run and grow the protocol, it seems important that we also hold REN so the treasury can grow with the token appreciation. However, buying REN from the market and driving up the price without running any nodes lowers the ROI for new Darknode operators, and does not increase the TVB by as much as when actual nodes would be operated with said REN. In that sense it seems like it is counter to our protocol security. Then again, if the treasury is an acyclical trader of REN we might dampen the market down turn a little and prevent TVB from falling more than it does :thinking:

Additionally, the fact that all our tokens are outstanding and none of them in control of the treasury also makes it more difficult to take advantage of easy ways to align incentives with our partner DAOs and integrators. Namely using token swaps, as for us it will be that much harder to get hold of our own tokens, it will be more difficult to match their contribution.

About time we launch renREN and start accumulating automatically :grin:

2 Likes

I couldn’t participate in the community call today but watched the video and I already commented how I could imagine we can create a working DAO structure here: RFC-000-025: Incentives for Community participation - #42 by XTC0r

After some more thinking I created a draft to visualise how it could look like. I imagine a two step scenario. First where the treasury committee controls most of the funds and later we move to a structure with different working groups.
The open question for me is: Who controls the actual treasury wallet or have can we release the funds after a positive snapshot vote? Do we need the REN core TEAM?


It was decided to use Safesnap as treasury management system, see RFC-000-024: Community Ecosystem Fund | Governance & Safekeeping

This means the Ren Core team does not need to facilitate and move funds out of the treasury after a vote. The treasury is on-chain in a Gnosis safe and we can use a Snapshot vote to move the funds. This means we also do not need to move the entire budget for a specific committee to a multisig owned by said committee because the committee as well needs to create snapshot votes to spend the budget.

The only exception is when we want to give the committee full control and discretion over a particular budget so they can spend it as they see fit, for example if they plan to dish out many small amounts and we do not want to bother DNOs with votes on each and every one of them.

1 Like

The issue I see is we have to vote too often or have to transfer too much money in one shot when going the path with different working groups.

Let’s say we have working group for SW development and they want to create a dapp which would benefit the REN ecosystem and they budget 120K$ over one year for it. After DNOs approved to spend this money I would not like to send the total 120K$ to them and also don’t like the idea to vote every month to send the next 10K$ batch to them. Rather the 120K$ should be locked in a multisig specific for this project and the reoccuring 10K$/per month should be released by the treasury committee (TC) (without additional DNO vote).
Also the TC should overwatch the project of this working group and put up a vote to stop the funding (multisig veto) to return the funds of the project multisig to the treasury if the development does not work out like stated in the original proposal.

I see the TC as a steering comittee which overwatches the acitivites of different working groups. Each working group will have separate projects and each project within a working group a specific funding (multisig). The TC has to approve the regular funding of the working group activities.

2 Likes

Reoccurring payments is actually an interesting case. Here it might be suitable to create a quorum vote for Darknode operators to approve the grant, and use Snapshot votes structured using the “rule of non-opposition” principle to release the recurring payments. The latter votes are non obtrusive for DNOs as they can generally ignore them, unless they want to oppose the transaction.

This has the added benefit that the funds stay in the general treasury as long as possible, making it easier to perform treasury management in accordance with the asset allocation and risk management strategies.

Again, I would avoid to put too much votes on DNO and think it’s better to put 4-6 people in charge to do regular payments and parts of once agreed grants. These 4-6 just need to get verified by DNOs every 3? months. This trust has to grow over time. So we might want increase the funds over time.

Maybe you can share a flow chart what you imagine or can directly comment on certain points of my (1) intermediate solution chart and second step chart (2) using working groups. Explain what you don’t like and how you would change it.

It’s a very interesting RFC, thanks’ for bringing the topic up. I will provide my thoughts on this.

I don’t see why we couldn’t pay anyone to create a proposal to get voted on. Why do we need a committee, if it’s to reward for contributions then why can’t we just reward anyone that wants to contribute.

I watched the call, all the traditional finance people thought they would be best suited, but that’s not how you build a team. Are any of these traditional finance guys real business or technology managers?

Why give power to the few when we can give power to anyone that has a sensible proposal. I think an easy to use voting UI could be very powerful for engagement across the community.

my thoughts are to grow the treasury for at least 12 straight epochs, in some way reinvest back into Ren for yield, cap the participation of the fund to 5% of the total staked so that the community fund never overtakes the community itself, and have a committee meet 3x/year (like every 4th epoch, or maybe just 2x per year) and discuss spending/investment opportunities of the community fund that would be of benefit to the Ren community.

Great proposal @DeFi_Whiskey, thanks for writing it up. I believe such a committee will be helpful in the long run but IMO it is too early to consider establishing it at this point, especially if members are to be financially compensated purely for belonging to the committee.
I think we should keep things more nimble for the first few initiatives instead of trying to impose the structure in advance. I also think that work relating to pushing forward proposals etc. can be better compensated as part of the individual proposals, rather than a salary. If a superstar emerges from the community we could certainly vote to allocate them a salary to continue their work, but doing so for a group - in advance of any initiatives being completed - feels premature to me.

First I need to apologize for spamming the discord discussion (as “olchemist”) before reading this. All of my own ideas are already mentioned here. Special thanks to @DeFi_Whiskey

Maybe there is a lesson. Our community is spread across this forum, TG, discord channels, etc. with little sync. It is difficult for initiatives to precipitate into action.

I feel the same is also true for funding activities. I understand the critics of centralisation and we definitely should stay nimble for the moment. BUT it’s not like there is a ton of engagement asking for community funds yet. I feel we need a dedicated group that feels the responsibility to facilitate and kick off this process.

Once it’s rolling, we can always reconsider.

Looking forward to the call tomorrow.