 I should have put MEV in my talk title because we are actually talking about MEV and I think we would have a high attendance. But anyways, it's going to be an interesting talk, I promise. Cool. So the focus for today is how basically application design decisions can remove or at least reduce the centralizing force that MEV is placing on the Ethereum blockchain. All right. So let's see basically the first part of the talk. We focus about the degree of centralization in proof of stake. So basically, we will look at a few data points telling us how decentralized are we actually today. And then the second part, we focus on a more bright layout for Ethereum where we are heading and hopefully ways of how we can avoid the dystopian future scenario. And that will lead us to the next part where we would talk about how specifically we can make design choices for applications to reduce MEV and then dive into protocol as one implementation of batch actions that basically facilitate this. Cool. Let's dive right in and look at some data. So we had a talk, the talk right before, was focusing on validators. And like he was saying actually is that the set of validators today is quite centralized in a way. You have staking providers such as Lido who hold more than 25% of the market share followed by individual stakers. But then already you have the centralized exchanges, Coinbase, Kraken, and Binance who in total combined also make up more than 25% of the entire validator set on Ethereum today. So you can say we have already some degree of centralization in Ethereum today. But of course, now with MEV, you add additional risks of decentralization growing further, right? Like MEV, why is that helping centralize? Why is MEV causing centralization is because people or like validators that have the chance of proposing the next block, they can move transactions around in a way that they're able to extract additional value out of it, in this way they're actually able to reap more rewards from the blocks than anyone else would be able to do. And this way they grow their pie more and more over time. And this is already bad. This already existed in proof of work, but now in proof of stake this is accelerated because now you also have the downside basically that you know in advance who are the next set of validators so you can have more sophisticated MEV attacks that involve multiple blocks and even are taking place across multiple blockchains. The response to that is PBS, the Proposer-Builder Separation, where basically you now divide the task of the validator into two. You have the block-proposer and the block-builder. And now the block-builder is basically competing against each other and the one that is able to extract most value is winning the competition because they are basically bidding against each other and the one who is able to pay the most to the validator is the one who's picked. So you might say that basically now PBS is helpful to move the responsibility, like to move the centralization away from the validators to the block-builders. But now actually this is problematic because now we have more centralizing force on the block-builders. You can even enter a scenario where basically more than 60% or even more than 90% of all blocks are created by one single block-builder. And this can even be accelerated if they, for example, would have access to private order flow. So if now you would have a wallet such as Metamask could decide to bring my transactions to a single block builder, then the single block-builder would have additional advantages over the other block builders and would more reliably be able to win this block-builder competition and gain more and more share of the network. OK, now let's actually get to the interesting point and look at some data. So here you see basically how much MEV has been extracted, 145,000 blocks before the merge and after the merge. And this is roughly equal to 20.1 days. And basically proof of stake has only been live for not even four weeks at this point. And if you look at this data, it almost looks like we are extracting less MEV right now than we did before the merge. It's interesting, right? But what is the conclusion? Why is this the case? Now, if we look at this slide, we basically zoom into one specific kind of MEV, sandwich attacks. And we can look basically that it's starting, it's showing the first 20 days of sandwich attacks on proof of stake. And you can see basically that the amount of value extracted where this attack is growing, right? So basically at the beginning, when we moved from proof of work of proof of stake, we had one short period of time where less MEV was extracted. But now over time, we are getting back to the same stage as we did before. And now here, what we see here is basically a chart that is showing the adoption of MEV boost. And MEV boost is the protocol created by the FlashBots team that allows for this proposal builder separation, that allows for this block builder competition. And the interesting part is that basically, they correlate, right? Like you see how with the growing adoption of MEV boost, you also have growing extraction of sandwich attacks. So that's one important point to make. But then also, let's see how the adoption is going. So today, already more than 49% of all validators that we were looking at in the first slide, they have already integrated MEV boost. Now let's go one level further and look actually at the relays themselves. So MEV boost was created by the FlashBots team. But it's open source so anyone can create their own relayer with their own rules of the game for the competition. However, the relayer that was created by the FlashBots team is by far the most leading one, right? It has 83% market share. So you would say, what's the problem with that? What's the problem about FlashBots having a large market share? But the problem arises then when one of these relayers decides to start censoring transactions. And this is exactly what FlashBots does today, right? They are complying with OPAC with the office of foreign asset control. And this means that any transactions that were created by the accounts that have previously interacted with tornado cash are not being put into these blocks. So if FlashBots has 83% market share of 50% market share basically of those that are being integrated by validators, this means that today, already more than 40% of all blocks on Ethereum are censoring transactions. They're censoring the accounts that have previously interacted with tornado cash. Now we zoom one level further and look at the block builders. So who is actually behind these block builders? And here you see basically this is an entire overview of all the block builders today operating with any of the relayers in PBS. And you see that the top two have more than 50% market share. That means if basically you have 50% adoption of math boost and within math boost, 50% of blocks are created by two players, that in total of all the existing blocks that are today created in Ethereum, 25% of them are created by two single individual block builders. And then just adding again the argument that I mentioned at the beginning, basically if you have private order flows, or anyone else is deciding to sell their order flow to this one individual block builder, you have very fast and accelerated centralization force even more. Like you have these block builders within even more market share. And suddenly this topian future scenario of where Ethereum hopefully is not heading towards, suddenly doesn't seem so unlikely anymore. Already today, you have two block builders having 25% market share. And they can easily grow this very quickly. OK, that was the negative side of the talk that's now focused more on the hopefully more utopian future where we are heading in Ethereum. And for this, let's have a look at a quote that Vitalik said earlier this year. So what is his vision for Ethereum? Like how can you avoid the centralizing force of MVV? And what he is saying is that we have to create an insulation layer around the core protocol to basically ensure that these negative externalities that created by MVV cannot affect the core decisions that we are taking. Because right now, with having smart contracts built on top of Ethereum, you have these applications that now allow suddenly for decentralized exchange trading and for liquidations and all these transactions. They basically set incentives now for value extraction that gives more power to very important players and stakeholders of the Ethereum network. And we need to find a way to not do this. Because right now, our solution is basically, OK, damn, validators are centralized. So let's move it to the block builders. But now the block builders are centralizing. So where do we move this? And we need to find a way to avoid this. We have to have a better structured way of protecting the Ethereum core protocol. And what Vitalik said himself is basically the way forward is that these risks, they need to be absorbed elsewhere. They need to be absorbed either by layer 2s or by the applications themselves. Here we have another quote by Stefan, the co-founder of Flashbots, who actually last week announced that he's leaving the team because he does not agree with the centering that Flashbots is doing today. And he is also stressing the point that the right way of dealing with MVV is not to basically try to extract it and then sell it or distribute it. But the right way is to create applications that don't extract the value in the first place. And this leads us basically to the next part of the talk where we will look at how can we design applications in this way that they're not exposing MVV. To do that, we first have to understand where MVV is actually coming from. Right? Like why do we have this? We need to understand where it's coming from in order to be able to avoid it. We basically believe, or it's pretty clear, actually, that one of the reasons or the main reason that MVV exists today is that within a single Ethereum block, you have multiple different token prices for a single individual asset. So if you use the example of decentralized trading, for example, you can have a block where five people all want to sell USDC, for example, they all interact with the same AMM, but each of them would get a different price. Within a single block that has one single time, like it's very interesting, right? Like you have an AMM, one person interacts with it, they move the price, the next person interacts with it, they move the price again. And because of that, they basically create incentives for other players to jump in, move their transactions around, place additional transactions in front and after them to extract value from these users. To give a more concrete example of a real block, this is like six days old. We had one single block where there was 11 different traders that all traded Ease USDT. And Ease USDT is obviously a super liquid pair, right? It's like one of the most liquid pairs on Ethereum. And still within a single block, you had eight different clearing prices, yeah? Like the price spread across 1,337 USD to 1,351. So you had more than 1% spread in price within a single Ethereum block. And this very much demonstrates the value that can be extracted if you have so many different prices in one single block. And here, this was just a nice pointer because MEV obviously has been discussed for a very long time, it hasn't been addressed for a very long time, but it was known about since 2014. And this is a Reddit post. And the interesting part here is basically the screen shot on the right, where Vitalik interacted with and he basically said, well, one way of how we could tackle this problem of value extraction is by processing orders in batches. So let's take a look, if like looking back at the previous block that we just saw where we had 11 different traders who got eight different clearing prices, what would happen if we were able to batch them all together and would give them a single, unique clearing price? Then we would actually be able to even offer them better prices because we wouldn't have to move the price on the price curve up and down, up, up and down. But we would basically be able to not have this much price impact and have additional value that we could give back to the users. And in this concrete example, it would be 930 US dollar that we could additionally pay out to the users. But the real benefit on top of this is that because you have a single clearing price, you don't expose those trades to MEV. Okay. And this leads us now to cow protocol, which is basically an implementation of batch auctions on Ethereum today. How does cow protocol work? So we are doing batch auctions, we are batching trades together. And what happens is that basically users on cow swap or cow protocol, they go to our UI and then they sign messages, they sign and intend to trade. And this is actually really important, right? Because they sign a message and they don't just execute, they don't just sign a transaction on Ethereum. This gives us more flexibility what to do with these transactions. We are actually then able to match them together. So we collect all these orders in our off-chain order book. And then we have a competition. We have a competition of so-called cow batch builders that basically look at what are all the transactions that currently exist in our off-chain order book and try to find the best possible way of matching them together with by finding a unique clearing price for all these trades. And then the winning cow batch builder is the one that would settle these trades on chain. And what is to be highlighted here is that it looks maybe on high level, it looks very similar to the block builder competition but it's very different. It's quite the opposite actually because in the block builder competition you are really high like you're focused on extracting most value from the transactions, right? In order to be able to win the competition against the other block builders. But on cow swap you maximize the value for the users. The block builder, the batch builder that is able to find the best possible prices for our users is the one that would win the competition. And this is enforced by the objective function that we are using. The batch builder that is maximizing most of the utility for the users is the one that wins the competition. All right, so how does this work? How do we keep our cow batch builders honest? Is they participate by staking on our protocol then they can participate in the competition and in case of malicious behavior they would be slashed but if they actually win the competition and they execute the trade on chain they're being rewarded by the protocol. So now this is all like all sounds very good in theory, right? Let's look at it in practice. So cow protocol has been licensed a year and a half. We have been processing $15 billion in training volume so we have a lot of real life examples. This is like an example batch from 11 days ago where we had one user that was wanting to say $40,000 worth of money fault against USDC and another user that wanted to actually buy money fault wanted to buy $48,000 worth of money fault. So in this particular batch our cow batch builders were able to match the two trades together and in this way create additional surplus for our users, additional value that could be given back to the users because instead of processing $48,000 worth of tokens on one AMM and shifting the price and then settling another transaction of $40,000, $48,000 and shift moving the price back instead we were able to match these two trades directly against each other and only the leftover amount of roughly $8,000 needed to be placed on executed in an on-chain AMM. And this way we were able due to the price impact, the removed price impact, we were able to save $1,500 for users and also we were able to save on protocol fees for the users and additional $800 that didn't have to be paid to the AMM. Cool. And that basically leads me already to the final slide of my talk. So our vision is to protect the users and our vision is to protect the Ethereum core protocol against the negative centralizing externalities of MEV but to achieve this we really have to become the backbone of decentralized trading on Ethereum and for this what we would like to achieve is that really like our cow batch builders are submitting one batch for each Ethereum block. Ideally this batch would actually be placed first in the block because this way we could also avoid negative slippage and fair transactions but the real argument here that I wanna make is that even if our batch is not placed first in the block by growing our share we are basically reducing the total amount of MEV transactions in the block and this means in other words, growing the share of cow protocol means at the same time reducing the share of MEV. Thank you everyone. Thank you Anna. We still have five minutes more so if there are questions I got one, two. Hi, I have one question. How it can be more profitable when MEV? So you have to reward more than flashbots, right? Do you mean, can you repeat your question? You mean how can we be, how can we ensure that? How you can give more rewards to co-builders than MEV builders? So basically maybe can I go back in my slides just to make this point clear? Is that possible? So okay, otherwise I can explain it but basically we had this one slide where you could see that the value chain of a transaction from it's being placed and it's being executed on chain. So basically, yeah. Okay, so what we do, so these are two separate processes, right? Like the first part is basically cow protocol that is the application on top and what we do is we collect the user orders and we collect them, they're signing and tends to trade so we collect them off-chain in an off-chain order. And then we have the cow builder competition and they basically, they have their own set, they have their own rule set and their own competition rules, right? And that, it is completely separate from the block builder competition. So someone who is participating on a cow batch builder competition, they basically, they know if they participate, they only get rewarded, they only win if they are maximizing value for the user. But this is orthogonal to the block builder competition on Ethereum, that happens at a later stage. So right like the cow batch builders, they find the perfect solution, they then submit them on chain and on chain they can actually decide how they want to submit this. This is up to the batch builders. They can either submit them directly to the public mempool or they can submit them via a relayer if they decide that they want to additionally protect themselves against MEV. However, basically at this point in the execution, if they're being front under sandwiched, this is actually something that the block builders, sorry, the batch builders have to pay for it. So at this point, the user is already protected by the price that the cow batch builder promised. So the cow batch builder wins the competition by promising I can get at least this price and then they hold accountable for this. So this is for sure the price that the user gets. Hey, thank you for laying out the problem with L1 right now in terms of MEV, the very nice slides. I'm curious about how you moving this problem into the application layer, how you deal with censorship resistance problems in the off-chain order books specifically. So today if I go to the cow swap website and I make a transaction, like how do I know I'm not going to be censored by the cow swap like company or whoever runs this protocol? Yes, no, that's a very good question. It's basically something that we're working on. We still have some centralizing facts, components in cow protocol. But essentially basically this is right now we have this off-chain order book that is hosted by us, but the idea is that in the future this will be decentralized and not hosted by us anymore. And yeah, but basically this is the answer. It's like it's an ongoing process where we have to decentralize more and more of the components. One last question here. Anne? Question is when you're trying to remove the MEV in the blocks by cutting these batch bales in between, how is it then still attractive from a builder perspective since he has less math in the block now, how can he still win the bid auction? And then how do you make sure that the block gets actually proposed? So I mean, right now, usually not 100% of these transactions in a block or MEV transaction, right? So basically you would, even if you're not the first in the block, you could still ensure that you're part of it. But I think one interesting point that where we could get at is by the more order flow we are actually processing, the more surplus we are generating, right? Like this was the point on like this one slide over here where we have this like real example of creating an additional $2,300 in surplus. So what we could do is, for example, if we are creating this much more value for users, we could take a percentage cut of this if it was needed in the future to pay block builders to guarantee execution in a block, we could do this. But our future scenario is more focusing in the direction that hopefully this won't even be necessary, right? Because we are basically trying to win over more share of the general transactions on Ethereum. And then that would automatically reduce the amount of MEV transactions in a block. Thank you, Anna. We are running out of time. So you have enough time to go to the next talk. Thank you so much, Anna. Big round of applause for Anna. Thank you.