Name: Community Ecosystem Fund | Governance & Safekeeping Category: Treasury Status: Draft Scope: To establish which method the Ren community will manage the Community Ecosystem Fund
To be able to pay out grants and to be able to deploy funds to a liquidity pool from the Community Fund, Ren governance needs to set up a treasury management system. Until RenVM has a governance module built-in that could provide this feature natively, a governance module already built on a platform like Ethereum needs to be leveraged.
A community multisig (5-13 members), with the option of Ren governance voting in these members and having the ability to vote and replace members
Gnosis SafeSnap, where a Gnosis multisig contract owns the funds but plugs into our already in-use Snapshot space, that can trigger transactions. It is also possible to use SafeSnap combined with a standard multisig group, that could have the ability to veto any accepted proposal (but the system can run completely without a multisig group with veto ability)
A full on-chain DAO contract system, where the Community Treasury is placed in a set of DAO contracts and Ren governance has to on-chain vote to trigger transactions
Details
The Community Fund was established to invest in and bootstrap the Ren ecosystem (https://forum.renproject.io/t/rip-000-005-launch-a-community-ecosystem-fund/698). Initially, the primary process for how funds will be disbursed in the Ren ecosystem is through Funding Rounds: https://forum.renproject.io/t/how-quadratic-funding-works/799. The Funding Round process takes care of where grants or liquidity should be going, but what remains is how those transactions are made, as there are different solutions with differing levels of decentralization, security, and cost trade-offs.
Requires a little more work to set up but would be using our Snapshot space that is already live (https://snapshot.org/#/ren-project.eth) which saves on development effort
No transaction costs to vote since that is done off-chain on Snapshot
High decentralization, although some reliance on the Snapshot service
I’ve just finished catching up with the community call and I’d like to add some input to the already excellent community discussions taking place, thanks to everyone who took part.
Regarding Gnosis:
This looks like an excellent, plug-n-play solution with little effort required. The only concern I have with Gnosis is the counterpart risk - I understand Gnosis is relatively decentralised, but in the event the multi-sig contract is exploited or drained the team/community would not be able to recover the funds or patch any bugs/ vulnerability. Is this the case?
Regarding DAO contract system:
I am a fan of the DAO approach, and I think there could be potential benefits to having a RenDAO in the long long-term to handle all manner of things related to Ren. I assume there would be no counter-party risks or GAS with this set up? As all DAO contracts would run on top of Ren?
Community Multi-sig:
This seems to be a very decentralised solution, but involves a high degree of trust in the integrity of elected community members. This risk decreases with more members, but would make the fund entirely community-operated and will give us valuable experience for the future, when we will be solely responsible for all Ren governance.
It’s exciting to see the early signs of governance coming to life though!
When you say that there would be gas costs to be paid under the DAO option - would those be Eth gas costs or could it be performed on a low cost blockchain instead? If ethereum - then I think that rules this option out since you wouldn’t be able to achieve quorum (or a sufficient spread of people if no quorum required) if people are having to spend $50 to vote.
I also wonder if there is a solution for the short term - to get the ball rolling (potentially your second option). And transition to a fully fledged DAO over time?
Guys, if you haven’t listened to the community call, you should def do it. It’s informative!
To reiterate my POV that I’ve expressed in the call, but in a more coherent way:
Our goal with the community fund should be to get rolling as soon as possible. By rolling I mean defining how we are going to develop it and actually start doing it.
Going with the DAO takes time that could be spent on the fund itself. What I propose is that we go with the fastest, start-up, bootstrap style way, i.e. multisig / safesnap.
And I’m def thinking of DAO. We can always adopt the same staged decentralization that Ren project has been following and introduce other governance systems at a later date.
@MaxRoszko what is the approximate time difference for implementing multisig vs safesnap? If the difference is really insignificant, than I think that’s our best option atm.
The Gnosis multisig contracts are some of the most used in this space, with projects locking up billions of USD in them. They have been extensively vetted and audited so any contract risk should be extremely low at this stage.
The risks would be even higher for something like a full on-chain DAO system on Ethereum through Aragon for instance, as those contracts have many more attack surfaces, while a multisig is much lighter.
Regarding contract interactions in RenVM and whether they will have transaction costs, we will have to see in the future what the best approach is, but given it will be the DAO’s contracts and we govern RenVM, we could maybe make exceptions for those contracts. Like if you own an apartment building and rent apartments out, and live yourself in one of them, it doesn’t make sense that you pay rent to yourself. But I’m just speculating here.
The contracts can also be designed to be completely decentralized without any counter-parties (and the community have to agree on using those contracts for governance initially as well, if the community isn’t happy about those contracts they will have to be redesigned).
Costs depend on which chain it is set up (until we have it in RenVM natively). If you set it up on Polygon instead, it would be much cheaper, but you could also not pay out grants to folks on Ethereum then.
That’s why a full on-chain DAO on any chain other than RenVM isn’t that attractive.
Yes the point of this all is a short-term solution until we have governance contracts on RenVM itself, so the idea here is to pick a short-term solution, one of those 3 options. And in 6-12 months we will be transitioning to a fully fledged DAO on RenVM.
If a community multisig is chosen you will have to organize elections and develop some procedures to make sure the funds are as safe as possible and that the group can coordinate and initiate transactions correctly.
For SafeSnap we would need to connect up a Gnosis vault with our Snapshot space, which will be a little technical work but here the Ren team can help set it up as we set up the Snapshot space, and then just run a couple of tests to make sure it works as expected, perhaps implementing a quorum threshold as well.
Yes the point of this all is a short-term solution until we have governance contracts on RenVM itself, so the idea here is to pick a short-term solution, one of those 3 options. And in 6-12 months we will be transitioning to a fully fledged DAO on RenVM.
I see that the activation of CEF in the current phase is not important, better to save time for something else until we implement it on top of RenVM.
The current average income is not enough to make good ecosystem investments, I don’t like to see RenVM doing small grand/bounty programs, also DN income is not increasing for a while. it is better to distribute CEF to DNOs to incentivize DNOs to continue until something big happens on RenVM volume.
I suggest postponing the activation of CEF until H2H to see our new average income. If H2H will bring a 5-10x increase in volume, I would suggest activating CEF ASAP by using the fastest and easiest solution which is the first option. In the meantime, we can start the CEF implementation on top of RenVM.
In principle yes, at first we should grow the fund, because liquidity incentives and such require very large amounts of money, but we shouldn’t just collect the monthly payout. Instead we should leverage what the DeFi space can offer and get extra double digit % to our fund via low-risk, diversified farming and/or LPing.
This will exponentially increase our treasury compared to just getting a cut from darknode earnings.
I like the Gnosis Safesnap option. It is fast to setup and we can use Snapshot, a tool the community is already familiar with.
The solution requires less dev time to setup than full DAO, but doesn’t require additional elections like a multisig. It’s a safe and battle-tested solution used by many high TVL projects.
While we wait for the Native RenVM solution this seems to be a good middle-ground
As I’ve mentioned on Telegram, I’m a proponent of elected representatives, so would ordinarily be in favour of the community multisig approach. I get concerned when individuals - myself included - are asked to vote on decisions we may not be qualified to make. That being said, Gnosis SafeSnap would presumably allowed delegated voting (in the way that Snapshot does), which may be a quick and dirty alternative.
Does anyone know for certain whether we could roll out delegation on Gnosis SafeSnap?
One thing I want to point out about the Gnosis SafeSnap proposal, and please correct me if I say anything wrong because this is still new to me, is the added complexity of creating snapshot proposals. Which is something that was not immediately clear to me.
When you create a new Snapshot proposal you need to create and add the Ethereum transaction(s) that will be executed after the snapshot has passed. We should also make sure that these transactions are audited and verified manually before the Snapshot has passed and is carried out. Which is another reason to have a multisig failsafe setup for the Gnosis Safe to be able to block proposals where the attached transactions deviate from what is proposed.
Of course with the vanilla Gnosis Multisig proposal, transactions still need to be created and verified but here the onus lies solely with the multisig members. The SafeSnap proposal has the benefit that the transactions will be visible by all before they are voted on, and can be independently verified, but has the drawback that not all members will be able (or are comfortable) creating a Safesnap vote which again shifts the onus back on either the team or trusted community members.
How are the funds sent from RenVM to the Gnosis Safe/multisig address, will this be automated inside RenVM to happen at the end of every epoch or is this a manual process?
Correct that the Safesnap solution would need every Snapshot payout proposal to be validated so that it sends funds correctly. This would be true for future governance mechanisms built on RenVM as well.
To make things easier though, the voting period where community decides on which grants to pay out, is necessarily separate from the payout period (because we can’t program how much to send before we know how much to send). So the Snapshot where all proposals are voted for does not include any transactions, it only decides how much and to which projects funds should go. Afterwards a separate payout proposal will need to be crafted and accepted by the community, and this one will have to be validated by independent people.
The vote is now closed, with a clear majority voting for the Gnosis SafeSnap solution, so the team will begin implementing this now! Expected deployment of the SafeSnap is roughly 1-2 weeks, depending on how much time the host-to-host deployment steals from our devs.
