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

[vbuterin]

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.

Implementation

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.

[Danny9]

Why stETH? rETH is more decentralized.

[vbuterin]

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.

[Danny9]

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.

[vbuterin]

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.

[Danny9]

OK, got it now. Thanks.

[yaron]

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)

[edsonalcala]

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.

[yorick]

@vbuterin

they would only need 16 * n ETH instead of 32 * n

With the Atlas update that’d be 8 * n ETH

[Jstar]

The described architecture is very similar to, and would specifically suit, StakeWise V3. By swapping StakeWise’s new liquid staking token (osETH) with CDP, you get exactly what is described in the ‘Merged LP’ing + Staking’ option.

StakeWise can enable any token to be minted through an overcollateralised debt position. By default, this would be its main staking token osETH, however it would be possible to add RAI as an asset to mint against at a safe LTV.

Idea 1 would still be the ‘simplest integration’ but it is the worst option by all other metrics. StakeWise V3 development is nearly complete and would unlock ideas 2 and 3 to allow for there to be no compromise in design. The StakeWise team is already actively working with the different DVT teams to ensure an integration with V3.

Whilst the V3 system is fully permissionless, it will also be able to cater to the needs of the semi-trusted oracle solution. All Vaults (CDPs) in V3 can be controlled/governed by the stablecoin provider and will have the power to whitelist node operators, allowing for permissioned/’trusted’ operators selected by the protocol to work alongside permissionless operators in a ‘safe’ DVT cluster.

This system would remove any reliance on a single LSD but instead allow for a diverse network of oracles (i.e. node operators) to stake capital in isolated/non-fungible capital pools.

[Oranges]

What if you could white label staking infrastructure, where the protocol in effect had their own LIDO, with their own staking derivative that they fully control?

Geode Finance has built staking infrastructure that enables any DAO / Org the ability to run their own staking as a service in a fully trustless manner, with their own, branded staking derivative.

• Helps inc Ethereum security through diversification.
• Staking as a service fees can be charged, generating sustainable revenue for the DAO. The community can also decide how this revenue is used.
• The protocol can manage their own risk profile: Choose which node operators they wish to use (or manage their own nodes)
• Utilize withdraw contracts to exit the LSD as required, with ownership always staying within the protocol.

[langers]

Thank you @vbuterin for bringing this up. Obviously we would love RAI to incorporate rETH as collateral but we respect the risk management involved.

As Vitalik said, with stETH you have to trust Lido’s governance to maintain safety but once that governance has been subverted, the direct cost of attack on Ethereum/RAI is zero.

In rETH’s case, each node operator puts up collateral (currently 16 ETH moving to 8 ETH) so the cost of attack is much higher. Any attacker would have to burn through their ETH and RPL before affecting rETH collateral.

rETH is designed with risk management in mind, please find our community-driven analysis on the risk of each scenario:

Analysis%20of%20LEB%20Minipools.pdf

Correlated slashing is an extreme risk. rETH gives the greatest protection against all other forms of staking risk.

With 0x01 initiated exits the risk could be reduced much further, by enforcing ejection earlier, we are talking to researchers and other market participants to draft an EIP.

We would clearly prefer that RAI utilise Rocket Pool’s trustless and decentralised network of 2k+ node operators to stake ETH (via rETH) rather than build staking infrastructure themselves.
We also recognise the need to balance network effects, Rocket Pool has 2.3% of the Ethereum stake so we are very far from being an issue.

Still, we have started the process of self-limiting, in principle at least.
https://vote.rocketpool.net/#/proposal/0x9e093dea49dee9d1b3e43dbb6e0d8735149c5fde6ef703620970129b81d0f7f8

[TylerEther]

I support the idea of RAI being backed by both staked ETH and pure ETH. Having ETH sitting in vaults is not very productive and it is apparent that a majority of ecosystem participants desire higher yields over the safety of pure ETH backing. If staked ETH generates an industry average of, say, 4.5%, then the cost of minting RAI is 4.5%. Interest rates for RAI holders must be at least 4.5% to maintain their wealth.

Thanks, @vbuterin for three well-thought-out ideas for how we could implement staking of the ETH in vaults. I like idea 3 the most, although I’m not a fan of relying on oracles to run the staking systems.

In addition to the concerns that Vitalik laid out regarding vulnerabilities and trust issues, I think one important aspect not mentioned is the ability of oracle providers to be the best in two distinct areas simultaneously. My thoughts build off the Hedgehog Concept. I think we’ll achieve the best outcomes by keeping the domains separate and allowing for isolated competition in both domains.

Here’s my idea for achieving this, which we can conveniently label idea 4.

Idea 4: A reflexive basket of liquid-staking derivatives

While Vitalik has talked about the problems with relying on a single liquid-staking derivative (LSD), we have not discussed the possibility of a basket of LSDs.

Currently available on the market, there is Lido’s stETH, Rocket Pool’s rETH, and Coinbase’s cbETH. Relying on all three of these LSDs and others that may come in the future, we significantly reduce centralization risks. But if we were to take this path, how would we determine the distribution?

Let the markets determine the distribution. The main issue we face in allocating ETH to any LSD provider is what happens when the provider is not operating optimally. Whether that be poor uptime, attacking the network, being weak in MEV extraction, etc. The markets can, and often do, price this in. Maybe the markets are not perfect at pricing risk in, but they are probably the best at it without relying on a centralized authority.

So how exactly can we use the markets to determine distribution? We could look at the overall DEX liquidity for each LSD. We could use a slow-moving time-weighted average liquidity (TWAL), and determine distribution based on this. If stETH has 60% of the liquidity, rETH has 30% of the liquidity, and cbETH has 10% of the liquidity, then we could use those respective values as the distribution of our basket.

The idea of using DEX liquidity brings about additional challenges, but thankfully I’ve been working on solutions like these for the past two years. Before we get into such challenges, I’d love to hear everyone’s thoughts on this idea.

Finally, I’d like to note that these ideas can be extended further by considering how we’d manage the ratio of staked ETH to ETH to prevent liquidity crunches and address risks related to too much leverage in the system.

[Fred.H]

Hi all, long time RAI holder, first time FLX holder. Please bear in mind that although I have been researching RAI and Reflexer pretty deeply over the past couple of weeks that I have not been present for all of discussions leading up to this. Basically I’m aware that I am likely missing very important technical and economic context, so take what I say with a big grain of salt.

The events of the last several days (bank failures, bank runs, USDC and DAI depegging, etc.), to not even mention the inflation of this past year or two, have caused me to redouble my efforts in trying to understand money and how we can make it better. I bet a lot of people are feeling this way right now. As far as I can tell, if we are talking about decentralised blockchain technology and specifically the Ethereum blockchain, at present the best candidates for the money (using the term in the everyday common sense way) of the future is either RAI or SPOT (which is backed by AMPL).

I’ve seen a lot of comments on this forum talking about what RAI is and what the value proposition is, etc. To me, unless I am fundamentally misunderstanding its technical capabilities, that is what RAI should aim to be. I do not necessarily mean that it would be widely adopted by the public. Maybe it will, maybe it won’t. But at least there is a solution in place. At least there is something for me to fall back on.

If I understand correctly, the advantage of SPOT/AMPL as money would be that when you hold AMPL you get to participate in speculation on price appreciation. Obviously if the protocol were to be widely adopted people holding AMPL would make lots of money. This is very appealing, at least to a degenerate like myself. Of course to get this chance you must take on risk. The risk is that AMPL goes down in price (actually goes down in market cap, the price of each individual token corrects back to a set a point by design). So you can make lots of money, but also lose lots of money. But in addition to this, you get mint SPOT, which you can use either a store of value or a medium of exchange.

The advantage of RAI against AMPL is that with RAI you get to keep your ETH. In order to buy, hold, and use AMPL/SPOT, you have to sell something, probably ETH, or money that you could have used to buy ETH. There is an opportunity cost. With RAI, you get the ‘future money’ but also get to keep the native asset of the Ethereum blockchain. I don’t think I need to explain to anyone here why that would be attractive. A disadvantage, however, is that you risk losing this ETH should something go badly wrong. Still, the single collateral ETH architecture is very attractive to me if I am considering whether I ‘trust’ RAI enough to own significant amounts of it.

In short, I don’t have any solutions to the problems you pose here, although I will be thinking about it as deeply as I can going forward. But ultimately I just wanted to say that I see and believe in the value of RAI. But I’m not sure I would be able to believe in it as much as I do if more types of collateral were included. The one exception to this that I could trust would be rETH. Possibly AMPL (perhaps in the form of wAMPL if necessary) as RAI collateral also, but I realise that’s a controversial idea and a discussion for another day (or maybe no day).

Now the problem is how do you keep someone like me happy, and still incentivize the minting of new RAI. Again, I don’t have an answer. But lower fee/interest rate (if understand correctly that’s how it works) would help, as would the chance to earn a return on your ETH, presumably via a liquid staking token (again rETH).

As for Vitalik’s comments on systemic risk when including rETH, I’m not intelligent enough to know anything about that or add anything of value. I will say this, VB is the only person I trust in the cryptosphere, so there’s that.

[Kenway]

Hi, I’m a researcher from Plancker community, we think maybe we can use DKG+DVT+RCO to achieve Vitalik’s Idea2 that uses native staked ETH as CDP.

The major problem of using staked ETH as CDP is staker can control their validators to make 51% attack by mint RAI before their attack to reduce their cost of attack. To create a secure solution, it is necessary to prevent the staker from controlling their own validator and also ensure the operators cannot launch attacks. Therefore, we propose combining DKG(Distributed Key Generation) with DVT(Distributed Validator Technology) to build this platform and achieve RAI products based on ETH staking.

Here is a brief description of several key technologies:

DKG

The DKG is built on top of verifiable secret sharing (VSS) but eliminates the need for a trusted party. Its correctness and privacy are guaranteed by homomorphic encryption. In this way, a signing key is generated for a validator jointly by the operators. But the signing keys are not known to anyone including all the operators even though they can make use of their respective KeyShares to participate in producing the signature for the validator.

Besides being used for signing, KeyShares are also used for Resharing. This mechanism allows for the redistribution of key shares to other operators in case certain operators go offline or for dynamic addition and removal of operators.

DVT

Distributed Validator Technology (DVT) is similar to a multi-signature consensus voting. It divides a Validator Key into multiple key shares and can aggregate signatures, allowing Ethereum PoS validators to operate on multiple nodes or machines.

It is important to select a mature DVT network for the underlying architecture. Currently, ssv.network appears to be a better choice as they provide a wide range of operators to choose from. However, their DKG technology is still under development. We have talked about this with their team, It is expected to be available shortly after the mainnet launch.

RCO(Random Chosen Operators)

To further ensure that the staking key won’t be controlled by anyone, there should be a mechanism to randomly select operators for the DKG process. We can leverage an algorithm similar to Ethereum’s Beacon Chain’s random proposer selection algorithm to randomly choose multiple operators from a cluster of operators that meet certain criteria.

Option 1: Randomly select operators from the top fifty performers in terms of performance within the operator cluster of a DVT network.

Option 2: Determine the selection range based on the historical performance of operators, such as those with an effectiveness rating of 95% or above.

These options provide a random selection process while taking into account performance metrics or historical operator performance to ensure a fair and secure selection of operators for the DKG process.

Solution:

Develop a smart contract to support:

1. The staker transfer 32 ETH to this smart contract.

2. The smart contract calculates random numbers to randomly select operators.

   2.1 For solo stakers who are willing to run their own staking nodes, the staker can run their own Ethereum clients and register two operators on ssv.network. During staking, they specify their two operators to be included among the four operators. The contract randomly selects the other two operators to match.

   2.2 For stakers who do not wish to run their own Ethereum clients, the contract randomly selects four operators.

3. The selected operators execute DKG calculations to generate the staking key and key shares.

4. Call the deposit contract with staking key information to stake 32 ETH, with the withdrawal address set to this contract.

5. Call the RAI contract to generate a CDP and mint RAI.

6. If liquidation happened, trigger exit and transfer ETH to the liquidator.

Trust Analysis:

• Increased decentralization: Operators cannot fully control validators, eliminating the possibility of operator collusion.
• Operators cannot collude to individually slash stakers.
• Operators cannot collude to orchestrate proposer attacks because block proposals require staker signatures.
• Stakers cannot individually cause slashing or dominate attacks, thereby preventing CDP losses.
• Operators or stakers can go offline, in which case the contract triggers resharing or direct withdrawal for exiting.
• If both operators and stakers go offline, the contract can trigger resharing followed by immediate withdrawal.

It can be seen that this solution actually implements Vitalik’s Idea2, where the trust is shifted from trusting a single oracle to trusting two operators, and this trust is also limited.

Another flaw mentioned by Vitalik regarding Idea2 is the concern about intentional or unintentional offline behavior by oracles. However, in our solution, this flaw can be mitigated. Firstly, the top 50 operators are generally professional operators, unlike oracles that may be low-quality operators. Secondly, we can directly trigger resharing or withdrawal.

In the future, if 0x03 withdrawal Credentials can be deployed on the mainnet, triggering withdrawal will be even simpler.

PlanckerDAO is a group of Engineers, Reseachers, PMs from Asia who long for building the Ethereum eco in the Great China, we’d like to cooperate with RAI and DVT team to solve this problem to make RAI better because we highly appreciate the philosophy of RAI, the crypto world needs a stablecoin that is completely decoupled from traditional finance, @vbuterin may let us know your thoughts about this solution, We can move further if it appears viable.