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

I’ve been working on a decentralized staking protocol that can generate more rewards than by operating a Darknode alone, increase Ren’s economic security by at least 3-4x, and allow REN to be used in DeFi while accruing Darknode rewards.

Motivation and overview

With 1,997 registered Darknodes and a Nakamoto coefficient of 42[1] at the time of writing, Ren is positioned to have the most decentralized validator set of any L1 or bridge in DeFi.[2] While this is a huge achievement, over 80% of the token supply and 94% of token holders do not currently contribute security.[3] This data raises a number of issues.

Decentralization ≠ economic security

If an adversary can afford to corrupt the network, then no amount of decentralization can stop them. In fact, if we allowed decentralization to create a false sense of security, adversaries may even be incentivized to artificially inflate the Nakamoto coefficient by using many different operator addresses. Currently, while consensus and execution have been managed by Ren Labs, the cost of corruption has technically been infinity. But once consensus and execution become decentralized, the cost of corruption will simply become a product of supply and demand.

Cost of corruption

The first issue raised by the data above is that there is currently too much supply and too little demand of REN to achieve a sufficient cost of corruption. What would qualify as “sufficient”? Considering that DeFi has yet to see a successful Sybil attack on a proof-of-stake network, and that the only successful economic attacks have involved flash loans and manipulated oracles, we can assume there is some threshold at which an adversary could no longer afford to corrupt the network, even if doing so would be profitable. In fact, as the cost of corruption scales beyond this threshold, collateralization becomes increasingly less necessary.

This proposal does not aim to suggest a threshold in absolute dollar terms. It does, however, suggest that the cost of corruption could be tripled or quadrupled, at the very least, by putting more REN to work. If each wallet registered as many Darknodes as it could, there’d be a lower bound of 6,661 Darknodes.[4] An adversary would need to corrupt 3-4x more Darknodes than today and incur prohibitively steeper price impact due to lower market depth. And if we assume that stronger security attracts more adoption and volume, then one would also expect higher demand to follow lower supply. So, instead of the security model saying, “more volume should attract more operators,” it should actually be inverted to say, “more operators should attract more volume.” Instead of security being reactive, it should be proactive.

Barriers to entry

To fix participation, we first need to understand the barriers to entry for operating a Darknode. Today, deregistration takes 1-2 full epochs (28-56 days), but for good reasons: to allow time to punish misbehavior and to stabilize economic security during price volatility (if Darknodes could deregister immediately during wild price swings, the network would be too manipulable). However, the 1-2 epochs of illiquidity without earning rewards disincentivizes registering in the first place.

Second, technical friction related to the CLI and off-chain infrastructure may be an even higher barrier to entry. Looking on-chain, we can see that around 30% of accounts with at least 100k REN do not operate any nodes at all,[5] while just 4% of operators with at least 200k REN keep at least 100k REN in their account.[6] This is a pretty big hint that technical friction is the primary barrier to entry, as once an operator is able to set up their first node, they typically bond all that they can to reap the rewards, leaving minimal liquidity available.

To bolster security and foster adoption, Ren needs a supply-side mechanism that enables and incentivizes more token holders to contribute security in a frictionless and decentralized way, independent of demand. So, what are some options?

Option #1: Adjust parameters

Surprisingly, cutting the bond size in half would only allow an additional 1.7% of the token supply (17.3M REN) to be bonded. This figure is estimated by looking at all on-chain accounts, operators, and aREN (Aave interest bearing REN) holders, counting how many Darknodes each could operate, and seeing how many would have between 50k and 100k REN left over. It does not account for CEX balances and smart contract positions, so it is a lower bound, but the estimate is conclusive enough.

And while shortening the deregistration period may incentivize more Darknodes to register, shortening it by too much could destabilize economic security during price swings.

Ultimately, neither address the technical friction of setting up and managing nodes off-chain, which data suggests could be the primary barrier to entry.

Option #2: Underwriter pool

An underwriter pool of REN could help recover lost funds after an attack. In return, LPs would earn rewards — albeit a smaller percentage than Darknodes — without needing to register, set up, or maintain a node.

While this could increase participation without imposing technical friction, it may actually decrease security for two reasons. First, Darknode operators could inadvertently be drawn to spinning down their nodes in favor of an alternative revenue stream with better liquidity. Second, Darknode operators would be the ones subsidizing the pool’s rewards, and less rewards could ultimately reduce demand to run nodes. While more REN would be utilized, the goal is to have more nodes, not less.

Option #3: Decentralized staking

A staking protocol could incentivize participation without technical friction or illiquidity while increasing both the number of nodes and the cost of corruption by 3-4x. If anyone were able to operate a node in such a protocol, it could also raise Ren’s Nakamoto coefficient too, as there would be more nodes and a wider pool of operators.

It would also have the added advantage of a liquid staking derivative that can be used in DeFi while earning Darknode rewards. Imagine borrowing against REN or single-sided staking it in Catalog while continuing to earn BTC, stablecoins, and other assets.

This appears to be the most beneficial supply-side mechanism for the Ren ecosystem, which is why I’ve committed to building it full-time. Like Ren Labs, whose two mandates include developing Ren into an L1 and building applications on top of it, Renbase will take on two mandates of its own: maximizing the percentage of REN used to secure the network and the Nakamoto coefficient of the operator set.

Technical approach & scope

To achieve these mandates, Renbase is implemented as a set of smart contracts designed to extend the productivity of REN beyond what is possible for Darknode operators and other token holders today. To better understand how, it is helpful to first look at how rewards are currently distributed.

When a Darknode deregisters, it forfeits the rewards it earned in that epoch to the pool of registered Darknodes. Because deregistration takes a while, only around 3% of Darknodes do so in a given epoch.[7] If deregistration took less time, one would expect more turnover and more rewards for registered Darknodes.

By having one large liquidity pool that can register as many Darknodes as there are multiples of 100k REN, in which liquidity is abundant and shared by all, and arbitrary quantities of REN can be deposited, requested, and immediately withdrawn with ease, Renbase is able to facilitate a higher turnover rate that generates more rewards for those who participate.

That flywheel helps explain the rest of the protocol. Most of its core features, explained further below, can be bucketed into the following categories.

  • Rewards
    • Dilution protection
    • Rewards flywheel
    • Multi-asset rewards
  • Liquidity
    • Protocol-wide liquidity pool
    • JIT (de)registration
    • Liquid staking derivative (Phase II)
  • UX
    • Arbitrary-quantity transactions
    • Persistent reward balances
  • Permissionlessness
    • Withdrawals
    • Deregistration
  • Decentralization (Phase II)
    • Permissionless registration
    • Staker / operator incentives
    • [Redacted]

To optimize protocol design in accordance with the community, and to start gathering feedback, it is worth exploring a few of these features in more depth.

Core feature: arbitrary-quantity transactions

A large liquidity pool that can register as many Darknodes as there are multiples of 100k REN enables deposits, requests, and withdrawals of arbitrary quantities of REN in one capital-efficient transaction. If there isn’t enough REN to immediately withdraw, one can “request” that the contract (a) set aside any REN that becomes liquid later in the epoch to fund their withdrawal and/or (b) deregister enough nodes to fund the withdrawal, which is fully permissionless, though the contract will first default to (a), as it keeps nodes registered and their rewards flowing. Transaction types include:

  • deposit;
  • withdraw-or-request: withdraws what is available and requests the rest;
  • withdraw-not-request: withdraws what is available but does not request the rest

So, for example, one could deposit, withdraw-or-request, or withdraw-not-request 125 REN or 125k REN all in one capital-efficient transaction.

Core feature: dilution protection

Unlike most staking protocols, users in Renbase earn rewards only once their deposits are put to work (“work-to-earn”), which prevents dilution by new depositors. If they received rewards for the epoch in which they deposited, it would be equivalent to Darknodes receiving rewards for the epoch in which they registered.

Additionally, there is a deadline by which to make REN-related transactions near the end of each epoch. This allows for the number of nodes registered on-chain and provisioned off-chain to align with users’ balances, which prevents deposits made late in an epoch from diluting everyone else. For example, let’s say Alice deposits 100k REN in epoch N with enough time to register a node. Without a deadline, Bob could deposit 900k REN at the end of the epoch and leave no time to register 9 nodes. In epoch N+2, there would be 1 node’s worth of rewards for 10 nodes’ worth of REN. A deadline forces Bob to deposit with enough time left in the epoch to register a commensurate number of nodes and guarantees fairness for Alice.

Core feature: just-in-time (JIT) (de)registration

The deadline also marks the beginning of when Darknodes can be (de)registered on-chain. At the DarknodeRegistry level, once a node is registered on-chain, its bond cannot be returned until it has completed the registration and deregistration cycle. And once it is deregistered, it cannot be re-registered and its rewards in that epoch become forfeited.

In Renbase, registering a node as soon as 100k REN became available would prevent others from withdrawing that REN. And deregistering a node as soon as enough REN were requested would risk forfeiting that node’s rewards prematurely, as a deposit made later in the epoch could be used to fund that withdrawal instead of the node’s bond. So, to allow liquidity to slosh around in a withdrawable state for as long as possible, and to ensure nodes do not prematurely forfeit their rewards, Renbase calculates the net difference in nodes between epochs and enforces their just-in-time (de)registration all at once near the end of the epoch, between the deadline in epoch N and the start of epoch N+1. This is a major piece of the rewards flywheel described below.

Core feature: persistent reward balances

When deregistering a node today, solo operators need to withdraw their rewards before refunding their bond or forfeit them altogether. In Renbase, users can deposit and withdraw arbitrary quantities of REN as often as they’d like without needing to withdraw any rewards. This encourages higher velocity of REN in and out of the pool, which also accelerates the flywheel described next.

Core feature: rewards flywheel

IMAGE 2022-09-07 12:40:18

Delegating to third-party operators lets users switch places without (de)registering Darknodes. For example, in the screenshot above of a prior epoch, 57 nodes are pending registration and 52 other nodes are pending deregistration. If the same overlap occurred in Renbase, only 5 new nodes would need to be registered and none of the 52 would have to deregister or forfeit their rewards.

But if those rewards aren’t forfeited, who gets them? For a bit of context, at the DarknodeRegistry level, deregistrations forfeit that epoch’s rewards to nodes that are fully registered — and not pending registration — in that epoch. Similarly, at the Renbase level, requests and withdrawals forfeit that amount’s worth of that epoch’s rewards to the users of deposits made in previous epochs. By keeping those nodes registered instead of deregistering them, Renbase is able to internalize those rewards for its users instead of leaking them to solo operators. By design, that second layer of rewards is available exclusively to Renbase users, not to solo operators, and is only constrained by the scale of overlap in the pool. The flywheel is thus: more overlap → more rewards → more deposits → more overlap.

Renbase is designed to facilitate this overlap in four ways, three of which have already been introduced. First, a protocol-wide liquidity pool makes liquidity more accessible to all and likely to be withdrawn. Second, JIT (de)registration gives that liquidity as much time as possible in the epoch to be withdrawn. Third, persistent reward balances make that liquidity easier and cheaper to withdraw. Here’s an example of liquidity that gets withdrawn as a result of these first three conditions that increases rewards for the rest of the pool:

  1. In epoch N, Alice and Bob each deposit 100k REN
  2. In epoch N+1, Carol deposits 100k REN
  3. In epoch N+1, Alice withdraws Carol’s 100k REN deposit

In return for that liquidity, Alice forfeits her epoch N+1 rewards to the rest of the pool that deposited in previous epochs, which is Bob in this example. In epoch N+2, Bob would be able to withdraw 200k REN worth of epoch N+1 rewards despite having only deposited 100k REN. And Carol begins accruing rewards in epoch N+2, just as she would as a solo operator.

The fourth way that Renbase facilitates overlap is by reserving liquidity that becomes available after a request. In the example above, consider if steps 2 and 3 were switched:

  1. In epoch N, Alice and Bob each deposit 100k REN
  2. In epoch N+1, Alice requests 100k REN
  3. In epoch N+1, Carol deposits 100k REN

What happens if Alice requests 100k REN before Carol deposits 100k REN? A naive implementation might deregister a Darknode to fulfill Alice’s request and register a new one for Carol, but that would leak a node’s worth of rewards to solo operators. Instead, Renbase internalizes that node’s rewards by keeping it registered and reserving Carol’s 100k REN specifically for Alice to withdraw. Once again, in return for that liquidity, Alice forfeits her epoch N+1 rewards to the rest of the pool that deposited in a previous epoch, represented by Bob. And again, in epoch N+2, Bob would be able to withdraw 200k REN worth of epoch N+1 rewards despite having deposited 100k REN.

Ultimately, the goal of the flywheel is to boost the incentive for REN holders to participate in decentralized staking.

Core feature: liquid staking derivative

Designs have already been scoped for a non-dilutive liquid staking derivative that can be used in DeFi while earning Darknode rewards. It would largely be expected to complement the rewards flywheel. This is an area of active research, so more will be shared at a later date.

Core feature: permissionless withdrawals and deregistration

A protocol-wide liquidity pool guarantees that if any quantity of REN cannot be immediately withdrawn, it will be made withdrawable in the same time or less as it takes to refund the bond of a registered node. If liquidity were pooled into individual nodes, withdrawals would likely require either a quorum of the node to agree to deregister or a depositor to replace the position in full, which may not be capital efficient for them if they need to deposit more than that amount.

In Phase I, if the contract determines that nodes need to be deregistered, anyone is permitted to deregister them. The contract basically says, “any n registered nodes need to be deregistered. Who wants to deregister them?”

The exact Phase II implementation is an area of active research, but is expected to work similarly.

Core feature: decentralization

Renbase will decentralize over multiple phases as the team and community gain confidence in its implementation. In the early days of the protocol, the ability to address unexpected issues as quickly as possible can help mitigate or prevent those issues altogether. And as a staking protocol that will presumably involve a fair share of REN, that ability is vital for not just Renbase’s security, but Ren’s too.

This phased rollout will apply primarily to two features: Darknode registration and rewards. In Phase I, the Renbase team will be responsible for operating all of the Darknodes and will likely levy a soft cap to make sure Ren stays sufficiently decentralized. In Phase II, however, the goal is to allow anyone to participate as an operator. Users would be split into stakers and operators, whereby stakers would pay operators a percentage of their fees for operating Darknodes. There are some exciting ideas in this area that are under active research, so more will be shared at a later date. And secondly, in Phase I, the Renbase team will also be responsible for rewards, the technical details of which will be shared closer to launch.

Execution risks and mitigation strategies

The intensely adversarial nature of DeFi makes it all the more important to define a security plan in accordance with best practices. The following is an overview of six measures that have and will be taken to help achieve a high degree of confidence in the implementation.

To help design and ensure functional correctness of the protocol, an advanced automated simulator called “Playground” was developed to verify business logic against a multitude of scenarios. It has been an instrumental piece of R&D and has helped speed up development time, optimize capital efficiency, and discover important edge cases.

As should be expected of any mission-critical software, comprehensive test suites have and will continue to test all conditions on each line of code and be run by a CI server after each git push.

All smart contracts will be thoroughly audited by a reputable, third-party smart contract security firm. While this process has not begun yet, it is quite close, so more will be shared when appropriate.

As we have seen in a number of frontend exploits, implementation risk is not limited to smart contracts. To that end, an infrastructure audit will be pursued for Renbase’s other software components.

According to Immunefi, over $20B in damage has been averted thanks to public bug bounty programs that incentivize whitehats to responsibly disclose vulnerabilities. If there are enough funds to support such a program, it will be among the highest priorities.

Last, but not least, confidence takes time. This supports the idea of a controlled release plan that disincentivizes too much adoption all at once and helps to contain any issues that arise to a smaller group of early users. It also allows for those users to provide UI/UX feedback before more users start using it.


In general, Renbase will follow Ren Labs’ tradition of not providing exact timelines because of how difficult they are to estimate, particularly considering the demand for third-party security firms. However, in this case, it is worth providing a high-level overview of the development that has already been done and of the development that remains in the months ahead.

After many iterations, Phase I of the smart contracts is fully implemented and tested. It is expected to undergo some minor updates before mainnet deployment as Ren 2.0 approaches and DarknodeRegistry receives some anticipated updates, but it should be ready for audit without much more development.

The remaining software components, all of which have already begun development, will continue to be built throughout the remainder of Q3 and Q4, culminating in a testnet deployment in Q1 2023 of all components in sync. As the protocol nears this phase, engagement with third-party security entities will begin, comprehensive audits will be conducted, and their reports will be shared publicly. After a reasonable degree of confidence on testnet, the protocol will be deployed on mainnet.


Renbase has been in full-time R&D for the past year, bootstrapped with personal funds. To maximize Ren’s economic security and third-party adoption, a bespoke staking protocol with strong incentives for all REN holders was needed. Excitingly, that design is now in development. But to get to mainnet, additional funding is needed for further R&D, audits, legal, salaries, operational expenses, and if funds permit, a bug bounty program. And as Renbase will presumably attract a fair share of REN, it is important for Ren’s own security that Renbase have the necessary resources to follow security best practices.

In consideration of the above, I am requesting a grant of $285k USD equivalent. Ultimately, enabling and incentivizing every REN holder to contribute security in a decentralized way, and in effect improving the productivity and utility of every unit of REN, will help create the most favorable conditions for adoption by third-party applications. At this stage, it would be as high-impact of an investment as the Community Ecosystem Fund could make.

For reference, comparable grants include 1M LDO (~$6.5M at time of vote) for Lido on Polygon and 2M LDO (~$3.4M USD at time of vote) for Lido on Avalanche.


Thanks to @Arviee, @MaxRoszko, and @SeekingKnowledge for reading drafts of this. I would also like to thank the many community members who have engaged in substantive dialogue in Telegram and Discord over the years, many of whom helped inspire some of these ideas. While I may not participate in every conversation, I am always reading along. This proposal is a humble contribution to many of those conversations, and I hope to continue building what I think can be a special part of the Ren ecosystem. Let’s make Ren the default multichain infrastructure of DeFi.

  1. The minimum number of unique operators needed to compromise 1/3 of the network; a measure of decentralization coined by Balaji Srinivasan (source). This metric is somewhat manipulable because an operator can register nodes from multiple addresses to create the illusion of more decentralization, but as Anatoly Yakovenko tweeted, "it is at least something.” (source) ↩︎

  2. According to nakaflow.io. ↩︎

  3. 848 out of ~14,121 accounts (6%) with at least 1k REN operate a Darknode. ↩︎

  4. Based on a snapshot of operator addresses, REN balances, and aREN balances. ↩︎

  5. Assuming Alameda distributed its REN over ~100 accounts and does not operate any nodes, then 327 out of ~1,175 non-Alameda accounts (28%) with at least 100k REN do not operate any nodes. ↩︎

  6. 22 out of 511 operators (4%) who are able to run multiple nodes keep at least 100k REN in their account. ↩︎

  7. Over the past 12 epochs, the average deregistration rate is ~2.9%. ↩︎


Hey David, great post. I’m a huge fan of this idea and its clear that you’re capable to bring this to fruition. My only question at the moment is if you have a specific breakdown for the grant use.

If anyone has questions on this Grant Request please comment here or attend our biweekly Community Call at
18 UTC on Mondays!


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


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.


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.


Thank you for taking the time to post this thoughtful and well laid out grant request @DavidPerkins !

In the context of Ren 2.0 announced last month (link here), and the promising journey in which Ren continues, I find your proposal an undoubtedly net positive development that ought to be mindfully considered by the Ren community, and supported with the relevant funding you specify. I strongly favor supporting this proposal overall, for several key reasons:

  1. After the last community call this past June 15, ‘22 where members from RenLabs confirmed as a priority the march forward in the spectrum of decentralization (link to call here), I am of the opinion that an output like the one you propose is a welcome development that can only help as time passes, in multiple ways such as: incentivizing folks with less than 100k tokens to put that amount to work, helping increase the amount of nodes to strengthen the Ren network and helping decrease sole reliance from centralized hosting providers, all in due time of course (longer term goals, possibly).

  2. Helps increase awareness in a sustainable way to the Ren ecosystem, in the same way that Lido staking and Coinbase staking have done so for the ETH network, and the former to Solana as well.

  3. Helps cultivate a framework of sustainable yield and utility for folks wanting to support the Ren ecosystem, but for a variety of reasons, might not be able to operate their own nodes.

I also appreciate all of the engagement from community members so far on this proposal, and have a couple questions that would appreciate your insights on each of them, if possible.

Specifically, as ETH transitions from POW to POS, staking services for that chain such as those provided by LIDO and Coinbase have come under scrutiny by a variety of folks RE: key questions on decentralization and governance, that might be helpful to keep in mind for Renbase:

a) Decentralization is a spectrum by definition, so 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?

b) 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?

Again, I appreciate all the work you have dedicated so far to Renbase and reaffirm my support for this initiative. Cheers!

1 Like

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.


Thank you for the response! I appreciate the flexibility in the approach described regarding voting power logic, as well as adopting options that RenLabs will eventually enable for hardware composition of nodes.

Looking forward to the scaling of Renbase!



Thank you for the response! I appreciate the flexibility in the approach described regarding voting power logic, as well as adopting options that RenLabs will eventually enable for hardware composition of nodes.

Looking forward to the scaling of Renbase!

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!


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.


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?


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.