RFC-000-016: Launch a Community Ecosystem Fund

1- This restricts proposals to Darknodes, which I do not think is healthy. The purpose the funds is to expand the community and to address issues beyond the core protocol (e.g. providing liquidity to a third-party pool). In this light, requiring a Darknode to conduit everything would be burdensome and also, at a technical level, unnecessary (if Darknodes are voting to approve/reject then Darknode support is pretty explicit anyway).

2- We can address this by having a quadratic voting option for “keep the funds”.

3- This is achievable regardless, based on the periodicity of a vote.

4- I am not sure I understand this point.

5- I disagree. It is neither here nor there compared to other approaches w.r.t. the simplicity of implementation/integration with the existing system.

1 Like

I do think if in the future the system changes and other Ren holders are able to support the network with some kind of pooling/ underwriting that the voting system should change so that everyone supporting the network has a proportional vote to the amount of ren they have bonded. 1 ren = 1 vote. But only if it is bonded to the network.

1 Like

In principle, I agree with you. However, it is not really a matter of “it would be nice to have REN holders be able to govern” in this setting. Darknodes are in power. This is a technical constraint that cannot be subverted. REN holders can signal whatever they want on/off chain, but at the end of the day it is only ever up to the Darknodes whether or not they obey. This cannot be enforced. It would be great if it could be, but I do not know of a way that this can be achieved.

2 Likes

Since the DarkNode operator needs a minimum of 100k REN which is the RenVM technical core. it is a big amount and we all know that before the start of the mainnet. core team determined 100k ren for some reasons to secure the network.

If the reasons still exist, keep it as it and let the darknode operators manage the project in a secure environment because we are holding people’s funds. all decisions should be done by DN operators not by someone who bought REN today to take a decision for us then sell the next day. Otherwise, reduce the required amount per darknode to 10k REN, for example, thus pooling and voting issues will be fixed.

Currently, ETH 2 node requires 32 eth (~$60,000) to run a node, one day it may cost $200,000 or even $500,000, Ren is similar even if the darknode will cost 1M USD in one day it does not matter as long as there are always enough REN supply for the darknode operations.

Our final target should be to bring ~%60 of the total supply locked in Darknodes. in that case I don’t think that we will need DN pool service or even 1 REN = 1 Vote anymore since 60% of holders can vote.

Compared to other projects, a Darknode is very cheap.
For example, to run a Thorchain node, 1 million Rune is required. At today’s price of $6.50, that would be $6,500,000.
I’m against lowering the bar for purchasing a Darknode. As it is with the current value of a Darknode there are a number of people that are surprisingly careless with their nodes. Making a Darknode dirt cheap would make it worse.

Great summary @MaxRoszko, I am in support of this RFC and further agree with:

  • DN Operators have a prioritized and or weighted vote in how funds are allocated.

  • I am in favor of a larger 10-25% of rewards going towards grants and incentivizing development using RenVM.

  • If Alameda is running nodes, and is Greycore I think they should be able to get a vote, like any DN holder, being a DN holder come with governance rights, and this should hold value. I also believe given their position and ability to invest capital that Alameda Research should match any investment the RenVM community backs, to further incentivize projects and development growth that align for all parties.

  • Could name it anything, no comment

  • a Committee should run the Fund and should be nominated, would personally like to get involved in this capacity if the community would be in support of such.

  • A framework should be set up, we can review and analyze other successful programs like BadgerDAO, and mimic and steal the best and most successful practices.

Cheers to the team for the progress and concept, I am very much in support, and can’t wait to see what great projects and concepts stem from this investment.

1 Like

You don’t need to be a Thorchain node operator to directly participate in the network. You can simply be a RUNE LP. In this way, all RUNE holders have a way to put their investment in RUNE to work helping to support and grow the network, while earning rewards. This is, I believe, very positive for the community. It aligns large and small stakeholders, and ensures more people have “skin in the game.”

My worry with Ren is not giving smaller holders a way to participate directly within Ren, outside of speculation. DeFi at its core is about more than just making money, it’s about building communities where all can participate. If I only own 3000 REN, how do I participate in a meaningful way?

Having said that, I’m not a fan of lowering the 100k REN limit for node operation. Simply seeing the community develop pooling options is, I believe, the way forward. Allow the investor with 3000 REN the option to bond within a pool, help secure the network, and earn monthly rewards. He or she immediately starts to think more long term with Ren, feels more a part of the community, etc. Win win.

2 Likes

Some general points i’d like to add concerning the concept of government:

• More people voting doesn’t necessarily lead to better decisions. Democracy is a form of government where the majority gets to decide, it’s inherently neither good nor bad. If the majority wants a bucket of poop for breakfast, it’s a democratic vote, but in the end, people still “feast” on poop.

• Assuming only people having skin in the game (dn ops) being able to vote, there are multiple approaches and views on how to tackle a problem, for example the fee debate (bigger chunk of smaller pie vs smaller chunk of bigger pie, what nets us the biggest amount of cake?), so decisions likely won’t by unanimous. Will we roll with simple majority for general decisions, and “constitution level changes” requiring 2/3 majority+?

• Even people with skin in the game need a push to vote because it can be a burden, or simply they don’t care. Example, the one person running 34 (?) nodes and just ignoring rewards/not collecting them as he or she is just is too lazy to supply eth. Relying on votes, but too little people showing up to a vote, can be an issue too. When looking at other daos, I do have the feeling that participation in voting is rather low (but slowly gets better).

• If people are forced to vote (for example by losing their voting right for the next vote if they don’t actively participate in the governance process), this could lead to uninformed votes which are more driven by the fear of losing the voting right for a future proposal which might affect them, than the will to actively participate. Basically, people would log in, vote just for the sake of voting, and stop to care again.

• Now the issue with votes is, if you want people to vote (and actually want to accept what they are voting on, as else voting would be pointless), you can’t judge what an informed/uninformed decision is. Information isn’t distributed equally over all participants and probably will never be. You can only count on involved people to think through stuff and have the best intentions in mind (and publicly discussing their opinions and thoughts on why they prefer x over y). As some form of power balance check a voted in group of “senior node ops”, let’s call them “council of wise node ops” (or senate), with a higher vote count than 1 node = 1 vote, would make sense in my mind. If the general “node population” deems them “unfit for office”, “wise node ops” could be removed from this council.

2 Likes

The only issue I see with this is could this senate of node ops be bought. We have seen it in our very own politics across the world today if you concentrate too much power to a smaller few they could be corrupted and because of their disproportionate vote hold a lot of power and sway that might not be in the best interest of the majority. Then we have to vote them out potentially after they have already made poor decisions or are dealing backhanders with devs and other protocols. It is a lot harder to corrupt a majority rather than a senate.

Blockquote “Now the issue with votes is, if you want people to vote (and actually want to accept what they are voting on, as else voting would be pointless), you can’t judge what an informed/uninformed decision is. Information isn’t distributed equally over all participants and probably will never be. You can only count on involved people to think through stuff and have the best intentions in mind (and publicly discussing their opinions and thoughts on why they prefer x over y). As some form of power balance check a voted in group of “senior node ops”, let’s call them “council of wise node ops” (or senate), with a higher vote count than 1 node = 1 vote, would make sense in my mind. If the general “node population” deems them “unfit for office”, “wise node ops” could be removed from this council.”

2 Likes

Agreed - why make something less decentralised out of choice.

Its already been stated that we could opt for a Gitcoin type approach to which incentives, and how much, would be invested. This wouldn’t require quorum to be initiated and so removes most of your concerns as far as I can tell

I would argue 3rd industrial revolution standards dont apply perfectly. They got away with it because there’s no penalty. The “cryptoeconomics” keynote speech by Vitalik was of the best in the space to understand the idea that this is a perfect reward-discipline system because the incentive is value.

But if you give higher voting power to a senate of node operators they could obtain value through potential back handers and other dodgy dealings as they hold a larger sway of the vote. Not sure I understand your point?

This being said you can’t guarantee this would not happen with some of the larger node operators who are going to hold a bigger sway of the vote anyway. So maybe this could potentially mitigate that risk as well.

Ok i guess i thought you meant the system in general. Where the darknodes dont know each other and voting against would make them malicious and slashed. Coordinating an attack would be very difficult.

For voting i guess its possible but theres still an economic outcome largest to the darknodes where incentive is to get it right. Buying a darknode vote is very hard. Maybe youd send a message tx to their ether addy saying “please vote xyz ill pay” otherwise how do you even know who the operators are?

1 Like

Fair point. I think it is more if there is a senate of node operators who have a voting higher power you would assume this would lose some anonymity as for them to be voted in to have a higher voting power there would need to be some kind of election. I think in this scenario there is more risk of voting potentially being corrupted. Keeping just a normal majority vote 1 darknode = 1 vote there is less risk of this because of the anonymity of node operators.

What’s not to like about this proposal? I’m all in. LFG!

Ren being successful, pools will come. There is already a project working on a pool, http://renpool.io/. I am in favor to only vote who has staked or run a node

I am in favor of this proposal. My only concern is that should be a council to take responsibility of the pool and coordinate activities to bring development and others to the ecosystem Ren. If the pool is to start asap (in combination with eliminating fees to claim rewards) probably is too close to vote for the council. I would like to propose that a interim council take place until a formal one is stablished.

2 Likes

In favor with caveats.

  1. the fee situation needs addressing. Agree here. May not agree that rewards should hang around in the protocol and wait to be called by the DN. Creates waste and reduces severity of un-bonding.

  2. 100% agree we need a community fund.

  3. 51% disagree that community fund financing should be tied to core protocol functions in any way. Human element that deep in is distressing. Longer term, the community fund (Could we call it the REN Foundation?) may become bloated, political and irrelevant.

  4. I have a better idea. Let’s combine the idea for an official REN staking pool for small-balance REN holders with the need to finance a community fund. In return for receiving their rewards in legit renBTC and not some platform shitcoin, stakers accept reduced rewards compared to a full DN bond and pay into our community fund. They would probably want some representation in voting, but it should be vastly watered down. Further, the number of darknodes from staked REN should never exceed 49% of the total in operation.

  5. any governance needs of the staking pool should fall to the general community fund governance, weighted to the DN operators.

  6. we could also look into utilizing the public staking pool for darknode gas subsidies…

  7. governance should be a separate RFC in my opinion

I support this proposal, having a fund to be able to incentivise user and pay for external resources is a great idea.

As liquidity mining is all the rage at the moment, subsidising certain liquidity pools (e.g. a BTCB/renBTC in pancake swap) would certainly result in a net gain to the Ren Protocol and DN holders as people move liquidity from Ethereum to other chains.

For everyone suggesting every REN holder should get voting power, please have a look at this tweet.

TSD DAO was taken over by a malicious actor who bought up a big portion of the tokens at cheap prices on the market and performed a quite blatant attack to the DAO.

This is the type of angles everyone should consider when only 1,700 nodes are active. Darknodes become a minority within a governance where only they are fully incentivized to act with best interest of renVM at heart.

Attack vectors like this need to be ironed out before any consideration is given to allow anyone other than node operators to have voting power for governance over renVM.

3 Likes