RFC-000-036: Ren 2.0

Quite interesting RFC with many thought provoking posts which feels quite encouraging.

I would like to take the opportunity to express my views beyond just the subnet topic, views I was not sure how to share before as it could be perceived as contentious and distracting. Feels like now is the right time :slight_smile:

In the beginning when I joined the community I had been a vivid community member of secret project (at that time called enigma). Long story short the Ren team and community resonated better with me and I eventually moved over full time. The reason I shared that serves as a preface to the main things I find important:

  • Privacy
  • Decentralization/Security
  • Interoperability
  • Permissionless/trustlessness (inclusivity)

To begin with privacy, I feel this category deserves a bump up the priority list. Not only for the benefits it brings users and developers, but also the security it brings to the network. This leads me to the (possibly) controversial take of Greycore, I am of the opinion we should scrap it.

Decentralization is probably the most important milestone to reach in the near term, I don’t believe a federated model with Greycore is the right solution and I would not be surprised if Ren community would later vote for its dissolvement. I even think we can achieve decentralization faster by just avoiding Greycore deployment to begin with.

There is just too much risk around having a few well known parties acting as second signature for every txs. And we have all seen how much discussion that has come up over Alameda Ren acquisition, as a decentralized network Ren should strive for zero external influence.

Now many will immediately bring up the TVL/TVB security ratio, I am of the opinion we should scrap that as well. Focusing on trusted execution environment (TEE’s) and privacy in general, and possibly a modification of tokenomics, I think we can achieve security/decentralization without TVL/TVB theorem as well as Greycore.

At the moment a huge risk for a model like Ren is that it acts as a custodian which has a flipside of also being a honeypot. To realize the “republic protocol” vision of boundless liquidity as well as darkpool for all of crypto, privacy needs to be prioritized. With privacy I also believe it will be easier to achieve decentralization/security.

Interoperability is already sorted with the sMPC model and permissionless/trustlessness (inclusivity) is an outcome if we achieve all of the above.

+++

To get to the subnet model, which sounds very interesting, I am not sure how it will influence the points I mentioned above. I am not fully convinced other projects will be enticed to even consider Ren subnets until the points above (privacy+decentralization) are resolved.

If the subnet model would be chosen I would like to see DNs be involved in every subnet by default, with a (random) rotational system similar to thorchain where all participating nodes will benefit and projects/subnets cannot select their own “favourites”.

If a subnet requires high performance hardware then they can set criteria nodes need to meet, any node meeting those criteria will be part of the churn with randomness (and preferably privacy). Also all interop txs should go through RenChain to benefit all DNOs equally regardless of hardware criteria.

+++

Another model I find interesting is a the modular one (like Celestia). I am not literate enough to know if it really is feasible for RenVM but it is an eloquent way of offloading a lot of burdens most Blockchains out there face.

+++

Lastly I also believe a bump in Rens tokenomics and just maintaining its own chain (L1) could possibly be the easiest(?) solution. Let’s say we introduced a new token, xREN, that was airdropped 1:1 to all REN holders. This token would serve as gastoken which any user of RenChain would need and anyone could bond any amount of REN to stake xREN. So initial supply would be 1 billy with an emission schedule community would agree on. Also nice if xREN could be a privacy coin hehe.

This might require DNO to maintain a bit more hardware intensive nodes (to manage load of everything being on RenChain), I do not see that as a problem though as I believe there are more than 10,000 entities out there who could run complicated nodes, especially if the rewards are juicy.

As I usually like non-inflationary models I would even suggest that xREN used as gas is simply distributed back to DNO and REN stakers. 50% of emissions could go to DNO and 50% could go to REN stakers (or whatever model community decides), that would incentivize people to buy and stake REN beyond just running a DN.

This would also make pooling solutions (as well as liquid staking) a lot easier for REN stakers who do not run a node. Can also be discussed how much governance power stakers could have, which could be regulated by conditions such as staking time and so on.

Maybe the xREN supply could be slightly higher than REN supply so there could be a bootstrapping phase where stakers and DNO would receive xREN from regular emission. Maybe even other projects on top of Ren could stake their tokens (eg. CAT) to receive xREN where 50% would go to DNOs and 50% to CAT/REN stakers. (I see that would dilute regular REN stakers a bit but just thinking out loud here)

Main purpose would be to benefit DNO the most as they secure the network and the more their 100k REN bond is worth the more secure the network is in terms of self healing capabilities.

+++

To not make this post too long I will stop there even if there are still ideas to present. Would love to hear from community how you feel around these topics? We have maintained our integrity during this bullrun and not given in to ponzinomics and have been one of the most secure options out there, now how do we leapfrog past competition and beyond!

6 Likes