Solana’s MEV Problem | Eugene Chen, Lucas Bruder

Transcript

All right, everyone. Welcome back to another episode of Bell Curve. Before we jump in, quick disclaimer, the views expressed by my co-host today are their personal views and they do not represent the views of any organization with which the co-hosts are associated with. Uh nothing in the episode is construed or relied upon as financial, technical, tax, legal, or other advice. You know the deal. Now, let's jump into the episode. Hey everyone. Before we get into it today, just want to give a quick shout-out to this season's sponsor, Rook. Close to a billion dollars worth of MEV has been taken out of users' pockets, and that's just on Ethereum, and that number is only getting larger, unfortunately. Rook thinks that it's time for a change, and they've built a

solution which is going to automatically redirect that MEV back to where it belongs, into your, the users', pockets. So, you're going to be hearing all about them later in the show. I'm a huge fan of this team and what they're building, so stay tuned to find out more. Right now, MEV is costing these AMM liquidity providers hundreds of millions of dollars per year. Regular traders are paying tens of millions of dollars per year. And this is just like so fundamentally unsustainable. Just like cannot be the backbone of the future of finance. But, no one wants to talk about it because the profits are all redistributed to ETH holders. Welcome back to another fun episode here. We're going to be talking about MEV on Solana.

You want to give a quick intro for who we've got on here and and why we've invited them? Yeah, so uh we have two outstanding guests. I I've been looking forward to this episode on Solana because MEV on Solana works quite different from MEV on Ethereum, at least today, and I think we'll tease out why that is, uh but also how how it's going to develop and whether the two are actually going to converge. I think another big topic definitely is going to be the role of latency. So, Solana is a chain that, you know, puts low latency everywhere. Like, having like a low latency chain that is the thing why like the reason why Solana that created. And I think that's why we get into some of the nitty-gritty and what are some of the ideological debate

about how late how low latency does your chain need to be in order to be useful. Uh but also what might some of the effects be on the chain. And so we brought on Eugene Chen. So he's a zero x c trader on Twitter and he's like a long long time contributor and lurker in the flash bots MEV forums and like on all topics MEV. He's he's building a central limit order book exchange on Solana so he knows exactly the experience of what that's like. And then we have Lucas Bruder. Uh and he is I think the founder of Jito Labs. So Jito is kind of the they are trying to build the quote unquote flash bots of Solana in the sense that yeah they they want to they want to basically

do an MEV option in Solana and I think in diving it deeper into this episode we'll see exactly what the challenges are with that and how that differs from flash bots on Ethereum. Yeah. All right, let's get right into it. All right everyone, welcome back to another episode of Bell Curve. Today Hasu and I are joined by Eugene Chen of Elipses Labs and Lucas Bruder of Jito. Guys, welcome. Hey, thanks for having me. me. Welcome to the show guys. Yeah, absolutely. Um All right, so we are we're super excited here because you know Hasu and I have spent most of this season focused on MEV from the perspective of Ethereum and some of the activity there. Obviously you two are very focused on the Solana ecosystem so very excited to pick your

brain about some of the differences about how MEV works on Solana. So maybe using that as a jumping off point either Lucas or Eugene, whoever wants to take this first, what are at a high level some of the big differences between how MEV works on Solana versus if you were an expert on MEV in Ethereum, what are the most important differences to understand? You know Hasu has this like famous slide of like the transaction supply chain. I think it's kind of worth diving into that on Solana cuz I think it kind of gives you a good high-level understanding of how a transaction flows through the system and like why things are the way they are. So, you know, if you look at Ethereum to start out with, you know, the the user signs the

transaction in their wallet, the wallet sends it to the mempool. You know, you have validators and searchers looking to capture MEV. Maybe there's MEV, maybe there isn't. You have a lot of builders that are kind of suggesting these blocks to build and proposers takes the highest one basically and confirms it. So um on Solana, it's very similar for the first half. So, you know, you go to like Jupiter aggregator or some other application on Solana.

So, you want to buy some Solana token. You sign in your wallet. The wallet will send the transaction to the current and next few block producers. So, I think there's a there's a big difference here compared to Ethereum where Ethereum has a mempool. Solana doesn't have a mempool. So, essentially what's going on is leaders changing every 1.6 seconds. They have four consecutive slots in a row. And so, when you send the transaction to the RPC server, it's figuring out looking at the current slot time, you know, figuring out who the current leader is and then the next few leaders and it will send the transaction to each

one of those leaders. And then it goes into this like kind of black box that executes the transaction and the transaction will um basically execute as fast as possible and streamed out as fast as possible as well. So, that's kind of another major difference compared to Ethereum. Ethereum has like discrete time windows where the state will change and I think that's every like 11 or 12 seconds. On um, Solana the state is constantly changing. So, the Solana is constantly executing.

It'll receive the transactions and start to execute them as soon as possible. And it will basically send out those uh, they're called shreds. They're essentially mini blocks and all the other RPC servers are playing replaying those shreds live. Um, so you know, after that it will uh, get confirmed. So, yeah, that definitely I guess that's good that's a good high level of like Solana to Ethereum. Um, what ends up happening on Solana is that um, you know, there are people that uh, because the state's always changing you're trying to ingest that state as fast as possible.

So, what ends up happening is that people will try to get in kind of like high staked regions like, you know, Amsterdam, Frankfurt, Tokyo. There's a few others. Um, people are on like modified RPC algorithms to replay things faster. And uh, you just see a lot of spam as well where people are they're kind of like reacting to what's happening because there's no mempool you can't really atomically bundle things. Um, so they're kind of reacting as fast as possible. Yeah, Lucas, thank you. That was a that was a really helpful overview. I don't know Eugene if you have anything to add before we move forward here.

Yeah, I think those are the main structural differences between Solana and Ethereum uh, as far as things that might affect the MEV supply chain. I think the competitive landscape is also quite interesting to look at where MEV searching on Ethereum appears to be very very competitive, relatively efficient. Uh, which is quite different from Solana, where today it's still quite primitive. I think there's a couple aspects here. One is that validators are mostly benevolent in practice, uh which is kind of a luxury, but not something that we can depend on forever.

And searching is also quite uncompetitive. Although as Lucas mentioned, uh it does impose negative externalities on the chain, like filling block space with failed transactions. I think in many ways MEV on Solana is today is quite similar to what it looked like on Ethereum in 2019 or early 2020, pre-flashbots, when MEV was just starting to become a problem. Uh but on the infrastructure and research side, I think we have a huge advantage because Ethereum has already gone through this. So, there's a ton of fundamental MEV research that's already been done, and we have a much better sense of the problem space than Ethereum did in 2019.

So, uh I would like to dig into something that that you said, Lucas. So, you said that Solana doesn't have a mempool, which is something I I didn't know, and I I find quite interesting. So, I want to explore a little bit more what it means in practice. So, in Ethereum, we have this problem where transactions they leak, quote unquote, to the public mempool, and then searchers can pick them up, and they can uh front run them, right? Um they can submit them as bundles to block builders. Um so, it kind of sounds like that's currently not a thing in Solana.

Uh correct me if I'm wrong, but it I mean, it like at the same time, there are a bunch of parties, even though it's not publicly gossiped to, who can presumably see the transaction, which may include the uh the application, the wallet, the RPC, uh the current validator, and all of the future validators would get also gossiped to, right? Is Is that also what you meant, uh Eugene, when you said that validators are today mostly benevolent in the sense that even though they could front-run transactions, they do not?

Uh to answer that specific question, I believe that to be the case. At least I haven't seen any evidence of it, although Lucas has probably looked into the into the data a little bit more. I think front-running is also just less of an issue on Solana than Ethereum almost fundamentally because the DeFi protocol design looks a little bit different. So, we see much less of things like placing an order on an AMM with 95% slippage tolerance that exposes you to sandwiching and front-running. I think in practice, just the back-running is going to be much more profitable, and it's also less toxic to the user.

Yeah, to uh I should elaborate on that. We haven't seen any issues or any like front-running pop up yet, but it is something that we are looking into. I think um as there's more like uh DeFi happening on Solana, and you just have more composability, and it becomes more attractive and profitable to do these things, I think it is uh probably going to happen. Um I think um it There's a good chance it it would have happened sooner if the validator was a little simpler. Um I think the the engineering curve for like modifying the validator to do these things is like

very complex. Um so, if if the system was simpler, we might have seen it sooner. So, if I'm a searcher today, and so, let's ignore the notion that front-running is maybe not as attractive uh due to the application layer design, uh but if I wanted to front-run users as a searcher, then what would be the best way to do it? Would be Would it be to run a lot of validators or to partner with a a of validators so they can gossip me the transactions? Um so the best way today would be to run a validator yourself.

Um and there's no there's not really any like gossiping between validators um when with the mem or with the like this pseudo mem pool that Solana has, it's uh so like basically if when you are a validator, you have uh kind of exclusive access to this track those transactions. Yeah. Yeah, oh yeah. I meant in the sense that I I send it to my searcher basically. So not not gossip publicly, yeah. Yeah. Interesting. Okay, but then shouldn't I since you said before that the transaction is only sent to let's say the N next validators, so I would have to run a lot of validators basically in order to get a high coverage of the transactions that go

through the network? Um so so yeah, I guess you could potentially see them if you're the next validator and potentially respond fast enough to uh make it back to the current leader. But um I think it would it would be more than running a lot of validators, it would be having a lot of stake weight. Uh because the leader's schedule is determined by stake weight. And you would still need to collude with the current leader because just because you see the pending transaction doesn't mean you can land in front of them. Right um unless they have something like Jito, right? Which I assume we would get into. So that right now that doesn't basically exist a channel for

like a front running market. Yeah, there's there is like some mechanism for priority fees for ordering, but it's not perfect. Um It's uh a decent heuristic right now, but um that's kind of a whole 'nother can of worms that we can get into later um on why that's not perfect. Cuz it's uh pretty in the weeds. Maybe we could I I would love to know maybe maybe Lucas is a starting point it could kind of tease up for you, but you know, Jito is one of the few projects on Solana at least that I'm aware of that's dedicated to solving the problem of MEV.

And you know, some of the I think it might be nice to sort of level set with listeners on just the sort of market size for MEV on Solana today versus Ethereum and also the sort of relative of adoption of Jito versus something like MEV boost on Ethereum. So, you know, I think when we were talking before this episode, you know, you you shared some statistics with me about sort of the relative size of MEV that gets extracted on Solana versus Ethereum. Maybe there were some I know Jito has put together some statistics on the amount of sort of spam arbitrage transactions that happen on Solana that, you know, don't even don't end up being cancelled.

And then I I would love for you to talk just a little bit about what Jito does and you know, how it's been kind of getting adopted by some of the validators on Solana. So yeah, starting towards the beginning, you know, I kind of fell in love with Solana like mid-2021. Did like the hackathon and before that was working on like a MEV bot on Ethereum. So, just kind of fell down this rabbit hole after reading the Dark Forest article by Dan Robinson and just thought it was like the most interesting thing. But skipping ahead to after a Solana hackathon, kind of had this theory about Solana that, you know, we saw Polygon and BSC having these like

huge spam issues. And then Ethereum definitely had an issue itself. And with just like priority gas auctions and people cancelling and making the gas super high for people and normal users. Kind of had a theory that that would happen to Solana. So started Jito. Basically, we're trying to minimize the spam and return value to users on Solana. So um Yeah, I guess like the current state of MEV on Solana, it's uh We did uh uh ran algorithm to like detect arbitrages and

uh compute the compute units, which are similar to like gas on Ethereum, and found that um 60% of all compute was spent on arbitrages. And there is a 98% failure rate. So uh you know, 98% of arbitrage transactions are failing on Solana. And um you know, because it's so cheap, they're not really bailing out early like they would on Ethereum. Uh they're just kind of like letting it run to the end and you know, have your balance check and it reverts and you're just spending a lot of CPU and compute units on that. Um And uh so yeah, like 58% of all compute on Solana is just spent failed executing

uh failed transactions. So uh we're basically trying to help solve that. I think there's um the main issue is that, you know, talked a little bit about this earlier, but there's no like discrete time window in Solana where the state not changing. There's not really like it's like a continuous time spectrum for uh landing transactions. And there's not really a good transaction ordering primitive. We kind of talked about this a little bit earlier, but um you know, the the priority fees aren't a perfect mechanism for ordering transactions.

So essentially, what we're trying to do is um you know, minimize spam. Uh we have a bundle primitive very similar to like the flashbots bundle, that lets searchers define these like ordering of transactions that they want to execute. And then, there's this like pseudo, uh, short-lived mempool. Basically, the transactions sit in the mempool for roughly 200 milliseconds today. And that's how long searchers have to kind of bid on these opportunities. So, essentially, we're running like a 200-millisecond auction in the block engine. Block engine's like simulating all these nodes, figuring out who's paying the most.

And, um, the the bundles that pay the most will get forwarded to the validator. Um, so, we're like pretty optimistic that that will address a lot of the issues because, you know, right now you kind of are Best way to like land a transaction is spamming transaction. With bundles, you have uh, very high reliability ordering on how the bundle executes in the validator. This is so fascinating. I have a bunch of follow-up questions. Um, let's go.

So, in one of the previous episodes, we talked with, uh, Robert Miller and John Charbonneau. We talked about MEV in the modular stack, and we discussed different approaches to sequencing and MEV supply chain design. And, um, the guys, they basically hypothesized that different ordering mechanisms predictably lead to like lead to predictable results. And, um, so, they said when you have a when you have a chain, uh, um, that is that doesn't have an MEV auction, that that kind of is low latency, and it has, uh, it has high fees, then it leads to a latency latency auction, basically similar to to TradFi HFT, co-location

games, microwave tower networks, and so on. And if you have, um, the same but with low fees, then it leads to spam, and it leads to on-chain searching, and leads to a lot of failed transactions. So, um, correct me if I'm wrong, it sounds like you can exactly confirm that hypothesis at least from the perspective of Solana. Yeah, definitely. There's a lot of failed transactions and spam on Solana. It's like a hundredth of a penny to send a trade not including priority fees if you attach those. So, it's super cheap to do it.

Yeah, so it's really interesting then kind of to dive into how you are approaching the problem of designing an MEV auction with with Jito because it like So, one of the major innovations in Ethereum was the idea of the bundle, right? Where you can kind of it's kind of an array of transactions that have to be included in the exact same order that they are submitted. But it seems like that's actually a relatively minor part of what you do at Jito because if you only introduce bundles, it would actually change nothing about the failed transactions because the dominant strategy would still be spam.

And so, what you're doing it sounds like to me what you're doing instead is you're actually slowing down time. You're turning it from like continuous time into discrete time. So, there's actually now waiting period for transactions to accumulate and then you run a simulation and you filter out the one best transaction and you discard all of the rest. So, would you say that is actually like your main approach to MEV in Solana? Uh pretty close. I think like they're the the delay that's running is kind of like a rolling 200 millisecond delay.

And we kind of discretize that to like a 200 millisecond window. And um you know, it's censorship resistant because of the way that we designed it. Packets of essentially flow through a relayer that any validator can run and that relayer is kind of the like custody or whatever you want to call it for that that transaction. Um So, the block engine can't actually We call it block engine, essentially like a submits a lot of bundles to validators. It can't actually censor anything.

And so, uh we're not actually dropping transactions at the relayer or the block engine level. We're really only dropping the bundles that searchers are submitting. Um so, I think it's It's kind of an important thing to note is that uh we're not just dropping everything randomly that's failing. It's more of just what the searchers are sending. Oh, so they have now basically two channels to send transactions, just like the main channel where you do not drop any failed transactions, and there's the searcher channel where you do drop them. And Yeah and you think it's preferable for searchers to tend send through the searcher channel because they don't want to pay for failed execution.

Um I don't think it's necessarily about the failed execution. I think it's just the guarantee and ordering. So, um you know, the bundle offers Basically, it's like an all or nothing commit sequence, similar to Flashbots. So, we modify the validator so that it knows how to process a bundle uh in this like multi-threaded context, and um it will execute atomically, which is um a very strong selling point for searchers that are kind of just spamming and uh crossing their fingers that it that will land.

But I thought you said earlier that um I mean, front so this kind of at atomicity feature you mainly need it for front running. Or for back running when you actually have the transaction hash. Um but it sounds like you do not really have either of those two, and so you're basically back running a lot. And you're kind of doing it because you saw that the state updated on some order book exchange right? Uh so I'm I'm still struggling to understand like why exactly the feature of the bundle is useful. Is it because the bundle is is kind of prioritized over other transactions?

Yeah. discrete time window? Yeah, so the bundle's prioritized. It has a special transaction like pipeline that it goes through that's much much less congested than the normal pipeline. So you get the stronger ordering guarantees and then you also kind of um get to like skip skip the buffer so that it basically executes um as fast as possible after the auction's over. Aha, okay, okay, okay. So I think that that makes a lot of sense to me that basically the the bundle skips the queue and it's it's So there's no concept of a block, right? Would you say you you you almost create the concept of like a pseudo block here by slowing down time?

Um kind of, yeah. I mean um I guess I guess you could somewhat put it like that depending on where you're going with it. Yeah, so because I'm trying I'm approaching it from the perspective of like if I'm a searcher, can I break this mechanism, right? Like is it for me is it actually like optimal to use the Jito auction? Uh or should I still are there conditions where I may still want to go through the public mempool and still want to spam? Because this is very cheap for me, right? And if if I go with that then I might prefer this. So how do you ensure that basically even if there's someone who's really good at spamming that's still better for them to go through the auction?

Yeah, I mean I think the main thing is that you offer the better ordering guarantee and the chance to skip the pipeline. Um I think we'll probably see something similar to flashbots where like if someone has alpha, they'll probably just go through the normal channel until it gets kind of like contested and starts to turn into uh this like fee war and then people start to extract things more efficiently using bundles. Yeah. I have a question about that, Lucas. Can you Can you walk us through what it's been like on a BD perspective of getting adoption of Jito? And maybe if we could and uh if I could pull you

and Hasu a little bit as well to just talk about cuz it there is a a stark contrast, I think, in between what Flashbots has been able to do on Ethereum versus Jito on Solana. And I do wonder a little bit if that is you know, if one of the big starting differences there is that Ethereum used to be proof of work at some point but whereas Solana never was and some of the BD work in the beginning for Flashbots uh Flashbots was kind of getting its start when there were these dominant mining pool operators and there were really only five or six entities that you needed to get widespread adoption of MEV-Geth or MEV-Boosts. Um I guess MEV, yeah. But uh Lucas, talk a little bit about, you know, what that's been like

on Solana. Maybe you could compare and contrast. Yeah. Um yeah, it's been pretty challenging from like a chicken and egg standpoint. So um you know, it's like searchers I guess validators like want to run the software. You know, the the main pitch is like this is healthier for the network. Um you know, like more efficient MEV markets will lead to more liquidity which means leads to more usage and you know, we want to see the net the network uh healthier and have less negative impact on users.

Um but at the end of the day, a validator's in the business of making money. So, it's kind of like how much money will I make? Well, it's like um it's pretty small right now because we have searchers that are waiting for more stake to run the client. So, it's kind of this like, you know, go to searchers, say, "Hey, we have bundles. Here's how you use them." Uh and they're like, "Okay, we need more stake." Go to the validators. They're like, "Oh, we need more money." So, it's like been pretty hard to kind of get out of that chicken and egg. Um I think like, you know, people talk about like doing things that don't scale in the beginning. We've definitely been doing a lot of that.

Like, a lot of hand-holding validators and uh spending a lot of time talking to them, making sure they understand what we're They making sure they understand what we're building and that we understand kind of what they want. And um I feel like, knock on wood, we're like starting to get out of that. So, we're seeing uh a lot of bundles landing today, a lot of tips. Uh this tips are still pretty low. Um but, you know, we're seeing a lot of bundles uh land and we're currently at like 24% of Solana stake running the client. And there's 115 validators running the client. That's anyone from like super small validators to like a

uh P2P or um like a staking facilities. So, uh definitely a wide range. I haven't actually as far as like the differences between flashbots at the beginning, definitely curious to hear what Hasu says. I think um my current take on it is that when proof of work was out, there was just a lot of concentration in mining pools. So, you could go to a mining pool and, you know, get anywhere from like 5 to 40% of hash power. Um obviously, there's a lot of BD and like hand-holding and things there, but, you

know, once that 40% flips on, that's like huge. I also think that the um MEV was probably a little more developed on Ethereum than it was on Solana at the time. And then I think um you know, as we saw the transition from proof of work to proof of stake, I think the flashbots uh like block-building model was somewhat de-risked. And people saw the money that they could make by running the software, and then also the improvements that uh they brought to Ethereum as far as like uh less wasted block space. So, I think it was somewhat de-risked from that standpoint. Um I think another the hard thing that's on Solana is like, you

know, there's been a lot of reliability issues on Solana, the network going down. So, you know, it's like we have this client that we've modified, and there are certainly people that are maybe skeptical to run that. Um because it is uh it's a hard uh client to work on and a hard kind of network to to work on. Yeah. So, I when you when you thought uh when you said that uh you have 24% of stake uh adopted, I I I thought you would say more like 2% because you have previously said it's like it's been very hard. But, I mean, 20 24% is a really impressive, right? Um so, because like the the first 20% is like super hard, and then the next 80%

is probably like going to be very easy for you guys. So, um I don't I don't know that you need any that you need any tips anymore. Um but I I can I can still go into it a little bit. So, I think um you're totally right in the MEV landscape on Ethereum was already like quite more developed when we started. It was like very rampant, like much more rampant kind of MEV extraction already happening in the public mempool for for 2 years, basically. And um it was uh like deals and things going on, too.

Uh not so much. So, I think Flashbots was was the company was started or it was started as kind of a collective in response to uh, to kind of vertical integration that was like just starting out to happen. Um, so with that came the realization we need like a public auction platform that anybody can use and that's actually the most optimal to use because that leads to the best market structure for Ethereum. Uh, now it was more so happening through priority gas auctions. So you could point to um, Phil Daian's paper. You could like Flashbots also started like very importantly with this kind of data product um, that just like illuminated how much MEV there actually

was uh, and in a sense almost advertised the idea of like MEV extraction to to searchers as well as uh, as mining pools at the same time because you could actually point to these numbers and say guys, this is like how much money is extracted right now. Like this could be your money, right? Um, and so I think that like data was a very important part of the adoption strategy. I think I was I think uh, Flashbots I wasn't around at the time but I think the adoption strategy was very smart in in terms of the order with which um, kind of the mining like we approached the the different mining pools.

Um, because it's like dominoes falling one after another. That's like how I like to think about it. Um, and so the the order in which you start has a big impact on how fast you can get them to fall. And um, what also resonated with me was when you said you find it very hard to get searcher adoption when there's not a lot of stake. So I think um, one of important ideas is definitely dog fooding the product. Um, and so you you need some way to bootstrap either side of the market in any kind of two-sided marketplace. And since it's very hard to bootstrap the validator side of the market, I think you need to bootstrap somehow the searcher side of the market. You need to make it very easy for people to enter this. And so, what what Flashbots did was it wrote a lot of open like uh

searcher bots, very very crude simple bots that had no chance at all in the public mempool. But, because the auction format was so the risk from the searcher perspective and so easy to use and you like if you paid more you always got priority, then even for some time like the most crude searcher bots had a chance to compete. Um and so they just open-sourced them and basically gave them to people for free to use uh and run. And so, I mean that way they kind of um yeah, basically got the initial traction in the auction. And so, yeah, it feels to me like um all of these strategies would also work uh most likely uh in Solana. And so, assuming there's like stuff like um flash loans and so on, but um

that should be, right? Yeah, okay. So, and you have the bundle, so you have the atomicity guarantee. So, really using the auction is risk-free, right? So, as long as you provide kind of mock searcher bots, then uh I think it should find a lot of interest. Hey guys, quick break from the show here. I want you to imagine something for me. Imagine swapping two stablecoins on chain, paying $0 in gas, and instead getting a rebate of $2,000. This is something that's actually happened on chain. To understand how, I want to introduce and thank this season's sponsor Rook.

Zooming out for a second, the current state of affairs in MEV is billions of dollars so far have been extracted from users' pockets using MEV. Rook is coming in and saying enough is enough. Blockchain should drive value to their users and the applications they use. It is time to leave the hobbyist era behind us if we want to move forward and we want to get this right. That's why Rook has built a custom blockchain settlement network, and it's one that gives you full control over the entire transaction lifecycle. Today, you can connect to an open-source Rook node. The Rook protocol will automatically match, bundle, and auction your orders and transactions in seconds with zero gas overhead. Also, any MEV that's discoverable along the way will be returned to you, the user. Created as a collaboration between the industry's top

mechanism designers and MEV engineers, Rook was built from the ground up to be scalable, safe, and programmable. You can get your own mempool, choose searchers and builders, and link your mempool with others to discover even more MEV. You can define how the MEV is shared and delivered as well. And Rook can basically process anything from transactions to meta-transactions and more. This is the way that blockchains basically should have been from day one. So, if you're a user listening to this, here's what I want you to do. I want you to go to your wallets, go to your favorite app, your node provider, and say, "Hey, I want you to be working with these guys, Rook. I want the MEV that I create to be redistributed back to me."

If you're a developer and you want to stay ahead of the game, best way to do that is to follow them on Twitter. They are @Rook. Or even better yet, slide into their DMs. They are lightning responsive. They'll get you set up today. And if you do slide into those DMs, as always, please tell them that I sent you. Is Is one other something else that sort of um actually entered my You made me remember Hasu when you were just talking there is initially in in the last season of of Bell Curve, we had uh Xavier from Chorus One actually he he observed something I thought was pretty interesting, which was he said the dynamic of who extracts value in the MEV supply chain is flipped from Ethereum to Solana. Whereas in Ethereum, you have an auction mechanism where the

vast majority of MEV ends up going to the validator because you can bid up an arbitrage opportunity. So, theoretically, if there's a dollar of arbitrage, you know, a searcher might bid up to 99 cents, right? Uh and so, the vast majority goes to the validator. What what he mentioned is that it's actually flipped in in Solana because there's no auction mechanism. The searcher, even though the overall market size for searching is much smaller, the majority of the value goes to searchers instead of the validators. So, I'm wondering A, is that dynamic correct? And then B, is that part of the reason why it's a little bit tougher to you know, make a you know, to get some of these validators to sign on because in Ethereum there's a clear profit incentive, whereas in Solana from the

validator perspective maybe a little bit less. Um yeah, I mean I think that uh I imagine that Flashbots had the same issue like pre-Flashbots or I guess you the Ethereum had the same issue pre-Flashbots where people where where searchers were like capturing most of the value and as more people compete in the auction, it kind of flips it. Yeah, I mean we're seeing like roughly like anywhere from like $4,000 to like $30,000 of arbitrage every day. And the Jito MEV system is not making anywhere close to that right now.

Um so, I think it's still um still kind of in its like infancy as far as like searching searching goes. Um So yeah. what I meant though. You should expect to see more of the value go to the validator as the auction becomes more efficient. Got it. Yeah, definitely. And yeah, we've also like the the systems that we built will uh basically have the built-in mechanism to distribute the MEV to stakers as well. Um just because the staking is a little different than Ethereum. Um where people can, you know, val a validator may have like 100 or 1,000 stakers on it. Um there's also the the mechanism to distribute MEV to the

stakers in a transparent way. Hm. So, I think most of it or a good chunk of it will go to validators and their stakers. And we're seeing anywhere from like a uh 5% fee to 100% fee on the validator side. So, some validators want to share more and some don't want to share at all. What would you say are kind of the problems with the MEV design in Solana today and how is that connected to um the spam but also maybe some of the outages? So, because we haven't touched on that yet. So, Solana notably had a bunch of outages last year. Were any of those connected to MEV in any way and yeah, what what do you see as kind of the big problems um uh in kind of the chain design as it

relates to MEV? Yeah, I think some of the very very early outages like maybe like mid to end of 2021 were related to MEV. So, there was one where um you know I talked about this earlier but uh when the RPC sends a transaction, it'll send it to the current leader and then the next few leaders and then it's also supposed to forward if the validator doesn't execute, it should forward it one hop and then drop it. Well, there was a forwarder bug where it just kept forwarding, forwarding, forwarding and there's like an IDO. So, you have all these bots that are trying to get into this IDO early. They were spamming it. There's this forward issue um and maybe not, you know, it was kind of uh

went I would say it's related, that was related to MEV just because people were trying to get into the IDO as fast as possible. Um I think that like you know, the the outages I think are a lot of outages are related to kind of just pushing software to its limits. Uh I was actually talking to someone about this last night but I think like uh kind of a kind of a interesting comparison but you know, Ethereum I I could see uh it's kind of like a maybe like a Honda Civic or like a Toyota where you know the person that's driving that isn't really going to be like pushing it to the limits. They're not going to be like revving the engine a lot and um

you know, going like 200 miles an hour. I I Solana's kind of like a dragster, where like everything needs to be working in like perfect unison and, you know, the pistons and the like cylinders and the drivetrain are like being pushed to the limits very frequently. And so that like if there's like any problems in any piece of it, then the whole thing kind of just explodes. Um So Yeah, I think that like obvious Solana's obviously a high-performance chain and it's being pushed to the limits a lot and I think that a lot of bugs are just like finding where those like cracks are in like the drivetrain and things like that and uh fixing it.

I'm sure uh Eugene has a lot of thoughts around this, too. Yeah, I think just the complexity, uh like the literal code complexity in the native Solana client just produce uh creates a much larger surface area for these types of bugs to exist. And then I think there is much more of an engineering mindset coming from Solana developers as opposed to uh a more like research first principles guaranteed safety that we see more of from the Ethereum side. So I don't think it's too surprising that you see more outages on Solana.

Uh I think the common theme though between all these outages, I think it's been like five or six, which, you know, over the last couple years, which is obviously too many. It doesn't seem like there's some core issue with the way consensus is done. A lot of them really do seem like like an implementation detail here or there. And that definitely points to potential issues with the development process, but not necessarily to the core mechanism itself. I'd be curious, you know, a lot of the a lot of the difference for the way that MEV works in Solana versus Ethereum stems from the way that I guess the the way that fees are handled in Ethereum versus Solana. So I really do love and I I think, you know, with hindsight, the

the way that fees work and the fee market that Ethereum has created is pretty elegant. And not to say that Solana's isn't, but definitely, you know, having a fixed fee, um and I know that things are changing a little bit with the the introduction of the priority fee, has created for some certainly some negative externalities in in Solana. I I'd be very curious um from the two of you and Eugene, we were just talking about this, so maybe I'll I'll turn it over to you first here. Do you see Do you see the way that fees work on Solana changing or evolving over time? Do you think it ends up being more like Ethereum with the creation of fee markets?

Yeah, I think it kind of has to move in that direction. The fundamental reason you need fees besides uh the network capturing a little bit more of the value it creates is you need to price these limited resources appropriately. That's just the most economically uh efficient way to allocate the block space. And so, originally with Solana, there was just this base fee, which essentially is paid per transaction. There's some nuance there, but it's not too important. And that's on the order of 1/100 of a penny per transaction.

And this is, you know, basically zero and it's basically fine when blocks are not getting filled up. Once blocks starting getting filled up, you need to and a lot of that is these failed arbitrage and failed competitions that Lucas has pointed out. Uh then you need to have some sort of mechanism for pricing the block space. So, there's currently this implementation of a priority fee. So, every transaction is still going to pay the base fee and then now you can pay some uh priority fee chosen by the user on top of that.

And because block production is continuous, this doesn't guarantee anything about ordering. It doesn't guarantee anything about uh your likelihood of getting included, but it sort of move things in the right direction. There's a lot of nuance in the way the Solana client orders transactions. It's sort of this like multi-threaded transaction scheduler that's trying to execute transactions. And if you submit something with a higher priority fee, you're more likely to sort of jump to the top of the queue in terms of execution and therefore placement in the block.

It's still relatively crude. I think one really nice thing about Solana's programming model where state has to be specified up front. So, if I'm making a DEX trade, part of my transaction actually includes, "Hey, I want to change uh for this transaction, I need to touch Lucas's token account. I need to touch the Phoenix SOL USDC account." And by account, basically mean a discrete piece of state. So, you can actually create state-based fee markets in the same way that you have a that there's like a multi-dimensional EIP 1559 uh proposal from Vitalik where basically

you have a few different types of resources uh and you want to price each of them with a sort of like a 1559-like mechanism. Well, there's limited amount of block space for touching the Phoenix SOL USDC market in a given block. There's obviously this global limit as well. And the resources you need are specified up front. So, I think it's pretty natural to have a very similar multi-dimensional EIP 1559 mechanism to more appropriately price uh different pieces of state.

Because in most blocks, you'll have some some state that's really really hot like a DEX market that people are trying to arb, and that should be a lot more expensive to touch than uh some other random piece of state that only one person cares about in this block. So, when you say, okay, it's the idea I think of a state-based fee market is very interesting, but you you basically still need the ability to slow down time slow down time, right? Uh in order for transactions to accumulate. I don't think this is necessarily the case. I think that's true if you want to very accurately price the state for the current block, but if you make some assumptions about the

shape of demand for block space, you can do something pretty crude where the base fee for a particular piece of state for this current block is based on how utilized it was in previous blocks. Yeah, that's very fair. Yeah, I forgot about that. So, this is less precise, but I think definitely um demand for block space while the demand for MEV transactions tends to be correlated because it happens in periods of high volatility uh predominantly, right? And so, yeah.

Uh You can definitely design a base fee based on historical demand for a particular state. Yeah, it's an imperfect mechanism for sure, but I don't think we can let perfect be the enemy of good. And in this case in particular, when it's something in protocol, like an in-protocol fee, almost by definition, you can't have a market for that that also lives in protocol. So, if you're going to have the market for that, you have to have that off-chain, and there's a lot of trade-offs that come with that as well. Just to just to make sure that I'm understanding this right. I mean, this this is very interesting to me because it sort of hearkens back to I mean, part of the you know, you hear this a lot from the Cosmos, you know, part of the part of the world, and their focus on, you know, app-specific block

space, which is the problem with generalized block space is that sometimes you have competing demands from one sector versus another that impede the performance of you know, our particular application. So, for instance, what you wouldn't want is a DEX going down because NFT mints are exploding or something like that. That just feels unfair from the perspective of a DEX operator. So, these sort of multi-dimensional or or parallel fee markets would theoretically solve some of that where you could have a very high base fee for, for instance, if you know, DeFi is really heating up, right?

As compared to maybe NFTs being slower, that would sort of separate the congestion between those applications. Is that Am I understanding that correctly? Yeah, I think that's fair. Again, this mechanism is imperfect because it relies on past demand as an estimate for current demand. So, if an NFT mint opens up on exactly block number 1 million, uh probably the base fee is going to be way too low for for that block. Mhm.

Uh that might just be an issue with the NFT mint mechanism where whoever is issuing the NFT probably had an opportunity to capture a lot more value. But, I think the I think the main point makes a lot of sense where by appropriately pricing different pieces of state, you are able to modulate demand with a fair bit of precision. I think I think it probably has some other downsides, too, right? So, I I was I asking myself, well, let's say it's like a very congested time like let's say there's a period of high volatility, like can you really design a mechanism that constrains like the usage of the

chain to be no more than like 25% on OpenSea or 25% on Uniswap or whatever. And um yeah, you probably could, but I wonder if that is if that's good, right? If that's kind of good for the users of that chain as well. So, I think it's it's kind of a double-edged sword. But now that we know a little bit more about the architecture of Solana and where kind of the current problems are, now I'm really interested to hear like what's the MEV roadmap looking like for um for Solana. So, Mike mentioned some maybe some version of PBS that that might be on the horizon.

Yeah, I think that I need to go back and read that. I think it was um uh it was it was just kind of like a proposal, so I think there's a lot of like hand-waving in the explicit details. I think that um it's definitely the right direction to go in. I think that um the thing that's going to be difficult is can you introduce PBS without uh slowing down the block times massively and massively reducing the throughput of Solana. Um so, you know, I think Solana is a very fast-moving chain. I think that there should probably be uh like a tiny bit of compromise to look at PBS, but you know, if it changes

things from like 10K TPS to like 1K TPS, that's just going to be like a non-starter. Um cuz it it kind of just ruins the pitch for Solana. Um but I think that there's uh some interesting things. So, we're the Jito's like the only I guess you could call it like a block builder. We're not building full blocks, but we're basically submitting like um sets of bundles to get executed. And um I think that we're definitely learning a lot and want to uh kind of incorporate the lessons that we've learned into what this looks like on Solana in the future. One thing that's like really hard right now is that, you know, talked about the Solana, but um the state on Solana is always

changing within a slot. And so, you know, what ends up happening is if we're trying to uh if someone sent us a bundle for slot 100 and we forward that 200 milliseconds later, uh there's a high likelihood that the state changed. And that makes it really hard. Um you know, we need to be the closer to validators that Jito's block engine is, the better. And um you know, there's a lot of like uh a lot of like crazy stuff that we have to do from like an engineering angle to simulate stuff accurately.

And I think that um you know, something I guess like whenever there's PBS, there needs to be kind of we need to like look at that part of the stack and see if there's a way to do it um to support multiple builders that can like simulate things accurately without slowing down Solana. It might be a little early to ask this question, but have you thought much about kind of the incentives for co-location between Jito uh and different validators and maybe different searchers? Given that kind of the latency of the chain is so low, how do you think this is going to evolve?

Yeah, I mean the the there's definitely incentive there. I think the approach that we're taking right now is like try to set up as many regions as possible so that, you know, it's not just Frankfurt. Um cuz, you know, the it's not like a heavy it's not like a force of gravity right right now, but I think in the future it could be. So, you know, as the uh as a block builder on Solana, we don't want that to happen. You know, we think that the geographic like decentralization is important and we're kind of like doing the best we can to support that by having uh we currently have four locations across four

different countries and we'll continue to set up more. Um but I think that, you know, that is obviously pretty expensive and something that we want to uh change. I think the the we just don't want to compromise on like the speed of Solana to get there. I think geographic centralization is also very path-dependent. So, if you start with a very decentralized set and then you slap a system like this on top of it, I think you're going to have a lot less gravity towards say like everything moving to sit next to Maybe a slight slight pushback on that, Eugene, with that you know, one thing that Hasu and I have talked about a lot this season is the big one of the big factors in terms of like sex to decks arbitrage is where price discovery

happens. So, you know, if price discovery is happening on Binance, you know, I I I feel like that's the more important sort of factor, I guess, than than anything else. I don't know what you have to say about that. Well, I think it's just really, really complicated. Like if I'm a searcher and I'm doing the sex to decks arbitrage on Solana, let's say the validators in Frankfurt, I think price discovery happens on Binance, which I believe is in AWS Tokyo. There's just like so many there's so many pieces that have to go right here. So, I need to get the price from AWS Tokyo into my searcher box, which is presumably running in

Frankfurt. I need to do whatever simulations I need to do to compute the transaction I want to send. I need to send that bundle over to Jito, which in this case is probably also located in Frankfurt. Um it's not obvious that the validator wants to move to Tokyo as well, right? Because every searcher that is in uh every searcher is going to be in Frankfurt co-located with his validator or, you know, in Tokyo co-located with the exchange, but the speed bump there is going to be the same or very similar for all the different participants. So, I think perhaps like at the margin by

having higher uh, latency between the exchange and the validator, you might have like a little bit more uncertainty and therefore like ever so slightly smaller bids, but I think this is just totally dominated by the size of the opportunity. Yeah. So, maybe a last question on kind of Solana uh, base layer infrastructure before we move on to DeFi because I think we're very interested in hearing also the perspective of what it means to build on a chain like Solana. What's like the pros and cons on the experience.

But, I I want to hear kind of what do you think is uh, what do you kind what do you think is kind of the role of Jump of Jump crypto in the Solana ecosystem? Uh, how do they think about the chain? Why are they so interested in it? Um, and also what is their project um, firedancer that that they've been working on for for some time now? Yeah, I think um, Jump is obviously like a pretty big supporter of Solana um, between, you know, Pyth uh, Pythnet which is actually kind of like a I don't even know if this is the right way to say it, but it's kind of like a side chain running the same Solana

validator client just with kind of higher requirements. Um, and their role of like building firedancer, I think, you know, they're some of the the most talented engineers in the space. The stuff that they have been able to demo and like the stuff that they will pull off will just be insane and I think that like a few years from now, I think it will be a reference for other chains on how to build like high-performance systems. Like, you know, chain XYZ is hitting this bottleneck. Let's look at like firedancer and see what they did to uh make this run faster.

Um I guess, you know, to play devil's advocate, there could be, you know, uh they do under- they will understand the validator pretty well. So, it does kind of um you know, there's a potential for them to understand what's going on inside it better than anyone else and extract MEV. But, I think that, you know, it's open source, anyone can read it, and it doesn't It's not necessarily like a a blocker for anyone else to get an even playing field.

Guys, I'd love to start talking about DeFi on Solana and maybe starting from a high level, you know, I feel like DeFi on Solana was, if you remember the clock back a couple of years, sort of the main selling point for the chain and people were extremely excited about it. I definitely remember when Serum launched, how excited people were about the possibility of a central limit order book that was on chain. And since then, I think, to be completely fair, Solana has suffered a pretty major setback in terms of its DeFi, um with sort of green green shoots, right? With uh like Eugene and what you're doing in in Ellipses. So, I'd be curious to just get a sense of what is Solana or DeFi on Solana kind of look

like today from just kind of a landscape and ecosystem. And then, if you could maybe dive into some of the points that uh you know, kind of hostile side of the of the of the argument, which is like, what is it like to build on a chain like Solana in terms of like pros and cons? Sure. So, I can talk about the protocol design space a little bit. I I across all of DeFi, basically over the last 5 years, we've seen very, very little innovation on the protocol design side. Basically, we had Uniswap, Compound, and MakerDAO as these pioneers who really showed the world that decentralized finance is possible.

But, these protocols were built under very heavy constraints of a 10 TPS chain. And pretty much everything we've seen seen in D5 since then has been anchored on these very old V1 protocol designs. And maybe with some Ponzinomics thrown on top. So, the thing that really excites us about Solana is that its high-performance decentralized infrastructure is available today. And so, we can really explore the protocol design space for these financial primitives from first principles. And some of the key differences in uh you know, the performance of Solana versus Ethereum, you know, you have these 400 millisecond block times, so that really reduces the MEV surface. You

have thousands of transactions per second, which allows for actual markets. Uh you have an oracle update every block, so for protocols that depend on an oracle, you might have like much more resilient oracle pricing, much smaller error bars on the prices there. And so, to be a little bit more concrete, I can give a few examples. I think trading uh Mike you mentioned that you can build a limit order book on Solana, and I think this is probably the one main innovation in D5 we've seen on Solana over the last 3 years since Solana's been live.

I think passive liquidity models like AMMs are much better than nothing, and they work really well for these long-tail tokens. But, you really need to have active liquidity for deep sustainable liquidity. And another thing with the AMM model where you have this two-sided of is it actually makes front running possible or front running is just not really that profitable on a limit order book. Uh certainly like a sandwich attack won't exist. Um and with limit order books we can also leverage all the work that's been done in electronic market making for the last few decades where you have all of these high frequency trading firms that have invested tens of billions of dollars into R&D and their entire goal is to

provide the most competitive prices to traders. And so now with limit order books on Solana, we can enable them to provide liquidity the way they want to provide it in decentralized finance. So DeFi traders also get the best prices possible. I think with borrowing and lending like frankly all across DeFi today it's basically stuck in the stone age where every design is still basically a copy of the original compound design. I think there's some pretty clear room for a step function improvements once you relax the infrastructure constraints.

Uh the most clear example here is you can just have a market mechanism to determine the rates rather than approximating a market with this piecewise linear interest rate curve. So I think basically the yeah the the protocol design space is much larger on Solana which gives a lot of room to explore. Uh and there are plenty of teams today that are exploring this design space. I think we're going to see some more products go live really soon. Uh I think like Mango Markets is a great example where they have an order book based decentralized perpetuals exchange.

Um and you know there's a few other teams working on similar things. Uh there there's teams working on different borrow lend implementations that are not just clones of compound and and Ave. On the NFT side, the use cases have also really just opened up where uh compressed NFTs have just shipped. And basically what this means is you can have collections with millions of NFTs or billions of NFTs at pretty reasonable cost. And so a lot of the original NFT vision of, you know, digital items uh that don't necessarily need to be 10,000 PFP collections that are selling for thousands of dollars. You can

actually have some of these more practical use cases like ticketing or items in in gaming. Uh these actually are more realistic now, too. I've got a couple more specific questions for you just on sort of central limit order book design versus AMM. And this was a debate that this has been a long-standing kind of debate in crypto. And certainly a couple years ago you heard a lot more sort of fierce uh debate about these two different structures. But maybe since this is an MEV podcast, I would love to know, you know, I think the this idea of active versus passive liquidity is definitely an important one. So, could you describe, you know, just why is for the passive liquidity construction of an AMM, especially kind of the concentrated liquidity provision in something like Uniswap V3, just throws off the enormous

amount of MEV that it does? And then I do want you to double-click into, you know, you mentioned that in a in an order book design you won't have things like sandwiching. Can you just describe exactly why that is cuz I didn't really follow you there. Yeah, so let's start with the sandwiching example. The reason sandwiching is a thing on AMMs is because of the two-sided liquidity. So, if I provide liquidity within a range, I'm and the price crosses me in one direction, now I'm automatically providing on the other side.

And so what this means is if someone places an order with very very high slippage, what I'm going to do as a sandwicher is I'm going to run up the price so that the trader or victim gets their execution at the very worst price specified and then I'm going to exit the trade by going back through the book the other way. And so in practice what this means is the first I make a very very unprofitable trade where I push the market really really far and then the sandwich victim pushes it a little bit further and then I close out the trade against with this very very profitable back run.

On an order book, you have all these limit orders but they're one-sided. So if you push the price very heavily one way, you don't have this very profitable exit on the other side. Uh with regards to like AMMs versus limit order books in general Let me let me let me ask before you move on to that. Let me ask you why So I from that explanation I didn't get understand why sandwiching wouldn't be possible in the limit order book because most traders don't use limit orders, right? They they they use market orders.

And isn't that kind of similar to how an AMM would work? Like couldn't you front run a market order in essentially limit order book? Uh yeah, but your front run is extremely unprofitable, right? Because you're going to have to take out all these other orders because the limit order book is always going to match the market order against the best price. So yes, one thing you could do is like you know, clear all the liquidity from the book and then if there is this naive market order, you can have them fill at the worst possible price. But your front running trade was really really unprofitable because you had to clear this book.

But isn't that the exact same thing in in AMMs? Like an AMM is also just like a limit order book except the orders are symmetrical and so you also have to clear out the book before you can You do have to clear out the book, which is very unprofitable, but then you have this very very profitable back run, which is running fixing the price after you made this trade. So it's like a pretty fundamental difference here with the two sides. I see. So basically in AMM it's almost like the order book replenishes basically after you made your unprofitable back run. And so, they are they are basically exposing you also very profitable trades on the way back that make up for it.

Exactly. And in a central limit order book, that that is not going to happen probably because like nobody is going to put any orders in like after you cleared out the book. And it certainly can't happen atomically. Yes. Okay. Okay, now I got it. Okay. Thank you. So, going back to like the AMMs versus limit order books in general. So, there's this really important distinction between active liquidity and passive liquidity. Like we're talking about earlier with electronic market making firms, these these guys are like real professionals and their job is to provide the most competitive liquidity possible because they're not providing competitive liquidity they don't get any fills in a limit order book model where if you're not providing the best price,

you're not getting any of the volume. So, there's this incentive to provide better prices to the extent that you can. AMMs and there's there's been a lot of iterations on AMMs of course, but essentially they rely on these liquidity curves which roughly are trying to approximate what a sophisticated market maker will do while having basically none of the information whatsoever. So, like if you have a XYK model for example, like yeah, you have a little bit more of the liquidity near the top of the book and you fade towards the you lower your size towards the back of

the book and yeah, the shape is, you know, roughly correct. Um but you don't have nearly the precision that a professional market maker will have. And then the really really really piece as it relates to MEV is with this DEX sex arbitrage that's exposed by these AMMs where the AMMs actually completely depend on arbitrage to fix the price to set the price to the correct market price.

And so what this means is if some pair is trading on an AMM and the you know the price on the AMM is 100, the price on Binance moves to 105, the AMM can't automatically move its price to 105. It relies on these traders to push the price from 100 to 105. And that is really expensive for the LPs. They're systematically overpaying for the service of getting their prices fixed. Uh and if you have active liquidity then the market maker is just simply going to move their quotes. Maybe they'll get into a race with takers who are going to uh try to pick off their quotes before the market maker can move them. But I think the MEV surface that's exposed is

really a lot smaller which means that the protocol itself is also going to be more sustainable. Zooming in into that kind of race that that exists um so why is it guaranteed or like to to what degree is it guaranteed that uh that the maker is uh is kind of favored in removing their bids in any way over the taker? Um why why does it like expose that much less uh arbitrage opportunity? So there's no guarantee whatsoever but you can also move your quotes just before it becomes profitable for the taker to cross.

Mhm. This is this is pretty similar in in TradFi HFT where yeah sometimes there's takers in the market that you know are just faster than you. And so what you do is you you give yourself a little bit of a buffer room. Yeah so you basically increase the spread in order to make it less likely that you will ever be so what you can't make up in speed you basically make up in spread. Yep. And that's why we see bigger spreads in Ethereum because the the time difference is basically like relatively big, and so the arbitrage opportunity that you potentially expose is really really big, and so um there's not that much liquidity around the peg typically.

Or like not the peg, but the kind of the the the current market price. Sorry, are you talking about on AMMs on Ethereum right now? Uh yeah, basically. Why it's like not profitable to quote a lot of liquidity around the current market price on Ethereum yeah. Yeah, that's right. Because you're going to get picked off a lot. Mhm. That makes sense. So, I wonder have you looked much into um kind of MEV capturing AMMs? So, uh I've seen a couple designs there that are kind of picking up in popularity, picking up in steam. I think we'll see something like that launch this year. Um and probably be quite big. Um and these would be kind of AMMs that that basically uh return the uh MEV lost to

arbitrageurs back to the LPs, thereby making it much more profitable to kind of use these automated strategies. So, I I wonder how you think about that. And whether that changes the balance in favor of AMMs maybe a little bit. So, I think this idea makes sense. Obviously, you could have something similar for a limit order book as well. Um with the the So, the main problem here is, I believe, correct me if I'm wrong, that to have this sort of MEV redistribution mechanism, you basically need to have your own app chain where you control the MEV.

No, I think you can build it into the into the smart contract on on Ethereum layer one this way. Can you Can you have like this efficient capture and and redistribution? Cuz I thought the fundamental thing that's happening here is the value is leaked to the network layer, right? Uh no. So, you would basically So, I haven't seen any concrete designs, but I think the way they would work is you basically auction off the right to execute the first trade uh in a particular pool in a particular block. And so there are some problems here with like unlocking the block. And so you maybe you want uh So maybe it helps if you also control it like you're ordering uh the ordering of the block so you can ensure that if like somebody doesn't take the opportunity and like within the first 10 slots of the block, then that the rest

the other like 90% can still trade. Um and so nobody needs to quote-unquote unlock uh the pool. Um yeah, but I think there might be some some ways around that. So. Yeah, I think this works to some degree. Obviously, the mechanism is pretty crude, right? Specifically because you don't control the L1. I don't know to what extent you're actually going to be able to recapture the MEV, but kind of the situation with AMMs on Ethereum right now is just so bad that pretty much anything is going to be an improvement, right? Like we see uh AMM liquidity providers losing hundreds of millions of dollars per year Mhm.

um because they're getting picked off. And it's it's all going to the to the underlying L1. Mhm. I I would have kind of a final arc here in terms of questioning um unless you have anything specifically about DeFi, Mike, uh that you want to want to bring in, okay. Um so I I think we so far one big uh theme of this um of this uh podcast season has been on kind of the role of latency. Like is Do Do you want high latency? Do you want low latency? What are the tradeoffs? And what might be kind of the like the frontier in terms of efficiency?

I'd be really interested to hearing from both of you. Um and I know Eugene you've thought a lot about this actually. So what is what is kind of here What is kind of the What do you think is kind of the the like optimal point where um the latency of a chain is low enough so that it can provide provide um, like a good design space for application developers and like the ability to manufacture liquidity at a cheap price, but where the also the latency is not so low that it causes this like intense geographical centralization pressure on the network.

Like, what's kind of the highest that we can go and what's the lowest that we need to go in order to to to make kind of the winning recipe. I think for DeFi, my best guess right now, and I'm not super confident on this, is that faster is just better, uh, where you can be just more competitive with TradFi. I totally agree that latency-driven centralization is a threat to decentralized systems, but it's not clear that, you know, having lower block times means the incentive for latency-driven is higher.

Uh, I think 0x94305 on Twitter has uh, been discussing this for a little bit, where you sort of look at the MEV that's exposed if you have 12-second block times versus if you have uh, shorter block times, and who is more likely to to win those sorts of races, how centralizing is it for validators and for searchers, and I think it's just really not that clear. And then from a more practical perspective, I think you just can't pause time for 12 seconds and expect the rest of the world to go along with it.

In the case of DeFi, basically what that means is today price discovery happens on centralized exchanges, and participants in DeFi have this really poor UX, and they get wrecked by MEV. I think the goal really has to be to create centralized systems that can be useful today, rather than systems that are only useful in the case of some collapse of the global financial system. And so that really means building a decentralized financial system that is competitive with centralized finance. I think it's very popular these days to paint HFT as a villain, low latency traders as like bad or parasitic. But DeFi on Ethereum today suffers from all

the worst aspects of HFT, like front running, and it offers none of the benefits like price discovery and efficient liquidity. And then obviously the protocol design space is just so heavily limited on the L1 today and even to some extent the L2s. And I think low latency systems or low latency blockchain reduces the total amount of MEV. And right now we see a lot of the MEV discourse focused on redistribution rather than reduction. Like we discussed before, right now MEV is costing these AMM liquidity providers hundreds of millions of dollars per year, regular traders are paying tens of millions of

dollars per year, and this is just like so fundamentally unsustainable. It just like cannot be the backbone of the future of finance, but no one wants to talk about it because the profits are all redistributed to ETH holders. There definitely parts that I resonated with me there, Eugene. I I you know, one one fun part of hosting this podcast is kind of jumping in between different ecosystems and taking the perspective of each like different ecosystem and definitely a big change for me in exploring MEV on Ethereum is that the user does not often take first place in terms of decisions that are being made. Although I do wonder in the long term

in the long term I think Ethereum might be or a designer of Ethereum might be thinking like that, but sort of with the idea that you have to make short-term compromises on UX to build uh, distributed sort of network. Um Or a or a neutral sort of network. I I I Lucas, I want to give you a I know we've got to wind down here in a couple minutes, but Lucas, I want to give you a chance to sort of bookend the conversation as well. Yeah, I think every I don't think I could have said it better than Eugene did. Um, I think that, um, you know, low latency can certainly it's can certainly drive like geographic centralization, but I think that, you know, there's

our 400 millisecond block times on Solana or the way that Solana is built right now, does that drive more centralization? Uh, not super clear to me yet. Um, but I think it's definitely something worth keeping an eye on and hopefully uh you know, validators and stakers can uh, participate in like preventing that from happening. Guys, you've been super generous with your time and definitely given Hasu and I a lot to digest. If folks want to find out more about the work that you're doing or follow you or your projects, what's the best way for people to find out more information?

Uh, yeah, my Twitter is Buffalo. You can go to Jito.wtf to learn more about what Jito Labs is building. Yep, and you can find me at 0xshittrader on Twitter. Amazing. Don't get better names, uh, than in the crypto space. So, guys, uh, thank you so much. It's been a real treat of a conversation. Um, appreciate your time. All right, partner. That was a great That was a great episode. What did you think? I thought it was amazing. That was, uh, maybe the most fun that we had so far. Uh, I learned so much. I think I think this is like a big reason I wanted to do, uh, this season on MEV, um, because I thought there's a lot that I can still learn and, uh, I think

Eugene and and Lucas, um, really kind of showed showed us the way there. You know, in doing my my sort of research for this season and this episode, the the way that consensus works on Solana, if you're familiar with how it works on Ethereum, it's really very different in Solana. And I think one of the challenges of this season, or it's like interesting but a challenge is to sort of separate and meet the MEV conversation from straight-up protocol design and consensus design because they're so intertwined, I think. So, I really enjoyed the part, you know, where we discussed just how Solana works because at least for me, the way that it works on Solana is a little bit more challenging to totally grasp. And I really enjoyed the the discussion about

sort of fee markets as well and kind of contrasting how it works on Ethereum versus Solana. Yeah, I completely agree. I think in the first half of the conversation when we discussed how Solana works different from Ethereum and what kind of MEV market structure results from that, I thought it was so fun, for one, because it it kind of validated a lot of the things that we had theorized about in previous episodes, right? For example, this idea that if you have a low la- if you like if you have a low latency chain and if you don't have a fee market and if you have fee cheap fees, then it kind of devolves into the spam war and Solana is such a great example for that.

Um and and yeah, I think um also Jito is taking a lot of the right steps in order to mitigate this problem. That's kind of the quote-unquote like flashbots of Solana. And I I thought it was very interesting when we unpacked um how exactly they approach um kind of solving this this spam problem, this MEV problem on Solana. And it was interesting for me to see how it's not really about the bundle and kind of the atomicity guarantee that it provides. It's really about um it's really about the ordering guarantee, right? It's about slowing down time and kind of tiebreaking between like letting transactions accumulate and then tie breaking between the transactions deciding which one

comes first and having kind of this auction between them that moving the auction to to like an auction on price and who can tip the validator the most instead of just an auction on on who's the fastest or who can spam the chain the most. I Yeah, I thought that would that was the most interesting in like the initial half of the conversation for me. I also do think, you know, there are probably some fundamental limitations with the the difference of Solana obviously being their focus on low latency which has a lot of benefits, but there are downsides and risks to that as well. One of my takeaways from this conversation is that you couldn't ever probably have PBS in the way that is being engineered on Ethereum on Solana because the hit the latency would simply

be too great. So, I thought that was a big takeaway for me from the conversation too. Yeah, yeah, but it was interesting um that I think like the MEV ecosystem on Solana and even like the base layer design in some ways as it relates to fees it's it's kind of converging on what Ethereum is already doing, right? And I think it it it kind of shows that if you want to be really like unique, you want to be really creative, I think a lot of the time there comes MEV with a sledgehammer, right? And it's just like destroys your plans and you have to go back to to some design that's already like that that kind of factors in MEV and is proof more proven to work, I think. Avalanche is another chain. We will not talk about Avalanche in this

season, but I think it's another great example for a chain that tried something really unique with their consent like Snowman consensus Dædalus protocol and then it got completely smacked in the face um once there was any DeFi activity on there because searchers started um basically manipulating the consensus and and basically slowing down the the block time to the point where the network would just stall out and not finalize for like 10 20 30 seconds at a time and so they had to change away from it and so it's interesting that we're seeing the same things on Solana.

And yeah, I think kind of their variant of PBS, it might look a little bit different. I think if I had to guess it will move a little bit more in protocol than we see in Ethereum just because if you have something that's out of protocol then it just takes more latency basically. Everything takes longer, there's more parties involved, there's more communication steps and Solana really wants to get their latency down. And so if I had to guess then whatever they end up with, I think there will be more components of it inside the protocol than outside and I think um actually I think Lucas made made this great point or might have been Eugene. One of them said that it's okay like when you want to do things like precise and efficient you do them

outside the protocol but you can also do them inside the protocol. You sacrifice some efficiency for example if you use some form of like uh base fee on a particular state part of the state, right? And then it just approximates kind of what the recent demand for that piece of state was and it really acts like an off-chain MEV auction in a sense. It's just like way more clunky, way less precise and generates less revenue but it works somewhat, right? And so this is a way that you can do something that we know that we know how to do really well outside the protocol. You can pull it into the protocol and you sacrifice some efficiency but at least it's like way faster.

You know, I wanted to so a couple notes on on all of that which is totally noted about in protocol versus out of protocol and we've talked about this a little bit on within the context of Ethereum about what makes sense to get enshrined versus what's what are we okay doing off-chain etc. Um I also do want to just you know, give a big plus one to it's it's very interesting to sort of note that designs are converging across different ecosystems. Uh You know, last season we talked a lot about how there I certainly there's a convergence in architecture between Cosmos and Ethereum. And Ethereum has kind of adopted I think an idea that sort of began actually with late lazy ledger in 2019, which was a sort of a Cosmos type

project. And it's interesting to see the same thing happening a little bit between Solana and Ethereum as well. I had a I had a question for you. I wanted to dive deeper in the episodes, but I didn't want to distract us too much. The the question of when we were talking about multi-dimensional or sort of parallel fee markets and the idea that you could let's say on Ethereum, if you wanted to probably categorize it as a defi fee market and an NFT fee market. And you asked the question, is that a good thing or not? I don't know it kind of seemed like you had actually given a decent amount of thought to that. And I can I sort of thought I started to see where you were going, but can you dig into that a little bit more?

Yeah, no, I I actually haven't thought about it much, but it was not clear to me that a chain shouldn't shouldn't kind of have a lot of slack and buffer for for specific applications to take over the chain basically when demand is really high. And I understand that this crowds out a lot of other application usage, but it's basically you also create this disincentive. You kind of arbitrarily throttle kind of the supply of the chain for a particular type of application and you create a disincentive for apps that might be really popular to build on your chain. And so I think with resource pricing, this is one of the most unexplored underutilized most

interesting kind of topics in blockchain design because how you price the resources affects so many things. It's It's like you're playing God or you're playing like the government in the sense and you're trying to well, like you you try to incentivize particular forms of economic activity, right? That's why for example, we have um these pre-compiles in Ethereum or opcodes uh it's another term for them, right? And it's basically subsidized usage of Ethereum because we say, "Oh, these operations uh very useful for Ethereum, like for users, and so we want to subsidize them."

Um and other things might be discouraged, right? And so it's it's it's about like encouraging certain behavior as well as discouraging others that might cause negative externalities. Um And so yeah, I think this both a science and an art in kind of designing these uh resource pricing mechanisms here. And Ethereum is making new grounds with I think multi-dimensional um EIP-1559, and I think Solana is equally breaking new grounds here with their idea of of kind of the uh you know, the state-based um base fee. Uh so, I think this is this would be also really really interesting to to see kind of how it develops.

The reason why I think it's relevant to Solana is I think I guess I want to think about it a little bit more before coming to a conclusion, but it's definitely a problem of generalized block space where you can have one application interfere with the performance of another. And I do hear you that, you know, would we have Uniswap or OpenSea, uh you know, kind of the only There are very few app success stories in Ethereum so far. The vast majority of them are on Ethereum, and I do wonder, to your point, whether or not they would be success stories if Ethereum decided to throttle, for instance, OpenSea's usage of block space. On the other hand, I think long term in a monolithic design where there aren't explicit plans for

app-specific block space or L2s or whatever, I think you have to solve that problem eventually because even just imagine in a in a DeFi sense, if you had critical financial infrastructure, you would not want it disrupted by, you know, some NFT mint or something. That would just Just imagine Just imagine how how much politics that will introduce on on kind of on top of that like something that aspires to be a base layer, right? As as kind of different applications uh try to lobby for, you know, their usage of the chain to be expanded, for them to be allocated more capacity, for their usage to be subsidized.

Um I think this is going to be really really hard for chain that aspires to be uh credibly neutral, aspires to be kind of an unpolitical base layer. Um I think we will see something like that maybe on some other higher-level domains, but the thing is the same thing that makes uh kind of this like very opinionated resource pricing very difficult, which is credibly neutrality, is the same thing that makes it very attractive for applications to build on your chain, compose with other chains, and settle down there because it's it's basically that like platform risk, right? Uh credibly neutrality minimizes platform risk, but it also minimizes your ability to kind of be uh opinionated about resource pricing, and so um

yeah, I I feel like it's a stalemate there. It's tough. It's very difficult. And I'd be curious, maybe this is a good segue into, you know, our discussion of DeFi and AMMs versus central limit order book constructions and the pros and cons there. But I I found myself thinking the same thing when Eugene was describing the amount of money essentially that LP sort of passive LP stakers on Uniswap are doing, and at some point I do feel like politics is inevitable.

And even like here here's an example of how this is happening on Ethereum, like blobs, you know, kind of data blobs for cheaper uh you know, cheaper yeah, execution on layer twos. I mean, that's all right that's a that's a very popular decision, right? And that's, you know, directly to support the road map of Ethereum, but it is already a political decision, I think. And I do wonder, you know, if I was Uniswap as a single entity, I obviously know that it's not, but if I was Uniswap and I was like, "Hey, I I'm responsible. My application is responsible for an enormous amount of activity on Ethereum.

I'm essentially subsidizing an enormous portion of Ethereum vis-à-vis my my LPs that are providing liquidity. Eventually, you know, right now we're in the pie is growing and we want to make the vision work, but eventually that's not going to be sustainable. And I would have to imagine Uniswap has an enormous amount of lobbying power in Ethereum. So, maybe if you could kind of respond to that and how how long you think that equilibrium is going to be stable for and then we could get into the AMM versus central limit order book. Yeah, I mean, it's not just that I think is not just that I think that Uniswap has lobbying power, which may be true. I don't think they're particularly close to core development, uh even though they are initially like funded by grant from the Ethereum Foundation.

Um I think it's more so that they have kind of bargaining power uh in the sense that like certain decisions might not like even without kind of any explicit form of collusion that that there might be certain forms of decision that like are very hard to make because then applications like Uniswap would leave the chain. And I think we will see that happen at some point anyway, right? It's like um I think um I think like the more kind of business people there are in in crypto working on these applications, um they will look at the entire value chain of that application and they will think, "Oh, yeah, this is like the amount that we pay for security. This is the amount we pay for settlement. This is the amount we pay for uh you know, our back end or like our

indexing, whatever, right? Our front end, all of these things." And they will think, "Oh, how can we how can we make more money, but also how can we spend less money?" And they will think, um, well, maybe if like we are spending a ton of money on data availability on Ethereum, whatever, right? Then let's also explore some other options. And I think there will be competition, um, and I think, um, for what it's worth, like the Ethereum core developers and the Ethereum Foundation is also very aware of that, right? I think they they understand that they they are kind like other applications and users are their their their customers and their users and we are all like a community, but we are also all competing with each other, right? And

um, if if if Ethereum isn't kind of the best, most cost-efficient option for someone, then that someone is going to leave Ethereum. And so, I think this is part of what motivates this whole shift to Ethereum becoming kind of the best settlement layer, the best data availability layer. And I I think we'll see a lot more changes that kind of optimize for the for the needs of, um, of of applications. Um, but I think it would be more like in the sense that uh, optimizing for like archetypes of of of applications and less so for any kind of individual ones.

That makes sense. Um, yeah, talk to me about what your thoughts were. I I really love just listening to you and Eugene go back and forth on AMM versus central limit. It kind of reignited this, you know, memory of mine that this was sort of a raging debate a couple years ago. People love to talk about this. So, yeah, give give me your What did you think? Yeah, I love Eugene. Uh, I think he's such a great guy. Um, and uh, yeah, that was a really fun debate. I thought it was great to hear his perspective of someone building, uh, an application on Solana. Um, and so he's someone who like was more closely aligned with Ethereum, I would say. So, I think that's how we met initially. And so, it's it's it's it's kind of great to see some bridges being built to that ecosystem. And I thought

he made a lot of interesting points just about how, um, there can be instances where a faster block time exposes less MEV, and like prices update faster, um, when uh, yeah, just like you you have an easier time manufacturing liquidity, um, it kind of plugs more nicely into whatever like mental and technical APIs existing TradFi market makers already have. And so it's it basically lowers kind of the entry barriers, um, that they have into crypto. And um, I think these were all super valid arguments, um, and it kind of hints at this general idea that it's not a just about building decentralized system sys- systems, it's also about building systems that can compete with

whatever's already out there in the real world. And um, yeah, I I thought that his argument really resonated with me. And um, yeah, I think the kind of like this geeking out about AMMs versus, um, essential limit order books, I think that was really just the cherry on top. Um, I think the last word hasn't been spoken about like uh, like central limit order books versus AMMs, I think AMMs have some tricks up their sleeves. I think central limit order books are relatively figured out. I think there's not much innovation to expect here. I think it's more about bringing kind of existing standards on chain versus in AMMs.

I think there's still a lot, uh, that's going to happen, a lot that's going to develop, um, and I think this year we'll see some very interesting things with, uh, MEV capturing AMMs. Yeah, I tend to agree with with all of that, to be honest. Um, trying to think, I think that was that was basically basically it. It was uh, there's definitely a lot to to think about, and I think I just always love hearing from the the Solana side of things. I think it's kind of one of the communities that has definitely taken the the Oh, oh, the one other point actually that I wanted to get your get your thoughts on is it was you know, his point, we talked about this a little bit, and even more greater detail kind of off air, but his point that look, in general, HFTs are sort of villainized

and they're not a very sympathetic group of people cuz they do frankly make so much money and they're very opaque. And, you know, his sort of perspective was actually providing liquidity is a is a good, right? So, we've been really you've been leading the charge on warning about some of the you know, what we don't want to do is just recreate the TradFi model here, but I think Eugene injected a little bit of nuance that look, what HFTs do in terms of providing liquidity and assisting in price discovery, that's actually not a net bad. So, I I'd just be curious to get your thoughts on that point then.

No, I mean, I I would agree with him. It's uh I I think uh my view and this is also nuanced in the sense that I can really appreciate the innovations behind kind of electronic markets. I'm not even a like a big hater of uh of like payment for order flow by anything. Like I I think it has uh improved a lot of the like liquidity um or kind of the the execution that that you can get as a user. Um I think it's more so about uh what it kind of does to market structure long term and the question whether that's a whether that's a better model here because to like crypto and DeFi is different from TradFi in the sense that if someone is really good at market making on chain, then by definition almost that means they

will be good at block building and it means they will be like they will have like equal amount of power over the chain. And so, an outcome about like a market structure outcome that that would be acceptable in TradFi, like entirely acceptable to me. I wouldn't even change the market structure in TradFi, but I can't say the same market structure is not desirable for DeFi just because it has more implications on base layer central decentralization. And so, I think that's generally where I'm coming from. Can you cuz I've actually questioned this a lot myself. Could you respond to the last point that Eugene made just about maybe Ethereum his broad point I'm sort of paraphrasing here was Ethereum is

building for a situation either explicitly or implicitly where there's some kind of government crackdown right or you know the government tries to ban it so the design is such that right like even in our discussion about latency latency would be okay if we weren't concerned that a government might come in and you know shut down that that's why we're very concerned about No I don't really agree at all with that I didn't really agree with all of at all with that I think that even at like a 12 second or 5 second block time I think there's plenty of things that you can build on Ethereum that's better than existing systems and I I don't think that Ethereum needs to be better at everything than kind of existing systems I think it needs to be better at some specific things and I

think those specific things is kind of verifiable computation and kind of making credible commitments towards one another and I think that what this does is this basically removes the need for trust in in kind of commerce in in in in collaboration and it it just like unlocks like a lot of human collaboration anywhere in the world and I think that that what makes it powerful and I don't think that latency is really like a huge factor in that and yeah I think the next few years will kind of show what you can do also like in in kind of higher latency chains I think MEV capturing AMMs one thing to look out for but also

batched options right so um I think these are generally like things that you can do in order to have also like very good price discovery without yeah with maybe like a little bit higher kind of latency also all right partner well this has been a fun one next next week we're going to be talking with some of the folks over at Cosmos actually in in another fun sort of uh departure from Ethereum, but that should be a good one, too. That should be good.

All right, Hassie. Good to be back, man.