RGP-000-001: Renbase: Decentralized Liquid Staking for Ren

Thanks for submitting the RGP. Great work but I have a few questions about yourself.

  1. Who are you? Could you explain your background and what you stand to gain from this proposal?

  2. Will you (any anyone receiving funds) be doxxed to anyone?

Thanks.

Thanks Chico for everything you do and for this - tackling the pooling issue that’s been on many wish lists for quite awhile.

Couple questions:

  1. I noticed in a post above that you expect a renbase node operator to earn more in rewards than a solo node operator. Or to quote, “these amount to incentives for operators that would well exceed those of operating solo”. This is a little confusing. Does a renbase node operator actually need any Ren to be an operator?

  2. what do you expect the difference to be in rewards between a solo operator with 100k Ren vs someone who deposits 100k Ren into renbase?

  3. building on question #1, if a renbase node operator does not need Ren to operate a node, what are their incentives to not act maliciously. With thousands of nodes being governed by renbase node operators, hopefully they have proper incentive not to collude or be bribed

Thank you

1 Like

Thanks, @HarryRobson.

  1. I’m a full-stack Solidity developer who’s been active in the Ren community since early 2018. I was a lead software engineer at a venture-backed robotics startup in San Francisco for 4.5 years and have won 1st place prizes at a couple of large hackathons, most notably TechCrunch Disrupt, DeveloperWeek, and Launch Hackathon.

  2. Yes, I’m doxxed.

Thanks, @shiny.

  1. In Phase II, operators will absolutely be required to have REN, and all nodes will be sufficiently collateralized to (a) disincentivize misbehavior and (b) recover all or most of a slash penalty resulting from such misbehavior.

  2. In Phase I, a depositor of 100k REN would be subject to whatever is levied by the soft cap; a measure to limit too much adoption all at once and to mitigate the impact of permissioned registration on the Nakamoto coefficient of the operator set. In Phase II, a depositor of 100k REN would likely only incur the operator fee, subject to governance. Notably, since that fee would be a percentage of one’s combined Darknode and Renbase rewards, it would be of a larger pool of rewards than solo operators’. So, for example, if the absolute fee were x%, the fee relative to solo operators’ rewards would be some degree less than x% for stakers and some degree more than x% for operators.

  3. N/A

Hi David, it’s great to see some of what you’ve been spending so much time working on. I am excited about increased decentralization, security, and incentives for more people to hold and stake REN tokens. I have a few questions.

  1. I saw you mention that Ren Labs helped with a few updates that will make Renbase a bit easier to implement, which is great. Since running a DN is permissionless, would Renbase need any permission or cooperation from Ren Labs or the community to fully implement? My inclination is that it would not since anyone can spin up as many dark nodes as their bond supports.

  2. You answered Sabobi’s question that Renbase would have no central components in its final stage. Will the collected Renbase stakers and operators be able to modify the code for further updates/refinements/security-patches once that state is reached through coordinated cooperation or internal Renbase governance?

3.) Will operators be manually registering and deregistering at the epoch changeovers, or will some of this be done via smart contract or some other form of enforcement? I picture their bond/collateralization being tied up in the smart contract, and they would receive an edict or set of requirements to manually execute to remain in good standing. To what degree would their manual intervention be necessary? Could you elaborate on this at all?

4.) In the final state, operators will be able to come and go like stakers according to the constraints of the smart contract and the market forces that rewards participation/etc?

5.) For Renbase’s own decision making and operation, will it have its own treasury or collect a percentage of Renbase rewards to fund it? Do you picture a Renbase token to perform any function of that internal governance or for use in funding the operations?

6.) Related to SeekingKnowledge’s question – I am very interested in how incentives might be created on purpose or accidentally that could lead to the collected Renbase participants acting as a single voting bloc that could hurt the decentralization or security of the Ren network. My concern is how something as seemingly informal as a “Hey fellow Renbase users, can we come to a consensus on how we should vote for RIP #116?” could lead to a sort of Renbase default position rather than each Renbase user coming to their own conclusion about the best decision to make for the health of the overall Ren network. It is natural that a Renbase user might have a particular incentive to vote one way or the other, but have you given any thought to how Renbase could be aligned in way to prevent the coalescing or grouping of such a large number of network participants into one bloc and the perverse incentives that could create for governance or security? Do you have any thoughts in how it could prevent that sort of single-minded-vote-accretion? I ask this in the context that there are of course natural self-interested reasons why group members might be incentivized to speak with a voice that carries the same weight as their collected network participation.

7.) In answering Sabobi’s question #3 – do you mean giving Renbase users voting power in addition to the already-existing permissionless voting power that the Renbase DN operators would already have? Because governance participation is permissionless and available for DNOs to participate in, I don’t see that Renbase stakers or operators acting on their behalf could be prevented from participating in governance (nor would we want them to be since increased participation and decentralization of voting is useful to Ren overall in a similar way node operating and validation will be), or are you suggesting that the ability for Renbase stakers/operators to participate in Ren governance might be contingent on RenDAO’s permission?

8.) Related to shiny’s question – Can you elaborate more on what would be required of operators? You mentioned sufficient collateralization. Do you foersee that being 100% or more than the 100k required for a dark node? It seems important that they are collateralized to the amount that would make the rest of the pool whole in the case of a malfeasant operator. Would their over-collateralization be put to work in the pool and earning rewards so that they remain incentivized to provide the required amount?

9.) Do you see any dynamic changes to the incentives offered to stakers or operators based on the how decentralized the Ren network is? Based on the relative supply/demand of stakers vs operators?

10.) Will operators and the stake they bring to Renbase be subject to similar joining/leaving constraints as stakers’ contributions?

11.) Related to Thomm’s question #3, would Renbase see any value in implementing a limit (dynamic or otherwise) to avoid concentrating too much of the network under one protocol/smart contract and the risks of an unknown catastrophic security flaw or attack that could result? For example: RenBase will refuse new stakers/operators once Renbase represents more than 50% of the total Ren network and will re-enable new stakers/operators once their share of the network falls under 50% again. Or can you elaborate on why this isn’t a concern – e.g.: the operators work independently and manually to spin up and spin down nodes based on the requirements and directions of the protocol/smart contract, and therefore the operation of the dark node is not so directly connected to the smart contract beyond incentive/collateral.

12.) Do you see any incentive for a DNO that has 5 nodes of their own to operate those nodes at Renbase rather than directly themselves? (I’d assume the operator incentives hinted at would might come into play.) Can you describe why a DNO would want to remain their own operator outside of the Renbase system?

13.) Do operators spin up nodes using their own keys/etc?

Thank you for working on such an important piece that seems like it will be getting more, not less, important going forward.

3 Likes

Thanks for all the great questions, @Renfield.

  1. No permission needed. However, there will naturally be some coordination with Ren Labs over time to ensure both projects are on the same page.

  2. Upgradeability will remain enabled as long as Renbase and Ren continue to mature. Eventually, it will be handed over to governance.

  3. In Phase II, operators’ (de)registration UX should function like it does today. They would spin up their node(s) locally, but instead of (de)registering and refunding through DarknodeRegistry, they would do so through the Renbase contracts. Let me know if this doesn’t answer your question.

  4. No, in Phase II, operators would not be able to come and go like stakers and would be subject to the same deregistration period as solo operators. Otherwise, an adversary would be able to misbehave and withdraw their bond before being caught. And even if their node were deregistered upon withdrawal, they would still have an ability to misbehave in that epoch. While there are ways to circumvent the barriers to entry described in the RGP, this is one aspect that must be implemented in accordance with Ren’s security interests.

  5. Nothing in this domain has been confirmed yet, so I don’t want to speculate. But there will very likely be a token.

  6. To echo these thoughts on voting power, it will be entirely up to RenDAO to decide how or even whether to recognize Renbase users in Ren governance. RenDAO could give voting power to operators but not stakers, to both cohorts but weighted differently, or to both equally based on the quantity of REN they’ve contributed to security over time. The voting power logic is flexible.

  7. At a high level, anyone would be able to participate in Renbase governance without RenDAO’s permission. What does require RenDAO’s permission is whether Renbase users would have voting power in Ren governance.

  8. Your point about being able to make the rest of the pool whole in case of malfeasance is spot on. However, not all collateral needs to be in REN.

  9. Based on the balance of stakers and operators, definitely. A dynamic fee would make a lot of sense, and the redacted feature mentioned a few times is related to this, though it requires some more research.

  10. This seems like the same question as #4, so I’ll refer to that answer.

  11. There will definitely be a self-imposed cap in Phase I to limit too much adoption all at once and to mitigate the impact of permissioned registration on the Nakamoto coefficient of the operator set. It would also make sense to keep a cap into the early innings of Phase II as well, but it should eventually be lifted altogether as the protocol derisks over time. I think you nailed the last point on why this wouldn’t be a concern.

  12. DNOs would earn more by operating through Renbase than they would by operating solo. While there may naturally be some migration from solo operators, these kinds of incentives are needed to attract the roughly 47% of the token supply that is able to be bonded but is not.[1] DNOs may want to remain solo to not forfeit their voting power, if they don’t have or want to post other collateral, or if they want to minimize exposure to implementation risk.

  13. Yes, operators will spin up nodes using keys generated on their own machines.


  1. Based on a snapshot of operator addresses, REN balances, and aREN balances earlier this epoch. This figure does not filter out Alameda addresses, nor does it account for CEX balances. ↩︎

2 Likes

Judging from the vote count on Snapshot, further discussion at this point is academic, but I would still like to register some thoughts.

Perhaps naively, my idea of staking pools prior to this proposal was simply as a mechanism to foster and encourage participation of <100k Ren holders. In my thinking, this service in and of itself would foster wider participation and make the ecosystem more robust by democratizing and further enabling bond participation.

As has now been made clear, a shinier, more dynamic, uber-protocol is now on its way to town, and if implemented successfully as of phase II, would almost certainly render the current picture of running a DN obsolete due to its enhanced rewards mechanism. It seems the on paper reasons Chico provides for why operators may want to remain solo would not stand up to the realities of market forces and inexorable operational pressures, if Renbase is implemented as stated. Of course, there are always going to be holdout DNO’s happy to operate the old way, but I’m referring to practical considerations, in terms of % of solo DNO’s vs Renbasers.

Thus, this leaves one simple question for the community: are we comfortable with a future in which a majority of the bonding, undergirding and operation of the network is realized through one protocol, the Renbase protocol? If so, then hooray for this new development, and let’s all get behind Chico in this new co-evolution of Ren, along with 2.0 on the way.

I’m a forever Ren Holder and DNO, whichever form that identity takes in the future. All the best to this community, and long live the Ren Protocol.

2 Likes

It has been discussed in discord that, through governance, Renbase could have some rules in place limiting the % of overall nodes it is able to control. While this decision would limit the overall number of nodes and decrease decentralization and security in that regard, it would encourage more solo operators which enhances decentralization and security in other ways.

I would like to hear some discussion about the pros and cons of a higher % threshhold, and if it is benficial to have more solo operators, what are some ways to reward them and attract them? Since just depositing 100K Ren into Renbase seems much easier and perhaps secure than dealing with the hardware and software connections, and if the rewards are not that much less I don’t forecast too many solo operators.

This is precisely my point when I say “market forces and operational pressures.”

And my understanding is not that RenDAO can enforce a cap on the number of Renbase operated DN’s. Chico stated that over the course of Phase I and early in Phase II there will be caps, but after that, it’s a free and permissionless Metaverse.

And besides, this free and permissionless nature means if Renbase doesn’t do it, someone else will come along and do it at some point, and the only way to curtail that is an arms race vis a vis Lido vs Rocket Pool for indomitable market share.

If capture by large influential pools is inexorable, then it’s incumbent on the community to actively monitor such developments and make whatever feasible and necessary steps are needed to ensure the safety and thriving of the Ren protocol long term. We can’t really control what outside parties do in an open and permissionless ecosystem.

1 Like

I’m still not clear on what would be the requirements to be an operator. How much Ren do you need, how much “other” collateral, and how many nodes can an operator run? Does every node an operator runs require equal amounts of collateral, or do multiple nodes require less collateral per node of the operator?

The working idea is for operators to bond 50k REN and a sliding scale of “other” collateral where more collateral earns more rewards. This could be something like 25-150% worth of 50k REN, where nodes would not earn rewards for any collateral above that 150% threshold.

In Phase II, registration will be permissionless, so operators can run as many nodes as they’re able to. Each node would be subject to the same collateral requirements because you don’t want to give whales a discount in case they turn out to be adversarial.

1 Like

Update: the grant is approved (Snapshot).

1 Like

It would be great if those who voted against the proposal could voice their opinion in the form of constructive feedback and criticism here on the forum.

In that way RenBase might actually be able to take it in to consideration, and hopefully arrive at an end state which has higher consensus among DNO than the ~64% of the Snapshot vote :innocent: