Dan Elitzer

Can we create additional systems on top

that essentially recheck these values that are critical values from a different perspective or a different validation point.

I think that is really important because the more you can have systems that either one of them can block bad state systems

from occurring in contracts, that is what's going to give us that next step function improvement in terms of the security that we can promise to users.

And I think one of the interesting things there that helped me wrap my head around this was the idea that there are things like there are bad states, right?

The amount borrowed from a lending protocol should never under any circumstances, right?

Traditional ones, not uncollateralized ones should never exceed the value of the collateral.

Right.

You can you can hard code that.

Maybe that's supposed to be checked through different paths of different interactions that you're having with the contract.

But what the credible layer lets you do is say this is a state.

It doesn't matter what's in the transaction where it goes.

Do not include any transaction in a block.

Do not sequence it if the end result is an invalid state based on these rules that we've predefined.

And I think that's very different from the traditional way of doing security analysis where you're saying like, hey, we're going to step through the changes here and like check each thing along the way.

Are there any paths that can get us to a bad state?

And instead you're just saying, what is a bad state?

I don't care how you get there.

You're not allowed to go into this.

Mm hmm.