One of the main challenges with RAI is the difficulty of finding ETH holders who are willing to act as LPs, particularly if interest rates go higher than their current level of around -5% to -10%. One of the main reasons behind this problem is that currently, RAI CDPs compete with staking as a source of yield.
An ETH holder today could put their ETH into a CDP, take out RAI, convert it to DAI with its 1% DAI savings rate, and earn a ~10% spread, or a ~5% annual return taking into account a 2x collateral margin. Or, they could just stake their ETH and collect that same 5% with less risk. If RAI interest rates increase to even eg. -3%, the calculation becomes even more in favor of staking.
Multi-collateral RAI is being explored as a solution to this issue. My own view on this is that DAI already fills the niche of being an arbitrarily (including “real-world assets”) multi-collateral algorithmic stablecoin, and so it does not make sense for the RAI ecosystem to compete in that space. Hence, in my view making RAI (or a fork) multi-collateral only makes sense if the “multi-collateral” refers to an extremely narrow form of multi-collateral: ETH and staked ETH.
This post explores some different ways of doing this.
Eigenlayer is a set of tools that lets stakers re-use their stake in other applications, by setting their withdrawal address to a contract that only returns their funds if some condition is met. Conceivably, one could make a version of RAI that uses Eigenlayer: users put their staked ETH into a CDP by setting their withdrawal address to a contract that only returns it once they pay back their RAI debt. If a user gets liquidated, the contract’s logic transfers ownership of the ETH to the liquidator (when it becomes possible in the protocol, it would also immediately trigger a withdrawal).
The main challenge with this approach is that while it works fine in normal cases, where penalties are very rare and very low, in extreme cases it greatly degrades the system’s security. In particular, if an attacker is going to make a 51% attack (or even a milder attack that involves slashing a few proposers), it becomes rational for them to put all the validators they will use to attack the system into RAI CDPs, and take out as much RAI as they can.
If attackers do this, then they are effectively “stealing” RAI from the system, causing it to incur a RAI-denominated debt. The system could try to quickly rebalance by making auctions to buy back the RAI with FLX or ETH reserves, but it still risks going bankrupt.
This is the approach that would probably require the least work on the part of RAI, while still solving the above problem. However, I would be concerned about such an approach, as there are Ethereum-level systemic risks to entrenching a staking system like stETH further. If it acquires much greater market dominance, then this puts a lot of trust into the system that governs stETH, introducing a new attack vector into Ethereum staking as a whole. This is much less true for stETH than for a centralized staking derivative, but it is nevertheless still a risk.
For this reason, it is my strong preference to try to find ways to use staked ETH in collateral that avoid entrenching network effects around a single dominant liquid staking derivative. And because RAI does not require fungibility of collateral assets (as CDPs are not fungible), RAI could actually be part of the solution.
Anyone who has a RAI CDP (or, for that matter, RAI), is heavily trusting RAI’s oracle system not to steal their funds. If RAI oracles start reporting an ETH/USD price of near-zero, all CDPs would get liquidated, leaving their holders with nothing. RAI holders (which a hypothetical attacker would perhaps become the largest of) would be able to come in and buy up the CDPs and get the ETH inside of them very cheaply.
For this reason, trust in the oracle system should be taken extremely seriously. In particular, it should not be possible for 51% of the protocol’s speculative token (here, FLX) to vote to immediately change oracle providers without a long delay (otherwise, the system could not run stably in an environment where the total funds at stake exceed the market cap of FLX). My own view on what the best model is is roughly something like this.
In any case, a key observation is that since RAI holders already trust oracles not to screw them over in this one way, it plausibly does not increase the system’s vulnerability if we also trust oracles in other, less risky ways.
One natural option is: RAI itself creates a copy of Lido where users who create CDPs can stake those funds, setting the RAI oracles to be the staking key (perhaps, RAI oracles could collectively run a distributed validator), but setting the CDP as the withdrawal address.
The level of trust here is less than it seems: bad RAI oracle-stakers could cause the funds to be destroyed, by either getting slashed or getting inactivity-leaked, but they cannot steal the funds, with rare exceptions like making some kind of exceptional MEV attack that involves the attacker being slashed due to double-proposing.
But this is still not perfect: such rare exceptional attacks are possible, and furthermore it’s not clear that oracles would want to be stakers. The legal risks of staking are plausibly higher than the legal risks of being an oracle provider, which in many jurisdictions falls into an unambiguous free-speech “just providing information” category. It would also create a greater incentive to hack them.
Here is an alternative that lets users keep more control and trusts oracles less. Instead of the staking key belonging to the oracle, the staking key is
P + Q, where
Q is a key belonging to the oracle and
P is a key held by the CDP holder. Because of the arithmetic properties of BLS signing, the oracle can sign with
Q, the CDP holder can make their own signature with
P, and add the two signatures together to create a signature that verifies against
P + Q. This is basically 2-of-2 DVT.
This strengthens the trust properties as follows:
- The oracle alone cannot slash the CDP holder
- The oracle alone cannot conduct proposer attacks, as block proposals would require the CDP holder to sign off
- The CDP holder cannot get slashed or conduct an attack, and so cannot destroy the system’s collateral that way
- The oracle or the CDP holder can go offline; in this case, the other party would trigger a withdrawal and exit the CDP with only minor losses.
- The extreme case if where the oracle or the CDP holder go offline during an inactivity leak. In this case, either party could grief the other.
This design is a special case of DVT:
- It’s 2-of-2, so it’s the simplest possible case from a networking perspective
- 1 of the 2 (the oracle) is serving thousands of partners. However, it could simply sign the same data and publish it for all of the CDPs that it works with to download
- To preserve autonomy of block production, in that specific case it could use a system where the proposer chooses what to sign, and sends it to the oracle to co-sign. The oracle should not co-sign two different pieces of data in the same slot with the same domain, as that could be combined with blinding tricks to slash the CDPs
This is new tech that would need to be implemented, and so it would probably require cooperation from a DVT team to actually build this. Once built, it should be not too difficult to operate.
The largest vulnerability of this system is inactivity leaks, as these can be triggered just by the oracle going offline. However, I would argue that it is okay to accept this risk. Validators get automatically exited and withdrawn if their balances drop below 16 ETH. Hence, we can simply accept staked ETH with a 2x collateral requirement instead of the 1.5x that regular ETH is offered.
There is an extreme case, where if many validators are leaked at the same time, only a few can withdraw at a time, and so some will leak even further below 16 ETH, but this is something that could be changed in the Ethereum staking protocol if there is demand for it. Even without a fix, it would take a very extreme attack (much more than 50% going offline), for a significant number of validators to leak far below 16 ETH before the fraction of balances controlled by honest validators returns above 2/3.
Another major weakness is that it does not work well in a world where the primary worry is not oracles maliciously slashing, but rather oracles either maliciously or carelessly going offline. This could be because we either (i) expect oracles to be low-quality stakers, because we are optimizing for honesty and not technical proficiency, or (ii) the oracles use trusted hardware, and users accept this as a (partial) trust assumption (cf. Puffer). To address these weaknesses, we propose idea 3 below.
Another approach removes the remaining trust issues in the case where you can guarantee honesty of most of the oracles, at the cost of reintroducing trust issues in the case where you cannot even guarantee that at least a few oracles are honest.
We define three constants:
N: the total number of oracles in the oracle system
k1: the number of oracles that can work together to sign a message together with the CDP holder (eg.
k1 ~= 0.2 * N)
k2: the number of oracles that can work together to sign a message without the CDP holder (eg.
k2 ~= 0.8 * N)
We ask the oracles to maintain two secret-shared keys:
Q1, in a
P + Q2, in a
k2-of-Nsecret share (one copy of the latter for each CDP holder)
Q1, the oracles can co-sign with the CDP holder, and with
Q2, they can sign independently.
In the case where
k1 + k2 = N (eg.
k1 = N/5 and
k2 = 4N/5), this ensures that neither slashing nor inactivity leaks can happen in either of two cases:
- More than
k2oracles are honest (as they can sign messages independently, and a malicious CDP holder cannot find a quorum of
- At least
k1oracles are honest, and the CDP holder is honest (as the two groups together can sign messages, and the remaining oracles cannot sign and cannot block them)
This style is similar to phase 1 training wheels for rollups, creating a linear hybrid between two security models as a way of partially trusting both but not putting too much trust on either one.
Note that this design can be viewed as a generalization of ideas 1 and 2 (and even the strawman “the CDP holder can sign by themselves” proposal):
k2 can be adjusted as needed to explore the entire tradeoff space of whom to trust for what.
- Credibly neutral, and does not introduce external dependencies: it would only trust participants that it puts an even greater level of trust in already
- Achieves the gains of users being able to stake and hold a CDP at the same time
- Avoids needlessly contributing to network effects of an existing liquid staking derivative. Instead, the stablecoin that the scheme maintains is the (stabilized) liquid staking derivative.
- Ranking by simplicity of implementation, idea 1 > idea 2 > idea 3
- Ranking by protection against bad oracles, idea 3 > idea 2 > idea 1
- Ranking by protection against bad CDP holders, idea 3 > idea 2 > idea 1
- Ranking by avoiding oracles being scared of running it, idea 2 > idea 3 > idea 1
Altogether, idea 1 seems more implementable in the short term, and would be an interesting addition to the “stake while earning other yield at the same time” space. But ideas 2 and 3 seem more trustless and more long-term durable, putting less trust on oracles and doing a better job of maintaining staking decentralization, and so they seem more appealing to me in the longer term.