We’re kicking off Season 4 with a deep dive into the MEV supply chain, SAUVE, order flow auctions, and the future of programmable privacy with Shea Ketsdever from Flashbots ⚡🤖 There has been A LOT of excitement around the MEV world lately, and Flashbots is one of its biggest contributors.

Shea demystifies the MEV supply chain, walks us through each of its steps and actors, and explains just how important it has become to Ethereum (around 95% of all transactions currently pass through it).  

Zooming out, Shea breaks down the MEV supply chain’s key ingredients of privacy and commitments, how they are used to create programmable privacy, and how they might be leveraged for other uses in the future. 

We also talk about SUAVE, MEV centralization risks, the privacy-efficiency frontier, and more!

📬 To keep up with the latest from Archebyte and receive articles and research from the rest of the Archetype team, subscribe to our newsletter: http://eepurl.com/iCApL2

- - - - - - - -

⌛ TIMESTAMPS

0:00 Intro

1:34 The “right” way to pronounce MEV

2:00 Shea’s background

2:32 The MEV supply chain

9:14 What is MEV? 

13:30 Privacy-Efficiency Frontier

18:19 Programmable privacy

20:10 MEV-Share and Order Flow Auctions

22:53 Evolution of the MEV landscape

27:35 SUAVE

37:53 Other use cases for SUAVE

40:45 Follow Shea and Flashbots!

40:58 Outro

‍

👋 FOLLOW US

Shea: https://twitter.com/SheaKetsdever

Flashbots: https://www.flashbots.net/

Archetype: https://twitter.com/archetypevc

Katherine: https://twitter.com/katherineykwu

‍

🌐 LINKS

Flashbots Docs: https://docs.flashbots.net/

Flasbots Writing: https://writings.flashbots.net/

Flashbots Protect https://docs.flashbots.net/flashbots-protect/overview

Flashbots Forum: https://collective.flashbots.net

‍

📜 TRANSCRIPT

KATHERINE

Hello, everyone, and welcome to season four of Archebyte. We are back with a brand new season after an extended break, and this season is packed with technical topics that are front and center on the minds of the Archetype team. We will be kicking off the first episode this season with all things MEV, past, present and future. We'll be exploring the MEV supply chain, the balance of programmable privacy, and lastly, why the future of MEV is SUAVE.

Our guest today is Shea Ketsdever, who has been at the forefront of tackling the challenges posed by MEV and has a wealth of knowledge to share with us. So without further ado, let's welcome Shea to the show. Hi Shea, thanks for joining us today. 

‍

SHEA

Yeah, thank you for having me on. 

‍

KATHERINE

So this is just a note at the top. And I know we were joking about it literally just a second ago, but I want to say, I know that the pronunciation of M-E-V or mev depends on the speaker. For this purpose, MEV as a standalone word is M-E-V. When it's added to a word after it’s mev. So don't come at me. Don't cancel us for the pronunciation. I'm saying this at the top. So that's a disclaimer. So, Shea, tell us in a sentence or two about yourself and about what you do in Flashbots. 

‍

SHEA

Yeah, sure. I'm Shea. I work on the product team at Flashbots, and at the moment we focus on everything from when a user submits a transaction to when it gets included in a block. So that includes our private RPC, bundle relay, order flow auctions, and block builders, amongst other things. 

‍

KATHERINE

That's the perfect segue way because I was going to ask you to help us get started by sort of level setting. So given what you focus on, that's what I want to look into. In particular is the MEV supply chain. So to your point about what happens really or the process and what your transaction goes through prior to going on chain. So can you maybe help us review the different components of that supply chain? 

‍

SHEA

Yes, so really simply the MEV supply chain is a framework that we like to use to describe how a transaction progresses before it's included onchain. In this case, we're talking usually about Ethereum and the actors in the supply chain are really important. I don't know if everyone listening knows this, but actually 95% of all transactions on Ethereum go through the MEV supply chain. So if you use Ethereum, you're actually using these products and they are really important because they effectively determine who gets included, when, how value is distributed and to whom.

At a very high level, the way this supply chain looks is that it starts with the user who has a goal or an intent. They then communicate that to a wallet, which will sign a message or a transaction and propagate it to the network. And if it's profitable to do so - for example, if the transaction interacts with the protocol in a certain way - then MEV searchers would create a bundle which combines the original transaction with their own.

MEV searchers are this more sophisticated class of actor. And finally, after this, block builders will merge many of those bundles and transactions together to construct a block which they send to a validator. If you are not familiar with what a validator is, it's kind of like the equivalent of miners, but in proof of stake. And this is the simple view. 

If you look maybe one layer deeper, you'll also notice that there are actually other actors and protocols that facilitate the flow of transactions and information between those parties I mentioned. So between users and searchers or block builders and validators. Two examples here. 

One is that block builders, like I just mentioned, will use the MEV Boost or mev Boost protocol to submit their blocks to validators. And I mention this because the protocol is really important. It does two things. It gives these block builders privacy so that validators can't steal their blocks before they're signed. And it also gives validators a commitment that the builders actually will reveal their blocks when the block is signed. And this is really important because it makes it possible for these actors, who in reality don't often know or trust each other, to temporarily collaborate and pass transactions along. 

Another example of this is order flow auctions, which kind of like MEV-Boost, mediates the relationship between builders and validators. Order flow auctions help mediate the relationship between users and searchers. And again, these order flow auctions do two things. They give users privacy so they can restrict what information searchers might see and commitments. So, for example, order flow auctions can let users require that the searcher will refund them any MEV that they generate by bundling the user’s transactions.

And this is quite useful because it makes it possible for searchers to enrich transactions that otherwise might be quite sensitive. And I just bring up this layer below, because I think it's a nice way to show the more fundamental ingredients that the MEV supply chain runs on, which are privacy and commitments. Each time we introduce these ingredients, we will see a new useful class of actors or and maybe applications emerge.

And those applications, hopefully, as these examples show, tend to create better outcomes for people. It's very exciting to think what net new applications or kinds of collaborations or better outcomes you could use those ingredients to build in the future. 

‍

KATHERINE

So before we turn into the intersection of privacy and MEV, which I definitely want to talk about, let me just try to sum up like a few of the actors and the process.

So we have the user. You submit something to a wallet, or you submit your intent, then it goes searcher, builder, validator, right? 

‍

SHEA

Exactly. User has an intent. They send it to a wallet to sign, which sends it to possibly a searcher to bundle, who sends it to a builder to turn into a block, finally sends it to a validator to include onchain.

‍

KATHERINE

So, yes, as with any long journey, there are dangers that lurk in the process. But this is why - well, let's turn into this next section, which is sort of privacy and MEV. So specifically the balance between privacy and efficiency. What I mean by that, I think we can generally agree, privacy is probably needed to decentralize those parts of the MEV supply chain, but it probably also comes at some cost.

I'm going to turn over to you to explain this balance to us and then maybe I'll ask a few follow ups.

‍

SHEA

Sure. So as we've already just been talking about, privacy is one of the key ingredients in the MEV supply chain. But exactly to your point, Katherine, it's a very nuanced topic. And I think to motivate why that is, I might actually just zoom out first and talk a bit about why we have MEV, how it works, and then from there we can talk about why privacy matters in this context, why it is more nuanced than you might think it is, and also how we're approaching it at Flashbots.

My goal here would be to motivate to you that, concretely, as a user or maybe an application developer, why you could leverage privacy as a tool to get better outcomes. So, why is all of this actually relevant to you? 

To start, though, let me just zoom out. I think there are a lot of answers to the question of what MEV is, but for our purpose in this context, I think it's useful to think of a MEV as a component of permissionless systems. And the problem you can think about it solving is that you often in these systems want to encourage people to do certain things. But if the system itself is permissionless, then you have to find a way to do that without entrenching, say, a specific actor or set of actors. And it's really common as a solution to this problem to sort of offer permissionless bribes to incentivize the actions that you want to happen.

So what does all this mean? One example that I like is in CryptoKitties. I really like this one because I think it's a very approachable example. Somebody actually needs to call a function to breed the kitties every like ten blocks, and the blockchain can't do that by itself. So the way the protocol solves that problem is it actually offers a small reward to whoever goes and calls the function to breed your kitties.

It is actually really important that those incentives, those rewards, are public because it increases the probability that these actions you really want will occur - that the kitties will breed. And I think that's a fun toy example, but it's not just true of kitties. MEV is also really important to things like decentralized finance, which is maybe actually the first context folks tend to hear about it in. 

Just as a couple quick examples, liquidation protocols use MEV to incentivize people to liquidate under collateralized loans. I think yield aggregators also use MEV to incentivize people to call this harvest function that actually harvests the yield they've created. And there's a lot to be said about AMMs, but in a certain way, you could think of them as relying on arbitrageurs who are incentivized also by MEV to bring prices in line with the external world.

I’m not going to get into all the details of how that works, but just as a couple of examples of why actually MEV is quite useful and in fact fundamental to making these protocols work in the way that they want to. And it's also not just kitties or protocols, but, you know, you and me. So individual users can also benefit from MEV. An interesting fact is that getting bundled by an MEV searcher - these sophisticated actors who look for your transactions and add them to their bundles - can actually result in faster inclusion for you as a user, because that searcher might pay a very large tip in their bundle to get it included by a validator. In the more general sense, you can also think about this from the perspective that it is just beneficial to be able to share your order flow with more sophisticated actors because they can often find you things like better prices or improve your overall execution.

This is all just to say, hopefully with a couple examples, why MEV can be very useful to use our protocols. But the problem, or the catch Katherine that I think you were alluding to, is that it's really tricky to harness those incentives so they actually work the way that you want them to. As a user who is maybe less sophisticated, you can unintentionally create incentives for other people to do things that you actually don't want them to be doing.

For one very classic example, if you're trading on certain AMMs, it might be directly profitable for somebody else to front run and sandwich your trade. So just by making a trade, you've sort of inadvertently created an incentive for other people to take actions that like a sandwich results in you actually getting a worse price than you would have otherwise.

So there is essentially this balance. You want to share enough information that people can take useful actions, but not so much information that they're incentivized to give you worse outcomes. And this is often what we refer to as the privacy efficiency frontier, a term you might hear thrown around in the MEV discourse. And basically what this is about is just the question of - how much information do I share to get the optimal results?

At Flashbots, finding the right balance along that frontier is something that's very important to us. We've been working towards it for some time. So I might just share two concrete examples of applications that actually try to find a balance on this frontier and configure privacy to give people better outcomes. 

The first example I'll give you is a little while ago we released the Flashbots Protect RPC, which is basically a private mempool that protects you from some of the negative externalities of MEV like sandwiching. So it prevents people from front running you, from sandwiching your trades, and basically ensures that you don't get bad outcomes. This is quite effective. You know, if you're doing basically anything of note onchain, I would recommend that you use a private RTC. Ours is just rpc.flashbots.net, and it takes you probably less than a minute to add if you go to our docs. You only have to do this once. 

In addition to protection, basically making sure you don't get bad outcomes, there are also ways you can leverage MEV to improve your execution, kind of like the way that protocols actually use MEV to incentivize important actions to happen. Because the truth is that private mempools actually leave a lot of value on the table. It's not claimed by searchers, but it’s also not claimed by the users, and effectively just gets sort of lost within the void of discoordination. And this is a problem that we've been quite interested in for a while, and we recently launched a new feature to address this. It's part of Protect, so if you're using that RPC you automatically benefit from this as well, and the feature I'm talking about is what we call an order flow auction. Very simply, this works by sharing a small amount of information about your transactions with searchers. So maybe the pool that you are trading on, like I am trading on a USDC/ETH pool, but no other information like how much I'm trading or which direction and trading in. And this is enough information for searchers to effectively bundle you without doing things like front-running you outside of the system, which we really don't want to happen. 

And the end result is that you can actually require those searchers to make a certain commitment to you that if they generate any MEV when they're bundling your transaction, they will refund you a portion of that MEV.

And this is, I think, very cool. Order flow auctions are basically a positive sum game because both the user and the searcher and actually as a result, the validator who gets the ultimate bundle, will all pocket some additional MEV. Basically, everybody benefits from participating in this mechanism.

So those are just two concrete ways. There are also other private mempools, other order flow auctions out there. But if you're interested in this stuff, those are two that you could actually use right now. And I think looking ahead there is even more we can do to refine how we manage privacy and also to kind of build on top of these foundations to create net new applications, which I think are quite exciting. 

‍

KATHERINE

That was such a great explanation because you started it with like, you know, long journey into this, like no protection, sometimes it can work to your benefit, sometimes not. And I think that's the really scary part for a user who kind of unknowingly wades through what Dan Robinson, who's a researcher at Paradigm, labeled as the Dark Forest.

So the RPC node is a protection. But I think one of the questions I have seen and I think you touched on it, is like how do you then optimize everything? Execution, extraction, merging without any information? And I think it's not really so much you're not doing any information, but it's that like a user, you can choose that, right?

And I listened to this talk that you did at EthCC where you mentioned the term programmable privacy, which I think is so perfect for what you were trying to illustrate, because the idea is that you can like control what you share, right? 

‍

SHEA
Exactly. Yeah. I think order flow auctions are this sort of early testing ground for where we hope to go with this, which is that, you know, privacy isn't just a binary thing. It's multi-dimensional. It's who do you share what information with, at what point in the process, what kind of actions are you trying to take? Because there might be different configurations that you want in each case. And so, it's a pretty complicated thing. There's no one size fits all to it. And that's why what we want to do is really offer people this like fine grained control about what they want to share.

Obviously, that might not be something that everybody wants to be presented with. So it's something that, say, your wallet could also manage on your behalf. But I think at least having that kind of choice somewhere or at the user level is quite important to, you know, find the right balance for you of being able to leverage MEV to get useful outcomes, but avoid the negative externalities that aren't benefiting you in the particular scenario that you're executing in right now.

‍

KATHERINE

Yeah. Are there pieces that MEV-Share as a product can help the user make those decisions? I think it's important to understand that like, sure, because everything is out in the open, it's scary. You can certainly choose, but is there some point in which MEV-Share helps the user decide on what hints to give? And what pieces are actually fully user-controlled? How do you guys think about that spectrum? 

‍

SHEA

Yeah, so first, just briefly, MEV-Share is a protocol that we have been developing at Flashbots, but also with other people in the ecosystem, which is a protocol for order flow auctions. So in case that name is new to anybody listening, this is an order flow auction protocol and we run one implementation of this protocol as part of Flashbots Protect. And I think the decision we've made is that there are certain hint configurations, where a hint is what we call the pieces of information that might be share with search, that we have done some research on and seen in practice seem to be good at striking the balance of how much information to share in certain kinds of settings.

So, for example, if you're making a swap on an AMM, we found that it's relatively safe to share what pool you're trading on, like the assets you are swapping between. And that's actually enough information for searchers to effectively back-run you by guessing various combinations of trades that you could have possibly been making on that pool. So, at least in our implementation of share, we make a few choices based on configurations that we've seen proved to be quite effective in practice.

But there's also, I would say, a lot that we don't know. This is all very new and there's a lot of situations that will probably also arise in the future, which we haven't studied well. And so I think that's why it's important to also offer the ability to kind of customize what's shared without a party like Flashbots choosing for you.

‍

KATHERINE

Yeah. And crypto products generally I think can be opinionated, but I think what I like the most is that they also leave the choice to the user. I want to touch on some of the challenges, but before we get there, I want to turn to the topic of SUAVE, which I think is a very hot topic right now. I know you guys are actively working on it and there was a big blog post last year that I read from the Flashbots blog that was titled The Future of MEV is SUAVE, which is a big title. So I want you to go into that. But also I sort of want to rewind a little bit and just talk about how the MEV landscape has changed over the years. And of course, what I want to get at is like why there is even block builder centralization risk. But I kind of want to rewind and let's just talk about the MEV landscape as a whole and how it's changed. 

‍

SHEA

Sure. I’ll maybe just start with one somewhat obvious trend, at least in my view, is that over time, this supply chain has become a lot more specialized and complicated. As we were going through it at the beginning, you realize, Oh, wow, that's a lot of actors. We have introduced a lot more people or services in the supply chain, and this is both in terms of what I might call MEV-focused infrastructure, for example, order flow auctions or block builders, but also other applications that are involved in this process of executing users requests, things like RFQs -  requests for quote systems.

And I think this is net beneficial in many ways. These actors are really useful. They prevent things like validator centralization by separating the validator from the block builder role, and they also prevent things like front running through private RPCs. And also from a market standpoint, it's just good to have competition between specialized actors. It leads to more efficiency, it leads to better outcomes.

But obviously, this isn't perfect. And one of the biggest risks is that the supply chain is both currently centralized and also at risk of further centralizing. If you just look at the numbers in the market today, something like 80% of blocks are produced by four builders, which is not great. And also all of these applications - basically everything I have named so far - runs on centralized infrastructure. So like private servers. 

This is far from ideal for many reasons. To name a few, it provides an avenue for censorship, requires constant policing to actually make sure these things are doing the things they say they will, and everything is fundamentally just based on trust. Trust is something that doesn't scale particularly well. So we're limited to who can participate in the supply chain and also in how creative we can get with the kinds of interactions and things that we build.

This obviously matters at the infrastructure level, but it also really matters at the application level. So as a user who maybe transacts on Ethereum, this should directly be important to you, especially if you think about how things have evolved on the UX side recently. There's almost somewhat of a paradox because users have a lot more options now about how to execute their transactions. There are all of these actors in the supply chain, but paradoxically, that optionality actually makes it more complicated to choose what to do. So while the infrastructure becomes more sophisticated, the UX side tends to go towards abstraction and delegation. 

You can see this recently in the growing adoption of things like intents and account abstraction. Basically, these are things that let the user deal with fewer executional details because all you have to do is define your goal and you don't have to figure out all of the steps or all of the actors involved in executing it. I also personally think that new apps like Telegram bots are quite interesting because they also let users delegate control even of their entire private keys to these more sophisticated classes of bots.

And broadly, I mention this because I think the more specialized the supply chain becomes, the more delegation we're actually likely to see from users. And this is one maybe less obvious, but important, reason why that centralization risk matters so much. Because you and me and everybody else, we are increasingly depending on these other parties for execution. And so that makes it really important for us to find a way to actually decentralize the execution engine that we're all relying on so much.

‍

KATHERINE

Yeah, Thank you for that explanation. The topic of MEV, it's not new, but I certainly think at least like with SUAVE specifically, I think that's the Flashbots solution, and I definitely want you to explain that. But there also are other solutions that have come on in recent years. So like I said, it's like some similarities and like how folks want to build solutions to help protect users and like some that approach it differently.

I know CowSwap has their own approach to it, that's a little bit different. Although the end goal I think is generally user-focused and you don't want your users to get sniped at any part of this process. Can you help define at least like the Flashbots solution, which is SUAVE, and how it keeps MEV or the block building part decentralized? And I don't know if you want to touch on maybe some of the pros and cons like some of the other solutions out there as well. 

‍

SHEA

Oh interesting. 

‍

KATHERINE

Sorry to put you on the spot. 

‍

SHEA

No, it’s a good question. I can definitely talk about SUAVE. I would say, just out of the gate. I think SUAVE is actually not competitive per se with other kinds of MEV applications. Hopefully I can motivate to you why it's ideally something that could be used to support other MEV applications. 

For example, like CowSwap, you could build CowSwap on SUAVE if you wanted to. But I might be getting a bit ahead of myself there. So maybe I'll start with, you know, your question about what SUAVE is and how it addresses this centralization risk that we were talking about. I think to answer that, it's worth actually thinking about why the MEV supply chain is centralized today. There are many reasons, I'm not going to talk about all of them, but I think one key reason to call out is that it's in part because there isn't a good alternative.

You know, there isn't a better way to run builders or relays or whatever actor you want to talk about, because MEV applications aren't well-served, not all of their needs are met by existing decentralized infrastructure that we have. In particular, they need a set of things. They need something we've been talking about a lot - privacy. They also need the ability to make fast decisions and commitments within a block time. For example, the commitments that searchers make to users in order flow auctions to refund some of their MEV. And finally, they need just generally cheap compute to handle things like the load of simulation. Running a searcher or running builder requires doing a lot of simulation. 

So all of this is to say basically we need MEV infrastructure for our MEV infrastructure, which sounds like a meme but I think is true, and that in some sense is what SUAVE offers. So it's a means to decentralize the MEV supply chain. And it does this by providing all of the things that you need to run MEV applications and the things we're talking about earlier, but on decentralized rails rather than a private server in AWS East Ohio or whatever. 

I'm happy to go into more detail about how it does this and how it works, but at a high level, I think this is exciting for a few reasons. First of all, SUAVE lets you address the centralization risks in the MEV supply chain that we have today. It lets you take something like any MEV application, something like CowSwap, and run it on a decentralized network rather than on a single server. It also gives you programmable privacy, Katherine, as you were asking about earlier. You know, if MEV-Share or OFA’s today are an early experiment with sharing certain amounts of information with SUAVE, you can actually program the precise variation of privacy that you want to get for specific applications. And both of those things - addressing centralization and having real privacy - are things that directly lead to better outcomes for users and also just more creative freedom in tools for applications to leverage. On that note - oh go ahead.

‍

KATHERINE

Oh, no, no, no. I was going to issue a slight clarification with the way I asked you the question just now, because I think obviously the end goal for everyone is to create a better decentralized network that's safe and good for the users. I think the Flashbots assumption is basically like MEV exists and isn't necessarily a bad thing. And you know, we can normalize it and actually redistribute it in a way that's good for the user. And I only mentioned CowSwap because I know it's sometimes brought up and compared directly, but I think that base assumption is also different. So I kind of wanted to maybe slightly clarify myself earlier. Sorry I interrupted you.

‍

SHEA

I think that's most of what I wanted to say. I think the really exciting thing here is not only can we address the existing risks that we see in the MEV supply chain, but I think once you have a fully trustless way to provide people with these key ingredients of privacy and commitments, you can build a whole class of interesting applications.

If today we have a couple of protocols that help mediate, say, the relationship between users and searchers, or the relationship between builders and validators, you can imagine those aren't the only classes of actors in the world who, for example, don't always trust each other but want to work together toward some common goal. And I think when you think about it that way, you kind of break it down into ingredients, the tools that SUAVE is providing, it's actually quite exciting to think about all of the things you could build on it. Whether that is something like CowSwap or existing MEV applications, or just like net new useful applications that we might not even have envisioned yet today. 

‍

KATHERINE

Any challenges ahead as flashbacks build out this product? And I ask this because, like I said earlier, it's been almost a year since the blog post that was titled The Future of a MEV is SUAVE was published, but what are some of the challenges that you have faced so far, like in building this out, and any further more ahead? 

‍

SHEA
Well, this is a pretty complicated thing to build, so it's generally just hard to execute on. In particular, there are a few broad challenges that I think we face as an industry and at Flashbots that are key to SUAVE as well.

One of these is - how do you actually provide the privacy that we're looking for? SUAVE, the way it works, is there are certain nodes which are allowed to run computations on private data, and these nodes need to have certain guarantees that prevents them from leaking that data unintentionally or maliciously. And there's a range of different ways that you could actually provide those guarantees, whether it's purely cryptographic, whether it's crypto economic, or maybe something like trusted hardware. And I think the challenge is to figure out how to choose the right set of tools to make these nodes, to make the privacy of SUAVE, effective. 

There's a lot more nuance here and a lot more smarter people in the privacy space than I am. But I think one thing we have found is that there’s not really a silver bullet. Each of the things I mentioned - cryptography, crypto economics, trusted hardware - have their own pros and cons, and I think it'll take a lot of research and a lot of engineering to actually get them to a place where we can combine them in a way that we actually feel like all of the pieces are covered and all of our guarantees are met. At Flashbots, where we're starting here with trusted hardware and we think it's the most tactically effective solution in the short term, but we're aware that there are a lot of drawbacks with it. So the question is how to add more defense in depth, how to patch those gaps. So privacy, how to provide it, I think is just a really hard problem. We're not the only team thinking about this, but that's definitely something that's on our mind. 

There's also other challenges with decentralized networks in general that we’ll face, as we are building one with one of these things. Kind of like I was mentioning earlier, as the network becomes more complicated, as you're centralized and you want more people to do things like run their own node or do self-custody, the UX actually tends to trend towards abstracting away from doing those things yourself. And so I think figuring out how to avoid getting into traps where, say, we have this decentralized network, but in between that network and the end user is the not so decentralized set of mediators - not dissimilar from kind of how the MEV supply chain looks today.

And so I think there will always be this tension and the need to figure out how to ensure that the entire journey from the user to their end destination is actually decentralized because if a very important part of it is not decentralized, then the overall system is at risk. 

‍

KATHERINE
Can I ask a maybe somewhat obvious question? So, with building with SUAVE, how much does it depend on essentially every single actor also building with SUAVE? Or do you think it's enough to just decentralize one part of that supply chain? 

‍

SHEA
It kind of depends a bit on the market structure, and it's probably okay for certain computations to be run in a centralized way if there are many alternatives. I don't think it's black or white or absolutely every application everywhere has to be decentralized. That seems a bit extreme. Yeah, but I think where it becomes a problem is where there's some sort of choke point. So there's a single or a few actors that provide a very critical role that almost all transactions have to go through. You really want to make sure that that role is decentralized. For example, I think the builder market is really a good example of this today. 

‍

KATHERINE

Anything that you are excited about looking ahead?

‍

SHEA

Many things, actually. First of all, I'm excited to address some of these existential risks that we see in the MEV supply chain. I think we actually have a path ahead to do that, which makes me quite hopeful. But I'm also quite excited because I think in designing SUAVE to address these problems and to provide the key ingredients that we need to build MEV applications to let all these actors in the supply chain collaborate with each other even though they don't trust each other, in building a system that provides those ingredients for MEV applications, we've also just created a system that provides these ingredients. It's kind of exciting to think about what you could build if you have a platform that provides the ability to do credible computations over private data. I don't think that's limited to the current MEV supply chain. There are probably other actors that will emerge in the context that use these ingredients, but there are also, I think, some very interesting and crazy ideas out there.

We typically think about auctions in the MEV context that would run on SUAVE. Well, there's also auctions in the world for things like, I don't know, Taylor Swift tickets or ads on Google. Google is getting sued because they were accused of sort of gaming their second price ad auction. And to run a trustworthy auction, you need privacy, you need a credible auctioneer, and actually, many of these things you could envision swap providing.

There's also other more general ways you could think about this. Any time you want to incentivize somebody else to take a very sophisticated action on your behalf and have certain commitments about exactly what they will do. Or any time you want to have multiple agents coordinate where they need to cooperate with each other and make short term commitments to achieve some goal, but maybe they don't know or trust each other in the general sense in the long term. Something like SUAVE actually is quite a nice fit for use cases like these. And these are just some shower thoughts at the moment, but I am kind of just excited to see what people come up with and what we can build on top of this platform.

‍

KATHERINE

We are talking about this like a very infrastructure or focused lens, but I like that you zoomed it out to something like in the real world too, so you've made me excited for it as well. Where can listeners go and find and follow your work? 

‍

SHEA

We post a lot of tutorials and information on our docs and we also have a writings website which I would recommend checking out.

‍

KATHERINE

Awesome. I know 40 minutes is not nearly enough to probably even scratch the surface of all of this, but thank you so much for coming on today and providing us such a great overview of everything. I mean, from MEV supply chain to SUAVE to everything else. Thank you so much. 

‍

SHEA

Thank you so much, Katherine.