RFC-000-029: Establish a CEF Yield Ops Multisig Group

Requests For Comment | RFC
1

Name: Establish a CEF Yield Ops Multisig Group
Author(s): Maximilian Roszko (@MaxRoszko)
Contributors: Various community participants (Discord)
Category: Treasury, governance
Status: Draft
Scope: Establish a Multisig group to handle the operational task of implementing community-approved yield strategies to grow the Community Ecosystem Fund

Overview

There have been open discussions within the community since November on establishing the treasury management part of the developing Ren DAO. The ultimate goal is to have the Ren community and Darknode operators leading and governing RenVM development and its ecosystem. Proper treasury management is key to ensure these goals are reached successfully. This proposal aims to tackle a key part of treasury management, which is establishing a process for deploying idle funds within the DeFi ecosystem to gain yield which can be used for Ren ecosystem development in the future.

It is timely to start setting up such treasury procedures because according to the Ren Core team, the ability to transfer stored funds in the CEF to any arbitrary address whitelisted by the community will be released in January. That would for the first time give us control over those funds which strongly suggests we should be prepared to make use of them as soon as it is possible, as money idle is money wasted. The appropriate thing would be for the Ren community to approve some kind of yield strategy, and prepare the operational side, such that when the funds are available to be moved, for instance the $BTC in the form of $renBTC could quickly be deployed into a Curve pool or a Badger vault, to grow the CEF holdings.

The operational side of that, such as sourcing ETH to pay for gas fees, swapping assets, contract approvals, and depositing, harvesting, and withdrawing assets, is logistically impractical to have all be handled through on-chain governance. We propose to establish a community-governed multisig, whose only task is to implement a yield strategy that has been approved by the community. Such a multisig would be much faster (as opposed to using Gnosis Safesnap voting) at deploying capital according to some yield strategy, as well as withdraw funds from a pool or smart contract in case there is any risk of exploits, or the funds needing quickly to be used for some other purpose.

This proposal aims to establish a multisig that handles that operational side. The initial members of that multisig group would have to be approved by the community. The proposal also lays out some initial yield farming strategies which the community can provide feedback on and potentially decide on a preferred one, or turn down all of them in favor of more research.

Background

For full context on this proposal, please refer to the Treasury Working Group Calls as well as the #treasury channel in Discord and the belonging subthreads, especially the #Working Group Structure and #Overall Yield Strategy.

The Community Ecosystem Fund (CEF) has ~$330,000 (mainly in $BTC) at its disposal currently, capital the community can allocate for investments in the Ren ecosystem, incentivizing DAO growth, as well as use for growing the CEF itself. This Fund has remained untouched since the launch, only growing every epoch, due to a missing technical feature allowing those funds to be moved from the RenVM smart contract they sit in, to any arbitrary address whitelisted by the community. This technical feature is finished now per the Ren Core team and will be deployed in the next RenVM release, which is scheduled for the beginning of 2022.

At this point in time, the only approved spending of the CEF is through Funding Rounds, which are quarterly grant sessions similar to Gitcoin Grants. For Ren Funding Rounds, proposals are gathered ahead of a voting session that takes place quarterly, where the Ren community can distribute their votes among their favorite proposals, and where the final results determine which proposals if any pass and how much funding they would receive.

While Ren Funding Rounds can be very flexible in their use, there are other categories of financial activities that would benefit from a dedicated structure in place. One such activity is incentivizing the Ren DAO growth. A properly organized and incentivized DAO can bring much more long-term value to the Ren ecosystem than any single proposal receiving funding.

Another clear task, which this proposal is focused on, is growing the CEF itself, especially during times when funds would otherwise be unutilized and not providing any value. Utilizing the DeFi ecosystem to do treasury growth is the obvious choice here, where funds can be deployed into liquidity pools or vaults for example to earn yield which can be harvested and brought back to the CEF.

There are many possibilities when it comes to growing the CEF, given the diverse set of strategies possible within the DeFi ecosystem, and it will require diligent research to find the most appropriate strategies for the Ren DAO, balancing risks, reward, boosting liquidity within the Ren ecosystem as well as using partner protocols. This proposal only includes a selection for a first initial strategy to deploy, but it will take organization and perhaps a dedicated and incentivized working group to work out the best strategies for the Ren ecosystem overall and to help ensure the CEF continues growing.

And to be clear, this proposal does not aim to change the structure of the CEF itself, and it does not suggest how the DAO treasury overall should be managed, and it does not alter the yet to be implemented Safesnap-controlled CEF which has been approved by the community already.

Details

Multisig structure

We propose to set up a Gnosis Safe multisig, with 4 out of 7 signers required to submit a transaction. This balances trustlessness with execution speed. Given that there are only 7 seats and there might be more community members wishing to be a part of the multisig, there will likely need to be some kind of election. Here is a list of initial members who have offered to be part of the signing set:

  • Arviee [Arviee#0151]
  • Liberty [Mr. Moonbags#5982]
  • pcheng [pcheng#0373]
  • MaxRoszko [MaxRoszko | Ren Labs is hiring#1898]
  • Renfield [Wheeler#2382]
  • Seeking Knowledge [SeekingKnowledge#6454]
  • dudeseeg [dudeseeg#8329]
  • Wes [WesĀ²ā™œā™œā™œ#0001]
  • Thomm [Thomm#7650]

Members who wish to be added to the list can announce that either in this thread or on Discord.

Requirements: be available to sign transactions and coordinate with other members in the multisig regularly. This is a big responsibility as it means a person in the multisig group cannot go off-grid for weeks or go on a long vacation without bringing their private keys with them and able to attend to multisig tasks. It is also a strong recommendation that everyone in the multisig group makes use of hardware wallets to secure their private key.

Privacy: the rough consensus currently is that there is no need to KYC members joining the multisig, because this isnā€™t a process that can be done in a decentralized fashion at the moment and it exposes private information about members which could be used against them. There was a suggestion that someone on the Ren Core team such as Max can do quick one-on-ones with everyone up for the election, to vet and make sure the person is ā€˜realā€™ and that there isnā€™t a person that is attempting to join with multiple account into the multisig. It has also been suggested that anyone up for voting has to submit a ~100 word blurb to introduce themselves.

Roles: there was a suggestion that one seat in the multisig group should be for a Ren Core team member, to make sure the multisig can coordinate with the Ren Core team better in case it is needed. There is potentially also another important role for someone with technical expertise (comfortable working with for instance Brownie, Truffle, Hardhat, ape-safe) to help out with technical steps regarding multisig transactions in case it is needed if there is no simple UI method to accomplish some step. And it would be beneficial for the rest of the community if there is someone in the multisig group that acts as a representative of the group, able to answer questions for the rest of the community and able to present tasks that have been accomplished by the multisig in the broader community calls.

Mandates: as already mentioned, the members in the multisig are only permitted to sign transactions according to some community-approved yield strategy. Darknode operators will have the responsibility of voting members in and out of the multisig, as well as dissolving the multisig if that is the consensus. But given that we donā€™t have a governance mechanism for forcing members in and out of the multisig (there might be some technical trustless process for this in the future), there needs to be careful consideration of the members added to the multisig so no takeover is likely.

Yield strategy

The rough consensus currently is to deploy $renBTC into a Badger vault, or to deploy manually into the same Curve pool being used in the Badger vault, and manually manage the yield farming through the multisig. One thing to consider currently is that Badger vaults donā€™t support Gnosis multisigs yet, but according to mitche50 from BadgerDAO it might be ready by the time we have the multisig deployed and funds from the CEF ready (mid to late January).

The first group of proposed strategies are based on depositing into the ibBTC / crvsBTC LP vault on Badger, assuming we can actually deposit into them by the time the multisig group is ready. This strategy balances risk/reward well, while maintaining $BTC exposure and utilizing our core partners which is Curve and Badger. But we would also need to consider whether to aim for boosted yield by staking $BADGER or $DIGG. Since we donā€™t have those assets, we would need to swap some of the CEF funds, which means we change our price exposure from only $BTC to these other assets as well. $BADGER is the governance token for BadgerDAO, while $DIGG is a rebasing token linked to the price of Bitcoin. Boosted rewards are additionally paid out in $BADGER.

Alternative 1a: 0% boost
Alternative 1b: 50% boost, 33% exposure to DIGG/BADGER
Alternative 1c: 100% boost, 50% exposure to DIGG/BADGER

An alternative (and can also be considered a backup) is to manually farm the same underlying Curve pool by depositing directly into Curve:

Alternative 2: Manually deposit $renBTC to the same Curve pool that the Badger vault utilizes and harvest yield regularly but not too often to minimize gas costs

A third alternative that has been discussed is whether we would like to diversify the $BTC into $ETH and USD, and in that case the Tricrypto pool on Curve is a great pool to park those funds and harvest yields as well:

Alternative 3: Split our $renBTC into $ETH and USD as well and deposit into the Tricrypto pool on Curve Ethereum

Implementation

  • Review and improve the proposal with community feedback
  • Publish a RIP when the details are finished
  • Vote on Snapshot
  • Deploy the Multisig
  • Whitelist the Multisig address in RenVM by Ren Core team
  • When the Multisig receives funds, deploy according to the approved yield strategy
9 Likes
2

Thanks for writing everything together!

Iā€™m glad we move forward to establish the multisig finally!

Rgarding Yield farming options:
My vote goes for 3 followed by 2. I would like to avoid exposure to DIGG / badger.
3 is my favorite as I think ETH and BTC are both very solid assets plus USD (or any other stable coin) make up for a good diversifaction for any direction the market goes.

3

Thanks for putting this together Max. One thing I think we could add is that we contributors to the Governance chat threads felt that, where we are staking Treasury funds for yield farming, we really want to be aligned with our partners and Greycore members. We want to make sure the community knows this was discussed at some length in the calls and pretty much everyone agreed that keeping the Treasury inside the REN ecosystem should be a requirement.

Also, something I just thought of, we could include a ā€œrisksā€ section, such as one sees on an investment memorandum. Some risks include:

  1. platform tokens used to boost APY decline in value themselves
  2. smart contract risk
  3. a stablecoin in a Curve pool becomes unpegged and destroys the algo functionality
  4. multisig wallet(s) get compromised
  5. we enter a bear market with no stablecoins in the treasury and are forced to sell at a loss to finance operations
4

Cheers for putting this together @MaxRoszko and anyone who contributed!

Personally I feel most for the Badger option for the following reasons:

  1. gives the highest yield
  2. we will support two of our partners and Greycore members (both Badger and Curve)
  3. no big change in price exposure for our treasurey, apart from some Badger which again is a partner

I think point (3) is important because to quote the proposal:

which I take to mean that we are not trying to come up with a holistic treasury strategy here, which would include asset allocation, risk management, etc. If we go there we open an entire can of worms which should be tackled separately in my opinion. This proposal would be a good starting point to get the structures and processes in place to go there, and earn a yield while doing so.

5

Great work everyone and nice to see how things are shaping up.

Iā€™m happy to be part of the multi-sig volunteers as well if the community wishes.

This should be mandatory imo.

I agree with this.

Agree with this.

In regards to yield strategy Iā€™m in favor of option 3 or option 2, rather keep the treasury with as little volatility as possible. The tricrypto feels like a decent balance.

Once again, great job to everyone involved in treasury discussions, its tedious but so incredibly important and things look like its shaping up nicely. WGMI!

4 Likes
6

Thank you all Max for putting this together and for all contributors. Itā€™s never easy to coordinate for a large group of people.

My questions go around risks of possible collusion within the group. Since there will not be KYC, is there a way to minimise this?

Regarding the alternatives suggested I would also vote for going for less volatile strategies so option 3 would be my choice.

1 Like
7

Exactly! The holistic treasury strategy is a big subject that needs to be tackled on its own. How yield farming is done if at all is only part of the overall treasury strategy we need to develop, but hopefully this proposal will make it easier to tackle the bigger project with an overall treasury strategy and how to manage it.

1 Like
8

Many thanks Max for putting together yet another, well-written and articulated RFC :+1:

I find myself agreeing with a lot of what you mentioned here and would support pretty much all of the suggestions outlined above.

  • For yield generation:
    I would favour the Badger Ecosystem for this, especially given the fact theyā€™re supporting us with Greycore etc. It would also help strengthen existing Badger-Ren relations if we used their Ecosystem for the CEF (great suggestion by Thomm).

  • KYC/Sig verification
    Iā€™m not in favour of KYC via personal documentation, but I would insist that Max personally verifies those members that will be a part of the multisig - especially if 3/4 of them are complete anons.

  • Hardware wallets
    I think it is a good suggestion that the overwhelming majority of signees possess (if not all) a hardware wallet with evidence submitted to Max etc. This just seems common sense.

  • Transaction deadlines:
    Is there a limited window in which transactions need to be approved? For example if a transaction needs to be signed by the multisig within 30 min, and 2 members are in North America, and the other 2 are in Europe - will this cause an issue with the timezones/availability to sign transactions?

I supppose this could be avoided by giving clear warning in advance to the multisig that a transaction will need to be approved (even if it means during the early hours for some of the signees etc.)

Overall:

It feels like itā€™s all shaping up really well, and the thought of having a functional, operating multisig for the CEF makes me excited. Iā€™m looking forward to the snapshot voting and electing the first multisig members. Onwards and upwards!

ā€“ Shilliam.

1 Like
9

I donā€™t propose to comment on yield strategies yet, because I understand from Maxā€™s section headed ā€œImplementationā€ that weā€™ll be dealing with that subject separately. What I will say is that I would very much be in favour of supporting our strategic partners such as Badger and Curve to help bind our ties more firmly (and to show prospective partners that Ren honours strong relationships). This should include, in my view, holding their tokens to boost our yield.

On the subject of the community-governed multisig:

I agree with @Sabobi that this should be a mandatory requirement.

I agree with this. We may want to come up with a template that has to be completed, so that we have each candidateā€™s views on specific questions (e.g., how long have they been involved in Ren, have they held a multi-sig position before, etc.). In my view, each of the ā€œnon-REN Core teamā€ members of the multi-sig should also be required to be operating at least one darknode. Having skin in the game is important for the alignment of shared values, and it also helps keep people honest.

Would this Ren Core team member be Max, or is Max proposed to be an additional member of the multi-sig alongside this Ren Core team member?

2 Likes
10

I think we will vote on it through a separate RIP, but can comment and discuss the strategy as part of this RFC

1 Like
11

Thank you so much for your feedback Shilliam!

To specifically answer this question, transaction deadlines will mostly only be applicable when the multisig wants to do DEX trades, because setting a DEX trade often involves parameters like how much slippage relative some price point you put into the transaction, and if it takes a while to submit the transaction, the trade might end up reverting because the price of the assets changed in the mean time, so the multisig ended up wasting gas.

But this is for instance why 4-of-7 is a useful structure because it doesnā€™t matter if 3 members are AFK, you can still get a transaction submitted quickly.

In general through there arenā€™t timelimits when it comes to signing a multisig transaction.

12

No it would only be me in that case since I would count as that Ren Core team member.

13

This is a great RFC @MaxRoszko, thanks for putting it together so concisely.

I agree with the general sentiment of the replies to this post.

Iā€™m aligned with @TooOrangey, whereby although we want to reduce volatility and risk we should still be supporting our partners, by which we should allocate a small part of the community fund to purchase Badger to obtain the boost. This should create a positive feedback loop, where the Ren community is observed to be supporting their partners.

I also agree that we should be diversifying into ETH and Stables as well. The Curve Tri Crypto pool is one method, but another potentially safer method would be to just have the stables lent out on Aave or Compound or Bancor once they release V3 and space opens up in their pools.

I also agree with not requiring KYC, but certainly an informal interview with the likes of Max should be required.

14

Iā€™d vote for a Badger implementation since they are Renā€™s best supporters so far.

Also, Iā€™d like to push for Max to ā€œverifyā€ multisig members in some fashion. I agree that multisig members should not need to publicly KYC, so the next best thing would be a Ren Core team member attesting to their authenticity and, if possible, financial incentives. Should it be a requirement that a multisig member be a DNO first?

The thing that scares me is that using the 4-of-7 rule ā€“ youā€™d only need to convince 3 other people in order to walk away with the CEF in itā€™s entirety. Thus, they should be properly vetted and have incentives aligned.

15

The CEF is controlled by the Gnosis safesnap and funds can only be moved out by DNO vote, the Yield Ops multisig is a separate wallet. This means they cannot walk away with the whole CEF, only the funds that have explicitly been send to the multisig on DNO vote.

As for convincing 3 people, I think this is not as easy as it sounds. The risk of approaching a member who will be extremely alarmed by such a proposal is high and would immediately sound the alarm bell to get the member jousted and replaced from the multisig.

16

Plus It would require James Bond level persuasion to corrupt Max if heā€™s in the multisig :grin:

17

And to add to that, who signs what transactions is visible on-chain and clearly visible on the Gnosis Safe page as well.

18

Summary of the comments up to now:

  • There is clear consensus that we should move forward with this proposal
  • Much support that any yield strategy should utilize our ecosystem partners like Curve and Badger
  • It makes sense to include a risk section for each strategy
  • So far only one additional person who threw their hat into the ring: Sabobi
  • Agreement that multisig members should be using hardware wallets for their multisig address, which would have to be validated somehow
  • Agreement that we should minimize the risk of collusion, by for instance:
    ā€“ that members up for election need to introduce themselves in a short text blurb
    ā€“ that members up for election should be validated informally somehow by a member of the Ren Core team (until this can be vetted by the proper DAO itself in the future)
    ā€“ that members need to have at least one darknode operating, which would have to be validated somehow

Anything posted here is not final of course, overall though there seems to be broad consensus so far. We will be discussing this proposal and the feedback on the Community Call next week on January 12th, and any more comments up until then are very welcome (also discussions in the Discord channel)! And hopefully after the Community Call we can begin finalizing a proper RIP or RIPs with some concrete options that can be voted on!

4 Likes
19

Regarding requiring multisig operators to show proof of operating darknodes.

Personally I donā€™t feel this should be a requirement. First off, except for DAOā€™s where members need to hold DAO tokens to be part of the community, I donā€™t see other projects requiring members to show proof that they hold a certain amount of protocol tokens to be eligible for a working group or multisig. Happy to be mistaken though on this front if someone has some examples.

Generally it is assumed that community members have skin in the game or are otherwise aligned with the goals of the DAO. Why else would we all be here spending our valuable time? I think the voting process will take care of only selecting members that have proven to be here for the right reasons.

Secondly, proving that someone owns a DN means doxing the ethereum address. If this is a requirement, I will seriously reconsider volunteering. Lastly, the group operates on a mandate given to it by DNO vote, this means it already aligns with the wishes of the greater DNO community.

20

I think the DNO requirement can be avoided if it can be proven that a specific member has been involved with the project for a lengthy period of time.

If the signees have been supporting the project for 1-2 years (and can be verified as a respected member of the community) - then Iā€™m not too concerned about if they operate Darknodes or not.

Someone whoā€™s been in the community < 12 months is more of a concern though.

1 Like