Slippage control upon withdrawals about lido-dao HOT 7 CLOSED

Actually, I got it, in the context of the Lido withdrawals it doesn't make any sense.

from lido-dao.

But wait, what if the following sequence of actions happens?

• Bob requests a withdrawal of 1e18 stETH. <-- Tx1
• AccountingOracle reports(Let's say the negative rebase happens here (after a massive slashing)). <-- Tx2
• The bunker mode is activated. <-- Tx3

In case of the following sequence of txs, nothing weird happens. But what if the Bob's withdrawal request comes right after AccountingOracle's report(which will report negative rebase) in the same block? In this case, the bunker mode is not activated yet, but it seems Bob loses some funds due to the negative rebase.

from lido-dao.

Anyways, I think it's better to have some slippage control mechanism for unexpected cases like that.

from lido-dao.

Hey, @Rassska
Thank you for bringing up this issue 👍

The current architecture presumes strict FIFO ordering of finalization, and requests aren't cancellable.
Based on this, 'virtual slippage' control isn't feasible for implementation on the protocol's level.

To overcome the issue, one might want to exchange stETH for ETH on secondary markets or sell the already placed request position represented as an ERC721-compatible token (NFT).

from lido-dao.

Of course, the probability for such case is pretty low, but as I got it correctly it makes some sense:
I'm talking about the following txs order:

• tx2(negative rebase),
• tx1(Bob's Withdrawal),
• tx3(Bunker mode is activated).

As a result, after 36 days or when bunker mode is de-ativated and the batch which contains Bob's withdrawal is finalized, Bob receives less amount of ETH compared to the case where he simply could front-run tx2 which causes the negative rebase.

I mean, the whole concept here is to explore some withdrawal requests passed right after negative rebase happens.

Anyways, thanks a lot, I'm just exploring the Lido for fun!

from lido-dao.

I see your point, yet the bunker mode activates retroactively, practically excluding the probability of the bunker mode front-running (by means of the associated frame definition of the withdrawal request)

see the second rule for the 'Withdrawal requests finalization' section
https://docs.google.com/document/d/1NoJ3rbVZ1OJfByjibHPA91Ghqk487tT0djAf6PFu8s8/edit

Nevertheless, maybe you see any additional weaknesses? 👀

from lido-dao.

Thanks a lot, gotcha!

from lido-dao.