Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
MEV Space #5: Sandwiched in Time – Tracing MEV on EVM Chains
Recorded: April 16, 2025 Duration: 0:46:31Space Recording
Short Summary
In the latest episode of MEV Space, industry experts delve into the evolving landscape of crypto, focusing on trends in sandwich attacks, project innovations like Shutter Network, and the balance between transparency and security in decentralized finance.
Full Transcription
Thank you. Thank you. Good morning, everyone.
Good morning, guys. Good morning, hello.
How's it going?
Good, how are you?
Very good, very good.
Nice.
So you had to stay on the bed for a while, right?
What was that?
No, I mean, for Hugh Dobby.
Yeah, he kind of like just had a...
Yeah, I got a surgery, so I need to keep my leg up high above the heart, you know, and get some ice and stuff.
But otherwise, always fine. It's just, uh you know i need to remain in a weird like
position yeah i'm having having some kind of uh similar trouble so yeah all right um
so yeah let's get started um just give me a sec okay yeah
started. All right, so thank you guys for joining here. So welcome to the fifth episode
of MEV Space. My name is Brian, I'm the chief content officer of IgonFi. So MEV Space brings
together the sharpest minds in crypto to dissect the evolving landscape. So today we will discuss the savage evolution on VM chains.
So today we have a group of great speakers here to unwind the mystery of it.
And I'm also happy to have Ben from BTCS as our co-host.
First, let's do a round of self-introduction and the job you've been doing about sandwiches.
So how about we start from Luis?
Yeah, thanks, I'm Luis.
I work with BrainBot as the product manager
at Shutter Network.
And Shutter Network is a threshold encryption,
encryption as a service mechanism, I would say.
And we apply it sort of primarily
in the form of an encrypted mempool
to combat front running and real-time censorship.
I'm live on Gnosis Chain,
and we built it as an OP stack, test net,
and we also are making the case
for it to be implemented on Ethereum L1.
And we also offer sort of encryption as a service, more generally speaking,
for commit and reveal and time-lapse use cases via this new API,
which we call Shutter API, more on the application level there.
Very great. I appreciate it.
Now let's move on with Yixing.
Okay, hi everyone. I with Yixing. Okay, hi everyone.
I'm Yixing and currently I am a data scientist at Acon5.
And as you know, we run a dashboard to track the typical MEV traits, both from a big view and in detail. And part of my work is to look out for some interesting cases
like trades with really high volumes of big profits
or something that involves complex pools.
So when I find something unusual,
I just dig into it to see if there's a new strategy behind it,
so that we can share some insights with the community to keep everyone up to date on what's
evolving this space. Yeah, I'm glad to be here to share some insights with you.
Okay, thank you.
So next we have Hildabi.
So Hildabi, would you please introduce yourself?
Hello everyone, I'm Hildabi.
I'm head of data at venture capital firm Dragonfly.
And I've been working on data for several years,
even before Dragonfly using unit analytics, publishing a lot of dashboards
as well as hundreds of datasets on the platform, some of them being on MEV.
So I've singled out sandwiches across, I think, 15 chains, as well as Atomic Arbitrage.
as well as atomic arbitrage.
So yeah, I knew there was a lot of really cool explorers,
such as EigenPhi, but I wanted to have a more macro look,
as well as being able to dive into this data
and couple it with other datasets for hopefully deeper analysis.
Okay, cool.
So last but not least, we have our co-host Ben.
So Ben, would you like to introduce yourself?
Yeah, I'm Ben.
I'm the VP of engineering at BTCS.
Currently working on a block builder for BTCS,
but I've been in the MEV space for the last four years.
Basically just being an engineer building an MEV toolchain so I've worked with
searchers directly builders and the entire stack for MEV on Ethereum and also getting started on
MEV on BSC as well. Okay cool let me set the stage for for a sandwich so I'm gonna do a brief
introduction for audience here who are not familiar with sandwich attacks so a sandwich. So I'm going to do a brief introduction for audience here who are not familiar
with sandwich attacks. So a sandwich attack is a trading technique, a decentralized exchange.
So where a bot profits by placing two transactions around the user's pending trade. So usually it's
like it can be describing three steps. So first, the bot front runs by buying the asset before the user's trade
and causing the price to rise.
So then after the user's trade executes at its higher price,
the bot back runs by selling the asset, securing a profit.
So this manipulation exploits the transparent nature of blockchain transactions
and the mechanics of automatic market makers,
so leading to users receiving fewer tokens than expected.
So this kind of attacks actually can cause a lot of loss for victims.
Like during the last M.E.F. space, we discussed a user lost like hundreds of thousands of
dollars in five minutes in six sandwiches.
So my first question is actually for Hugh Dobby.
So like you said, you mentioned that you already compiled
with like the Dune dashboard,
like covering 15 EVM chains, right?
So what is the most impressive data or trend
that got your attention in terms of in the macro level?
So in terms of the macro, there's a couple of things.
I think the interesting part is looking at historical changes
through major shifts in data.
The two of them that I can think of is,
two years ago, Optimism had the Bedrock upgrade,
which essentially made EIP 1559 go live,
which is a better fee market.
And prior to then, transactions were practically free.
This caused a huge shift in sandwiches
because even though there was still a centralized sequencer
back then people were spamming transactions hoping for sandwich transactions or at least
that's my interpretation and essentially the upgrade kind of killed sandwich checks on on
that chain and we see something similar on on bunnyan Smart Chain just last month with the Goodwill Alliance.
And you can actually see the data where sandwich attacks were predictably eradicated for this month.
Okay. Yeah, I saw the data too, it's kind of like pretty impressive, right? So it's
like from 93% to like 15 or something. So that's a pretty good sign. I mean, yeah. Okay.
My next question is for Ishin. So as part of the IGNFAN team,
so we've been monitoring the sandwich from Ethereum since 2022. So could you please like
share with us some unique cases that you've been observed?
Sure. I think I will share some interesting sandwich categories from a more microscopic view that occurred on Ethereum and to show how sandwich attacks have changed over time. flashboards offered bundle protection. And at that time, it was kind of the unchartered territory
for these sandwich tradings
because miners had full control over the order of transactions
and the sandwich boards, other than these miners,
had to play guessing games with guest fees
to get their transactions in the right position
as expected.
In this condition
restrictions, so to speak,
some
sandwiches
were, most of the
sandwiches, I'd like to say, were very
simple. Just one user
in the middle because the risk and difficulty will rise up as the number of transactions they need to order.
But sometimes we found some interesting behavior or some cases strange because there was some case that one attacker's background got sandwiched
by another attacker, which means that sandwiched boards at this period, when just attacking
users, they were attacking each other also. So this is the first category that emerged before we have some protection opportunities to change the rule.
And the second category occurred mainly after the transaction when flashboards introduced bundle protection in the first quarter, I think in 2021.
And the bundle protection service is offered to users and upcharge bots
to give them a private way to send transactions to miners or builders.
And it was meant to reduce sandwich attacks on the main chain. I think from a technical view, the service or the bundle protection didn't block sandwich bundles,
and miners or builders had no incentives to reject these kind of bundles. At least from the
data we have observed, we found that the sandwich attacks actually became more creative instead
of just targeting one user. Some bundles started sandwiching dozens of victims at once because
they have bundle protection and the attack style became more diverse and aggressive.
Even LPs of providing liquidity to Uniswap or Balancer can become victims.
And this is a second category. And now we observe a new category with more advanced strategies.
I think a new category with more advanced strategies and majorly in two types.
Some attackers managed to use flash loans from Aave or Balancer to borrow large amounts of capital for just one trade,
which means they can scale up each individual attack without locking up their own funds.
I think it is really a need to pay attention to.
And on the other hand, maybe we all be familiar with Jared.
be familiar with Jared.
Bots like Jared, they can use smart
cost-saving designs to attack more users.
These users may not be victims
before, but when Jared
can save its own cost, these
users, even though they may have set the slippage protection,
they can also be sandwiched or they can be used by Jared to pump up the price for the next victim.
The strategies used by Jared is more sophisticated than other sandwich bots. And we can see that as the sandwich bots evolves,
it becomes harder to detect and to prevent from them.
So these are our recent observations in this space.
So that's interesting.
You're saying that Jared uses other mempool transactions
that have like correctly sets slippage about
to actually front run another user's
poorly set slippage transactions?
Yeah.
In a simple sandwich,
we can always find one front-run transaction.
But in Jerry's trades,
we can find that sometimes
he will split its front-run transaction
into two or three.
And in between these splitted front-run transactions,
there will be other victim transactions
that with the same token pair,
the same direction of swap.
And we have done some simulation to see if the victim can be sandwiched alone.
And we found that the victim has already set some slippage protection.
And maybe it's not profitable for Jared to just sandwich it itself,
but it can be used as some like pump up the price to help Jared to sandwich others.
That's really cool.
Cool.
Yeah, I think the meaning of this latest strategy
means that no trade is too small for Jared to exploit.
So everybody needs to pay attention
to this kind of stuff.
Yeah, the space is always so interesting.
It sucks how exploitive this nature is for sandwich bundles, but some of the creative ways that people find MEV opportunities is always so interesting to me.
how these more sophisticated sort of
maybe researchers are using, let's say, AI or
energetic stuff to
scale their activities or is that kind of just
an unknown black box? I think they
generally try to keep it as a black box, but I do know that the
I've heard from a few people from the Gerida Subway team is that
it's a pretty large group of developers.
At least that's the rumors in the MAV mill.
Yeah, I think that AI was on this stuff
might be a little bit too slow to, I guess,
characterize these transactions or these trades
to be able to quickly output a profitable path for those.
Yeah, but just maybe the long tail of stuff like that,
it's not really well for them to look at on some obscure chain or, yeah, but I'm just, yeah.
Yeah, one more data to add is like, we noticed that like about 83% of sandwiches actually
are done by Jerry.
So although most of them actually not with very pretty high profit, but still like this
very stunning number. Okay, my next question is for Luis.
So, Shardin Networks has been working on encrypted mempool for a while, right?
So recently you guys released a white paper and a research post on Ethereum Foundation's
forum.
So, if you return to the first principle, so do you think encrypted mempool is the best
way to solve signature attacks, or is there any other thing that can be done?
Yeah, good question. So there's many things you can do, right? And then
the most usual thing that is being done is, you know, private mempools, right?
And are on the case of L2 sort of trusting the,
the sequencer not to front run.
And that can solve it.
It kind of solve some of the,
some of the issues of the malicious part of MEV,
which is usually, you know,
front running is usually considered to be the malicious aspect of MEV, which is usually, front running is usually considered to be the malicious aspect of MEV.
But that isn't, in our view,
that isn't really the long term solution
because you are just transferring,
or you're just moving the trust assumption really
to that private mempool or the sequencer, right?
So whereas maybe like short-term you have solved in some ways, you are entrenching and
you are now centralizing this problem even more.
And in general, I think we have a huge problem with centralization in the PBS transaction
supply chain, also characterized by relays, builders.
There's all these sort of centralized, relatively centralized intermediaries
along the PBS transaction supply chain that I think
sort of a quick, quick, quick bandaid solutions like private mempools
are even more dangerous in the long term because they entrench centralized intermediaries.
So, so we think kind of a decentralized sort of
encrypted mempool is the best solution probably
because it's a first and foremost,
it just makes it so that no single party can see
what the initial transactions before the order
is sort of finalized
and before the inclusion of these transactions are included.
So neither the validator nor a relay nor a searcher
or anyone can see the transactions
until they are then finalized
and only afterwards can you see them.
And that's how, yeah, so that's kind of fundamentally
how we think, how it works, right?
And then it gets decrypted and then executed.
And we think that in general can sort of prevent
the front running and leave open the back running
to have MV cannot be prevented this way. So that is then kind of just left open to any way how the chain wants to deal with that MEV.
And just, I love this first principle to approach, right?
And like, why do we think it's the best solution or why from a bird's eye perspective kind of,
is in the real world, you have the same problem, right?
You have sort of front running
and you also have payment for auto flow
and you have this general MEV problem,
it's just called differently, right?
And you have brokers and you have intermediaries
between you and your transaction
and market makers and things
like this. But in the real world, actual front running is not a problem anymore. You can be
sure that your transaction will not get front run because it's illegal kind of, and because you are trusting the exchange operator,
especially to not front run you, right?
And the exchange operator,
if he wants to maintain a good sort of trading,
a good marketplace that is A, legal,
B, sort of just a healthy kind of efficient marketplace,
they just don't allow front running,
they don't front run themselves,
and they don't allow front running, right?
So kind of, I think the ideal place we want to get to is where you can trust the marketplace that there is no front running.
But then in blockchain, we can decentralize that trust assumption.
We don't have to trust centralized intermediary, not to front run you,
but rather with this kind of decentralized
special encryption approach
where you distribute the trust assumption
to a subset K out of N of these encryption nodes,
you hopefully end up with the same sort of level of trust
where you can trust that there's no front running,
but you're not relying on any single entity
to guarantee that kind of that's,
I would say that's the high level.
They want to go to that healthy marketplace
while keeping it decentralized.
That's really cool.
So how do you guys actually control the execution
of those transactions? Or how does encrypted web pools, how do you guys actually control the execution of those transactions?
How does encrypted web pools, how do they work with, I guess, contentious block space,
where the order of the transactions is important, but you don't know what the output of those
transactions are until they're finalized?
Yeah, so the simple answer is it encrypts it
and the order again is sort of committed to and finalized
and then it's executed.
So yeah, we don't know
and the validator doesn't know beforehand.
Yeah.
Okay, so the answer is that you don't know the order.
You don't know how to, like how to order those aside from maybe like priority fees or anything
that are maybe exposed.
Yeah.
So you won't know what it is.
Okay.
That's interesting.
Yeah.
So it, it obviously it disables some, maybe some positive aspects, right, of MEV or kind of,
some MEV things are, you know, positive and can kind of enhance user experience, right?
So maybe some of these are then taken away again from the user and we sort of go back to this
pre-PBS or pre-Flashbots world in some aspects.
But we think also that's a different layer, right?
So I think I would say that we need to get to
just a neutral kind of censorship resistant base layer, right?
And then those trading type of things
or UX enhancement like account abstractions,
abstraction, they can live on the layer above.
So a different way to think about it is, yeah, you could build a whole intense layer and
this whole sort of like transaction ordering, separate transaction ordering system on top.
But then in the end, you still have someone who wants to put his final sort of bundle
or partial block or full block
on chain and they also don't want to get front run by another bundler right so so we think at that
point again you will still need you will still want to have that kind of neutral base layer so
we think hopefully it can be combined hopefully you can have all these benefits of of more creative
traditional ordering and and what's generally I would say
just trading, right? Market making trading and intense solving and all those things can live
on the layer above and underneath I think it is desirable for everyone to have an as neutral as
kind of a base layer that is as neutral as possible and where you can be kind of sure that you, if you reveal information
to the chain, that you are benefiting from that information, and you can safely reveal
that information to the chain without having the fear that someone else benefits from that
information.
Yeah, that's really cool.
That actually leads really well into our next question for for everyone on the panel here
how should we balance transparency with security and mev and whoever wants to handle that first
i can i can give a quick just high level um. I think kind of information symmetry is the key just on a very high level. So transparency is important I think.
Privacy is important and transparency is important. We need both.
Sometimes we need privacy, sometimes we need transparency. And
the end goal should be to have information symmetry. And if you have information symmetry,
you can guarantee an equal marketplace. And sometimes you need to hide stuff and sometimes
you need to expose stuff. And in the end, obviously, ideally, things need to be transparent
from a transaction perspective,
not from an anonymity perspective, but yeah.
Hildabi, Gizin, any thoughts as well on transparency?
Sorry, go ahead.
Okay. I think it's a big question for me, and I cannot share opinions from the technical angle.
I just want to share some of my opinion from the angle of either a user or some researcher from the MEV space. I think
I think the goal of the blockchain or DeFi is more likely to be to to create a trustless or
to create a trustless or a more secure trading market.
And we introduced transparency as a method to achieve that in the current state.
So maybe transparency is not the goal of our design.
design. And we leverage the public mempool and the open ledger to make sure that everyone
can verify that builders and validators are playing by the rules. But the result is that
too much transparency also brings some challenges for us, and we are trying to tackle with the challenges right now.
And I like to break the trading process into three parts.
The first stage is the price discovery stage,
and then matching the intentions.
And last, we need to settlement.
And I think DeFi right now provides a solution,
or in DeFi we can process the needs in the matching and settlement stage
with an open and permissionless manner,
which is a major advantage over CIFI.
But during the price discovery stage,
where many AMEV boards are working in,
in this stage, right now, almost all market data is fully exposed,
and it makes the market or the price somewhat predictable
so that some bad actors can exploit the information to further exploit the users.
And I think this is a challenge we are discussing today.
And to solve these kinds of issues, right now we didn't have a solution that can fully protect the price discovery process in a trustless way. And we use some fixes like modular designs like PBS or some private mempools to mitigate
the issue.
But I think this cannot fully solve the problem.
cannot fully solve the problem.
And we also are discussing how to encrypt the mempool
to make the transaction fully private
until it was finally landed on chain.
But I'm not sure if this kind of solution
can also keep some kinds of MEV like backgrounding or upcharge
remain active in the process to make the price discovery more efficient. I'm not sure.
But I think the trade-off lies here. The real trade-off we need to balance is the problem,
how to improve the price discovery process in a trustless way.
And maybe we need to discuss and decide which part of the transaction information
must remain fully public or transparent, and which part might benefit from some kind of privacy
must remain fully public or transparent,
ensured by the cryptographic tools. This is all what I'm thinking about.
And yeah, I think Luis may have more opinion
on this kind of problem.
I think you put it very well.
And just to add to that, yeah, as you said, exactly,
not everything can be prevented,
and nor should you want to prevent all MEV, right?
In general, MEV is also just arbitrage.
Arbitrage is good for the price discovery, right?
So, yeah, I think you're very correct
with some of the aspects you want to use,
cryptography or other mechanisms to provide privacy
and then some others you don't
and it's all about timing when to do that.
And then I think long term, very long term,
I think there's this beautiful,
hopefully everything kind of works together, right?
This beautiful, I mean, just for blockchain privacy in general, right?
Hopefully there's this end state
where we can have full auditability,
full verifiability, full trustlessness,
all based on encrypted data, right?
And some crazy FHE powered indistinguishability
of authentication powered black box,
virtual black box machine, right?
Where all this works and it just prints out sort of proofs
that everything is correct and that everything is working beautifully.
But yeah, it's going to be a long way towards that.
For now, I think MEV is an inherent problem of decentralized systems.
problem of decentralized systems.
And so far, all attempts at trying to remedy that problem,
or at least mostly front-running,
have been around centralization in some shape or form.
And of course, those work as fixes for now,
but ideally we want to land on some system
that balances decentralization
as well as maybe less fraught running for the end users.
I think encryption does make sense
maybe for the mempool,
but that also has some implication for transactions that benefit from being seen in the mempool for the mempool but that also has some implication for transactions where
that benefit from being seen in the mempool that aren't you know MEV target transactions essentially
but I think it's a it's a really good research topic and trying to see how we could improve
the systems later down the line is something we would everyone would benefit
from um and yeah um i'm very curious to see where we go from here um and i'm also curious in seeing
you know how other blockchains because for now most of mev is on uh ethereum has been on
binance smart chain uh l2's due tos due to centralized sequences haven't seen it too much.
But eventually we'll see hopefully more decentralized sequences on those Layer 2s.
And the same problem with Arise.
So maybe this brings more people working on that same problem.
And we can find one, if not multiple solutions.
On that last point, I can also just recommend
to look into the Arbitrum Espresso work
that they've been doing on decentralized time boost.
So that is a decentralized sequence,
right, the Espresso decentralized sequence
and also uses a threshold encryption sort of approach
to mitigate front running.
I think it's a pretty interesting design architecture.
Okay, interesting.
I'll take a look.
And then our last question today,
I'm actually mixing it up a little bit
because we kind of answered this earlier
with Jared from Subway Strategy. So I hope i don't throw everyone through a loop here
but uh the main question i have is uh how hard is it to identify a uh trade or transactions
inside of a block as a sandwich attack versus some other type of maybe happening on the block
um hill dobby i feel like you have that with your dashboards that you're
monitoring this on those macro levels.
You probably are running into issues
maybe trying to know
if one's a back running
bundle or if it's just
an actual sandwich attack.
What's the challenge there?
How hard is it to identify those?
Dune, what I benefit from already is a table called Dex.Trades,
which is fairly popular and has all decentralized trades across many, many exchanges.
And since it's so widely used, it's also updated frequently to add latest Dexes.
So I'm using this as a foundation.
And then I'm looking for he heuristics. For sandwiches, I have two different tables that anyone can query or look into for multiple
chains. The first being the sandwich attack transactions. For those, I'm looking for, you know,
a back and forth matching transaction
with at least one victim in between
where the same pool was affected.
So I feel like those are fairly deterministic.
You don't accidentally trade on the same pool
in the same block back and forth
with a victim in between.
That seems like a very unlikely scenario for this to happen randomly.
So I've kind of assumed that all those are sandwiched attacks.
And then for sandwiched attacked transactions, those just happen to be, you know, those transactions that are placed in between and
are surrounded by at least one attacker. There's a lot of things that could be refined. One of the
main kind of problems is that I currently don't factor any kind of liquidity changes in pools. I only look at trades themselves.
So you could always enhance
and add more MEV transactions.
But I wanted to get that first set,
which is, I believe,
the majority of MEV activity out of the way
and maybe later down the line work again on it.
Or if someone else wants to improve it, anyone's welcome to contribute on Dune.
Yeah, one of the reasons I ask this is a lot of block builders in the space,
on Ethereum or even in other chains, at some point they all want to filter filter out harmful mv either front running or sandwich
attacks um and so they uh they they try to set up these like bundle heuristics to filter on the
incoming side before they include those bundles and chain and there's always there always ends
up being ways that searchers are able to work around those heuristics um so it's it's always
curious to me to see like where people are getting their data
and are there sandwich attacks that we're not seeing in these chains
or on these dashboards or these tools
because they're working around that kind of heuristic style.
Yeah, I think my data is probably undercounting a little bit
due to many complex strategies arising.
But the most efficient and well-known strategy tends to be single block, two trades, back and forth.
Like I said, the only major problem is the liquidity part, which can be used for you know jit attacks and stuff like
this um but uh i feel like it's it's a good step of the way and um i don't really see any ways to
go around uh around my heuristics or at least for uh if you're looking at trades themselves and not liquidity.
Oh, it makes sense.
All right.
I think that's it for the questions that we have on the schedule here.
We do have a few more minutes left on the time for this.
Does anyone in the audience maybe have questions
that want to ask the panels or anyone on the panel
anything you want to mention for final thoughts?
If anyone wants to look into this data, feel free to DM and ask any questions.
I'm happy to help.
It's all publicly accessible.
And the goal was for, you know, I'm not deep into the MEV space.
I hover around a lot of different analytics.
And the goal was for anyone to enhance the network
and hopefully bring more access to this data.
So yeah, please feel free to use for anything.
It's all out there for you guys.
Yeah, so for Hieu, Darby, do you have any plans
for further investigation into sandwiches in terms of data under Dune?
I have some slight fixes. I was talking to some FlashBots people about some small things I need to fix in my query heuristics.
my query heuristics.
But for now, I'm mostly working on other topics.
So I'm looking at surfacing all bridge transactions, central exchange activity on on-chain and
stuff like this.
There's so many sector analytics that MEV is one side of it, but I want to have all these, I guess, evergreen, important sectors surfaced in some way for anyone to look into and analyze.
And it's also important to mention that many of those kind of play a role with one another. other. So, you know, MEV by itself is super cool, but it can actually be enhanced by having other
datasets and deeper analysis can be brought in that way rather than just by enhancing the dataset
itself. So yeah, I'm just, a lot of my work is creating many, many tables on Dune and for me to
showcase in dashboards, but the goal is also for anyone to query
and do their analysis using those.
Yeah, that's really cool.
Yeah, okay.
So yeah, I guess it's time to wrap up.
I think we all have a lot of things can be done
regarding sandwich attacks.
And I think the future is kind of like still not very clear,
but it's definitely something that we're doing for the house of the ecosystem
and for everybody's future in this crypto space.
Okay. All right.
So that's it.
Thank you very much.
Thank you for all the speakers and listeners here.
And hopefully we can talk something
about some of these other types of MEVs
in our future MEV spaces.
Thank you guys.
Have a great day.
Thank you so much.
Thanks everyone.
Bye.
