Should MEV be Tackled at Application Layer or Protocol Level?

Hello, hello. We're at the final debate of dev conflict. I can't believe I'm saying that. This afternoon we will be talking about MEV, and this debate is about, or titled, sorry, should MEV be tackled at the application layer or protocol level? Please welcome to the stage Felix Leupold from Cowswap.

The debate will be moderated by Greg theGreek.eth and Tomas Stanjak. I hope I didn't pronounce that right. I'm sorry, Tomas. From Nethermind.

Thank you. And here's your chance to vote. So should it be resolved, or be it resolved, Mev should be handled at the protocol rather than the app level. Alright we vote now, we don't vote at the end? We vote at the beginning and then again at the end.

Okay. Yeah So your duty is to persuade the crowd. Okay. All right give it like 30 more seconds. Whoa.

I did not expect this. Nice. What? Anyone else? Holy cow.

The last call. Okay. We have 16 in the agree category. 6 in the disagree and 10 in the abstain. So without further ado, the last debate of today.

That many of you really don't have an idea. All right. Welcome, everybody, to the final debate. My name is Greg. I have Tomas over here, and I have Felix over here.

We'll start with some opening remarks. Each of them will give kind of their stance on things, and then we'll kind of go into a bit of a free flow structure. I do want to clarify what we mean at mitigation level at the protocol, because I think this one's a little bit murkier. We've agreed to discuss it at, not at the infrastructure layer, but at like enshrinement within the protocol. We did agree to that.

Sure. Yeah. Is that our... Oh, okay. Wow.

I would even argue that it should not even be at the infrastructure layer, but I'm happy to just argue a larger portion of it. But yeah, we can maybe even look at the two and. Let's look at the two, and we'll clearly define that as we go. So we'll start with Felix. Yeah, my name is Felix.

I lead the technical development at Cow Protocol. And well, Cow Swap is an application layer solution to MEV. So my stance here is that MEV should be tackled at the application layer. And I think my main argument would be because it's a problem that stems from the application layer The reason that we have MEV is mainly because we've taken Trad fi mechanisms that work well on continuous time and deployed them to a system that doesn't have continuous time so kind of defy is built on the broken premise of continuous time mechanisms and the fact that two people that are trading the same asset within the same block get different execution leads to this incentive for the builder or some other party to order the transaction in a certain way so that they get the best execution of an asset in a block and somebody else gets a worse execution. And so I think, you know think really it stems down to having used inferior mechanisms and we can fix the problem by looking at better mechanisms to achieve the same thing.

And kind of my stance is that 99% of the MEV or even more that we know of today can be mitigated this way. And in that world where there's one or less than 1% left I'd argue that enshrining or even building infrastructure kind of across different use cases to it to tackle that that little MEV that's left is just not going to be worth the complexity effort and time. Thank you Felix. Tomas? TOMAS STANTSCHEGGENERNANNEN This is my five minutes now.

TOMAS STANTSCHEGENERNANNEN Two and a half. TOMAS STANTSCHEGENERNANNEN Okay. Hi, everyone. So I'm Tomas Stanscheg. I've been working on MEV on the protocol level for a few years now.

But obviously, I've been looking into all the different levels of potential mitigation of the problem. When I think about MEV, I think mostly of the marketing efficiency in general, and marketing efficiency that becomes problematic when you inject into the protocol actors that are at privileged positions. So when we say minor extractable value, it was coming from the space of there was a minor, and minor was in the place where they could decide how the block looks. And nowadays, it's a block builder or proposer actually having this ultimate say of how the block looks. And I feel that in most of the cases, the application developers simply don't have access to being able to remove those privileged positions that exist on the protocol.

Without the protocol intervention, you cannot remove the most privileged positioned actors advantage in MEV extraction. The problem simply has to be addressed on the protocol level. And it doesn't mean that you recklessly build applications that are inefficient or simply incorrectly designed on the algorithmic sense of pricing. You still have to address it, but it means that just those applications are designed properly, correctly. And then what stays, do you create separate memples for each application?

This becomes a bit like separated inefficient markets. It reminds me the time when, as one of my first jobs, even my first job in the IT, I was helping the company that was selling cigarettes in Poland to the people from Germany that were crossing the border over the bridge. Actually, those two cities were separated by the river on the Polish-German border. And the German would cross the river to buy cigarettes in Poland cheaper. And would you say is it solved on the cigarette market level in Poland that they are better at pricing cigarettes because somehow those cigarettes are priced so well that the application sells that it's cheaper and no it's a market inefficiency of the bridge and actually when you connect all those markets when you remove the borders and limits and tariffs then suddenly you can still sell those cigarettes if you produce them cheaper but you have suddenly access to the to the larger market and I think it can be simply seen as the applications in MEV, like in the space when we consider DeFi, everything else together, they create MEV because of inefficiency, disconnections, and different privileged positions.

On the protocol, if you connect the markets, if you remove the privileged access, you're actually allowing everyone to discover pricing efficiently. The applications can resolve those aspects of the pricing that are never resolvable in isolation. So very few markets are totally isolated. And very easily you can see that, like in the global traditional finance markets, is oil isolated from equity? No, it's not.

Is oil isolated from interest rate markets, from the gold prices? No. So even if you have efficiently constructed markets, commodities markets, separately from efficiently created markets on equity, you still have those arbitrageurs and coordinators that understand how one market affects the other market. And even if those markets are perfect, you still want to have as connected market as possible with the equal access and with perfectly organized market structure. And those are designed nowadays by international regulators, market organizers, which in the space of blockchain are the protocol level designers and researchers so on the protocol level we can create markets where everyone has equal access where everyone can contribute to the price discovery across multiple different applications and this can be can be only solved there on the application level it can be done correctly, but not address the major problem.

Thank you. I have to move my mic away from my nose. Apparently everyone can hear me. Thank you both. Let's...

I want to address first the, which you both briefly discussed, which is the surplus or the arbitrage that does exist because I think there's kind of like two categories, there's some categories of MEV that we're actually trying to deal with versus some that we don't care to deal with. For example, back running can be healthy to the network, right, versus something like a sandwich. And so from the cow perspective of how you're dealing with it, what type of member are you actually trying to target and mitigate, and which ones are you promoting? I would even disagree with that backrunning is net helpful. It's a bit like you're losing your wallet, and somebody is picking up the wallet behind you giving it back to you For a finders fee and yeah, you of course it's better than not getting the wallet back But the best thing would be to not lose your wallet in the first place, right?

So one of the issues that I have with the protocol level approaches is that it requires you to extract Mev in the first place so it requires to first take it and then maybe we can find ways of how to efficiently Redistribute it or even give it back to the originator of the MEV But let's take back one as an example if you are going to execute a big trade on just a single AMM and then rely on some PBS auction and maybe an OFA that will give you a rebate on your transaction to have an efficient market maker back run your trade Maybe source some liquidity from another trade, maybe source some liquidity from another AMM, maybe source some liquidity from Binance. Then you're moving the AMM that you traded with twice. You are paying price impact twice. You're paying LP fees twice. You're paying gas fees twice.

So you have all this extra leakage, which basically, sure, you'll get a rebate, but you're not getting the best execution that you could have gotten if in the first place you had used an application That prevents this type of me V at the source and for back running specifically that would be Just a dex aggregator or like some venue where those participants that would otherwise have to go and back run You can directly bid the best execution for you. On the background side, I feel the problem is simply a bit more complex. So the user comes and executes a trade, and unless it's a very sophisticated user but has to execute large volumes, they move the market. So it's not simply losing wallet, it's moving the market and realizing that you have to have some solutions to not move the market. And then the way you can do that, you can algorithmically split the order into smaller bits.

So you have to have someone providing that service, right? So you would have to use maybe DarkPool with the algorithmic execution, maybe some broker helping you to execute the trade. Or you can have an automatic system that is supported by the protocol that provides you with the transparency, well, privacy for your trade, for your order, which is a bit DarkPool style, and at the same time, creates this programmatic privacy solutions where others can start practically bidding for providing you the service. And the more efficient the market, the more open and permissionless it is for the bidders, the more they will pay you back. Which means that practically the protocol efficiently remove the need for you to go to anyone for that service in the first place which means that suddenly you can execute all the large trades without any worry that you will not discover some part of the market related impact that you introducing and this as I mentioned before is very often outside of a single application because I can trade on a single app service, but those who are bidding for my trade to back run it can actually realize that that trade has some secondary effects on multiple other applications.

So they'll collect it and they'll understand that they're competing with each other and they have to pay me more because the others also discover those secondary effects. So suddenly what I can be paid out is much beyond the single application and then only the protocol that enables everyone to to beat equally across all the markets to me uh gives me ability to get that background back i would disagree with that because i think if you want to make a large trade and you're split it into multiple um legs you want to basically do a t-wap then this is something you can do on Cowswap today. It's an application layer solution which works with smart contracts that, based on a certain condition, place an order inside the Cowswap batch. So as time passes, the next leg, if you will, becomes valid. And solvers, which have access to the entire liquidity pool, which have access to Binance, which have access to all secondary markets, will then compete at the time that the order comes valid for best execution.

So even if you do, I mean, I think it's very smart to, yeah, if you have a big market moving trade, you should split it up into chunks. But even then, if your individual chunk has some price impact, just because the cost of execution maybe on main net might be so big compared to your trade size and the liquidity of the token that even if you split it into $1,000 trades, you're still incurring some price impact and it's better to go 50% to Balancer and 50% to Uniswap. Instead of executing it on one venue, you're benefiting from a DEX aggregator that kind of aggregates all those price sources. Maybe we have a different understanding what is application versus what is protocol. Like to me, cow protocol is an application.

And maybe for you, cow protocol is a protocol. So yeah, maybe this is where some of the... Did you say cow protocol possibly is a protocol? Cow protocol is an application solution to... Why did you call it cow protocol then?

Because it's an application solution to... Because it's not Ethereum, right? Like enshrined PBS to me is a protocol layer solution because it's an application solution too, because it's not Ethereum, right? Like, enshrined PBS to me is a protocol layer solution because it's actually Ethereum. Like, I can be an Ethereum validator and I cannot give a shit about cow protocol.

But if PBS is enshrined, then I have to run like a... Yeah, definitely I see cow protocol a bit as a protocol solution. It's not protocol solution to the level where you have it in the Ethereum protocol and that's why probably over time it has some limitations in the ability of providing full secrecy and privacy and efficient execution and permissionless access. So it does have to overcome the problems of how to handle white-listing and who can participate in the market and over time it improves and hopefully it reaches the stage where actually you saw in Duke cow protocol behaves on such a good protocol level they can enshrine it into aetherium as a protocol already cross blockchain protocol right because then maybe you go even further you think that cow protocol becomes like a overarching protocol over multiple blockchains and the blockchains become more like they some kind of specialized protocol within that ended aspect of the protocol for the market when I think of application level solution I'm thinking of a single maybe like job or a series of smart contracts and defining very particular market whether this is like interest rate market, like particular decentralized exchange on the FX or lending protocol. And this one doesn't have usually access to all the interconnected aspects of multiple markets.

So definitely I see that when I argue for the protocol level solutions, I see that core Protocol goes there. And yeah, that's simply the name comes from that, that it escapes that understanding that it's just a single application. So Tomas, to understand that better, you're stating that much similar, opposite to Felix, that you actually think when you say protocol, you're saying it can be on chain. It can be the protocol, the actual someone like a cowswap protocol? Well, I would say cowswap does exist outside of the chain as well.

There are solvers. There are those who look for the. Cowswap doesn't exist in this fork choice rule or in the state transition. So. Oh, when I say that the evolving protocol, the one that actually wants to achieve all the permissionless access, all the aspects of privacy, the mempool that is protected by the aspects of the protocol as the blockchain protocol, would over time require to be merged into protocol to have all of this.

Otherwise, it will have the off-chain components and the aspects of governance and whitelisting that we will not be capable to secure them with the same level of the entire blockchain protocol security. And this will be needed because the market in the end, all the markets together in blockchain blockchain will be the single thing that Will have to be protected secured with the largest amount of the security deposits and slashable offense So I think I mean I think I would not want or I don't think our swap or protocol would be enshrined into Layer one at any point I think for me the difference between what is an application specific solution and a protocol or infrastructure solution is not like, Uniswap is a Uniswap protocol. They will call their smart contract a protocol. But I would not say it's a protocol solution to, or even if they were found a way to solve ME with their smart contract, it wouldn't be a protocol solution just because something is called a protocol. There might be other reasons why projects like to call themselves protocol.

To me, really, the difference here is when I make a regular transfer or if I buy an ENS name or if I make a tweet on Farcast or whatever, if I have some use case that has nothing to do with what people go to Cow Protocol or Cow Swap for, which is making DeFi interactions, do I have to care or am I affected by that protocol or infrastructure choice? And I think with PBS, that's a very clear yes. Well, I might still be able to send my transaction in the public mempool, but if I have an address that is disliked by Beaverbilt and Titan, I will have to wait 15 minutes, 15 minutes 20 minutes before my every for my transaction actually gets included so Because of the way that me V is solved or attacked or mitigated right now People or applications that have nothing to do with the root cause that's producing the MEV have to worry about it And I think that's where I see the difference between what is protocol and what is application level? Hmm still like saying that the cowsap will always have some selection of markets that it will be integrated with, and the only way to integrate with absolutely all the markets that exist, let's say on Ethereum, is the way to be a builder of blocks on Ethereum. So over time, by introducing the builders that have the full programmable privacy that is absolutely trustless.

So, I say something beyond the solutions like trusted execution environment because here I think easily we would find the argument saying, well, this is not something that we dream of long term. I think that was like a stepping stone to go to the space where you have the Probably cryptographic solutions for the privacy, but then suddenly the solver slowly becomes that same aspect of a searcher or builder competing for the beats back to the To the proposer and then those forced for the protocol through the protocol back to the users like dissipated for the application so so sure when you have the applications that say we're not doing anything stupid we're not leaving any money that is like really very easily internal internalizable and those applications but i i trust that there exists ethereum level memple handling uh beating for value uh beating for mev that is like uh easily enforceable back to where the value is created because of that in the perfect market, in the perfect competition, and that bidding actually removes all the value back to the application. So in a fully permissionless market where there's full access to information and full privacy for the order flow of those bidders, and they exist in this like black box, that's where you have perfect competition and all the value in perfect competition goes back. And then practically there's no sense for the applications to create some alternative mempool constructs. So like even the mempool constructs that are only encompassing some subset of protocols that got integrated, whitelisted by the whatever only encompassing some subset of protocols that got integrated by whatever governance mechanism of the group of protocols that says we introduce a concept of solvers.

So protocol like this, like Kausma, is extremely important in this transitory period. It provides the solution on the way to have the solution being accepted by everyone, saying technically we can deliver protocol level MEV solutions. So over time, this is the way to go. Nowadays, both are actually approaching the problem of technical limitations from two directions. Both serve its purpose, and both have also limitations.

Maybe just to answer or asking some more questions on this end, where I see or where I think MEV cannot be really tackled efficiently at the protocol level is that the core Ethereum protocol primitive is transactions. And even if we have a perfectly TEE-built block builder where we can run private searching algorithms on top of all the flow, the user has to sign a transaction and the transaction is I'm gonna make this Uniswap trade. And then I can have like some searcher looking around and see like, oh actually the price on Uniswap is not the right price, you have to go to Balancer, and some price that then this arbitrageur actually executes. So we end up with different prices for the same asset within the same block, which means that somebody gets to buy it low and sell it high and is making a risk-free profit. And so this, to me, is a fundamental flaw of the Ethereum protocol, the fact that transactions, if a user's willing or intent or like whatever action is surrounded by a by a transaction then you cannot actually have Most efficient mev capture which in an application that says okay don't sign any theorem transaction just sign a limit order sign an intent We're gonna batch all those intents together And then we're actually going to find the most effective way to trade to clear you which in a perfectly competitive market with participants that provide liquidity would just be Some of our adjunct equilibrium like you're trying to all the people that are selling ETH and all the people that are buying ETH You would trade them directly against what another peer-to-peer and like what we call coincidence of once and then you would take the excess Demand and look on whatever is remaining on chain as liquid sources whatever is remaining on binance liquid sources, whatever is remaining on Binance, and you sweep that in, and you derive at some price for some asset in that block, and every participant of the batch gets exactly that price.

So there's no advantage of one user gets another price than a third user, and just this solution is something, unless we make a huge change to Ethereum, the base layer, which I don't think we will or want to, cannot actually achieve. So even with like perfect TEs, with perfect block building, I would also actually like to talk a bit more on like how much privacy is actually needed. I think, you know, there's an argument to be made that if you cannot guarantee perfect privacy, probably the second best thing you can do is maximum openness and say like, oh, I'm a DAO, I'm sell 50 million dollars of ETH the next week and I want to do it over a TWAP there's like on it's gonna be very hard for the DAO to really not leak that information to anyone so the next best thing you can do is actually have an open auction on how protocol and basically say like you know bidders line up and give me the most competitive price so the worst thing that can happen to you is you trying to make a trade private You're not leaking you're leaking it to one party that has advantages information. It can like, you know Execute you at or like a front run or you have some value extraction And I think it's very it's going to be very difficult to guarantee this and there's only very few trades that actually benefit from from the perfect privacy. And yeah, even those aspects, I think, should be solved more on the application level.

Like maybe the cow protocol batch should be private and solvers should run in a TE. I think those are all things to be considered. But I don't think that Ethereum should force block builders to be creating basic transactions based on some trusted hardware components. So Felix, interesting, because why does an intent-based system, or a coincident of wants, however you want to describe it, why does that have to be so tightly bound to whether a user can be sandwiched at the protocol layer? Why can't we have transaction ordering, whether it be random or not, and still have your auction system work over top of it?

Because it seems like you're making them mutually exclusive when they don't necessarily need to be. Yeah, so I mean, for me, the fundamental root cause of MEV is that the same asset is traded in the same block at a different price. And this is the root cause for all relevant types of MEV. That's my claim. If you look at sandwichings, which you just mentioned, in a sandwich, you have somebody that is seeing a trader who has a large slippage tolerance, and they are inserting a transaction before them, buying the asset at the old cheap price, maximizing the slippage tolerance of the user who's buying the asset then at a higher more expensive price and then the Sandwicher sells the asset at the highest price back And so we have the same asset set selling trading in the same block at three different prices Right if you look at six six arbitrage The price on the AMM is whatever it was on buying It's 12 seconds ago time has moved on new information has been incorporated Binance price moved and now people are racing to trade against the AMM at the outdated stale old price So again, there's an arbitrageur which gets to take that price and then the rest of the block is trading somewhere close to the new equilibrium price if you look at liquidations, there is some liquidation threshold that's been reached and then and Lending position is being liquidated at a discount.

So whoever can Back run the Oracle that has put that position underwater now gets to liquidate that position at a steep discount Let's say 10 15 percent liquidation discounts are usual and so again whoever gets liquidated trades at a price a and whoever Trades in the rest of the block trades at a different price So the fact that even though blocks are created in one instant of time There's no it's up to the block producer to decide the ordering of transactions within a block There's no information which transaction actually was first right like the whole idea of having Execution prices depend on the ordering of transactions in the block. It's just it's just crazy I mean, that's that's what creates a movie and if we have a system in which we say Every asset can just have one price per token per block you solve sex-tax arbitrage because the LP will trade at the new Equilibrated fair finance price it will not you you already already have this limiting notion of having to have a notion of price. If you're thinking about executing actions or transactions that have a way of expressing themselves in a price that is balancing everyone. But there are so many other aspects of MEV, like, for example, executing a vote or delegation. I'm delegating someone and someone back-runs me because they say, well, actually that vote creates the opportunity to execute a lot of other interactions with a chain.

So they pay me, I voted, I just delegated to someone and someone pays me, let's say, $1,000. And I think like, how is it related to a vote? And it happens to be that others started competing for being the first one to act after my vote. So what are they doing after the vote? They are buying an asset right and so literally the vote is somewhere in the middle of the block everyone that bought the asset before the vote paid a shitty price and everyone who is buying the asset after the vote is paying different price.

But per block and if the vote has passed before the auction it's whatever the price was before the vote and if the Auction gets headed after the vote. It's the new incorporated price, but you don't give privileged access to one person that Gets to background the vote and then execute whatever liquidity is now available for cheap But you actually have a fair market bid for this entire new supply maybe that was produced or demand that was produced by the vote, and you clear it at a uniform clearing price for that block just because there is no... The right who gets to background the transaction is arbitrary. It's whoever pays most money to the validator, which has nothing to do with this, right? Like, we're relying on MEV to secure the chain, but it's like something that has, it's actually nothing to do with the core, yeah, reward or work that the validator does.

Is it not fair to say on cow, and in most systems like this, though, that a lot of the solvers, advanced solving is very difficult, and the pathfinding algorithms to actually get that take considerable effort to get there, Advanced solving is very difficult and the pathfinding algorithms to actually get that or take you know considerable Effort to get there and a lot of the bigger players actually end up using their own float meaning they can actually set pricing borderline to sex pricing and Actually give that competitive offer in a per block basis I wouldn't say I think 80% of volume. I don't have the exact numbers I think 80% of volume is still settled with on-chain liquidity. I think I checked it a little earlier, it was closer to 60. 60? Okay, I mean, but still like, I mean, more than...

But 40% is a lot. 30% of inventory. Yeah, it's their own float. But that means that basically you get the liquidity from Binance and Coinbase and all central and L2s like in that atomically in that in that Batch because those parties will actually have inventory and will then hedge each other themselves on on secondary market So I think it's I think it's a healthy sign I mean, I think it would be I think sixty to eighty percent is something that I would expect It's just like the way that price finding happens So here's an ethical question for both of you I don't know who wants to take it, but it's basically like, should we actually be considering that we need to rely on application developers, whether it's Solidity or whatever, on the execution layer, to actually implement these mechanisms correctly to protect the users? Or should we not just have it as a public good that anybody can build an application and just assume that there will be a lower threshold of MEV on their protocol.

Because frankly, we still see that reentrancy guards don't get implemented properly, and that's a pretty basic concept at the Solidity layer. But that's what I was talking about, the correctness of implementation. Yes, from application developers, from the Solidity smart contracts developers, you expect that they'll handle the security concerns properly and they'll understand the market that they are building. Do we want them to actually have to think about the trade privacy, mempool construction, the interactions of the validators, and the handling of all the possible interactions with all the possible markets existing on blockchain? No.

We want them to feel very comfortable that by deploying the application on ethereum blockchain they automatically integrate it with the entire market and there is some efficient mechanism that actually allows them user their users to interact with that application with safety that they can recover all the value that they create across all the applications that they don't have to think about all of those different integration if i deploy an amm i don't have to think how i interact with the traditional finance like real world assets commodity prices or the lending markets or in an nft market because just someone deployed in an nft market that the body grows whenever the price goes above some like there can be so many like expressive and creative ways of of introducing a market that you cannot predict and that it cannot price and easily if you don't connect permissionlessly for any arbitrarily sophisticated trader to pay it back to you and only protocol can deliver. I think that argument is a bit like saying you don't have to drive carefully as long as you have an airbag, right? Like, as long as there's safety on the base layer, you can do whatever you want, you're not going to die, but you're still significantly better off if you don't crash your car into a wall. And I think who is best to, you know, if MEV stems from the application, then the best party to think and internalize and mitigate that MEV is the application designer. They have the domain knowledge, and we don't need to overload the complexity of the base chain.

Yeah, I think that's what I say, that you have to drive safely. I said that every single application developer has to think about the safety, but also they need to know that when they go to the road, that there is a rule, there is a set of rules, the traffic code that says that others will behave according to some rules. So when you go with that airbag and drive safely, that you know that others' reckless driving will not cause you to be in the accident. Right, but that rule can be something like we order everything by priority fee. It doesn't have to mean like, okay, there's this auction where now, even if I have anything to do with the underlying use case, I'm not affected by this.

But ordering by priority fee is also solving this on the protocol level. Is it solving it, though, at the L2 level? Because L2 is sort by priority fee. No, I'm saying this is one of the approaches which is resolved on the protocol level. That if we say that all the transactions will be always ordered by the fee, the solution has to be done, implemented in the protocol.

We cannot allow the builders to ever sort the transactions in any other way, which means that it requires the designers of the protocol to decide that this is a solution. Whether this is a solution or not is questionable. Arbitrum says it is solution. Whether this is solution or not, that's questionable. Arbitrum says it is.

The other protocols say that it's not. But if we decide that this is a solution, we say that actually it's only solvable on the protocol. Now, we need to move to Q&A shortly. I do have one last burning question I've been wanting to ask. Felix, do you have a response here?

To what? response here to what to the to the well I mean I would disagree with so we had priority fix be ordering prior to kind of the rise of me V right and so I think you know I think yes priority fee ordering is I would like to see blocks be ordered by priority fee and if that for you is a protocol level me V mitigation then I guess I would you know I'd then that I think it's something that we we just for, the protocol MEV mitigations we're seeing are something like, yeah, block builders with TEs, these back running auctions, private mem pools. To me, these are the type of solutions that I would not like to see enshrined PBS because they are overloading the complexity of the consensus layer, saying like every block should be ordered by a priority fee is to me an acceptable protocol level rule that if we can agree that's all that's needed to solve MEV on the protocol level, I'm signing up for that. Perfect. Finally, one last one for you because...

Interesting. One last one for you. If MEV was solved at the protocol layer, true and true, let's green playing field, would that mean that cow swap or cow protocol potentially loses some product market fit? So I think when we built, when we originally thought about the value proposition of cow protocol, we did not know the extent that me V would play the role to The extent to which the me we play a role in the in the ecosystem so the the reason we thought multidimensional batch auction with uniform price clearing are Better is because they allow Just the most structurally efficient way for people to trade if you're selling an asset And I'm buying an asset instead of you going to a market maker paying an LP fee and me going to a market maker paying an LP fee the best or more sufficient way to trade is just by Incoincidence of once so I think even if there's a perfect Mev solution at the protocol layer It would still be beneficial for people to trade using the cow swab batch auction and it would be You know still a better application Right now there is a lot of extra value that's coming from the application because of the presence of me V but I don't think that cow protocol as an as an as a Trading mechanism would have no USB or it would still be you know, the best way to trade It would just be less obviously the best way to trade Cool. We do have Q&A ready.

Oh Or it would still be you know the best way to trade it would just be less obviously the best way to trade Cool We do have Q&A ready. Oh a friendly face all all week long I Just want to briefly nitpick because you're talking about a one price per block kind of solves all and maybe which it definitely doesn't and And just concretely it doesn't solve which transactions are included in that block, which is a huge deal. And the question of how we guarantee fair transaction inclusion is not solved by having one price per block. And more broadly, the type of MEV that you all have been discussing has not really talked about transaction inclusion as a primary mechanism, which it absolutely is. Yeah, but I think if MEV is solved at the application layer, then it's trade inclusion in the batch, right?

If the solver actually executes your trade or ignores your trade. And there you have application level solutions to it. You can say, here's the order book, and there's a data availability consensus on what was part of the order book. And if the price of Ether is $3,000, and there were limit orders resting in the order book that were willing to sell Ether at $3,100, then they cannot be unmet. And that might make sense what censoring resistance mean in a trading use case, which is very different to what censoring resistance mean in a transfer use case, right?

Like if an Iranian EOA is not allowed to transfer funds to another EOA, that's like a different type of censoring than saying, oh, this user had this limit order and for some reason we didn't include this limit order, although arguably the equilibrium price was satisfying this user order. So I think censorship resistance makes also a difference in the context of the application. And by all means, the batch needs to have fair access to everyone. So we need to have censorship resistance on the batch level. But it doesn't mean that MEV needs to be solved at the protocol level.

Does that make sense? Maybe to add to this question, you see, I think that MEV could be seen very broadly. So if we talk about the use case where one Iranian person cannot transfer to another EOA account, well the privileged minor proposer can actually charge for that. They can say like, oh, anybody would like to censor that person? I accept the bids and I take like to censor that person?

I accept the bids, and I take money to censor that person, which means this is MEV situation as well. And that's why I think that MEV escapes just a simple conversation about the pricing of assets, because there are so many situations that escape it. In those cases, we talk about censorship, and we want to ensure that for this efficient pricing, we always create the opportunity that inclusion, those who want to pay for inclusion will always have ability to out beat those who want to censor. And you have to create the market where, because if you limit that market, then if I want to avoid censorship, then maybe the market will not give me the price. And pricing this in some application-specific protocols is very hard.

It's hard to predict and qualify. But if you create a generalized protocol-level solution that says whatever can be priced actually is defined by this most basic structure, fundamental structure of blockchain, constructing the block and choosing transaction and ensuring that everything is permissionless and that everything is censorship resistance and that the liveness is ensured. And then if those conditions are ensured, then the market will permissionlessly solve those problems and give me the price for how to prevent censorship How to purchase but it won't it won't if you have to send a transaction and the transaction first have to move a pool And then somebody else has to move the pool back then you're leaving money on the table and you're giving up We're giving me v2 into an external party the LP and And the other thing that I think what I dislike about the debate is kind of this, oh, MEV is super complex. We have to like everything is MEV. Like me going on stage here first was MEV or like, you know, this kind of debate.

I think in practice, MEV today, more than 99% of MEV is literally people making swaps. Maybe NFT belongs to it, but trading an asset for another asset. There's sex tax arbitrage, there's liquidation, and there's swap MEV. This, to me, is what we need to tackle. And yes, we can say there's some hypothetical, like we can call this MEV and maybe this, there's other...

It's only until we realize that actually the fact that whether Elon Musk will tweet a particular thing at a particular time defines all those prices, possibly. And it happens to be that all this MEV that we thought is in pricing happens to be around that tweet actually, because that tweet defines whether someone will win election or not and whether the prices of all the crypto assets will move 20% up or 10% down. Sure, and then the next block should just have one price for the crypto asset that's affected by this tweet instead of allowing somebody to pay a third party. What if this tweet is on the centralized social media and is included as a transaction and someone wants to back run that tweet and have access to the tweet and I'm as a tweeter, tweet creation, I am the person who tweets, wants to reclaim the value that I created. Yeah, right.

I mean, this is what we're doing. We're over-complexifying the whole supply chain to a point where it seems like, No, we cannot solve this problem But really the fundamental issue is there's multiple like a single asset has multiple prices within the block if that wasn't the case anymore 99.9% of me be today would be reduced and then what I agree with on the base layer We should have priority ordering and we should have censorship resistance. Yes, but I don't think we need to have PBS You know te based block building or other building, or other very fancy solutions for it, we can have a Shutter-Rise beacon chain with priority fee ordering kind of enshrined or into the consensus layer. Validators don't attest to blocks that are not sorted by priority fee.

And to me, the goal of that change would not be to mitigate MEV. This is just to have a simple censorship resistant, credibly neutral base layer. And then we build sensible mechanisms on top of that, that don't expose MEV and create these games that are kind of, you know, played today and necessary because we've just built the entire DeFi system on a broken mechanism. Question. Felix, you mentioned Shudder.

Recently, Gnosis, Nethermind, and Shudder collaborated to launch encrypted mempools on Gnosis chain. This prevents the block builders to know the contents of the transactions when they're ordering the transactions in the block and this can prevent Malicious MEV like front-running and sandwich attacks. It can also prevent real-time censorship What are your thoughts on this approach both for Gnosis chain and for a theory and mainnet? Yeah, I think it's great. I think it's all we need, basically.

I think we should not work on TEE-based block builders, Suave, Enshrined PBS, all of this. We should give it to some researchers and not continue actually engineering efforts on it. And all we need is priority fee ordering and censorship resistance. I think Shutterize beacon chain is a very good way of achieving this. I am somewhat inclined by multiple proposers as well, but I think, honestly, Shutterize Beacon Chain is the most straightforward and simple approach.

But to me, this is not solving MEV at the protocol layer. This is having a credibly neutral censorship-resistant protocol layer and then solve MEV at the application layer. Because the problem still remains that if somebody then makes a large trade against the Uniswap pool, nobody can see it because it's encrypted, then the back running opportunity is still created and then in the next block there will be some arbitrage or some opportunity to back run this and there will be some games to be played at the next block. So the problem again here is we need the trading use case case and 99.9% of MEV today is trade MEV.

That needs to be solved at the application layer by having on the application layer a credible neutral auction which ensures that there is one price per asset per block. Well I agree with the concept that it's very important to deliver the encrypted mempool just on the way to solutions that will be more advanced. So encrypted mempool with programmable privacy, with programmable condition, a programmable market within the encrypted environment can resolve and surge prices and payout. So you want to create an entire market that is operating within this protected environment. And I agree that simply if you just do encrypted mempool and blindly reorder transaction, that you have something that still lands with the privileged player in the next block.

And then they have the privileged position of being the ones to be able to choose which transactions are go first in that block. So you decrypt the block, all the transactions, you see what happened in the market, and now you have a privileged position player that says, all right, let me first send transactions, one, two, three transactions, and will not be blind for me anymore because I know really what their content is. Place them in the first positions and then execute everything else. So you don't solve it, but the encrypted mempool is the step on the protocol level to solve in the future MEV because we'll progress with the abilities within the cryptography context, the cryptography solutions on how much we can execute within this protected environment. And for now, the stepping stone is DE and say, okay, we don't have cryptography that is efficient enough that we can process within the block time, so we use the hardware solution.

And we have all the concepts of feeling, not trusting the producers of the hardware, hardware not being vulnerable to attacks. So we say, so maybe one path is the OpenT, it's like the hardware that we can actually all trustlessly execute. But on the other side, we also progress with the cryptographical solutions and say, how do we combine FHC, ZK, MPC solutions? And if you don't make the first step with the encrypted mempool of the Shutter-REST protocols, you don't make the next step. Because it helps researchers to look at the behavior of that market.

Thank you. Thank you both. Closing remarks. So we'll start with Tomas, because we started with you last. disagree very often just because they think about different time frames or maybe definitions so you see like icmev in a very broad context and i say there will always be this concept of multiple markets connected and you can only address it on the protocol level and i think that some of the solutions will be coming after pretty long time so after three five six years or even longer because they require massive progress on the cryptography side, on the protocol design.

And within all of this time, you have a big subset of MEV, as you mentioned, like maybe even 80% of the value. That is actually easy to simplify and say there is the value that we can address with the protocol. And for these few years, it will be one of the most efficient solutions. So it has a value for a long time to address it on application layer at least, for the protocols that are outside of blockchain protocol, on the way to protocol. What I say is that to address it entirely and to address it over time, the only solution will be to look at it on the protocol level, deliver something that is available for everyone.

And in the end, this will be the way to think about it. Felix? In my mind, MEV is a very, again, application-specific problem. I think it's very clear where most of the practical MEV is coming from today. What I would like to see for the protocol layer is censorship resistance and priority fee ordering Which to me is not an MEV mitigation technique to me.

It's just a basic feature of a credible neutral base layer and then I think the actual efficiency gains for routing for trade execution for connecting different venues those should all happen in the trading protocol that sits on top of the base layer, which is to the base layer at least an application and They're very specifically to all the or 99.9% of the MEV sources. We know today. We have a pretty good Application layer solution with cow swap or cow protocol We will maybe over the course of time learn new sources of mev where we might have to design different auction mechanisms Maybe for some types of trade a Dutch auction is actually better than just a kind of max bid second price auction and But I think it's really up to the domains and the applications to think about what me V do I Create and how can I mitigate and prevent this and it will be very very much dependent on on each and every Application and just with Dex trades. We haven't done this and we've built an amazing, you know primitive with a MMS But which are also creating a huge amount of value and but they are just you know primitive with AMMs but which are also creating a huge amount of value and but they are just you know also creating this tax that we're now having to deal with and that are with the solution that's being proposed putting complexity putting a lot of strain on the base layer and it's not even clear that any solution we'll find on protocol level will have a long-term adoption just because with TEs we also have latency issues.

MEV is a highly latency optimized game. So any builder that doesn't have to use a TE and gets a hundred millisecond edge over incorporating the latest finance price might have an advantage. So making sure that actually whatever complex protocol level solution we implement gets adoption and just doesn't unnecessarily make the protocol more complex is something that is not at all a given to me. And that's why I think really the clear solution is mitigate MEV at the application layer, make the base layer credible neutral, censorship resistant, and priority-free audit. Thank you.

Thank you, thank you. And it's your turn. Now is our opportunity to vote once again. We'll bring it up on the screen here. Be it resolved, MEV should be handled at the protocol rather than the app level.

I thought everyone's abstaining now. Is everyone abstaining? No, no, it was just the first person. Should the vote revelation be just one revelation per vote, or should we see the... So we started off with 16 people voting in the agree category 6 and the disagree category and 10 and the abstain category anyone else want to vote on this final debate a few more and it looks like we had a very persuasive debate because the majority of the crowd voted for disagree.

24 disagreeing and 16 agreeing and 3 abstaining. Everyone, please give a round of applause for our speakers. Thank you so much. Thanks. And thank you so much for attending.

This was the inaugural DevConflict, so please look out for additional DevConflict side events at another conference, maybe in Berlin, I'm sure. I think this was a great temp check on the Ethereum ecosystem. Ethereum is multidimdimensional, and I think all the debates that we hosted over the last two days were a clear reflection of how vibrant the Ethereum ecosystem is. We'll see you all this week at DevCon. Thank you so much for coming.

We'll see you later. Ciao.