Martin Koppelmann

And then there is this transaction coming from L2 that also wants to kind of go through easy kind of into this specific liquidity pool.

There needs to be some ordering, which ultimately does the Ethereum validator or builder does.

But here, there needs to be some... Yeah, if you want to do this efficiently, ideally, you have some coordination between the sequencer of CL2

and the builder of L1.

And there are ways to start, or we will start the EZ kind of with just submitting bundles.

So kind of without additional required protocols or without additional required standards.

But as soon as you want to have, want to go beyond one chain, you have multiple chains, then it absolutely does make sense that this,

coordination layer, which is implicitly already there through kind of block builders and their protocols, that that will become more important to actually

build proper blocks that have all the aggregated proofs.

You can have all the chains having separate proofs, but of course it's also more efficient if they aggregate the proofs.

So long story short, it can be thin, but to make it work well and to make it work efficient, there will probably be some layers.

Yeah, for sure.

Basically on the second one, so right now, L2s essentially create relatively little L1 demand.

So kind of they, I mean, yeah, they use blobs, but they...

sometimes only settle every 10 minutes.

So basically just a couple of transactions every now and then, every few minutes.

In this world, essentially every L2 user has the option at any time to do a transaction that also uses L1 liquidity.

And if there's enough interesting things on L1, which they usually are or still are, then the expectation would be that, let's say,

let's say there are 200 L2 transactions in a 12-second time, then at least a couple of those, 3, 4, 5, 10, will actually also want to access L1 state.

So definitely much more, yeah, much more