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
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:
- In epoch N, Alice and Bob each deposit 100k REN
- In epoch N+1, Carol deposits 100k REN
- 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:
- In epoch N, Alice and Bob each deposit 100k REN
- In epoch N+1, Alice requests 100k REN
- 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.
Milestones
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.
Target
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.
Acknowledgements
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.
-
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) ↩︎
-
According to nakaflow.io. ↩︎
-
848 out of ~14,121 accounts (6%) with at least 1k REN operate a Darknode. ↩︎
-
Based on a snapshot of operator addresses, REN balances, and aREN balances. ↩︎
-
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. ↩︎
-
22 out of 511 operators (4%) who are able to run multiple nodes keep at least 100k REN in their account. ↩︎
-
Over the past 12 epochs, the average deregistration rate is ~2.9%. ↩︎
