RFC-000-037: Incentives for a decentralized network

I think this proposal and the existing one should be taken under consideration together.

First, the team is recommending that Ren become a full-fledged Layer 1 with a subnet architecture. That potential approach is still under discussion.

Now, we are receiving a proposal asking us to consider inflating Ren’s supply to fund ongoing efforts of a Ren Foundation that would be responsible for driving that Layer 1 forward. And, this proposal is being put forth as a means of moving quickly to decentralization.

I think the Layer 1 and the inflation proposals are interesting, but for the community to truly take this into consideration, I think a few questions should be answered.

  1. The existing plan for decentralization. Ren produced a document “the road to decentralization” that presented the Greycore, and eventually DNs themselves as a means to making the network decentralized.

Can you provide us with information about the pros/cons of this effort (ren foundation, plus deflation) and using Ren as a gas token, versus the existing decentralization approach?

Is the existing decentralization approach no longer valid or feasible? Should there be a vote to move Ren from the greycore model specifically? We need more information about existing decentrlization efforts.

  1. Funding

This is a big one. When Ren was first launched the team had a number of tokens available to it that, presumably would be used for ecosystem development (I don’t know if the allocation included an ecosystem fund). Presumably all of the team’s tokens were sold to Alameda in the acquisition?

Are there any Ren tokens available to the Ren Labs that could be provided to the foundation to fund operations as opposed to inflating the supply? Commonly this is how DAOs and foundations are funded with an existing ecosystem fund. Alternatively, these tokens could come from Alameda, which would provide tokens to fund operations/the foundation based on them having access to existing supply? Again this (transferring tokens to a decentralized organization is a best practice that other teams have engaged in, and it has worked well.)

In summary, it’s hard to judge or assess this proposal without understanding:

  1. Pros/cons of this effort versus existing decentralization approach (greycore)

  2. Alternatives to Ren inflation based on gifting tokens to the foundation from existing players, or other sources. And if these tokens are not available, understanding why no more Ren is available.

Also, it’s pretty much imperative that DNOs and the DAO have ultimate control and authority over funds disbursement and the foundation (via elected representatives), as imo best practices around foundations are that they are only there to fulfill the will of the community in meatspace contexts. For me, any other setup is a non-starter.

12 Likes

I’m not a fan of inflationary models and one of the reasons I fell in love with REN was its economy. That said, and imagining that the transition to a new incentive system in which inflation will be included is going to be inevitable, I am strongly opposed to it being a fixed percentage that is repeated over time:

  • If successful in terms of early adoption, within a few years the CEF should vastly outperform token issuance rewards, so constant high inflation would be detrimental to the value of the token.

  • If it is not, even offering extremely high emission rates, the project would be doomed to failure and in any case, with a total reformulation, the new conditions would be established, including inflationary ones.

Therefore, a model that, for example, reduces inflation year after year until it reaches a minimum is probably the best option. 9-7-5-3–2. Three years with inflation equal to or greater than 5% is a reasonable time frame to incentivize and ensures that the token after that will remain at or below the average inflation rate in the world.

After being temporarily hit by so many changes proposed, i`m seeing a bright future. We need people from the economy formation side to participate and add value.

Cheers to all!

1 Like

I agree with whiskey. We should figure out a way to reward small token holders if this inflationary model is the best way to move forward. How many times have I seen people pop up asking in both telegram/discord on where the pooling solutions for Ren stands. That would only benefit the project, as it would increase the number of token holders, bring more demand for it and increase the market cap, thus allowing for more funds for the foundation. I’ve been a dno since epoch 2, I don’t mind diluting my rewards at all for the benefit of the collective network participants.

1 Like
  1. " Under their leadership and direct support from Alameda, Ren Labs will take on two primary mandates: continuing the development of RenVM into its own L1 "

Does ren still have Alameda’s direct support to be a L1 and what if they do does that direct support entail ?

2 Likes

I’ll throw this comment here as requested. Just how much time and effort was wasted on greycore? Sure you learn the hard lessons by trying, but it feels like the project is set way behind. Unless the culmunation of work over the last 4 years can fastrack development to this l1. If no effort was wasted, then what was gained? As a DNO I would like to know the lessons the team took away from delving in this greycore method of decentralization. Did the team walk empty handed from this endeavor?

5 Likes

I’ve thought about it a bit more and this feels rushed, i wrote more of my thoughts in discord about why

1 Like

Hypothetical Question: The Ren Foundation provides an incentive with REN tokens to build on Ren L1. KAVA provides an incentive with KAVA tokens to build RenBridge on KAVA EVM. Does the Ren Foundation now use these KAVA tokens according to Ren DAO governance?

Hi @MaxRoszko @Susruth, it is mentioned in the post that

Could you please clarify whether the inflation model presented is to be applied in this new Descentralised REN chain, RenVM or both? The reason of my question is because later in the proposal is said:

So if the incentives are for developers to build on Ren, where would they do that or where do we want them to do that? I would expect developers would like to build in the decentralised, more secured chain.

From your post it seems the idea is for RenVM to be phased out and for the ecosystem to be migrated to this new chain, however it seems also dependant on “sufficient security-related achievements have been met “ so it begs the question, if these achievements are not met, is the idea to maintain two chains? If not, what happens with the apps living in RENVM? It also says DNO will be able to deploy in te new network, does that mean turning off the nodes in RENVM and move to the new network or the same DN will be deployed in both chains?

One concern I have is that if this is not clear for developers and community and they do not have guarantees about what would happen with their app, it won’t matter the incentives we can create.

Another concern is what will happen from now until all of this is decided and built. We are talking another 12-18 months being optimistic and developers may decide to wait for this new improved Ren chain to develop on it.

Thank you

4 Likes

As there’s no mention of burning REN when paying for transactions (see Ethereum EIP 1559), then I assume all fees are split amongst Darknodes. How do Darknodes come to consensus on what the fees should be for core-layer transactions? Will there be a base-fee that fluctuates based on demand (this is regardless of whether it’s burnt or not)?

If we have an inflationary model introduced then what is the incentive of holding additional REN received as Darknode income?

Scenario 1: The max cap 10,000 nodes is still respected and each node requires 0.01% of the supply (suggested by Susruth), why would Darknodes hold REN? I imagine they would immediately sell on the market. Unless if Darknodes are required to keep their bond up-to-date with 0.01% of the total supply, there’s no incentive to hold. This doesn’t even consider the REN coming from “inflation protection” for Darknodes.

Scenario 2: The bond requirement remains in place at 100,000 REN effectively removing the 10,000 max Darknode cap. Larger DNO’s could dilute smaller DNO’s such that it’s a race for control of the network. Large DNO’s win and there’s diminishing incentive to join the network over time. You could introduce an inflationary measure on max Darknodes but that could just be more troublesome with having 2 levers to control instead of 1.

For utility sake alone, I think we wouldn’t need it if Subnets and applications could just pay in any Ren-supported asset (again, I imagine this is hard today due to lack of oracles in Ren). This could easily remove the barrier of acquiring REN in order to interact with applications and Subnets - users would already be bringing their own assets so the additional step of getting a gas token is nothing innovative from what we already have today.


Going back to my previous post, why are we not pushing for more volume through the bridge? More volume = higher TVT = more fees = increased REN price = increased bond requirement = better network security? Seems pretty simple to me. What doesn’t seem simple is introducing additional use-cases and inflation to REN and claiming that it will increase network security - you are just introducing additional attack vectors (in forms of market forces) to the network.

2 Likes

Very interesting thread.I see a lot of PROs and CONs. Very fair points mentioned on each side. However in lights of what has been well written by other fRENds I feel more inline with the CONs side. I’m against the supply increase.

Increasing the overall supply is, for me, not the road that we should take, at least not without a burning mechanism that will offset the equivalent amount of new token created. The fixed supply and the no dillution were few of the core element that I love about REN project.
I guess we should focus our effort to increase volume going through the bridge as mentioned by @DryOracle just above. This summarize our goal to achieve, even if it is easier said than done.

There are a very fair amount of questions raised by the community that needs to be answered to convince me that the overall suggestions is actually beneticial for the REN Project livelihood.

1 Like

Why is a foundation appropriate rather than a “triparty structure”? Not opposed to a foundation if that’s the appropriate entity, but please make sure qualified legal counsel vets it.

Inflation does not create value, so if more funding is needed let’s talk about how such funding is attracted from outside and/or extracted from DNOs at a greater rate by increasing the community fund contribution. (EDIT: or preferably by increasing volume+fees)

Absolutely agree with this.

Regarding the development of the platform and sustainability over time, an attempt to break down the origin of the funds:

-CEF Difficult to imagine a collection greater than a million dollars for the year based on the previous epochs.
-Token distribution: Hard to calculate with a value that plummeted 90% in half a year (like most of the market). Assuming a complex context and a cumulative increase in interest rates (FED), I find it not easy to imagine a value higher than 0.25 for the next year.
7% * 1,000,000,000 = 70,000,000 * 0.25 (hypothetical, average) = 17,500,000 usd
DNO= 2000 (20%)= 3,500,000
Developers fund = 14,000,000

The immediate question: with funds of 15,000,000 per year (probably less) is the development of the project sustainable? Do you think of another way to attract VC`s or other types of contributors? For the entire market this last option seems difficult, that is the negative part of the bear market. The positive, if development is really possible in a period of less than two years, maybe we can be a primary participant in the new wave, like Solana, Avalanche, and Polygon were in the last bull market. Timing was also key.

Thanks for the proposal and the great discussions in here, great to see it!

I think the overall direction is very bullish, even though there might be a lot of disagreement about the details.

Especially the Ren Foundation gets me very excited. It is clearly necessary to have a transparent legal structure if we are to decentralize and if the DAO and wider community is to take the reins. It is paramount though to get the structure right, and as others have voiced as well, to achieve synergy and alignment between the DAO and the Foundation there should be some kind of overlap between the governance structures. Potentially DNO voting can be involved as well. Great to see some community members already stepping up to start to give form to this!


As for decentralizing and growing the network; some thoughts on the current proposal and strategy:

  • I’ll join Max here in celebrating what we have achieved already. It is no small feat and the team and community alike can be proud. What I’ll challenge though is the mature state of our current offerings in terms of security. Yes the product has so far been safe from hacks, but there are more angles to security, and decentralization is one of the primary means, and part of the original road map. I don’t think maturity can be claimed without it. Decentralizing is not an easy feat, so we should focus on it instead of brushing over it.

  • Another point where I don’t think maturity has been achieved yet is on the front of adoption. In recent months we have actually lost valuable integrators (Badger, Curve) instead of growing. Though Badger will integrate again using the ZeroBridge which is build on Ren, and the team mentioned they will help Curve integrate again using RenJs 3.0 (iirc), the fact that we are only talking about one of our closest partners and earliest integrator of almost 2 years ago is kind of the point. As mentioned, we have a working product that is trusted to move billions, why are we not moving many more, by dozens of integrators?

    There are many avenues we should be aggressively targeting, places where we can be value add, there is still so much to gain by increasing adoption of our current offerings.

  • In terms of adoption and ren asset support there is still very low hanging fruit, e.g. getting renBTC on Aave, others maybe less so such as AMM integrations but they should be our lifeblood. Are there any impediments to reach those? If so, we should work on getting those resolved. Is it too difficult to integrate RenJs then we need to make it easier or do/fund it ourselves, if its the fact we are not decentralized then we need to make this our priority etc.

  • Framing the creation of an L1 as a growth strategy seems slightly folly to me unless we expect we can dethrone or take significant market share of the current leaders in the space for the long run. Either way, we are here because we believe in a multi-chain world, we don’t believe in silos, we break them down. This means, even if we have our L1, we need to integrate with other chains but they also need to integrate with us (i.e. integrate RenJs). Which brings us back full circle to increasing adoption of RenJs integrations in the established space as a growth strategy.

  • On the most recent community call the team mentioned decentralization as main priority, but we need to wait until L1 whitepaper for the roadmap. Where is the V1 roadmap, including decentralization and growth strategy? Completing the original vision should not be part of the next phase that requires additional funding. And if it does, we need to have a clear post mortem on why we cannot achieve the original vision with the available means, and how the new means will ensure that we will.

  • Why is setting up the Ren Foundation part of the “Incentives for a decentralized network”? On the community call it was said that Alameda was funding the inception of the Foundation as part of decentralizing the current offerings. Can we split these proposals in to two distinct tracks of “Set up Ren Foundation” and “Incentivize building Ren V2.0”?

2 Likes

Can address some of the comments here:

We certainly are not brushing over decentralization, that’s why it’s the primary focus at the moment, and the timing of it is explained by our commitment to security. We’ve only ever wanted to do upgrades when it didn’t negatively impact security, some of which taking a long time to be robust enough for it to not negatively impact security when deployed. This is why Greycore was delayed for so long and ultimately will be leap-frogged now, because on a security to decentralization spectrum, it actually still reduced security no matter how we made this design more robust, while not really improving decentralization because it would not be censorship resistant.

We need to improve the mental model here, because we are not proposing to create a new silo. Here’s a quick model I drew. Here’s Ren currently:

Even if not perceived, there is a thin layer at the moment between Ren and different host-chains, this is where RenBridge lives you could say. At the moment, it only allows you to move assets between chains.

Here is Ren with smart contract support:

It still lets users move assets between chains like before. But now they can pass through smart contracting logic which leads to more possibilities. And importantly it does not take away or hinder the movement of assets between chains like before. This thicker layer supports apps through subnets, which can differ in programming frameworks and security, all the while the core safety of the assets and the movement of them between chains is handled by Ren Core.

There will be a new blog post style update which will include a new roadmap.

A foundation will need long-term funding, which we cannot rely on Alameda for, which is why they are part of the same proposal. Alameda is primarily committed to funding Ren Labs at the moment.

5 Likes

renBTC on Aave failed because of lack of decentralization, and not having a credible path to decentralization. With renFIL I suppose the bar was much lower, as the potential impact should something go wrong was much lower.

Has our state of decentralization improved over the past two years? No, it has not. In fact, it has declined since we currently have no roadmap to decentralization. Two years ago we had a very detailed roadmap. We later abandoned it, but at least we could point to a plan. All the screenshots below are from our initial discussions with Aave:

“More non-team members will be added [to Greycore] over the coming months…” from Sep 2020. :man_shrugging:

“… not necessary at this stage…” LOL. I keep going on about TVL to bonded REN. Many here are quick to laugh and tell me that doesn’t matter! “Ha, we have Greycore, so TVL/TVB is not relevant!” Um, it’s extremely relevant, because it’s how we will finally decentralize. At least I suppose that’s still the plan, otherwise what’s the point of the REN token?

Good news, btw, is we were only at 10% bonded REN to TVL when this proposal was submitted, now we have around 16%. So it’s moving in the right direction, aided by falling TVL and the rising number of darknodes.

Bad news is how quickly TVL can change. And value of bonded REN. And the tokenomics model, central to REN, has never been tested, it’s a major issue. I remember we had a lot of discussions about this 2 years ago as it was a hot topic. Everyone knew we had to get that right if we wanted to decentralize, and we felt decentralization was very close. But then it just disappeared from discussions, overtaken by Greycore watch… Time to bring TVL/TVB discussions back, I suppose. :person_shrugging:

Not having open sourced the software will likely be another major blocker for Aave and others. Saying the “juicy bits” are already open sourced is, again, outside of the Ren bubble, not very convincing. It’s like being a little bit pregnant: either you are 100% open source or you are not, just stop talking about it until it’s 100%.

And related to that, the lack of proper audits. Not talking about piecemeal audits with limited scope, but a system wide, complete, line by line, proper audit.

Decentralization, open source, proper audits… these things are critical, and any talk of greater adoption will aways come back to these key items. Recent failures of CeFI and CeDeFi (Bancor) will only strengthen the case for limiting cooperation and partnerships to properly decentralized projects.

The proposal was never rejected. The screenshot you shared was just one user and his post has been removed from the thread…

As is mentioned lower down in the thread there was a new governance process introduced where the proposal would be put up to a vote. This is the process that renFIL went through and passed, no reason renBTC should not be able to do the same until proven otherwise.


I might have been a bit too harsh in my choice of words which took away from the main point I was trying to make.

Which was giving some push back to the claim that Ren reached a mature state in terms of utility and security while not having reached decentralization yet. Since we have not yet reached decentralization, and this is part of the original vision, it is too early to claim maturity in my opinion. At the same time requesting more funds to achieve the original vision (and bundling this with stretch goals such as L1 and smart contract capabilities), I’d be keen to first see a post mortem on what happened exactly with the original funds, why the original vision of decentralization cannot be achieved with them, how much additional runway and thus funds we think we need to achieve it etc.

Also it was said before that the team would be running nodes to fund itself. At the time it was also said that this was not done yet to not dilute the available income. What is currently the status and view on this? It still seems like a great way to align incentives.

1 Like

Not sure I follow this. Can you clarify?

I agree it’s a fantastic way to align incentives. But you need REN to run nodes. All of the REN is gone. Are you suggesting that Alameda set up nodes and give the income earned to the Ren treasury? I would guess they don’t have much REN left, either, but that’s just a guess.

On a tangent, but I see most protocols failing lately because they have too many use cases and work so hard trying to make their token the currency, adding a bunch made up stuff like high yields for and with whatever silly requirements. The only thing that matter imo is for an application protocol such as Eth or similar is reliable, fast and easy development. Example someone may use Amazon or shopify because it’s quick to buy and get their stuff or set up a shop not because someone was interested in getting some amzBucks or incentivize with some $dollars to program in the language liquid on Shopify. Basically getting just a few use cases or a few things right and having it implemented really well and not messing up will give us a first mover advantage and win out on the long run. Where am I going with this? Not really anywhere, just putting mindful info in the ether for us to think about.

1 Like

i wrote a bit in discord about this idea too but figured id add my thoughts here. while at first i was hesitant towards inflation, given the situation of our complete independence from Alameda, i think it is appropriate for the ren 2.0 team to while spinning off to the ren 2.0 token, take 40%, of which 75% should be escrowed imo, and give the remaining 60% to ren 1.0 holders. i can see that the ren team has done something extraordinary in building ren 2.0 from the ground up in such a short amount of time and want to make sure to keep the same critical people like Susruth with ren for years to come, a good way to do that is him owning a large percent of the project, in my opinion. this provides 3 benefits: 1. the team will be able to stake the 40% for additional funding from both the potential 7% inflation as well as burn and mint fees, 2. the 7% inflation can be given to darknode operators as additional fee structure, 3. to date the team has been charged with 100% of the security, when we move to ren 2.0 i actually believe it is in darknode operator and ren ecosystems favor for the team to continue this vital role with having a major hand in security, and this can be accomplished by giving ren labs the 40% to guarantee that many friendly nodes.