Agree. I was surprised to hear Catalog will be deployed first on an EVM chain Ren already supports.
If so, what exclusive features, if any, will Ren subnet brings to Catalog compared to that version on an existing chain?
2 Likes
Can anyone run a node on a ren subnet, or would it be limited to DNOs only?
The idea with subnets is to allow teams to build chains and/or applications on top of Ren, adding value to darknodes and the ecosystem, which in turn boosts the security of the network, making it more attractive. With subnets, teams can get access to a decentralized pool of validators (darknodes) to run their chains/applications, which natively supports cross-chain and multichain functionality, while allowing them flexibility in what programming framework they want to use. Deploying on some other chain and only integrating RenJS does already support a lot of use-cases, but itās not the same package deal and introduces much more dependence on confirmation times and wrapped liquidity. Deploying on Ren would significantly alleviate those multichain UX frictions. Itās one of the ways weāll stay more competitive in this scene as well.
Chicoās post regards the idea about whether nodes running on subnets would need additional bonds. This is not something we have suggested, what I mentioned previously was a design possibility where subnet deployers would need to bond some REN to spin up a subnet, which is the opposite of requiring darknode operators to bond additional REN to run validators on subnets.
One possibility we are considering is simply to make it so that anyone running a darknode can spin up a validator in a subnet, so it is opt-in, instead of some rotation mechanism where only a fixed number of nodes less than the total amount of darknodes are able to participate at one time. At least for the flagship EVM subnet that could be a possibility.
But if we want to allow teams to deploy private/permissioned subnets on top of Ren (generating volume and value for every darknode), or some fast centralized subnet with only a few super-computers powering their application while darknodes handle all the MPC stuff, then we might have to consider a model where they would have to spin up darknodes themselves to be able to run their private/permissioned/centralized subnets, since it would be impossible to force them to allow other darknodes to participate as that is not the solution they are looking for anyways.
Either way the point of it all is to bring more value to darknodes in the end. But if the community doesnāt support this proposal the team can drop the focus on developing Ren into an L1 and shift all focus to decentralizing the network, which we will make a proposal about soon as well.
3 Likes
What does that mean for Catalog? Was the Catalog design dependent on Ren being an L1, or was that just a ānice to haveā and running on an EVM chain with RenVM integration is completely fine? I suppose Iām missing the point of recreating Ren as an L1 with subnets, which seems like a radical change from where we are today. Not saying it canāt be done, just seems like a massive, high-risk undertaking, and not so sure I see a market for it, tbh. I see a market for a cross-chain AMM, but if that can be built without Ren having to introduce subnets, then why embrace all this complexity and uncertainty? I say letās go for something we can actually deliver in a reasonable amount of time.
And yes, actually building a decentralized network of Darknodes should be our primary focus, imo. I didnāt realize it was an āeither orā option ("the team can drop the focus on developing Ren into an L1 and shift all focus to decentralizing the network"). To be honest, I canāt see anyone building their own apps or chains on Ren L1 without decentralization at a minimum, so this was going to happen first anyway. Maybe Catalog, OK, itās more or less the same team. But anyone else? Doubtful.
And from a business perspective, who is asking for a Ren L1? Apparently Catalog can function just fine without it. I canāt see any established project like Curve, Aave, etc. building on Ren L1. Can you imagine the process to get community approval from Aave to join a Ren subnet??? I would think a better business model is we help existing or new projects go cross chain by incorporating Ren into their stack, not having them come join a Ren subnet.
Letās get back to basics and deliver what was promised, what has been on our roadmap for years. Letās focus on decentralization so we can have credibility across web3 as a cross-chain option with a unique value prop (h2h). Letās focus on differentiating renBTC from wBTC (still 99% of our volume!), and work with projects to create use cases that can drive renBTC volume further. Letās look at helping permissioned chains move assets onto Ethereum, Solana, Cosmos, BSC, etc. For that we need bus dev and marketing people focused on that segment. No doubt our friends at Alameda have many contacts, why wouldnāt they help? I would expect permissioned chains to take off in the coming years, as countries and corporations look to interact on-chain, but in a more tightly controlled space. But theyāll want to move assets on and off Ethereum, certainly. Seems like there are so many business possibilities that donāt require us to transform ourselves into an L1. And where we already have credibility. Why donāt we go for those?
If the community chooses to focus on Ren as an L1, I really hope weāll see a lot more details on how thatās going to happen. More technical info, plus a detailed roadmap and frequent progress reports (not monthly or quarterly updates lacking substantive info). Because Iām incredibly skeptical it can be done in any reasonable time, and Iām also skeptical there is a market for it once built.
8 Likes
Just want to make it clear I am in favor of the subnet direction the team is proposing and that @DeFi_Whiskey is not speaking for the whole Ren community.
1 Like
without smart contracts, ren will never have liquidity and eventually die out.
susruth said it should be ready in less than 12 months.
all the time ren was doing the major redesi
gn and ended up not using it, ever.
all cross chain Smart Contracts where bridging is no longer necessary is a huge thing.
1 Like
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 
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
Iām with whiskey here. This new subnet design is a little concerning to me. It almost seems to me like the project is stuck at an impass the team canāt get past and so is stuck at square one trying to reinvent the wheel to find a solution. Why exactly must the focus be either decentralization or turning ren into an L1? What has the point of bonding nodes for 2 years been if not to further develop renās decentralization? Is there a report that can highlight what the 1k+ nodes have been utilized for in the last 2 years?
4 Likes
Without smart contracts we lose a lot of things.
In the end, we build where it is easiest and cheapest.
Without smart contracts, we wonāt really be able to differentiate ourselves from layer zero and other messaging protocols.
Max, hypothetically what are the pros and cons of focusing on decentralization first, getting the roadmap fairly complete, and then moving toward a more sophisticated protocol design? Is it impossible, or just extremely difficult? I understand attempting to perform a major system upgrade to a group or 2 groups of decentralized nodes while in custody of billions $$$ is not an easy or comfortable task but a clear picture of just how tough it is may help clarify for some.
Another issue I think that may be influencing others is confidence in this 12 month time frame. I for one, respectably, would not place a bet that this would be accomplished in that time, and it is a risk to lose any momentum we have for a better solution that could potentially, like we have already seen happen, present a number of unforeseen difficulties that pushes 12 months into 18 or 24 months.
So along with clarity on the difficulty to switch post-decentralization, clarity on the confidence you guys have that you can actually achieve a massive overhaul in a year or less. Is the bird in hand better than two in the bush? Perhaps the space has plenty of time for us to try, I donāt know.
5 Likes
Very interesting and always appreciated your opinion.
If we continue without greycore, would it affect the relationship with curve and alameda and the other partners?
-what would become of the serum & ftx integration?
-what about all the work the ren team has put into greycore and security?
-is this not developed yet or what would happen from it?
- think we should take the L1 model which suits ren best and offers the best UX and application areas and also put a lot of research into the area with private sidechains (hyperledger) that it is a very popular tool with many (very many) interest of companies.
I just saw some research on this.
Because Hyperledger can be viewed as a building block with which everyone can do what suits them best,
but this only makes sense with Smart Contracts (l1)
that would set us apart from most of the competition.
Iām curious about your opinion.
This was specifically mentioned by Susruth earlier above in this proposal: ā A subnet can have an additional bonding requirement on top of the 100k REN staked to run the DNā
This is the bonding that it is still not clear in which currency is being thought out to be.
This comment is kind of worrying. The first post where proposal is presented sounded like an invitation to discuss and to try to tailor the model taking into consideration possible concerns and/or different points of view. As with any discussion, and more with something that drastically change the network, questions are to be expected. We must be open to accept that not all points may be supported and then we work together to sort those in order to move forward. But these type of āeither or nothingā comments feel like an ultimatum and itās not great.
Regarding @DeFi_Whiskey post I also agree decentralisation and full renās crosschain function (aka H2h) are always a requirement to move forward regardless of the model and even more if being an L1 was/is on the table so this should never have been delayed.
I think as a community we are ready to support any proposal but all aspects should be well explained first in order to have a clear picture and being able to make an educated decision. I/we also expect that modifications will be considered to meet community concerns.
1 Like
I think that the complete ren l1 should be built first because everything is much faster and then ren will be decentralized.
the question how much can be done in parallel and how long would a decentralization process take?
@Susruth
?
If we seriously plan to move to a Ren L1, I would hope we at the very least have a handful of launch partners lined up in advance, i.e. before we make this massive pivot. Reputable projects within crypto that are interested in being part of the Ren L1 Beta launch. Names like Badger, Curve, etc. Or at least mid-tier projects. Independent projects that need to coordinate with their communities, i.e. the types of projects weāll need to attract once this actually launches.
Ren has credibility in crypto, we can easily arrange calls with many reputable projects to present this new vision. And since Iāve been informed Ren L1 will only take a year to build (note: I donāt believe this at all, but ok, Iāll defer to the team), I think the time is now to line up Beta launch partners, right? Their feedback will also ensure we are scoping the technical requirements for Ren L1 adequately.
Getting community feedback on moving to Ren L1 is great. Getting target usersā feedback and tentative commitments to be part of this new journey once launched is even better! And since this info is all public, the Ren community - or a small number of community members, e.g. an "Ren L1 Evaluation Working Group - can participate on these calls, too, report back to the community, and help us make a more informed decision on next steps.
4 Likes
I mean, what is there to say? After years and years of promised decentralization with very little actual results in production (based on published posts, roadmaps, etc. by the Ren team itself), Greycore was at least a plan to become more decentralized. It was at least something tangible. And required reputable projects like Curve and Badger to be more involved, look at the Ren code in more detail, involve their communities, etc. And now youāre proposing we scrap even that, in a post that states privacy and decentralization are critical?
At some point you have to ask what has been built to date, right? A centralized bridge run by a small team? Am I wrong?
Iām not fixated on Greycore per se. Iām fixated on decentralization. What is Renās plan to achieve that, if Greycore, something that has been promised for years (I was informed itās going to be āa blastā), is thrown on the dustbin of history? Whatās your decentralization Plan B?
This seems like something that requires a lot more detail, no?
Why not? Bonfire of the Ren vanities. 
Aha. Ok, here is the meat. But if youāre going to scrap the one path we have to being somewhat decentralized (I realize Greycore is just a Zwischenzug), then please give us a lot more details than this, ser! I would love to learn more about this new and exciting journey! How will TEEās and new tokenomics make us decentralized?
Yea, although I do like this subnets proposal, when I step back, what you are saying makes a ton of sense and is probably felt by many in Ren community. It feels like, as a community, we are always just waiting.
Look at H2H. Weāve been waiting a year now for it. Everyone got super excited and launch announcement in December was useless b/c there was no UI bridge yet. 5 months later, we are still waiting and excitement for H2H has died down.
Next is Greycore. Super criticial b/c itās first step in decentralization. Itās been 5 months since we first learned Greycore was live on Testnet with the first member. The Q1 update didnāt even tell us anything new. We already knew Greycore was on Testnet and it didnāt bother to clarify if more members were onboarded.
Now we are looking at Ren becoming a layer 1. Susruth said in Discord that current thinking is that it would take less than 12 months. Based on how the rollouts of H2H and Greycore have been going, this becomes really hard to believe and just adds something else for Ren community to be waiting for.
6 Likes
I understand there is a bit of a bitter taste around Greycore but I donāt see that as a reason to get hung up on things of the past. I think we all agree on what kind of outcome we want, I wanted to express my opinion around that outcome.
To me Greycore is not even a āzwischenzugā, itās an element that will need to be removed later on regardless and we should consider pivoting beyond that instead of holding on to old promises that might just delay the final outcome we all want, decentralization.
If I misunderstood please enlighten me how Greycore is a milestone when at the end of the day all it achieves is a federated model of semi-decentralization (and locks us to that model), that model will be ripped apart amongst savvy CT peeps imo. Also, the Greycore model is kind of what wBTC was already doing with with a consortium of big projects being part of their multisig.
+++
I think the key to this all is privacy (TEEs). If nodes operate in āblack boxā kind of environment the risk of colluding is severely decreased. When nodes do not know what they sign (but can verify its correctly signed) and at the same time (through sMPC) only have access to a part of private key (they donāt know which part), I donāt see how they could collude. But someone more knowledgeable around this would need to chip in, I could be wrong.
The team has already compartmentalized things in an eloquent way where no set of nodes can access all of the TVL. To protect against TVL of a specific āconsensus roundā to be drained it is important to have sustainable tokenomics so the network can heal itself in case of exploits. Not sure if you had a look at the rough tokenomics change I wrote above and what you think of it?
In the new tokenomics model I suggested regular stakers that dont run nodes, maybe there is some technical feasibility for them to act as second signature to all txs as added security/decentralization (instead of greycore) while they dont need to run any heavy computation such as MPC?
+++
Also, Iām only thinking out loud here to invite new ways to see things and Rens future beyond what we have believed to be right in past. Not saying this is the way to go, I just donāt believe Greycore is/was a good solution.
If we put all our brains together I think we can find a better solution, but that requires everyone to be a bit more open minded instead of approaching the team with an entitled āwhat have you done for me latelyā attitude
I also donāt think this will delay things, quite the opposite, it could speed things up beyond what we had imagined before.
There are plenty of privacy protocols out there we can learn from. Plenty of failed/successful blockchains out there we can learn from. Its not about re-inventing the wheel here, its just slight architectural design changes to achieve decentralization/security asap
1 Like
Is this for me or the core team? Iām only expecting the team to deliver on their own roadmap! Isnāt Greycore something weāve been discussing for maybe 2 years? I didnāt make up the term! Btw, this is the first Iāve heard Greycore is actually a waste of time, but Ok, you may be right! Iām not qualified technically to answer. But it would have been nice to hear this argument 2 years ago, tbhā¦
Agree with you that the āmeansā are not as important as the āends,ā Iām not fixated on Greycore per se. But I do want the team to actually deliver on its professed roadmap, and the last time they published a roadmap (granted, long ago), Greycore was on it. I believe it was even in Loongās farewell address to the community as an imminent deliverable. But Iām honestly not so sure what is being developed now, tbh 
.
My main issue. which I suppose Iām repeating ad naseum (my apologies!) is there doesnāt seem to be any transparency or accountability in this project. Iāve heard about the strategic importance of h2h and Greycore for a long time, suddenly weāre building subnets. Letās have a clear actual vision and roadmap, letās have dates and people responsible, and letās monitor progress. Delays happen, weāre not children, we can work though it as a community, if everyone is serious about the vision.
My apologies for believing Iām entitled to know whatās actually happening with Greycore and a host of other issues about which the team is eerily silent. Transparency is a noble goal, but alasā¦ Iāll go back to patiently waiting for those quarterly monthly updates.
Was for you, the community and the team. Everyone
But feels like we are just circling around same things, I just wanted to encourage more discussions and provoke thoughts on how we can improve and possibly change the roadmap you so desperately want them to live up to, even if it doesnt benefit the protocol.
Sounds like you just want the team to lay out everything, I want whatever thats to be decided to be a result of community discussions.
1 Like
I would like to be able to build my apps on ren in the future with good ux and cheaply and directly cross chain and ideally with hyperledger possibilities.
All of this works best if we all make a decision together without allowing too much criticism and work productively.
1 Like