Exploiting deposits before the exchange rate update

[ruuda]

As reported by Neodyme:

• It is possible to deposit sol during the window in-between solana-epoch-has-passed and update_exchange_rate. This allows for the following (admittedly far-fetched) "attack":
• One slot before epoch-boundary, an attacker buys (or lends) a lot of stSol. He immediately uses this to withdraw at the old exchange rate. He gets a locked stake account, which he promptly deactivates
• Immediately after the epoch-boundary, the stake is unlocked. The attacked withdraws it, and re-deposits it into Lido. He will get the same number of stSol tokens back as he put in in the first place, as the exchange rate is not yet updated. These tokens he can sell or give back to the lender.
• In essence, this was a zero-sum-game for him. To make this a far-fetched attack, the attacker would have to bet on the price of stSol going down (or not increasing as much), which he can do since he effectively "deletes" one epoch of rewards during which the newly deposited sol is activating. I cannot see anybody really doing this, but it could be fixed by disallowing desposits during this short window. (you could even use the new sysvars-as-syscall feature to avoid having to pass in the clock sysvar account).

Our delayed exchange rate update doesn’t change things that much, but it does play a role here. You could do the same without racing the update, just withdraw at the end of the epoch, and re-deposit at the next epoch. This way you “prevent” some rewards because the stake takes an epoch to activate, but you don’t directly gain any rewards yourself. You might then benefit from the value of stSOL not going up as much with trades outside of Solido.

I think this normal and not something we can prevent; it is not really different from one user withdrawing in one epoch and another user depositing in the next. Withdrawing some SOL in one epoch and depositing it in the next is always going to result in lower rewards than keeping it with Solido.

Where the exchange rate update comes into play, is that it allows an attacker to do this for free*. If you withdraw in epoch i, and re-deposit in epoch i + 1 after the exchange rate update, you will need slightly more SOL to get the same amount of stSOL. But if you can execute your transaction before the exchange rate update, you don’t need any additional SOL. In a sense, depositing immediately is not some special case; you can always do this withdraw in epoch i and re-deposit in epoch i + n, and the greater n, the more expensive it will be to do this (if you want the same amount of stSOL out). Racing the update is the case where n = 0.

* Aside from transaction fees.

So the impact of this is small, and additionally, it will be difficult in practice to pull this off. But it is also easy for us to mitigate, by just blocking deposits before the exchange rate update. So now the question is, is it worth blocking deposits for this?

We discussed this in the past and concluded that we prefer to never block deposits if possible, but we should re-evaluate in light of this new scenario.

[ruuda]

Given that

• This “attack” is difficult to pull off in practice.
  • It requires racing the maintenance bot to get your transaction executed first. (We can tweak the maintenance bot to make it more responsive than it is right now, if needed.)
  • You need to have a large amount of stSOL available to make a dent, and assuming that the majority of stSOL holders are benevolent, it will be difficult to control such a large share of the pool.
  • There is no direct benefit, you need an additional external system where you can speculate on the stSOL price, to benefit.
• The impact on Solido is limited. It prevents some rewards, but not loss of funds, and the amount of rewards you can prevent is proportional to the amount of stSOL you have, which should be a small part of the pool.
• It can happen at most once per epoch, and it should be possible for us to deploy a new version that mitigates this within one epoch if needed.

I think this is not worth blocking deposits on this right now, but if new information becomes available, we can re-evaluate, and it’s a simple fix that we can deploy quickly.