Lido V3: Security by Design | Tomer Ganor - Certora

Hi everyone. Hi everyone. I'm Tom Gor. I'm Tom Gano working at Satara for three and a half years a security researcher and I'm happy to talk to you about Lido V3 securing by design. Um so let's start.

So why should you trust me? Um I've worked on all of these protocols. Uh the trust me with their security especially a lio balancer silo which I did the designer v4 which mean basically that I audited their design uh security design a v4 lido door governance lido v3 balancer v3 and also the latest version of silo. Uh so let's start. Um so what is lido?

Um my journey with Lido started uh in Lido V2 when they added the withdrawals. Um and from uh from my experience the Lido team really cares about security and they really value it and whatever small uh issue that I told them they fix it immediately in thoroughly completely uh fixed it and not small fix just deals with a problem or just say no it's a low issue we don't care and we'll see here also how they really really care about security. So, Lido is a liquid sinking protocol that you deposit your ETH. It goes to the consensus mechan consensus layer and the lido stake it use validators get rewards and you get a portion of those rewards 90%. You deposit ETH you get SD yield bearing token h and that's it very simple.

Um but the problem that we have uh with lido lido core is that institutionals h can't use it. H the reason that institutionals can't use Lido core is because when institutions want to deposit their ETH to the to the Lido pool to the LDO core their ETH mixes with everyone else's ETH maybe dirty ETH maybe ETH from moneyaundering scheme maybe ETH from terrorists maybe ETH from a bunch of different entities that they don't know and institutionals just can't make Oh sorry a can see the screen. Sorry. Oh, great. Sorry.

Uh, so institutionals cannot get their ETH mixed with dirty ETH from regulatory perspective, from compliance perspective, and they just need to be to have the ETH isolated from everyone else. So if institutions want to stake their ETH, they can just stake it like any solo staker. But if they do it, if anyone wants to withdraw, wants to exit, let's say ETF or a bank or sell their ETH, they can't just sell it because it's in the consensus layer, which means they need to wait until the exit queue clears till they can withdraw their ETH. And only then they can sell it and repay exit the user they want to exit or the trader or whatever. And they can't stake their 100% of their ETH because then they couldn't repay immediately to the H user.

That's a problem because if you stake only 50% of the ETH and let's say in light you can get 3% or 4% you get only 50% of that 3% or 4%. Which is less yield than what you want. You want to stake your ETH fully. You want to get all of your rewards and you want to profit. Uh so how Lido V3 solve this problem is by letting the institutionals just do the same as solo staking but with extra uh benefits.

So they take their ETH deposit to the staking vault which is just an isolated vault that they uh that they control and they get st from there. Up until this point it's exactly the same as just solo staking. Just take their ETH put it in the staking vault isolated and stake it. Then after that happens uh they take everything 100% of their ETH and if any user want to withdraw uh to cash out from their position what they can do is they can just borrow SD from Lido mint it directly from Lido sell it the market immediately get the money to pay uh the user they pay him and then initiate the withdraw for the valid the required number of validators they need to withdraw when they do it then they will wait the amount of time that need that will take let's say couple of days maybe a couple of weeks currently last I think two months ago it was like 60 days they need to wait but now they could repay the user immediately so they don't care then when the money comes back they could repay their debt and that's it and they don't care about uh this uh time that passed maybe they need to pay a bit more for this extra yield that STS acrew in this two months or this one months or couple of weeks but but at least in this time they get keep getting the yield from the validator so it's in their favor at the end um so this This is the flow for light of V3. Um, now let's go uh about for a bit of context for the bug.

So when we do a deposit in the consensus layer in Ethereum in EVM, we want to deposit our ETH to the VCON chain which means that we set our 32 ETH, we send it uh to the deposit contract signed with the validator private key and also the withdraw credentials that we have. So if I am a solo staker, I don't care the private key, I control it. I control the validator. I control my credentials. Everything is my control.

Everything would work. This is the happy flow. H. So I just sign with my private key, sign on the window credentials, deposit it, everything is good. The said flow or what can break is that there is a a predeposit front which means that before I deposit my uh ETH, maybe someone else that control the private key of the validator could frontr run me with different withdraw credentials.

which means that basically I deposit my 32 ETH and he deposit let's say in the same block or the block before deposit 32 ETH to the same validator but with different withdraw credentials the withdraw credentials are basically the address the return address where do we send the money after we exit after we profit after we get rewards which means that if you front run me this is immutable so whenever I decide to withdraw credentials that's it so they are fixed forever which means that you front run me you had your your withdraw credential first now I deposit my you're going to get it for free. You're going to get my entire money but I 32 ETH and you just have have them and I can do anything about it because the the consensus there doesn't care about a new deposit with to different withdraw credentials just because if it's immutable that's it then you you can't change them. So the fix for this problem or the partial fix for this problem in the consensus there is um this is the contract smart contract that shows that they don't care about if it was deposit or not trust me just checks the formatting. Um so the fix for this is to do the pre-eposit. You deposit only one ETH to reserve your space in the in the uh Bitcoin chain Bitcoin layer.

You have your uh validator withdraw credentials reserved and then it's pending. It's not active yet because you haven't deposit the full amount that you need but you still can check that you you know exactly what what is the withdraw credentials that what you expect. Great. Then you can deposit the rest of your 31 ETH to activate the validator and then you could participate in the H staking. H this is a partial solution because if you front run this uh this operation you still gain profit the one ETH and not 32 but you lose less but you still can lose 3% and not the full 32 E which is better but not perfect.

So if anyone here's know anyone in the term foundation please let's fix this because it's very annoying both for security perspective and for liquid staking protocols lido has a solution for this with the lido core it's very cumbersome it's very um they use oracles they use a bunch of stuff but uh it's it works for them great uh so now uh we know what light of v3 we know that we deposit fund the vault we transfer money to the vault stake it we can mint we can borrow against it great now what is the problem. H sorry this is the predeposit. Let's go to the problem because I don't have a lot a lot of time. Um so basically what happens is that the attacker funds the vault uh let's say with one ETH then we predeposit the one ETH. We send the money uh the ETH to the predeposit to the post contract.

We uh then we um we see that the prere deposit worked as it should which means that we can verify onchain that the um the correct withdrawals have our e the validator match. Great. Now we could just mint because we as we said we deposit with the consensus layer. Now we could uh borrow against it if we want. Let's say we mint 80% of the one e we borrow 0.

8 E. Uh and now we wait. Usually what should happen is that now the attacker should or the user now this attacker should deposit the rest of the 31 E to activate the validator. So now it's just spending it waiting until you complete the 32 ETH and now we could start profit. But if you don't uh deposit the rest of the money it just stucks.

It just it just stuck. It just stays like that. It's a pending validator. Nothing bad happens. you don't lose anything but you don't profit other and at the other side if we wait uh a long time now uh the attacker debt is increasing because time pass the SD increase in value so it increase and increase and increase and then uh now we should be able to rebalance uh the user we should be able to liquidate the user once we liquidate the user we repay the debt withdraw the stake ETH we liquidate the debt we repay the debt and everything works but this would not work.

Why? Because the Bitcoin has this behavior that after you predeposit a validator, you can't withdraw it immediately. You need to activate it and only then you can exit. So you can't exit before you before the VA was activated. Which means that in this state, the one ETH deposited or even any amount below below 32 deposited is unaccessible for withdrawals.

And only when we put the full 32 E and activate the validator and then we need to wait of course the entrance Q and everything. only then we could exit which means that this money as a collateral is stuck. Imagine you have a borrow position in a lending protocol and you can't liquidate the position. So that's what happens here. We can't access the collateral.

So we have a borrow borrow position that's position that is very very that increasing but we can't repay because we can't liquidate. So that's of course not not good. And um and the reason it's problematic is because that this is an unloosable bet for the attacker. either you you want basically to short ST and long ETH. You think ST is gonna gonna get slashed.

Didn't happen in the past, but maybe it happens. Maybe you think it's going to happen. So you short ST, you long ETH and then either you you're right and then in your leverage position you can just um get profit because you borrow SD and and as ETH as collateral or you haven't lost yet because I can't liquidate you which means that you either you win or you wait to win. So this is a un lossable bet. So maybe you can't win immediately but you can't lose also.

So of course that's not something we want for the attacker or for anyone. Uh how do we fix this? So the fix for this is uh quite simple uh from a logic perspective but it's but the to get to it from design perspective is not it's not easy. Um basically what we do is we fund the vault of course with the 18 from before. H let's say we mean the 0.

8 like before. When we predeposit, we stash to the side 31 ETH. Which means that when you want to do the predeposit itself, you need to have enough money to activate the validator already. You need to have to deposit already enough money to activate the validator. This means that when we prove that everything was okay with the pre-eposit, everything worked, we can activate, anyone can activate the validator, can can force the vault, the staking vault to deposit the rest of the money and activate the validator and then we can withdraw it if if necessary.

Which means that here you cannot make a validator get stuck and not be able to withdraw it. H and of course later we wait some time, we attempt to rebalance and we succeed because we can force the validator to exit. now because now the vi is finally activated and when it's activated it means that h we can withdraw it and we can force it to exit. The most important thing in this bug is that the code was right. So if even if the code is perfect and does exactly what it's supposed to do that to do the predeposit and then we need the user to deposit the rest of the funds and if they don't they just don't because that's what the design entails.

Even if the code is perfect we still have this bug. So this bug is in the design of the code is in the design of the of the system and not in the code itself. So it's a very difficult bug to find because the code was right. So even if even if everything is perfect in the code even if the team tells you this is what we want to happen and light team are very smart people h this is a very subtle mistake because uh everything is work perfectly and the collateral exists and everything exists but the concrete operation of redrawing it would not work in the consensus layer in some specific cases. So this was a a very very difficult er um bug to notice because the code was correct.

Uh and so so for summary so what is light? We have the vault owner which is an institutional entity or any other if you want a DAO or any other user can do it also h you deposit to your um to your staking vault. You could mint directly against there even if it's staked. So you could profit h from that stake uh from operating a validator or doing some um agreement with node operator that operates a validator and you have the agreement with them and then you could access the um the liquidity directly by uh borrowing from lido st and repaying later of course. Um and in storaa um we offer these services as I said design review which is the process where you look at the at the code at the design before the code even exist.

H actually we did this I did this for Lido for the dual governance mechanism h and um and we do of course auditing for modification web to security we run validators in Solana um and we have the sort of approval for RS and everything um okay great thank you everyone thank you very