Can oracles double as co-stakers? How RAI-like systems might safely support staked ETH

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.

Can we just let any (solo) staker dual-use their stake as CDP collateral?

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.

Could RAI just use Lido’s stETH?

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.

Idea 1: Oracles as stakers

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.

Idea 2: Oracles as 2-of-2 stakers

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.

Weaknesses of idea 2

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.

Idea 3: Semi-trusted oracles for graded security

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 k1-of-N secret share
  • P + Q2, in a k2-of-N secret share (one copy of the latter for each CDP holder)

With 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 k2 oracles are honest (as they can sign messages independently, and a malicious CDP holder cannot find a quorum of k1 to co-sign)
  • At least k1 oracles 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): k1 and k2 can be adjusted as needed to explore the entire tradeoff space of whom to trust for what.

General benefits of these approaches (ideas 1 of 2 or 3)

  • 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.

Comparing idea 1 vs 2 vs 3

  • 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.


Why stETH? rETH is more decentralized.

My concern with reth is similar to my concern with the first strawman idea: that if anyone wanted to 51% attack Ethereum, they would start by spinning up a lot of reth staking nodes, and they would only need 16 * n ETH instead of 32 * n.

1 Like

That’s a valid concern for rocket pool, but how does enabling rETH as collateral make it worse? Node operators don’t have access to their 16 rETH (otherwise we get back to nothing at stake) and users who just deposit/buy rETH have no control over nodes. This basically gives users the choice to either run a node (and get that extra reward) or use rETH as a collateral.

The issue for RAI is that if a 51% attack does happen, the value of reth could drop a lot because its collateral dries up.

And in general, the “product” that RAI is selling is tail risk insurance, and so having the system have a high risk of extra collateral loss at the exact time that an extreme event takes place that could also drop the price of ETH a bunch is not really a good property to have.


OK, got it now. Thanks.

I am a newbie to reflexer, so maybe it is a dumb question. But is the idea to convince chainlink to provide this functionality? Or for reflexer to operate its own oracle?

For chainlink, one could argue that most of the trust is because they have great past record in quoting prices. Which is not the case for staking eth.

A new oracle will likely suffer from lack of trust, and would make sense to operate in a similar mode to how MakerDAO osm work (with one hour delay, and monitored by the DAO)

I have some comments

I agree with the fact that using a single dominant liquid staking derivative as collateral is not the best solution. Also the multi collateral part.

About the idea 1

While RAI can copy Lido and stake those funds, wouldn’t that situation lead to the same LIDO case? And turn RAI into a single dominant liquid staking derivative?

And in the case that Oracles become stakers wouldn’t that lead to a centralization issue where only the Oracles will be the only set of stakers with a large amount of ETH staked under their control? Wouldn’t that affect the network in general?

Even with the DVT approach, that would means that only the group of participants in the DVT setup will be responsible of the security and stake of the whole protocol.

I think Oracles would like to be stakers since considering user’s behaviour, users are willing to do whatever is possible to increase their yields, i.e MEV builders.

But again I think this will lead to the same issues as Lido and the security of the system can be endangered by a single subset of validators.

About the Idea 2

Would it be realistic to think that CDP holders will be running infrastructure or how do you imagine this 2-2 DVT setup. Since we have 2 parties Oracles and CDP holders with a portion of they key but how is the consensus going to be achieved?

I think the idea 3 is similar it, how do you envision CDP holders with a key. How do they validate the information being signed?

My personal point of view is that the oracle issue is really a consensus issue, where users have an external source or sources of data that needs to be retrieved and validated by the others. i.e I want to get the ETH/USD price how do I get it?

If we say we will query a coingecko api, then you could have the centralization issue and going offline problem. Perhaps if we say the ETH/USD price will be a median between 10 sources of information the going offline problem can be minimised. However, how do you know the information was properly retrieved? That’s where I think a middleware similar to Obol for DVT can be used for an Oracle middleware that can take external data sources that can be verified by validators running this piece of software.