MEV: Next Frontier of the DeFi Stack - Dan Elitzer, Scott Bigelow, et al.

all right well um thank you thank you tom uh for for this panel and we're now down to our our last panel of of the day moderated by by dan um i guess i'll stop sharing my screen so that we can see all your faces guys i was just showing the questions real quick then i'll let you uh i'll let you take the stage all right well thanks thanks for having us this has been an incredible day of talks and i feel like we're very very privileged to get to wrap this up uh and really focus on impacts for protocol developers and for users of those protocols so uh thanks i know the the schedule said we were having something from one to join us um and uh i don't think we are until we've got benji richards from uh future swap is added to the agenda and so welcome uh benji joseph scott and your own so uh actually just maybe you want to take the first shot at this um you know we've had a lot of quantitative approaches to mev today and trying to quantify how much mbv it is how bad it is from what you've seen interacting with the sushi swap community how much of a problem do you view mbbs today for the users and potentially for the development team as well so um i mean like uh basically everything every trade that's like five digits or more is um you know in in usd terms right it's like in the tens of thousands of dollars is getting sandwich attacked if your slippage bounds they're not tight enough or if there's like um a profitable sandwich attack there um do you guys notice that users are aware of this or is it just not like happening no i just talked to somebody just the other day who's like a large trader they're trading in um seven and eight figures and they said they they went back and like once somebody had showed them kind of like a site that would like highlight um mev um that had happened to them uh on the like just selected by their wallet um and they they said like every single trade i've made like this year has uh been hit with mev it's like damn yeah that's uh um but like i'd say quantity wise like if like like capital wise it's bad but i think quantity wise like most users aren't like trading in that range or they're trading in ranges that are just not profitable for for mev um if they're if like if we're not having like a gas crisis you know that makes sense um scott you you've had a pretty broad view across the ethereum ecosystem and you've been part of the flashbox community since the beginning does that sound similar to what you're seeing across other projects of like it's just a fact it's there people don't really think about it that much but it's just her present yeah i mean i think that slippage has started to become a instead of a an amount that you'd be willing to accept it's i think i've seen some users start to recognize that this is the amount that i will be accepting and if that isn't the case it's like you know it was your lucky day and so i i think that with this change um you know that there are some users who are are more aware of just how much that that they are leaking here and trying to set their own slippages tighter and work with work with protocols that maybe don't have slippage in them such as these rfqs and i think that there is been some awareness there but i think we could do a better job of of promoting this information especially from the wallet that makes sense um so while users are it seems like they're accepting it just because they have to uh from the protocol developer side and i'm curious how much is this coming up in in conversations within your teams or talking to developers on other teams is this something people are designing around or just it's there and we have to deal with it or if it's going to get solved it's going to get solved at the protocol out layer yeah it's kind of fun in this way because flashbox has both kind of created the crisis but then it also has the band-aid which is well just privately relay or transactions so it's it's a bit of like uh like two sides of the same coin here i do think that relying exclusively on on private relay is a little bit of a band-aid um to to to get us through i think what's going to be some real fundamental changes and protocols um and and ux that are going to i think ultimately mitigate this to a level that i think that users will find more acceptable but yeah so but mostly it's mostly it's projects that come around and say like hey we want a private we want a private relay because we actually haven't solved this problem so also sorry luciano's here just not on on video uh from from urine um uh luciano i'm curious within the the urine developer community as you're looking at different vault strategies and different pieces here how much does mev factor into discussions for for what you do and don't do or how you implement it yeah hey guys so yeah mav is actually a big part of uh what i developed for these days or this past past month i think so for strategies and for strategy sorry and for most uh like protocols that or forks that usually use the same kind of code base as as we do uh kind of the most critical part is the kind of the harvest method so whenever the strategy kind of claims the rewards and and also blindly swaps them so we usually uh have like uh like 100 percent sleepers tolerance tolerance on those methods so they're like extremely juicy and extremely uh poundable and sandwichable uh yeah by by whoever basically uh but the thing is uh we haven't been uh we haven't seen any attacks at least on wire until a month ago uh whenever uh this first happened uh and right right there so we were using kind of uh or we were using keeper uh keeper network jobs uh to do that so our keeper got sandwiched and we lost i think around 9k uh on a trade uh so we stopped all the jobs and we've been doing kind of this harvest uh manually through taiichi uh and we've been as well like developing a lot of contracts uh to kind of force or incentivize keepers that are like the boss running the the jobs to use either flash watch or uh private memo so it's kind of being uh a pain in the ass kind of to having to deal with uh but we already kind of knew that it was going to happen we're just like waiting and hoping to give to have a bit more days to be able to develop but also it helps us uh ruin like a more robust and kind of yeah a reliable solution so when you're using these relays at keeper networks is that just kind of like a standardized repeatable solution you can just apply across most situations or do you have to do a lot of tuning for specific implementations no yeah it actually is kind of a generic solution we come up with so we have a set of contracts called the kind of the stealth about and the stealth relayer that let's say uh they have a few checks uh both for only eoa transactions or accounts uh and for kind of a slashing mechanism uh that it will happen if the transaction gets either publicly available or there is like another issue or a collision with ebv so the keeper will get slashed and the protocol can at least get some refund out of it if the penalties is high enough but yeah the thing we we develop obviously is right now we are we're starting to test this uh i think that we deployed yesterday actually on yarn but then when it's like kind of battle tested at least for us we like anyone can can use this so we hope uh it helps a little bit on the ecosystem so this will be something that anybody in the ecosystem can just start using this once you guys have got it to a place where you feel good about it sorry i don't i don't think yeah sorry guys oh yeah so yeah obviously it has a little bit of gas cost for the user but let's say like for example for us the keepers running jobs on keeper and network usually kind of have an implicit cost uh for reverted transactions since they are always racing each other uh the first one that gets the job done is the one that gets paid all the other transactions if they don't get cancelled or even the if or even if they get cancelled uh incurring a cost uh of the cancellation of the council of transactions so by forcing them to use flashbacks uh we are actually making them save money uh so we can also lower the cost of the jobs uh that we work uh so this is kind of a good win-win situation for both of us that that does sound pretty good i mean so so that's it sounds like you guys have some good solutions there we've heard that it sounds like generally people are accepting this it's kind of like ever present thing are there any um features or things that any of you have looked at implementing and then discarded and just said like we can't do that because just the mev problems are too great uh not sure uh so our our problem is a pretty a pretty small one uh and it's pretty easy to tackle so we are not kind of our vulnerable method quote-unquote it's not like user facing so the the end users don't actually are not the ones that are kind of taking the slippage uh so it's easy for us kind of to mask or to move uh this uh yeah this vulnerable swap into more protected systems but in the case of alex or you know a cdp where you need it you need this to be like publicly available it gets more complicated and we didn't even like thought about a solution for for those kind of issues it seems like maybe a bit more relevant to like the sushi or or future swap projects because you guys do a lot of trading is was have there been anything you guys are trying to do where you're just like can't do it mev is going to be too much of a problem i mean yeah right like our harvest here for uh like we take all our fees and lps um and then we have to unwrap and harvest those and um we get with um our uh we have like um a service that helps us with vulnerabilities and about once a week we have like a vulnerability reporter it's like people can say how much in fact the you know when they press the harvest methods right it's like you know it's just like it's just something that we have to deal with or we either have to like privatize that and like put tighter bounds on it yeah i know like at future swap like we were looking for our v3 to use polygon and essentially the miners or i guess stakers can trigger block reorcs in certain situations so you would actually have like a two and a half minute window to go back and insert one of your transactions and that's definitely something where we had to scrap our plans and kind of go back to the drawing board and rework that and so you guys were going to launch on polygon didn't because of that what did what did you do what are you doing instead yeah so we're launching on arbitrom we've been chatting with the team and essentially their sequencer solves that problem it's a trusted entity where you're trusting arbitrom right now to run that um so it's essentially you're trusting them not to wreck their brand name sorry okay so i i don't know if everyone was um online earlier for for tom schmidt's talk about kind of protocol approaches um to to mbv uh or sorry i guess more application level approaches to maybe so one of the things that he mentioned was like ways to internalize some of that mev into the protocol itself uh is that something that any of you have explored um as a potential solution or if not are there other things you've looked at to kind of like turn this on its head rather than just being like we'll try to minimize it but it is what it is um for for us we have looked into that um the the issue that we come around with this is like to solve mev every single solution relies on asynchrony um and like we just have this lovely like synchronous composable network right now and an introduction of asynchrony is problematic for if you're an application that you want other people to compose with you so it's like where do you put the acronym do you put it like in the protocol level do you put it in pre-consensus like with flash bots do you put it at the um l1 because they're they're great solutions if if the assumption is is that what is fair is natural ordering right like first arrived first executed um there there are good solutions out there like threshold signatures etc um that work but it's just like um are we gonna remain synchronous i think is the real question and we're probably gonna have to give it up in e2 anyway anyone else have thoughts on that um some of the designs that i've heard floated around revolve around trying to get the number of participants that can extract this mev very very low sometimes even down to one one of the proposals was to have some sort of a token that has a supply of one that if you are the owner of this token you are the exclusive executor of any of these meb operations but you need to pay to hold on to this token and that payment can go to the uh can go to the project operators um usually via some sort of like a harbinger tax um yeah exactly yeah this this came from from austin williams oh then i think you right yeah yes yes so got it stuck yeah yeah it did um yeah so i i think that's probably one of the the the solutions that i think of the most when i when i try to like find a way to reduce that contention around uh um you know around who's competing and who's sharing so much profit with the miners cool um so when we we think about you know different places where you can potentially have solutions we talked about you know things you need to potentially the protocol level at the uh deep application level but how about at the at the dap level like this is one thing that i've thought about when i'm getting sandwiched on the daily um it's you know is this something that the wallet should handle for me or is this something that the kind of the web app should have some solution um an approach for this do you do you guys have any strong opinions on uh where some where some of this responsibility most easily sits i think the easiest one would be the application as joseph mentioned just having really tight bounds for example future swap we have an adjustable bound but like i think the limit is like or defaults to 0.1 which is relatively small 0.1 so applications can definitely do that but beyond that it would be amazing if wallets started doing that but pretty much any problem everyone's always like metamask should do this for the users and i'm sure the hands are very full good i was going to add that i mean one of the things that i've always felt that wallet should participate more in is like updating your slippage um you know as blocks progress i think that the ux around signing a transaction is so burdensome that people choose much larger slippage limits that are necessary because they don't know if a transaction is going to land in three or seven blocks where if your wallet and dap could like work together to keep your um your slippage really really tight based on the current situation as opposed to just firing once and hoping it lands in a couple blocks i think you could prevent that single block mev from growing especially when prices move um kind of in your favor that feels like significant complexity to add yeah yes yeah yeah i mean absolutely no yeah it's definitely not simple but just i think it's really sad that we you know i'm gonna ship this with two percent slippage because i don't know what's going to happen because i'm not a computer that can react but yeah um all right i have some thoughts around this is like for with with the ex mev is like do we think that that um mev is like a tax that we're willing to pay right like are our our um this all comes from just like pre-consensus right like this idea that i can't like validate you know that a message derived right this is all included in the um byzantine general's paper um i can't validate when a message arrived and so um like a lot of our network just relies on this pre-consensus like kind of like whisper and gossip like like al altruistic network um and like our our like public mempool is going to suffer pretty soon um if we start kind of like going down this road of of like okay well i don't want to get um you know i don't want to get robbed so i'm going to like uh be blackmailed more regularly right like it just doesn't make sense to me uh yeah it feels like we need some i mean i i i know that when i am doing certain trades that i know are likely to get sandwiched i just like flip over to tai chi and and and i'm asking that's like the easiest solution for me but it it feels dirty like why am i sending it just to one mining pool that doesn't feel like the decentralized future we were promised um well so one of the more extreme things that we talked about here and joseph you actually addressed this a little bit one of your earlier answers is the idea of uh where composability kind of gets becomes a trade-off here uh one thing that i've seen at least discussed more and i think we're starting to see in in outside of the earth theorem ecosystem a bit is the idea of application specific chains where you can have more uh i guess fine-tuned to trade-offs to your own application and potentially manage uh fair fair ordering in some way but the trade-off is you lose a lot of composability is that an approach that you think will become more common or necessary or what would it take for to take some you know that you're working with a protocol what would it take to get you to say okay yeah we need to go and do this just to create a better experience for our users uh i think it will become more common i think uh part of the reasoning is like um people in search of a solution um to mav but it's not really a good solution in my opinion to say that you're gonna do fair ordering it's like okay well i i hope right like you're gonna pinky promise each of your notes that you're gonna do their ordering of the transactions right that's what like optimism is saying they're saying oh we're going to do natural ordering of the transactions like okay like how long does that last right like uh i you can't in like when you move to these application specific chains you don't really have any control well you you can say that you're going to do it a specific way and you may or may not that's not what we rely on we um rely on like programmatic guarantees a little bit do we need to rely on programmatic guarantees or can we think more kind of like economic guarantees like i always go back to i'm sorry crypto economic guarantees yeah sure yeah yeah but even even some like softer ones right like thinking to like say like the auger uh security model aren't using rap as you're bonding rather than just bonding heath right you can cheat it but if you cheat it you're gonna like destroy the value and something that you've been holding it's it's more of a problem rather than using a completely separate platform asset as the thing that you're putting at stake so by moving it to a single obligation chain if you've got a native governance token and you're putting that at stake it kind of aligns interest more for you to play fair because if if you try to cheat there people are going to stop using the application and you cost yourself all of your future cash flows as well yeah yeah i mean i i just like there there are like threshold signatures so far to me seems like the best solution flashbacks are probably like the second best solution as like a patch but i definitely think that this solution has to come at the protocol level and i don't think like starting a new chain um for a specific like application is gonna alleviate that at all but there will they will be very popular no doubt because people think it's a pretty light undertaking but it definitely isn't you could almost consider that is like what duidx did with starkware yeah effectively yeah so uh i know benji that you know future swap when you guys did your your alpha launch um a while back uh one of the reasons that you you guys ended it early was realizing that there were some meaningful mev problems uh related to doing like oracles on l1 especially once you've added on a significant amount of leverage um can you share a little bit more about um what that what that looked like or and how you may have tried to address that in future versions yeah definitely so we launched future swap v1 like when mev really wasn't a common term this was like april 2020 and essentially what you saw was exactly what everyone now knows mev is front running and back running we had the front running handled of like at least the oracles but the back running was definitely a problem so we went back to the drawing board and no l2 was even close to ready this was last summer and a solution that we came up with was what if we have somewhat trusted entities these off-chain oracles that are in charge of sequencing the transactions so the user would actually sign the transaction and then it would get broadcasted to the we call it the oracle relayer network and then they would be in charge of putting it on and again like there's a whole complexity about how you trust them what are the repercussions if they're dishonest and how do you prove that which is a whole other can of worms but essentially in the last version future swap v2 traders would just sign a message and then their trade would be pretty much executed because we broadcasted to the off gene oracles they would sign it and then they would be with the ones putting it on it's chain kind of all all that went on chain through that through that network exactly and since they already have the price labeled off chain in that order it really didn't matter if you got in front of them or behind them when it mined on jane that's interesting um i didn't know that about your platform that that sounds very similar to how um a pre-consensus happens on flow the dapper labs blockchain they use a sequencer so you kind of like get block ordering from the jump um and then like and then they do like their um uh execution and block creation afterwards that's interesting you know i have to check it out it's we we now are going down the model of saying arbitrarily trusting that etsy is good enough for now i i know that they ed felton has a paper on actually how to prove sequencing i haven't dove into it that's much like that's way above my head but hopefully they actually implement that so it's not a trusted entity so is this is this like one of the more i guess practical solutions right now it sounds like going to a smaller number of people who can take actions or trusting some party in some capacity to be ordering is this the path that we're likely to go down over the next i don't know six to 12 months where we're just going to rely on some more trusted or centralized solutions like it sure looks like it is like everyone's ready to launch on arbetron and while you can it's still like they can only reorder and manipulate it that way they can't actually do anything fully dishonest uh it seems like that's the consensus everyone's perfectly fine with that anyone disagree or yeah yeah just a little bit i think uh like with the technology we have today we we can uh minimize mvb a lot uh so basically a similar thing uh like let's say okay yeah you can basically like just reduce slippage to like a minimum uh percentage amount as a user obviously because you can like off chain calculate uh the price you you're going to get uh doing this on chain obviously it's like way more expensive uh you only kind of have the risk of uh the price moving and having your transaction repaired so basically losing money or losing an opportunity you can obviously use as i said like flashbot flashbots bundles to kind of avoid your transaction getting reverted uh you can also kind of send your transaction through every layer that only executes the transaction on a certain block so you can actually kind of avoid having like the uncle bandit attack uh on your transaction if it gets included in a block uh but yeah but i think just by having users uh kind of opting into okay yeah i i want to pay like a little bit more but my like my transaction obviously having to sign a bunch of transactions until it gets included into the block this is kind of the bad ux you will have uh but it won't cost uh like as much as let's say whenever there is a bank run or or whatever like there are a bunch of failed transactions i think vitalik was the one that kind of had to use archer dao to it's kind of to drop all the the dog tokens uh like a few months back but i like let's say the regarded transaction costs for last month were like 150 ether so like around 330 000 just on reverted transactions that did nothing so let's say like hypothetically if you could send a transaction to the protocol and it cost the same as a regular transaction but you you send it with a flag that okay if this reverts don't include me that will be like a huge improvement on the portable because you can like just uh circumvent this cool feature that flashbot uh gives you but i think with only that obviously it kind of ruins a bit the user experience uh but i think those are kind of the 99 uh like cases where like where users like get a bad experience out of the network because of uh anyb so it sounds like is that is that like you're kind of like top like near-term wish to see an ecosystem for like improving the mbv situation would be better i guess uh especially transaction management from wallets uh is that what i'm hearing yeah yeah yeah exactly yeah this obviously can be done at application level so in the ui but the wallets are the one that uh i should implement this as a more general approach yeah i'm curious the rest of the panelists like what we've heard from the foremost experts in the world on the topic of mev today um they've proposed a lot of different paths for research different different solutions uh you're you've all got your hands full kind of working working on very specific projects right now um for the broader research community are there like asks or things that you would say like hey this is the thing that for our protocol for our users would make the the biggest difference for them like realistically over the next six to 12 months i mean flash spots that's what we're going that's the direction we're going to these private um mempools uh we have integration with archer dao i think that's already released maybe it's not maybe it'll be released this week but integration with archer dao y cabal um and a bunch of these other like uh mev bulls benji scott um yeah i mean i i mentioned earlier you know i'd love to see you know smarter wallets that are able to kind of take advantage of some of them you know either the private relay to protect users or you know cancellation when things don't work anymore i think you know to to um to the point that was brought up earlier about like how much is wasted on these inverted transactions you know we have we have the capability to do these things and and i think it would improve a lot of things improve negative externalities and how much money users are spending on these things and um yeah i i think i also want to make sure that when we talk about mev we don't try to overcorrect and reduce mavs so much that some protocols become unstable with the black monday thing from what a year ago there was a pretty massive problem that occurred i think because mev was reduced too much in that system and i think some meb is is a good thing and uh we shouldn't try to to drive it all out we should try to leverage it into a system that can react appropriately when necessary i mean what if we take this to a logical conclusion right like if you want the wallets to help manage this if we don't want to waste gas on failed transactions shouldn't wallets then by default just submit everything as a zero-way transaction through flashbots um like i mean what are the but the bigger consequences of that right like that solves that problem but it presumably creates some new ones yeah i mean i think it creates a lot of probably a little load on the system especially a system we're still trying to decentralize that the point made early about who do we trust you know flashbacks is a system that's also working towards this more decentralized um you know architecture uh i i i think that there is probably not that much negative aspect of it so long as the these back channels and private relays and um these executions can keep up with with that load i think that there's not i can't think of a lot of negative externalities to these transactions appearing directly in my blocks uh actually maybe gas wars right you're gonna get back to gas wars because people who want to take these mev are going to try to outbid each other on the next block as opposed to doing it in the current one that is i wonder if there could be some you know reverting to the old top of the block warring again right i guess the minor the miners will be happy about that sure yeah yeah benji any any wish list for you um yeah i wish that the wallets would natively like handle this for users because you're already getting in like using metamask is already complicated enough for the average person that's just using robinhood or something like that and then trying to explain to someone what mev is like there's zero chance it's actually going to happen and like there's the site and you can see like 750 million dollars or something in mev like if you look at it it's not like a linear graph it's like it's growing almost exponentially so like this year we could easily see it break two billion dollars and so the quicker we address this i think the easier it'll be on the end user right well uh we're we're about up on time here um so i want to thank you guys all for for joining and and participating in this and uh thank you to the the audience the organizers for having us well uh yeah thank you this will mark us exactly i would say well five minutes short of uh eight hours marathon uh on mev and uh and this panel has wrapped up our part four which is application level response to mev thank you for a great panel and it's very it's very rare for us actually here that some of the biggest developers um uh in d5 um sharing their expectations on uh uh uh on how future of the device stack is going to evolve so um we hope to discuss more of these with you guys to bridge the researchers and the builders together um so that we can get a much more coherent and coordinated view on what is ahead of us in tackling meb um yeah um so here we go our time is up and i would like to see you all on the next muv roast thank you everyone for joining