RPL Low Liquidity Problem:
- Creating a staking function that locks up the native protocol token will lead to low liquidity on exchanges.
- Low liquidity on exchanges will lead to volatile price movements that’ll render price oracles useless.
- Measuring collateralization levels will be useless since the price will be easily gamed with low liquidity.
- Potential ideas around RPL-only minipools or RPL only DVT pools will not be implemented as it’ll increase the speed we approach illiquidity.
- Illiquidity will provide a bad UX for all minipool operators (current and future Node Operators)
In the current state of Rocket Pool, the RPL token functions as insurance for node operators. As more node operators join the network it’ll equate to more RPL and ETH being staked. This is a single source of demand that’ll be able to remove massive amounts of RPL from circulation and into staking. From an economics standpoint you can project how good the effects might become “if” the demand is constant, but in reality it’ll likely conclude differently. If a supply shock does happen it’ll cause way more harm to the protocol than good. An extremely illiquid market is a bad UX. No one wants to lose 30% immediately because there just isn’t enough liquidity. This will cause distrust from node operators towards the Rocket Pool network and will likely lead to extremely stagnated/slow growth as people try to minimize their RPL exposure. Another possibility is an exodus of node operators because early adopters will still be in profit. I suspect that overall growth may start to trend negative once illiquidity starts to take place.
Overall Problem:
Cryptocurrency is still in its infancy and that means ideas are always evolving around creating different functions and utilities around tokens. Many different protocols have opt-ed for the default way and that is by creating an ERC-20 token and giving it utility. It is the most straightforward path, but it comes with a not very obvious drawback.
Users currently have 2 Options: use the token in the protocol, or use it outside of the protocol.
If a user wants to use the token within the project. The token will be locked in the system and will not be able to be allocated towards any external projects. This can create liquidity fragmentation and that will become the main contributing factor to illiquidity.
My proposal/solution:
I propose to allow bnRPL to become collateral for Node Operators alongside RPL.
The bnTKN idea:
This proposal is based on a talk Mark Richardson had at ETHDenver. The talk can be found here:
(thought experiment starts at 9:25)
This talk goes over a lot of the basics, but I’ll be covering a bit of what it looks like when it’s implemented below.
In the current state of DEFI, liquidity is a choice individual users have to make (not a protocol decision). In most cases people will stay away from Liquidity Providing, simply because IL exists and individuals will choose the more conservative approach that will ensure gains rather than have the possibility of losing money (ie. using the functions of the closed system, like protocol staking).
In the most recent upgrade, B3 (Bancor V3), Bancor has introduced a derivative called bnTKN. bnTKN is a standard erc-20 token that represents a TKN that is providing Liquidity in Bancor(in our case it’d be RPL). This will change most tokenomics models (imo) for the better. Protocols would be changing their native token utility/purpose to become permanent liquidity on the Bancor network and be transferring the utility and functions to the bnTKN derivative.
In the Rocket Pool protocol we’d be using bnRPL as a new collateral for minipool. This will enhance the UX for Rocket Pool users on the Node operator side. Since bnRPL is an interest bearing asset Node Operators that opt to use bnRPL as collateral will always increase in value when the ETH/RPL ratio is stagnant. For Node operators sitting near the minimum collateralization their bnRPL stake will always have a more positive price movement compared to a user that staked the basic RPL.
What is Bancor:
Bancor.Network is a project that serves 2 kinds of customers with 2 different products. The first product is a DEX, a place where users can exchange assets with each other. The second is insurance for Liquidity providers. Bancor, in their current model (v2.1), provides insurance to all Liquidity providers on their platform. On Bancor users will only be able to provide single-sided liquidity to the token they choose. From day 0 to 24 there is no protection from Impermanent Loss, in the case users do pull their funds early. On day 25 users’ single-sided liquidity positions will be 25% protected and each day it’ll increase by 1%, up to the max of 100% on day 100.
The upgrade Bancor is going through right now, to v3, changes the way the insurance works. Notably, starting from day 0 all Liquidity Positions will be 100% protected, no matter how much or little users will be provided. A summary of the upgrades happening on Bancor can be found here:
Final Thoughts: An upgrade like this is can be very risky for all parties (compounding smart contract risks, etc). Bancor V3 hasn’t been battle tested yet, nor has it launched. Once this new update does launch on Bancor.Network. I’d like to give it at least 6 months of being live before Rocket Pool decides to actually pursue any kind of integration of something like this.
With illiquidity not being a problem (if all things works as intended) I believe we’ll be able to pursue RPL-only minipools as Price volatility will no longer be an issue.
Put comments of what you think below and thank you for coming to my TED talk.