**A** (0:10):
Thank you so much. Yes, indeed, mev, very hot topic. So yeah, want to talk a little bit about exploring osmosis? Mev? I kind of came up with this slide last night because I normally have like a prepared pitch deck which is like Cosmos 101 exploring app chains. And I realized that that's probably not what this audience wants. Right. You know, I feel everyone here already already believes in Cosmos. So I was like, okay, what's an interesting topic to talk about? What's a relevant topic right now? And so, you know, I think mev, especially cross chain MEV is really growing as a, you know, a point of interest for a lot of people. So, you know, very relevant today. So want to talk a little bit about how MEV is growing in osmosis and how we are sort of planning on approaching it. So what is mev first of all? Right, so it stands for minor extractable value. Realistically, the term was created in a bygone era back in like, you know, Phil Dyen, he created the term back when like everything was proof of work. But really what it really is is proposer extractable values. Right. So you know, obviously in all these classroom chains we're all running proof of work, but you know, we're not using proof of, you know, we're not using proof of work. It's all proposer extractable value. What is this like proposer extractable value though, right? What I define MEV as is the ability. What sort of powers do proposers have that they can single handedly do to extract value? And there's actually a number of different things that they can do, right? You can do things like censoring other votes or you can do timestamp manipulation. But we're going to focus very specifically on transaction related mev, right? So what are the powers that a proposer has when they're creating a block and when it comes to transactions? And I think there's like three main ones that we have to consider. They have the ability to read the transactions from the mempool, they have the ability to choose which transactions come into the block, and they have the ability to choose what the order of the transactions in the block are and thus what the order that they execute in. And via these three powers, they can kind of achieve a lot of interesting, you know, extract a lot, do a lot of interesting value capture where you can do things like sandwich attacks, front running, generalized front running, which, you know, dark forest attacks, if you've heard that term before, which we'll get into in a bit but you can also do, and these are things I would classify as bad mev, right? Like, you know, this is very extractive of value from users. But I would say there's also like good MEV that exists, right? Like the ability to do liquidations, right? This is good for protocol health, right? You want liquidations to be happening or you have cross chain arbitrage happening. You want the arbitrage to be happening because, you know, that's how you get your Dex's prices in sync with external markets as well. So, you know, we have this interesting, like, you know, I guess I've been a very like MEV minimalist, but I've realized over time that there's actually, there are some types of bad. There's a lot of types of bad mev, but it's also good MEV that exists as well. And so what we should be doing, as you know, an ecosystem in general, is we should be trying to, one, minimize the bad mev, but two, internalize the good mev. And so I'll get into. So we're going to start with talking about how do we minimize bad mev? And then we'll talk about how do we internalize good mev? So what is bad mev? Sandwich attacks? Generalized front running? Censorship. You'll notice that a common trait around all of these types of bad MEV is the ability to read transactions from the mempool. And so if we can solve that, we kind of actually end up eliminating most of the bad types of bad mev. And so how do we do that? Well, before we get into that, walk through some examples of how front running works. So normal front running. What it is, is Alice will send her transaction to the block proposer. In this case it's sika, which is a very bad validator. Never delegate to them. They're evil, the validator. What they'll do is they'll add it to their mempool. And what they'll do is they can read all the transactions in the mempool and maybe Alice is doing a trade or something, right? So what CICR could do is they could insert their own transactions into the mempool and sort of put their transactions before Alice's. And basically what happens is you usually set a slippage bound when you're training on a Dex and what a malicious validator could do via sandwiches, that is make sure they take all the value from that trade. You also have these issues like generalized front running, which is also called a dark forest attack, because this blog post that Dan Robinson, Georgia wrote. But basically the idea is, imagine a toy example where there's a $5 that goes to the first person that can show a solution to a puzzle. You know, it's not really a puzzle, it's like some sort of arbitrage opportunity or something like that. But what happened is Alice, you know, you know, she spends a lot of time finding the result to the answer and she can broadcast her transaction. But the problem is that the validators could read the, whatever submission she, whatever solution she submitted, copy the exact solution and, and submit their own same exact transaction and they can make sure that their transaction gets in first. And so they get to, you know, whether do the liquidation or do the arbitrage opportunity or whatever it is and steal that value from Alice. So to solve this, both of these situations, there's a simple solution which is encrypted transactions. You want to make sure that the validators can't read from the mempool. And so what we actually do is we have a system where what we're going to do is all the transactions that are being submitted to the blockchain are encrypted. They get sent to the validators and then what happens is we need a way for us to come to. We create blocks of fully encrypted transactions. And only once a block is finalized and the inclusion in a block is finalized and the transaction ordering is finalized, then we, oh, sorry, animations don't work on this I guess. But that's when we decrypt the transactions and then execute them. So that way it's too late for anyone to front run it because we're creating blocks of. No one can read the transactions before the block is actually finalized. So there's actually a couple of ways of achieving this system. I guess there's three main ways that I'm aware of or there's a couple more. But the other ones have very far out cryptography needs. So the three current ways of doing this are trusted hardware, which is the SGX system, time lock encryption and threshold encryption. And so we spent a lot of time sort of evaluating these three systems. You know, when it comes to SGX Systems, I think SGXs are, you know, pretty cool. I think, you know, secret network is doing cool stuff, but like, I don't think it actually solves. It doesn't work for defi applications where, you know, every two or three years the SGX ends up getting broken. And if you really wanted to break the sgx, how much would it cost? You know, you, you could probably hire a team of like 10 top notch researchers, pay them like, you know, $20 million and you'll probably break the SGX in like six months. Right. And the thing is, MEV is worth way more than $20 billion on Ethereum right now. And so it's a economically rational thing to do to go break the sgx. And you know, today on SGX based systems, you know, MEV might not be worth that much, so it's not worth doing it. But once it gets to the point that it is it, people are going to end up breaking it. So the security budget of SGX based systems are just not that high. So we'd rather rely on cryptographic systems rather than these black box trusted hardware systems. So then we're left with basically time lock encryption and threshold encryption. And I'm not going to go too much in detail, but time lock encryption is quite cool as well. But the problem is that it has a lot of UX concerns. Basically all transactions get delayed. You have to, you make a transaction, then it gets executed a few minutes later, which is like maybe not that bad. But I think the UX that we've come to expect is you want transactions to be executed almost as soon as they're created. So we're left with threshold encryption. And how threshold encryption works is basically today in Tendermint we have this BFT system where 2/3 of validators have to submit transactions, submit votes on a block before it gets finalized. So how threshold encryption works is similar to threshold signatures. If people are familiar with that, where you have a quorum that says, hey, these set of people can sign a transaction, it's the same thing but with decrypting data. So what will happen is all users, they create transactions that are encrypted to this shared key that all the validators have. And then the proposer will create a block, the block has encrypted transactions in it, and then as part of their votes, validators will include their decryption shares. And as soon as you have and to make a valid vote on a block, you also have to have a valid decryption share. And so as soon as you have 2/3 valid votes on a block, you'll also have 2/3 decryption shares. And that means you can decrypt the data. And so as soon as a block is finalized, that's when you also have enough decryption shares that you can decrypt and execute the transactions in a block. Meaning that decryption is fully atomic with block production. And there's not this Weird delay that you get with things like time lock encryption or out of protocol systems. So yeah, this, you know, basically what we do is like, you know, by making sure that no one can read anything from the mempool, we get rid of things like sandwich attacks, generalized front running, all this kind of stuff, and we effectively, for the most part, I think, minimize bad mev. This bad MEV is really a privacy failure, right? When you make, when you want to make a transaction, you expect like, you know, you have some sort of privacy until time of execution. And today I feel like every single blockchain is basically leaking that information. So with threshold encryption we solve this problem. But what about the second part? Right? This is the. And you know, I feel like I've talked about the threshold encryption stuff a lot before, but I guess the new part today is this internalizing good mev. What does that mean? So, you know, Anatoly had this good tweet a couple of weeks ago where he said that really the full value, the value of L1 tokens is their ability to capture MEV and the value they can extract by doing that. And this tweet actually stuck with me for a little bit. I've been thinking about it for a while and then what I realized was it's like as an app developer, why are you leaking that value to an L1 token when instead that full product value could be captured as part of your. This is part of the pitch of app chains, I guess, which is like you should be capturing that value as part of your protocol and distributing that value to your app's token holders. Right? So how can we take that MEV that is inevitable, the good MEV in osmosis and give it to OSMO token holders. So there's a couple of ways of doing this. Right, so what are the types of good mev? We have things like liquidations on chain arbitrage opportunities and there's all sorts of things you can do. So let's start internalizing them. So step one, let's build an on chain liquidator. So I guess one thing to note is that there's quite a bit of MEV in osmosis today with just the trading, but it's going to get more and more over time, right? We are moving away from, we're moving from the AMM model towards order book systems, right? That's definitely a plan. You're going to see order books on osmosis within three months. And once we have that, we're going to have way more MEV opportunities or Once Mars launches on top of Osmosis, you're going to have a lot of liquidation opportunities. So the amount of MEV on osmosis is inevitably going to go up. So how do we deal with this? You can build things like on chain liquidators. So if anyone's familiar with Liquitee on Ethereum, they have this on chain stability pool that gets like first access priority to liquidations. And so they end up instead of things like maker and compound, they end up leaking a lot of value to the off chain liquidators and giving that value to them when instead that value can be internalized to the protocol. Because we have these cool app chains and stuff, you can actually have these liquidations happen automatically in the protocol. In the begin blocker, you can make a bunch of very easy checks and say, hey, we're going to check to see if these things can be liquidated and you can do them. And this is good for protocol health because you want to get rid of bad debt quickly. But also it's protocol revenue for the protocol, the full value of liquidation instead of giving it to whoever's triggering it, it can go all to stakers. For example, the same thing with the on chain protocol arbor. So when people in osmosis there's a lot of pools and you can route through different ways and what inevitably happens is pools become out of sync. And what's happening today is people are submitting arbitrages where they want to be the first one to sort of, you know, you can do these circular arbs where they can like, you know, trade on pool A, B and C and like you go through the same thing and you can get some profit from that. Well, what we could be doing is in the begin blocker of osmosis we should be running a basic arbitrage protocol. You know, the problem is that like solving these like arbitrage opportunities is actually like an NP hard problem. So you're not going to get all of the profit. But you know, even if we can get like 50%, 75% using some basic system basic tools, that should be protocol of revenue that could be going to all osmosis stakers. Right? So I think that's another source of protocol revenue in the long term. And then finally like you mentioned, there's things that you can be application specific that we understand, things like liquidations and on chain arbitrage. But, but there's things that we just won't understand. There's MEV opportunities that people are going to be discovering all the time. And so how do we capture the tail end of the. I think through things like on chain liquidators and on chain arbors we're going to get most of the MEV and internalize it into the protocol. But eventually there's this tail end of things that we might not be able to understand. And so how do we capture, internalize that? Basically so how is this done today is you have systems like flashbots, which are these off chain transaction prioritization systems. And what happens is searchers, people who are finding MEV opportunities, they submit these, what they call bundles, which are like sets of transactions to a centralized system, like flashbots. And what they do is they basically simulate the transactions and say like hey, if this you're basically bidding for the first slot in the block and what it's doing is there's really two auctions that are going on inside blockchain today for blocks where there's one auction which is you just want to be included in a block, let's say you're making a payment, you don't care where in the block it's happening. And then the other is people are competing to be like sort of the first spot in a block. They want to be the first one to pull off the liquidations or arbitrage opportunities. And you have these off chain systems like Flashbots which are exploiting this discrepancy and saying that hey, here's a centralized system where you can bid for the first lot in a block without messing up the auction for the rest of it. But what we realized is you can actually build all of this on chain so you can do these full on chain transaction prioritization systems in protocol. So what we can do with especially post threshold encryption, we can say that hey, transactions can make bids, they want to be the first to execute in a block, they want that first slot. And so what we're going to see is transactions are bidding to be like the pull off these arbitrage opportunities and and all the revenue from those bids can actually go to all stakers. With these off chain systems you have situations where all transactions are going through these very centralized mempools and the value is going to validators when really what we want is this to be internalized as protocol of revenue to all OSMO stakers. And by building these systems in chain rather than allow relying on these off chain centralized services, we can internalize that protocol revenue. And so we see that we actually have a rise of more of these off chain systems in Ethereum and stuff. They definitely have taken a big rise they're starting to show up in Cosmos as well. And my general take is that we should be trying to avoid them. I think functionally they are effectively validator cartels. If you look at things like threshold encryption, it's not safe against a 2/3 collusion of validators, right? So threshold encryption, it works by 2/3 of validators, sort of. You require 2/3 of validators to decrypt data before it's done, before the transactions are created. And I'm just slightly worried that these things are like, these systems like flashbots are like a foot in the door towards validator cartels. And what happens when these systems decide like, hey, it's revenue maximizing to bypass threshold encryption because it will increase revenue for these systems. So that's something we're a little bit worried about. It's something we've really started thinking about in the last few days. And let's like, what do we do about this? And this is kind of like a question just I want to kind of open the discussion up for people. You know, hopefully this will like raise, you know, interesting discussion throughout the rest of the day. But like what do we do about these validator cartel systems? I think there's different things, you know, different levels. You know, I think one is like, you know, just in the protocol we can do things to make sure that like they're not as effective. Build the on chain prioritization systems. The on chain in protocol prioritization systems will always sort of win out against the off chain ones. But like other things we can do otherwise. You know, Dev, for example, he's like, he wants to build like slashing conditions for like if people are caught using these like, you know, these off chain validated cartel systems, he wants to like start like slashing validators, you know, I'm just interested to hear from people of like what are ideas of what we can do about these validator cartel systems. So yeah, that's it. Thank you. Thank you.
**B** (21:20):
Sunny.
**A** (21:21):
We have one, we have time for one question.
**B** (21:29):
Thank you. Thank you Sunny for the great presentation. It will be hard for me to follow on with mine. I do have a question, actually. I think it's a great thing to think about. How do you create value for OSMO stakers and the participants of the OSMO ecosystem. But my fear, if you integrate the arbitrage directly in the protocol, maybe you won't be able to attract professional market makers that also provide liquidity in these kind of systems. So you kind of take away part of the revenue that they would generate. Obviously to protect the ecosystem. But at the same time maybe it's also a trade off to leave those professional arbitrageurs that come build the whole tech to connect to your system and then also provide liquidity, maybe LP and also just benefit and provide also value to the ecosystem. What do you think about this potential double edged sword?
**A** (22:34):
Yeah, for sure. You know, I think I feel like the MEV game has been one of the best like marketing systems and just like, you know, it actually has brought in a lot of talent. Like the number of people who I know who started with like MEV searchers and stuff and then ended up building like, you know, getting bored of that and started actually building interesting protocols instead and like doing, you know, real value add stuff has quite a few people have done that. So I think that's a valid point. But I do think that like, you know, when it comes to like market making and stuff, I think like the arbors are a pretty different class of users than market makers. Right. And so the people who I don't think like reducing arbor profit and internalizing that into the protocol will actually reduce the number of market makers necessarily. And also what ends up happening the way to, if you want to realize that, profit from those Arab opportunities by internalizing into the protocol, it brings that value to OSMO stakers. And this is kind of why incentive systems are so important and why we make sure that OSMO is majority distributed to LPs and market makers. So it kind of aligns those incentives in that way by making sure the market makers stuff. The best way for them to realize that the ARB opportunities and MEV profit from their market making activity is by owning osmo. Big applause for Sunny, please.