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

Thank you Chico for all that you’ve done. Something like this is long overdue. Very excited to see this all pan out. I think $285k + an extra 50k for your troubles is more than acceptable

3 Likes

Thanks, @OneofTenThousand. The budget below represents the bare minimum needed to get Phase I to mainnet. It was prepared in consideration of wanting to leave the CEF with enough capital to fund other important initiatives that may come about.

  • Audits: $100k
    • Included in this are 2 smart contract audits and 1 infrastructure audit. The 2 smart contract audits will either both be allocated to Phase I or split between Phase I and II.
  • Legal: $45k
    • Conservative estimate based on feedback and Renbase’s expected future roadmap
  • R&D: $115k
    • Includes resources for 2 core contributors. This is forward-looking and does not include retroactive payment for my work to date.
    • This will need to be complemented by a contributor grant paid in future tokens.
  • Operational: $25k
    • Includes gas for on-chain transactions in Phase I, like (de)registering and refunding many Darknodes, etc.
    • Includes costs to operate off-chain software components.
  • Total: $285k

This does not include a bug bounty program. During Phase I, if a soft cap on the number of nodes needs to be imposed during the controlled release, proceeds may be directed toward a program.

The tightness of this budget is probably a good argument in favor of inflation in Ren 2.0. Other projects will inevitably need help bootstrapping their applications, and it would make sense for the Ren community to be able to provide some of what’s needed.

5 Likes

I am pasting this question over from Discord:

Interesting proposal here… is the Ren labs team onboard and does this affect prior tokenomics discussions related to our transition towards an L1 blockchain? Would token inflation play nice with your model? Thanks for thinking all this through.

Good questions. Labs has actually already merged a few pull requests to help optimize some stuff in Renbase and has been pleasantly receptive to making staking happen. As far as inflation, there may need to be some minor updates depending on exactly how it’s implemented in Ren 2.0.

3 Likes

Thanks, @SeekingKnowledge.

…how do you envision Renbase’s structure/framework in regards to relying on centralized hosting providers such as AWS or DO to operate nodes, and the possible attack vector posed by any overreliance on those centralized entities?

Ultimately, the goal is to let anyone participate in Renbase as a node operator, so as Ren Labs supports more ways to run a node, the hardware composition of Renbase nodes would be as diverse as operators want them to be.

For Ren governance matters, what type of framework or logistics do you envision to help reach consensus among all stakeholders/participants in Renbase, when issues that requiring voting for node operators come up?

Currently, voting power is measured by the square root of how long a Darknode has been registered in months. For example, if an operator has 2 nodes registered for 9 months each, their voting power would be:

sqrt(9) + sqrt(9) = 6

We can also imagine this as the square root of how long 100k REN has been bonded to a registered node in months. For example:

sqrt(100k / 100k * 9) + sqrt(100k / 100k * 9) = 6

We could do the same in Renbase. If the Ren community agreed to do so, it could recognize Renbase users’ voting power by the square root of how long 100k REN has been deposited in months. For example, if an operator deposits 50k REN in epoch N and 33k REN in epoch N+3, then in epoch N+9, their voting power would be:

sqrt(50k / 100k * 9) + sqrt(33k / 100k * 6) = 3.53553390593

Now let’s say they withdraw 50k REN in epoch N+7. Currently, deregistering a node forfeits the voting power of that node. If we apply the same principle using last-in-first-out (LIFO), they would lose the voting power of their 33k REN deposit as well as 17k REN of their initial 50k REN deposit. In epoch N+9, their voting power would be:

sqrt(33k / 100k * 9) = 1.73205080757

This is just one option, and the voting power logic is flexible. Ultimately, Renbase will support whatever approach the Ren community decides to take.

3 Likes

Hey, Chico; great proposal. Thanks for the detailed and comprehensive outline of what Renbase would entail. The community has been requesting essentially, this service for a long time, and the security add-ons inherent to the protocol are a welcome bonus.

My one question at this time would be how you see Renbase impacting the epoch rewards of current DNO’s in the short term, barring some level of exponential increase to Ren TVT?

The way I read it; Renbase could dramatically increase participation in Ren bonding, but without a proportionate/outpacing expansion in TVT, it seems to me, this would measurably dilute epoch rewards to current DNO’s.

And if I’m reading and understanding correctly (which I may not be), Renbase will have as a core feature, code to divert forfeited Renbase deregistration rewards from “solo” operators back into the Renbase protocol to further incentivize Renbase staking. Would this not negatively impact interest in being a “solo” operator, possibly detracting from overall Ren security as DN and protocol ROI is impacted?

Again, thanks for the work and effort put into this. I look forward to seeing the community discuss and hash this out even further.

1 Like

Thanks, @Useful_Idiot.

It is actually not a goal of Phase I to dramatically increase participation, for two reasons. First, as mentioned, confidence in the implementation takes time, so there will be caps in place to limit adoption that will be gradually (but never completely, for the next reason) lifted over the phase. Second, one of Renbase’s two mandates is to maximize the Nakamoto coefficient of Ren’s operator set, which is impossible to do as long as registration is permissioned. For those reasons, the short-term effect on operator rewards is expected to be modest.

Phase II, however, is all about operator incentives. They would earn the exclusive Renbase rewards discussed under Core feature: rewards flywheel that you alluded to, in addition to a percentage of stakers’ fees. On top of that, there is a third source of rewards, redacted in the feature list and not implemented in any other staking protocol to date, that is under research. Together, these amount to incentives for operators that would well exceed those of operating solo, which are needed to get more nodes online in a decentralized way.

1 Like

First of all great write-up, awesome proposal, thank you for your work @DavidPerkins!

Wonderful to see the engagement and thoughtful questions from the community as well.


That being said, allow me to pose some questions of my own that I would love to hear your thoughts on:

  1. Regarding the withdraw-or-request feature;

    1. How does it work in practice if there is no liquidity available and a node needs to be deregistered to satisfy the request, do the requested REN go to some special bucket where they do not earn rewards, or are eligible for voting rights etc. I could see how you could otherwise grieve the system by not withdrawing after the deregistration. But I’m sure you thought of this.

    2. If there is no liquidity available, but it becomes available because another user deposits before epoch end, can a user immediately withdraw or do you still need to wait for the epoch to end. In other words, in your flywheel example 2, can Alice withdraw after Carol deposits but before the epoch ends?

  2. Regarding the REN-related transactions deadline at the end of each epoch; you mention this guarantees that the number of nodes registered will be correct at the start of the epoch. In my experience relying on such guarantees that span several software systems is bound to bite you at some point, as they are never guarantees 100% of the time. Can you maybe explain in a bit more detail why I am wrong, or if you have thought about additional fallback/fail safe mechanisms? I suppose you can reward users prorate based on the actual nodes that (de-)registered for example.

  3. Operating nodes through RenBase has many advantages, this could potentially introduce another risk factor to the network when most nodes will be operated through RenBase. More decentralization and more nodes (increasing the Nakamoto coefficient as you say) could make the network safer and more robust against economic attacks and censorship, on the flip side the RenBase layer adds complexity which could make the whole network more prone to bugs and hacks. For the network as a whole, we might also want to optimize a healthy mix of solo operators, RenBase and potentially other staking services. Interested to hear your thoughts on this.

  4. The requested grant will only go so far, how will the project be funded after the grant runs out? Do you expect more grants to be requested, or will there be other ways to fund the project after it has been bootstrapped (collect fees, token launch, other). Details could be disclosed or worked out later, but will be good to know if the project expects to be self sufficient after the grant or if more grants might be necessary.

  5. Lastly, will everything be open source, and if so when?

Very excited to see this come to life, cheers!

2 Likes

Thanks, @Thomm.

1.1. Yes, requests forfeit that amount’s worth of that epoch’s rewards because requests can trigger deregistrations, and deregistrations forfeit rewards. For example, if Alice requests 100k REN, that could trigger a deregistration that forfeits one node’s worth of rewards. Naturally, Alice should be the one to incur that forfeiture. Voting power will depend on what the Ren community decides upon, but in the proposal a few posts above, requests would forfeit voting power. There’s a strong argument against this though: it may disincentivize requests and withdrawals, which we want more of to accelerate the rewards flywheel. There is no risk of griefing by not withdrawing after a deregistration.

1.2. Yes, in that example, Alice can withdraw Carol’s deposit before the epoch ends.

2. That is definitely true. The deadline itself does not guarantee anything. It merely allows for the number of nodes (de)registered on-chain and provisioned off-chain to align with users’ balances. I edited the post with the change in wording. Thanks.

3. A healthy mix of solo and staking operators will be key. But while it is true that all protocols come with implementation risk, it is worth pointing out how concentrating around one staking protocol could be in Ren’s long-term interests. Economic security goes up when more operators participate, which they’re more likely to do given stronger incentives. It is based on that premise that Renbase is heavily optimized to maximize those incentives, which grow stronger as it attracts more liquidity. A keen reader may have noticed how a deposit by one is able to increase rewards for another instead of diluting them (in both diagrams in the RGP, note how Carol’s deposit facilitates a withdrawal by Alice that increases Bob’s rewards). This makes Renbase a positive-sum game for stakers. So, with more liquidity to fuel that game, the incentives to participate and contribute security grow stronger. With strict implementation security measures in place and the resources to adhere to them, one could see how economic security may benefit most from concentration.

4. This is expected to be Renbase’s only grant request from the CEF.

5. Yes, the code will be open-sourced before Phase I begins.

3 Likes

Hi Thanks Chico for the work that has been put in so far.

Staking pools gives incentives to people who cant afford 100k but are committed to Ren.
i think its important that anyone who is interested to run the network to get rewards be given a chance.
If this pulls through, it will be the seeds of building a strong community.

As per Thomm’s point 3, i do have concerns on centralization of large voting power to singular entity but it will be a happy problem to solve once this kicks off the ground.

This is amazing, really like the initiative as this addresses a lot of the concerns community has shared lately. Few questions from my side:

  1. Who will run the actual nodes and will it be necessary for these individuals to be doxxed? Assuming requirements change quite a bit with Ren 2.0 and running a node becomes more similar to running eth nodes where liquid staking services like lido appear, is that how you envision this to evolve and will there in that case be necessary with a multisig group?

  2. Is there a liquid staking idea behind this with a derivative token (stREN)? The subject implied while I didnt see details in the proposal… maybe I missed it :innocent:

  3. I’m assuming a certain % of fees of node rewards will be allocated to Renbase in future? Would it make sense for Renbase to have its own DAO or do you envision more a scenario where Renbase is a branch of RenDAO. Thinking voting for critical decisions especially when phase II has launched.

  4. A bit of a vague question but any thoughts around privacy? Consequently the level of decentralisation achieved through having the actual node operators as un-doxxed as possible with a wide spectrum of geolocation. The flipside of that is level of trust people need to have not knowing who is running their nodes. Maybe in Ren 2.0 the person who locks the bond doesnt necessarily need to be the entity that operates the node? Just thinking out loud here :slight_smile:

Thanks, @mrdgw. There would not be any centralization of voting power to a singular entity. See this post for more discussion on voting power.

Thanks, @Sabobi.

  1. In Phase II, anyone would be able to register and operate a node without needing to be doxxed, so it would be more permissionless than Lido.

  2. Yes (details).

  3. Renbase would likely have its own DAO to make Renbase-related decisions, but as mentioned in this post, RenDAO could give Renbase users voting power in Ren governance.

  4. An important aspect of the protocol-wide liquidity pool is that stakers in Phase II are not linked to any specific nodes or operators, so there is no single point of failure. And operators would be sufficiently collateralized and thus incentivized to not misbehave or go offline.

1 Like

I like this, what balance between solo nodes and renbase nodes you reckon will be good? When thinking about it feels like having a layer where ‘stakers’ and ‘operators’ are separated adds another layer of security in comparison to single nodes where the operators and stakers are usually same. So wouldnt it be better for Renbase to be the dominant part?

So Renbase has no central components in its final stage as I understand it? Smart contracts with node operators who can freely jump in and out to operate nodes and earn fees. How is that part balanced? Will operators que to participate when there isnt enough capital to run nodes? Whats the incentive to “wait”?

…what balance between solo nodes and renbase nodes you reckon will be good? … wouldnt it be better for Renbase to be the dominant part?

Hard to say, but the ideal balance is that which maximizes both the percentage of REN used to secure the network and the Nakamoto coefficient of the operator set.

So Renbase has no central components in its final stage as I understand it?

Correct.

Smart contracts with node operators who can freely jump in and out to operate nodes and earn fees. How is that part balanced? Will operators que to participate when there isnt enough capital to run nodes? Whats the incentive to “wait”?

The idea is that operators would not have to queue during an operator surplus and would always be able to earn commensurate rewards for their REN. More will be shared when this is finalized.

2 Likes

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