Flash Talk by Marc Egli - Blockchain Engineer, ChainSecurity

Hello everyone. I'm Mark and I'm going to talk to you about uh stable con safety under L2 sequencer downtime. So um I work at chain security. Uh we are a blockchain auditing firm since 2017 and we work with the major players of the space. Uh from my side I'm a blockchain security engineer since two years.

I worked with circle a velo and poly market and many others. Um, initially I'm come from a web two uh background but um I've also done some like basement fuzzing so if you want to talk about it after happy to talk about it but yeah let's talk about uh risk of L2 sequencer downtime. So for cryptobacked overcolateralized stable coins but more generally for uh lending markets uh we have this assumption that the uh price feed is up to date right but also that we don't have big price jumps. So uh if you want to represent that is um why we have LTV a loan to value right so if you have a a a collateral with 90% LTV it means that we implicitly assume less than 10% price jump I mean price draw down so that we don't create bad depth um so those assumptions are very important but um and we can ask ourself do they always hold and for example for L2s, right? Like like Eve has this Ethereum chain has this livveness guarantee and L2s inherit from the security of Ethereum but don't don't actually inherit from all the livveness properties as we will see.

So a sequencer basically uh to sum up is this big machine that uh produces blocks and it's like centralized entity usually and it will just produce blocks and uh um advance the L2 chain. But if this sequencer fails, no more blocks are produced and now like our prices are frozen and we have to wait until recovery. And this basically breaks the assumptions, right? Because now our price might not be up to date when the sequencer comes back up, but also when we recover and update our price, we might have a larger price jump than we would want to. So assumptions made for for like L1 do not hold for L2.

And by L1 here, I mean mainet. Um and we will see that now, right? So assume we first start with the real price and our oracle price being the same, right? And when the sequencer fails, the Oracle price stays the same, right? Until it goes back up and and the transaction comes in to update our oracle price.

And if the real price drops, right, we have this uh difference between the oracle price and the real price. And when the oracle price gets updated, it might decrease so much that that the position gets under collolateralized and creates bad depth in our system. So that's one risk, right? Creating bad depth. The other risk is now you have a race between liquidators uh and the borrowers because a position is madeatable as soon as the oracle price drops.

So it might not leave enough time to the borrower to supply collateral to save he save the positization and not incur a liquidation penalty. So what we see here is suppliers suffer because the whole protocol might take on bad depth because of the price changed which is too abrupt and borrowers might not add collateral in time. So both sides are suffering from that problem and I mean because like I work in in in uh in security and audits you always think can I make it worse? Can I exploit this? Right?

And actually you can um if you manage to borrow before the Oracle price update happens, you borrow at a higher rate than then then you should be able to. So here you would borrow 800 USD against one if which here is priced at 1,000. But the real price is 500. So I already create a position that will be under coll that will be under collolateralized. Um and now we can ask ourselves can we like prevent this right?

And the obvious question is can I just check that the price is stale but the problem is we don't know if the price is stale or just has not changed right and usually the like chain link oracles have a heartbeat of one day. So you're not sure if it's a it's a sale price or unchanged priced. Um the other thing um which is for example used in a V3 is chain link L2 sequencer uptime feeds. Um, here you would use an oracle that tells you is the sequencer up or down, but you you would use it to say did a sequencer downtime just happen. And if it happens, you can prevent, for example, borrows and liquidations for a grace period that allows on one side borrowers to um to uh add collateral and that gives enough time for the price to update before any new borrows can be open.

However, it's it's not really perfect because like the update of that oracle must come in when the when the sequencer goes back up and you're not guaranteed to be the first transaction that is processed when your sequencer goes back up. And there's some ways if you include your like transactions option through the inbox to actually raise this. I will not cover this but if you want to talk about this with me later you can come and see me. Um and yeah like we can can conclude here that actually landing markets have additional risks on L2 right because the assumptions of livveness don't uh don't fully hold and uptime feedation is also not perfect because it's a hard problem and I haven't found myself a perfect solution. And the last I mean key like takeaway is lifeless assumptions that hold on one chain might not hold on another.

So like even though you build a protocol that that can be launched on like every like EVM chain what the chain underneath matters and those properties actually really matter for security and safety of stable coins but also lending markets. Thank you very much.