Panel 2: The Orders Must Flow

Panelists
Robert Miller - Flashbots (𝕏: @bertcmiller)
Didier Le Floch - ConsenSys (𝕏: @Didier_Le_Floch)
Anton Bukov - 1inch (𝕏: @k06a)
Felix Leupold - CoWSwap and MEVBlocker (𝕏: @fleupold_)
Teo Leibowitz - Uniswap (𝕏: @teo_leibowitz)

Moderator
Stephane Gosselin (𝕏: @thegostep)

So we have the order flow panel now starting.

I don't want to share too much information or get people too excited.

So for this panel I think we have a really exciting set of individuals on here.

I think last time I wrote a dashboard that I Looked at a dashboard that said okay.

Where do all the transactions on aetherium look like you know there was about a Good chunk of it came from Uniswap another good chunk of it came from metamask and a good chunk of it came from cowswap And I think all encompassing including including 1 inch we covered about like 95% of all the transaction flow that hits Ethereum and so I'm really excited that today we have all of the culprits for For that that order flow here on the panel together and we can grill them a little bit So I'll hand out this mic everyone can grab a mic and then we can we can get started

So we have Robert, who is head of product over at Flashbots, Didier, who is working over at the Consensus, looking across all the different product suites that they have We have Anton from from 1 inch Felix from cowswap and mevlocker and tail from from uniswap So I sort of primed this by saying, you know these guys have a lot of the activity that ends up hitting Ethereum.

I think 1 of the questions that we've been asking and talking about regarding order flow over the course of the last year has been sort of ringing the drum or hitting the drum about the dangers of exclusive order flow.

And I think 1 of the things that I want to bring up and sort of have as a starting point for conversation is the fact that basically every single participant on this panel now has some kind of private order flow solution, where they're exclusively routing order flow to a subset of market participants, as opposed to routing it to the public transaction pool.

And I think a lot of this is often done under the guise of protecting the users.

So what I want to start with is the question of, how much of this is protecting the users versus creating some systemic risk to the ecosystem?

How do you make the decision of should you route privately or should it be routed publicly?

I will say I really want the entire group to be involved here.

I want to move sort of directly into Q&A questions.

And so I will let the conversation flow fluidly.

I'll only jump in and add additional conversation when it dies down.

So yeah, without further ado, how would you tackle that question?

I think, so you framed the question as how much of it is protecting the users versus creating systemic risk.

I think it is clear that there are reasons why you would route your transaction flow, your intent flow, or whatever form it takes to a private mempool.

Culprit number 1 here with Flashbots Protect.

You don't want to be front run in the public mempool.

Maybe you get an MEV kickback, something like this, or best execution.

And at the same time, I think the nuance is that we need to provide these solutions with a clear path to how we can make them more permissionless and not rely on any set of entrenched actors, like you're saying.

And I think if we can get to that place, the risk that is systemic becomes much less.

And that's why for all of Flashbots products, we try to make them permissionless for all market actors.

And I think that was a small other nuance as a part of the intro that you gave.

So users can choose where they send their order flow when they use Flashpots Protect, what builders you send to.

And any of the order flow that goes through our MevShare node is permissionless to search on for anyone in the world as well.

I think private mempools are going to come up.

And we still want to address that long-term systemic risk as well.

I think the systemic risk, more so than the private mempool, is actually the MEV-prone application design that we developed and use on-chain today.

And Uniswap is just 1 of the biggest examples here, where x times y equals k is a great mechanism for price discovery for long tail tokens, has a bunch of really, really cool advantages, but also comes with a drawback that it's substantially prone to front running and ordering attacks.

And basically, well, we think that the benefits outweigh the drawbacks, but these drawbacks need to be addressed on some level as well, right?

And so that's where the private mempool comes in.

It's not a solution that we see as the long-term way to handle MEV on Ethereum.

We think we need better DEX designs, we need better swap mechanisms that are not substantially prone to these type of attacks, but until we get there and until we can convince all the people, not just in this room, but in the community, that they shouldn't be using the private, the public mempool with kind of MEV flawed designs, We need easy to use, easy to understand, easy to adopt solutions.

And I think that's where MapBlocker, that's where also now with Uniswap X1 and Fusion, Cowswap, of course, comes in as an attempt to cover up some of the mechanism flaws that we've developed over the last years?

Yeah, I think there's a massive timing question in all of this.

The way you are protecting users Over the past year is not the way you're gonna protect user This coming year or even 3 years or 5 years from now So I think we you know, it's about being practical.

There's an end state that we all wish for But on the pass from here to this end state, there will be different iterations.

Today, actually, we can say the space, even the MEV supply chain space, is very early, right?

Like, there's so many innovations in all sorts of directions.

And I think as a wallet, for example, you would want to leverage all those innovations while being quite practical about it in the short term so that you get the best outcome for the user but we also work towards the end state.

I would say that it's very interesting how we saw that since arbitrage opportunities like really created in

we saw like a huge evolution of order flow and Initially, we thought that protocols should protect users traders from this MEV But from what we can see now, that it's not possible to be solved on protocol level.

I mean, there is no any way that all those DEXs protocols would include kind of protection from this.

We should wait until Ethereum or any other chain, layer 1 consensus will change and process mempool differently, protected somehow from front-runs, back-runs, and anything.

Or we also can see that evolution ended up that 3 major platforms like OneInch, Cowswap, Uniswap, they changed their mind recently.

They changed the order flow So all those platforms decided that it's not possible that every user will protect itself because users use different software, different wallets, different dApps, and It's so hard for them to protect themselves.

And it's much easier to put this order flow on professional fillers, as Uniswap call them, or resolvers, as 1inch call them, or solvers, as Calswap call them.

So it's much less participants like tens or hundreds of participants who are professional and can protect users from all these risks.

But I believe that we will probably see any kind of protection on consensus on layer 1 layer.

I'll just add to that that I think it's important to have a degree of perspective here as well.

Ultimately, all these systems are still non-custodial, all trade, settled on chain.

It's not that much that can really go wrong by hosting sort of order dissemination infrastructure off-chain.

Sure I think it's important to have a roadmap to a slightly more decentralized state but of all the mechanisms within the order stack to have slightly more centralized, I think, yeah, order dissemination is probably okay for now.

So I think a lot of the trends that we're seeing is pulling some of this execution logic from on-chain to being off-chain, relying on some counterparties to do this execution, do the validation, and sort of have like pre-inclusion guarantees.

The struggle there is that it involves some level of trust.

You need to have some relationship with these counterparties to make sure that they're operating in a way that's in line with your expectations.

And I think a lot of the questions that you guys are spending time on is how do we make sure that these counterparties are behaving in the way that we expect them to behave?

On the 1 hand, I want to hear from the room, when you hear about this design problem, what do you think are the key concerns in both having these aggregators of order flow be policing who the counter parties are allowed to participate in their game are?

Like what sort of comes to mind as some issues in designing systems in this way?

And then also for you guys, the question that I want to lead into is how do you go about identifying these counterparties and making sure that they're behaving within the parameters of your protocol.

So the first concern that comes to my mind because I'm a lawyer is that when you have those centralized or semi centralized intermediaries they look like intermediaries also under for example EU Mika and they may be classified as so for example service providers who provide reception transmission of orders or service providers that provide execution of orders, and there is a lot of requirements.

Basically, you have to become a financial institution almost to provide that, right?

And you may hope, oh yeah, I will do reverse solicitation to the EU.

So I think this is an underappreciated problem for going this way, right?

But of course there are concerns there that can be addressed and there are conversations with regulators that can be had successfully, I think, but for that you need answers to how do I benchmark best execution, for example, right?

If you want to compare yourself, I'm better than Tratfy or I'm safe, I'm trusted.

Okay, so best execution, and then the question is, so is best execution, can it be best execution on the Cowswap, best execution on OneInch, or best execution across all DeFi, or do you benchmark yourself against Binance, right?

So I don't think anyone has a legal answer to that, but these are the sort of questions that you will need answers for, and quite quickly.

The regulatory front and the concerns I introduced?

So, I mean, 1 question that this does bring up is the idea of like best execution and how do you guarantee that You know 1 way to constrain what the counterparties can do is to say you need to bet beat a certain threshold So what's the right way to sort of define actually?

What's the best execution that you need to be able to beat everyone has sort of this problem when they're initiating transactions?

I believe you new swap X would agree that Dutch auctions probably 1 of the key solutions to the best execution because it's like Every arbitrage traders competition would make it better for the user

Is that true Is that true even in highly volatile conditions or for long tail tokens?

Yeah I think it's all relative right but the important part is creating this competitive environment on an order-by-order order Basis, but I agree with the the member of the audience here, which is that defining best execution in crypto markets?

Is really this non-trivial problem, right?

Because you do have these synchronicity issues between blockchain-based markets and centralized exchanges.

Not everybody has access to the same flow.

The way that we sort of think about best execution in the context of Uniswap X, or execution that we're happy with is using a combination of Uniswap V2 and Uniswap V3 as a benchmark.

And we try and give swappers, users, some price improvement over that benchmark.

And then we guarantee that the lowest price that they're going to get, the ending price of the auction, will be the Uniswap V2, V3 aggregate price.

You talked about giving users the best value for their transactions on a one-to-one basis.

How do you deal with value that's not contained in a transaction but in aggregate?

So like 1, 000 transactions have value, but 1 doesn't.

That is solved by, I mean, it's 1 of the problems that OFAs are meant to be solving if you direct forwarder flow to them.

But obviously, it's early, and not everyone is able to capture that value.

But you can expect that that would be a natural evolution of the system to capture that quality value of transactions.

I mean, I think actually this is part of the answer to Stephane's question that sparked this discussion is, how do you ensure trust?

And I think the repetitive nature of your interactions as a protocol like Cowswap or MevBlocker or 1 Ensure Uniswap is that you have these repetitive interactions.

And for example, on MevBlocker, we can talk about how we build trust with the block builders that we route our traffic towards.

And it's by assuming good intent, monitoring them, observing them.

And then when they misbehave, they get cut off from the order flow and will have to pay a penalty to get relisted.

And the demand from builders that get cut off from that order flow is huge.

Like the value of the 5% of transaction volume that that MathBlocker is processing is very, very large.

And so that repetitive value, to me, can be used to assume or ensure some of the trust that we talked about.

At first, just from the cost perspective, want to just also talk about best price here, because I think we take quite a different approach to 1-inch Fusion and Uniswap X in that we don't want to upper bound the value of the best price that a user can get.

Basically, if there is a price swing block to block that goes beyond your Uniswap or your 1-inch fusion Dutch curve, we still want solvers to bid that price.

And there's no kind of limited upside for the user what the best price can be.

On the downside, what we enforce is what we call EBBO, Ethereum Best Bid and Offer.

It's similar to the NBBO on lit exchanges.

We basically look at the well-known baseline liquidity, accounting, Uniswap, Balancer, SushiSwap, which are probably also at curve at this stage.

But basically, what is the price that you would have been getting on the lit AMMs.

If a solver can improve prices by more than the curve dictates, then by all means, they should get priority to access your flow, and all that value should flow back to the user.

Are we like sort of shooting ourselves in the foot with this concept of EBBO, right?

Like on the previous panel, we talked about how LPs are just losing a ton of money to LVR and toxic flow.

And they always have sort of outdated prices, but then we're also benchmarking what good quality price execution is based off of all of these LPs and these pools.

So we're almost saying, okay, here market makers, you can come in and join the system and provide some liquidity.

The benchmark that you have to beat is all these uninformed traders are providing liquidity in this open market.

They're sending toxic flow towards already.

How does this make sure that the users have the best price if you're relying both on the market maker for setting the price and for improving it upon that set price.

It's actually the second line of defense that the user has when they trade on KaosWeb.

The first line of defense, which is always guaranteed, is the limit price that you put in your order.

Second line of defense is EBBO getting the best price that is visible on chain, which of course is maybe not the absolute best price that can be achieved, but looking at traditional finance, NBBO is also not the greatest price you can achieve.

Dark pools usually give you better price, and wholesalers can give you better price execution than what you can find on the lead exchanges, yet it is what defines price improvement, what defines kind of, if you do worse than that, then it's a pretty clear sign something is off.

And the real, the holy grail of what is the best price is the off-chain competition.

And basically, I'm sure there's like centralized aspects of it now, but at the end of the day, how I see this centralized or this decentralized competition is just a consensus for data availability.

What were the bids in the auction that were proposed by a certain point in time that was enough to be considered valid for the competition.

And if there's consensus around that, it's very clear which solver, in a way, had the right to execute.

And if they misbehaved, then, well, in KaoSup's case, there's a bond that can be slashed.

I think there's different protocols of different models on how to enforce that trust.

But to me, that is the unlimited upside for the user, best price.

Off-chain guarantee with some more layers of defense on-chain seems like, given the current status quo, a good solution.

But there is 1 thing which is really hard to compare.

Since more than 1 orders are being budgeted together with each other, it's hard to compare which of proposals of solvers is better.

For example, if we have 2 or 3 users' orders, which solver are going to fill in 1 transaction, we can't compare them directly because it's not 1 number, it's 3 number, it's 3 different prices which each of the user would get and I'm not sure if there is like any kind of truly sustainable and decentralized solution to find which offer is better like it could give better rate for 1 user or for other user and we can be sure that 1 of these users is not related to this solver also so it's it's hard problem

right I think I'm not an economist I sure economists was on the panel before but just in economic theory.

There's this concept of a equilibrium prices in like a perfect economy where demand and supply matches And what we are talking about in in cows up with multi-dimensional batch auctions We're looking at a barter economy And so the the holy grail of you know What a optimal solution would look like is is a competitive equilibrium or I think we're Rajan equilibrium how it's called sometimes as well the You know the The reality of the mechanism today is that we are trying to approximate this by maximizing surplus, which has the drawbacks that you mentioned.

And we're actively working on finding ways to approximate these equilibriums in more exact ways.

But yeah, I mean, that is an ongoing challenge.

So I think in general, I agree that all of the sort of metrics that we've talked about are flawed in some way.

And the best that we can do is try to have a maximally competitive market.

And I think what stance that we've taken, the approach that we've taken with Flashbots Protect, with MevShare, has been having permissionless execution against users flow.

So anyone in the world can go to mev-share.flashbots.net, go and look at the transactions that are coming through Flashpots Protect, see them, try to search behind them.

And we think that this permissionless kind of execution on users' transactions is going to maximize competition in the long run and give users the best price.

What we're really trying to build towards also, and what I think the holy grail here is, is having some sort of crypto and economic guarantee for any given trade that you can point to that says the user here got the absolute best price possible.

I think That kind of guarantee is what is going to make crypto stand out from traditional finance, and that kind of guarantee is, I think, how we win in the long term.

So you need to have a proof of best execution or a proof of best price?

On the proof of best execution, I feel like that isn't possible on chain insofar as the builder is the only position, the only 1 positioned in the supply chain to be able to provide that guarantee.

Because a lot of the problem of providing optimal execution is looking at incoming mempool transactions and accounting for the private flow on top of that, right?

And so if you're bound by the access to purely the mempool, which a lot of them aren't already, you can't even guarantee that.

So you could only give that guarantee after the execution is finished and you've seen all of the other transactions that have been included.

Yeah, but I think this assumes that there isn't some way to define a strategy that executes at the time of building a block also that has access to both mempool transactions and private transactions.

And I think if you get into a more expressive way of searching on transactions and building blocks like we're trying to do with Suave, then I think you can absolutely do that and take in all that information at block building time and provide kickbacks to the user with that.

But we're not there today, to your point.

What role does payment forwarder flow have to play on top of this?

It's something that there's rumors that it exists and people are paying forwarder flow and approaching people and making deals.

Is this something that we've seen in practice?

Is it a mechanism that should be enshrined?

Or is order by order basis really the only way to

I think it is something that's happening in practice.

I think all of us have heard either some rumors or some concrete instances of exclusive order flow deals that exist out there in the market.

I think what we should be aiming for in the broadest terms are the lowest barriers to entry with the maximum amount of competition possible.

I'm open-minded to whether that happens on an order-per-order basis or some other time frame.

I haven't seen super compelling models for how you have a longer time frame that keep barriers to entry as low as possible.

But if people have those kind of designs, then I'm open-minded.

Like, if you get a box or a subscription or an app subscription, you set up codes or whatever.

So are you already paying for order flow in that matter?

I think paying for high-quality access to mempool transactions is very different than going to a wallet and saying, hey, you're going to exclusively send to Nathan and only Nathan.

So should the user decide where your transactions go, or should it be down to the wallet, or the IFA, or somebody else?

You're going to have very sophisticated users who know exactly how to execute their transaction the best possible way.

We might want to make their decision themselves with their own user preferences.

And then you can have people who need a curated experience, something a little bit more abstracted, and where the wallet hopefully can help them make the best choices and direct the transaction in the best way to optimize outcomes.

Have we seen an experience where like the user really picks where the order flow goes yet

Were you picking your RPC endpoint is in a way?

I suppose people who use a movie blocker some of them have do it from a wallet, right?

Yeah, but I would actually say that we, with MFBlocker, follow a slightly different philosophy.

That we believe users should have complete control and offer a variety of different flavors of the endpoint.

There's a fully private endpoint where none of your flow gets shared.

And then there's the default endpoint, which shares back running opportunity without the signature.

But we believe that really the importance is to give users sensible defaults that are protecting them and that are secure.

And I think in that sense, I would say that's 1 of the design philosophies that MavBlocker differentiates from Fshare, for example, where I understand that it's really up to the user to fully specify their preference of builder selection, of information leakage, and all these things which we see in practice not happening.

And we think giving the user sensible defaults and then running with that has been working quite well.

And so I would love for every user to decide what they do with their order flow.

But the reality, we see it with Cowswap as well, the reality is, you know, wallets have the control and I think also the responsibility to act in the best interest of their users and give them sensible defaults.

I think 1 of the challenges with that is that we're still iterating towards what I think makes sense as sensible defaults.

And I think all of us agree that we should do that, but taking a data-driven approach and iterating towards that I think is what makes the most sense at this time.

And we might be a little bit more conservative with where we share our order flow, as an example.

But a user should be empowered to choose to send to our friends, the HFT builders, if they would like.

And I would love to see MapBlocker allow users that range of preferences on where they send their order flow right now.

Let me raise 1 more issue here that I'm not sure what would happen and how much is sustainable is this way.

But what if everyone will start using map blockers, flash bots for preventing front runs, back runs on their transactions.

It seems like problem will not disappear, problem will move to another slice, you know.

It's, I'm not sure, but there is a chance that these systems will start working on top of own mempools at some point in time.

Just imagine no 1 is using Ethereum mempool, everyone is using like private mempool.

I mean, it solves this problem for those who use it.

But if everyone is going to use it, we need another solution, I believe.

Well, then you sell access to the private mempool to the top bidders, right?

Sorry, can I follow up on the sensible defaults very quickly?

Surely that implies an opinion about what you think something sensible is.

Do sensible defaults open you up to regulatory risk?

You were asking for examples of sensible defaults?

Yeah, so if you're putting forward sensible defaults, you're having an opinion about what something sensible is.

you opening yourself up to regulatory risk?

Oh, I mean, I can't comment on the regulatory risk.

Did you want to have an example of a sensible default or that was just a comment on we should look into regulatory risks?

a sensible default would be no front-running.

Right, so we say you can't front-run on this endpoint, and that's like a sensible default.

So if all of a sudden you're saying, okay, no front-running on our default endpoint, and you do allow front-running on another endpoint, does that open you up to a problem from opening up to regulators?

I think the problem is sensible defaults, you need to educate them by data.

See all Frontier Research transcripts on Youtube

MEVday Paris: The Orders Must Flow