Slippage control upon withdrawals

[Rassska]

Hey there, hope you're doing fine!

Do I get it right, that the current version of the feature/shapella-upgrade doesn't provide any opportunity for users to set the desired slippage on-chain upon withdrawals?

Thanks!

[Rassska]

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

[Rassska]

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.

[Rassska]

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

[TheDZhon]

Hey, @Rassska Thank you for bringing up this issue :+1:

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

[Rassska]

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!

[TheDZhon]

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? :eyes:

[Rassska]

Thanks a lot, gotcha!