IMO the core promise of RAI is stability and trust that comes from the fact that there is no governance and thus no chance to undermine the governance and thus undermine RAI and turn it into FIAT. This is the main reason why RAI only allows ETH as collateral as it is widely believed that allowing more collateral would require governance to decide which ones.
I am making here a proposal that would allow ANY token to be used as collateral and this also does not require governance. Each collateral would essentially spin up a new fork of RAI and would create a new RAI token (lets call them RAI*) that is backed by a specific collateral. (collateral could theoretically also be a basket of assets)
A core challenge here is to get sufficient liquidity for all those RAI*. However - this can be overcome by making is extremely easy for R* holder to provide liquidity. The idea would be to let any RAI holder decide what collateral they trust. There can also be (governance-controlled) lists of colletrals that user can subscribe to.
E.g. a user could select a bunch of assets: e.g. ETH, stETH, cbETH and rETH. This would express that the user is indifferent about holding RAI-eth, RAI-stETH, RAI-cbETH or RAI-rETH. Another way to express that would be that the user is always willing to trade 1RAI-ETH for e.g. 1RAI-cbETH (+ epsilon).
To dig a bit deeper - as prices of those different RAI* will fluctuate a reasonable strategy would be:
- Only buy another RAI* if it currently has a higher redemption rate change
E.g. if the RAI you are holding changes -4% you are willing to buy RAI that changes -2%
- You are willing to trade both the RAI you are selling and buying at each of its redemption rates
This base structure would allow people to hold RAI and largely abstract away from them which individual RAI tokens they are currently holding.
From a technical perspective, nothing you’re proposing here is based on poor assumptions. And, frankly, this is more or less what the team has been discussing as a good path forward to explore with more effort than we previously thought.
I guess this is as good a place to air out my current list of hang-ups.
Providing liquidity and the demand for leverage
A. for all of these new Rs you need to have someone that has the underlying collat and is willing to generate leverage against that collateral. This is easier said than done as we’ve seen.
B. Each new R needs it’s own set of bots and oracles, which is a fixed cost hurdle to overcome. It’s likely that all of these new R*s will need to be on L2 for this to have a chance to reach escape velocity
The need for education, information digestion and/or middle-ware
A. in your example a user has to constantly be weighing various R* redemption rates against the matrix of collateral risk in differing R*'s collateral (and to a certain extent the liquidity depth of that R*). This is probably doable for those reading this post, but is very much not doable for the vast majority of even the population of users who make on-chain txs.
B. I’ve always been a fan of developing middle-ware solutions to these problems. In the past we’ve tried approaching different developers about trying to construct some useful middleware that could handle this. Consider the juice that’s been on the table since we’ve had negative rates vis-a-vis all MakerDAO users. If there was a tool that, with a few clicks of a button and some txs, delegated safe mgmt to a contract that just switched between a dai safe and a reflexer safe depending on RR, I believe a significant portion of users would love it. “Literally free arb” if you trust the tool and the underlying protocol stack. In the same vein, this same dashboard could be used for your different Rs. A user checks the box on what R + Dai she’s interested in and the middleware contract takes it from there.