Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
MEV Space 8: Merits, Myths, and Milestones about Encrypted Mempools
Recorded: July 23, 2025 Duration: 0:47:18Space Recording
Short Summary
In the latest MEV Space episode, experts from Shutter Network and NetherMind discuss the future of encrypted mempools, emphasizing their role in enhancing transaction privacy and security on Ethereum. Key topics include the launch of new encryption solutions, ongoing partnerships, and the importance of community support for EIP proposals.
Full Transcription
Thank you. Gracias. y y y
y y y y
en el dolor y y eso
es y
por allá por el centro y con su risa grito en silencio
y All right guys let's wait for a few minutes for more people to join in. y el y y
y sí
para que la sí
sí y
y Okay, let's do it. Welcome to the eighth episode of MEV Space. My name is Brian. I'm the chief content officer of Eigenfine. So MEVSpace brings together the sharpest minds in crypto
to dissect the evolving MEV landscape.
Today we're going to discuss encryption amount pools.
So for years we've traded the public amount pools like an open air market.
It is great for transparency, but it is terrible for traders
because they're getting sandwiched and protocols are actually leaking alpha.
But in 2024 to 2025, it's kind of flipped the script.
So we see Shutter Network, Espresso,
I mean Commit, VDS, and even BuilderNet.
So this kind of solution is actually
high translation data until the other game is locked
while giving users privacy.
But some of them actually not that good.
We'll talk about that later.
So we have special guests from Shutter Network
and NetherMind to dive deep into this in-prepment booth
and debunk messages about such solutions.
So I'm gonna let our speakers do a round of self-introduction,
including our co-host.
So how about Luis, could you please start?
Thank you so much for having me.
Luis here from BrainBot Product Manager Brainbot for Shutter Network.
So I've been working in the protocol
and sort of infrastructure space since 2016 in Ethereum,
and now fully focused on Shutter Network.
And Shutter is essentially a special encryption
as a service mechanism.
So you can essentially protocols or other use cases,
for example, we also have non-MEV use cases,
non-encrypted mempho use cases,
which is to do with voting, for example,
and a snapshot which uses it for shielded voting.
So these sort of clients can sort of buy encryption,
decentralized encryption from Shutter,
encryption, decryption, and the nice property
that the special encryption approach has,
it is sort of unstoppable.
So it is guaranteed to decrypt
as long as the trust assumption holds.
And that makes it ideal for this use case
of encrypted mempool, which we've built out together
with Gnosis Chain for now for a POC essentially
to show that we can have an encrypted mempool
to prevent front running and malicious MEV
and real-time censorship and now really looking
to bring it to Ethereum L1.
Great.
Next we have Mark, who's a first time guest here.
So Mark, would you mind introducing yourself
and the single most like a concrete thing
you've been researching on CrimeMN tools.
Yeah, great to be here. Nice to meet you guys. So I'm Mark. I work at Nethermind on the Ethereum Core team.
I've been doing that for a couple of years, like working on various EIPs and kind of bits of implementation and research.
and kind of bits of implementation and research.
But I worked on the implementation of Shutter integration
with the NetherMind client, which is being used on Gnosis.
And I've also proposed a couple of EIPs
around encrypted memples.
Okay, cool.
So yeah, I just want to mention that we also, Okay, cool.
So yeah, I just want to mention that we also,
we should have AJ of the radius here,
but AJ had some accident this morning,
so he couldn't be here and we wish all the best on him.
So next thing we have Ben as our co-host.
Yeah, I'm Ben.
I'm the VP of engineering at BGCS.
I lead most of our developer operations at BTCS.
Very excited about Encrypted MinPools.
Hoping to be able to help out with the implementation of it on Ethereum L1.
I've been talking with Luis a lot about that lately.
Ideally, we'll have something cool to show with that in the coming months.
But yeah, very excited to talk more about encrypted mempools today
nice so yeah ben uh do you mind start a question yeah for sure um yeah so what would you guys say
is the biggest myth people are holding now about encrypted mempool solutions?
And why do you think that myth persists?
Let's start with Luis.
I think most people think that it prevents,
think that the claim is that it would prevent all MEV,
and then they rightfully say that it can't do that.
So we think in general, it can prevent front running,
it cannot prevent back running,
nor is it actually maybe desirable to prevent back running.
But yeah, we saw that with, it was a really good,
or generally it was good from A16Z,
there was this analysis of encrypted mempools
and some of the potential drawback.
But yeah, so the headline was really like that,
what I just said, right?
Even those researchers, analysts from ICCZ,
they sort of seem to have this misconception
that the way an encrypted mempool works
would be trying to prevent all MEV.
And then their conclusion is, well, it fails to do so.
And they say kind of the quote is,
it's not a silver bullet, which of course that's true,
right?
But that's because the goal isn't even that.
And it's clearly understood that the way it works,
it cannot prevent back running, yeah,
nor does it aim to do so.
I think that's probably one of the biggest.
MARK MIRCHANDANI- Mark, any other myths
about encrypted mempools
or anything that you want to clarify with the community about it?
Yeah, I think I agree with Lewis.
That's probably the biggest one.
I mean, I'd say one common kind of misconception
that I've heard people have is that it's like a privacy thing,
which it is in a way, but it's all about only
short-term encryption.
So as we kind of talked about, it can help with censorship resistance and front-running
protection, but the kind of encryption is just like a short-term privacy solution.
It's not giving you any kind of long-term privacy.
privacy.
Okay, so yeah, my next question is going to be a little bit spicy.
So yeah, I was just on the other like Twitter space like 30 minutes ago that was held by
Christian Kim talking about the incoming upgrade such as like a groom's turn. They're gonna like can try to implement an EPBS
into the incoming upgrades.
But why isn't like Ethereum foundation prioritizing
like a increment boost?
So because I've heard all kinds of rumors
about like how this like politics
kind of like impending the development of Ethereum.
So like Mark, could you please name one of the blockers politics kind of like impending the development of Ethereum.
So like Mark, could you please name one of the blockers
that you think is like stopping encryption being implemented in the L1?
Yeah, I think there is interest in encrypted mempools,
but it's just not really a priority like certainly in the
short term kind of scaling maybe fossil like lots of these other things are kind of the priority
but I have kind of been working on this and speaking with various people at the EF that are
also kind of looking into this problem and I've've proposed a CIP, which I'm hoping can potentially be in Glamsterdam,
which would kind of add support for or kind of help to support encrypted
mempools like Shutter.
And I kind of think that potentially a lot of this doesn't actually need to be
done by the Ethereum Foundation, like similar to how we have, you know, L2s,
where they're kind of somewhat maintained outside of the core protocol.
Like certainly for the short term,
I think we could make some small protocol changes on the L1
and then the majority of the sort of work would be done by, you know,
people like Shutter or whoever else is developing them.
So I think we're just not really at the point where it makes sense like people like Shutter or whoever else is developing them.
I think we're just not really at the point where it makes sense to put everything
into the whole protocol yet.
Like I don't think we've kind of solved the problems.
So Luis, what's your take on this?
Yeah, I would agree with Mark.
I think there's a number of reasons.
One being that misconception that we touched on before,
that is kind of misunderstood, right?
I think one other is, there is, I would say,
a little bit of a, people who are active in the MEV space
or who are knowledgeable about these things,
they might, some of them, some of these actors,
some of the actors in the PBS transactions to blockchain
who are then also like influential in those discussions
what should be implemented at the protocol level,
might also, there might also be really sort of like
an incentive not to be that interested in preventing AV
kind of on the higher level, right?
Although I think that's, again,
that touches on that misconception
where I think everyone sort of agrees
that front running will have to be going away.
So that's kind of like,
that's probably why some actors
and some people who are involved are,
again, might be even disincentivized,
but again, I think it's a misconception
because the front running will be going away anyway.
So that's one.
And then a little bit of sort of orientation complexity
that we have to get around.
And then also, I guess a big one is I think
because on the encryption, on the kind of cryptography side
or on the technology to encrypt side,
it does no, unfortunately there's
there's probably not a perfect solution right now, right?
So there, unfortunately there is no way essentially
to 100% reliably, trustlessly encrypt something.
Well, to encrypt, you need to encrypt with the key, right?
So unfortunately, it's not like in blockchain transfers
or something where you can say you just fully decentralize the validation of transactions.
Unless you have the more people validating transactions, the safer it is essentially.
With encryption, there is no, like someone needs to hold the keys, right? So depending on all the cryptography options that we have,
have some kind of trust assumption.
Either it is in the special encryption case,
it is sort of that there is at least a certain subset
of the decentralized network of committee nodes
that is honest and not colluding.
And then for something like TEs or VDE or VDFs,
it would be something like a hardware trust assumption,
right, where you need to trust the hardware,
which is something that's definitely, I think,
probably not really interesting to the lithium foundation
to enshrine at the protocol level.
So I think that it's a mixture of things,
but I think the good news is that all of these
are not kind of 100% blockers,
or more just like difficulties that are being overcome
as we speak.
And as Mark said,
there's definitely an interest as well. And you see like Vitalik in for example,
this one of his blog posts really mentioning
encrypted mempools as a solution to a lot of problems.
And especially if you go into this,
what Mark has called the holy trinity
for censorship resistance,
this kind of fossil EPBS and encryption mempool.
It really becomes apparent, I think, if you dig into this,
that it is a solution, right?
Flashpots did this really cool answer to the current
Glamsterdam EIP lineup and fossil and EPBS.
And one of the criticisms they have about EPBS
is that there is a free option,
that there's a free option problem, right?
And that essentially the builders can choose to,
if they see something that's going against them,
they can choose to not,
to include an empty block essentially.
Right, and then you have a lot of empty blocks
and that's one of the criticisms.
And that is sort of exactly, ideally something
that this concept of tertiary encryption can solve,
this type of free option problem.
And we think that if fossil EPUBFs and could remember
work in this Trinity, then that free option problem should be eliminated and that option should be not even be usable essentially.
barrier to entry for some features while we allow kind of short-sighted solutions that 98% of blocks
go through out of protocol. Like for instance, like PVS going through relays all out of protocol
for block building. I feel like that was kind of accelerated through while we require such like a
high, I guess, solved solution,
very thought out solution for some of the other features out here.
So it'd be nice to start with good enough instead of perfect
for some of these things.
But I think that's part of the accelerate mindset recently.
mindset recently.
So hopefully, we can move a little bit faster
So hopefully we can move a little bit faster
on some of these cool features.
on some of these cool features.
Let's definitely.
Oh, what's that?
So as I said, definitely, yeah.
Yep.
Cool, so we already talked about how
this doesn't really block MEV.
It may block some toxic MEV,
but what are some unexpected bonuses
from encrypted
mempools?
I think the major one, and that might even be the major one, is real-time censorship
resistance, right?
Where I think we have, on a higher level, I would say blockchains solve that transaction ordering problem on longer timescales.
And we have, and especially then censorship resistance,
right, on longer timescales.
So you can, even if,
you only need one validator who doesn't censor, right?
So then eventually you could get even the most contentious
kind of censored transaction tornado cache,
whatever transaction in, maybe it'll take, you know,
a year or something until that one validator
who doesn't censor gets it, but you will have like
eventual censor resistance.
So we solved that problem, but we really didn't solve it
on short timescales, right?
So then there's this really cool old blog post
from Vitalik, I think 2018,
or somewhere in between, around that time,
where he talks about this difference
and sort of like how sometimes,
something you could argue, well,
real-time censorship listens,
that doesn't matter that much,
you can just wait, right?
And it might be true for some people,
like criminals who just, they don't care
if it's going in like in an hour or two hours or whatever.
If they, right, if they just have like,
the source of it or the target is like
an illicit target or something, sure,
then maybe they don't, maybe just,
for them it's not even relevant,
the real timeness of it, it's just relevant
that they get it through at some point.
But Vitalik makes this really cool example
where he says, real time censorship can be really important.
Let's say you have a, you know, in trading basically, right?
And let's say you have an options contract,
I think he's, or futures adoption contract,
he's referring to where only once a certain price has hit,
can you exercise the option, right?
And maybe it's only hit for sort of seconds or minutes,
that target price.
In that case, real-time censorship
kind of can really make or break someone's profit.
If you then are sort of DOSed
or if your transaction has been censored in that instance,
you then lose the opportunity to use the trade,
to use the opportunity to exercise an option.
So that's I think one example of kind of
real-time censorship.
Another one was with this Sony L2.
And for L2s, that's kind of the most apparent
is the difference between real-time censorship
and long-term.
So L2s, you always have censorship resistance
because you can push through the transaction on L1, right? So eventually you always have censorship resistance because you can push through the transaction on L1.
So eventually you'll have censorship resistance,
but then the sequence that can just centralize,
so real time, kind of on shorter timescales,
the sequence that can just censor.
And that's what they did, right?
There was like malicious or in that case, in their view,
there was transactions on meme coins
that they didn't appreciate being on this kind of corporate L2 in that case, in their view, there was transactions on meme coins that they didn't appreciate being on this kind of corporate
L2 in that way, right?
So they were just like ignoring
or censoring those transactions.
And people lost a lot of money
because in this meme coin trading or in this world,
time matters a lot, right?
And people lost a lot of money.
You can push, eventually I think someone pushed through stuff
on the other one, but like to them, that didn't even matter
because in the time that lost all the opportunities
and lost all the money in those hours
that they were censored, right?
So I think real-time censorship resistance is the big one
sort of as a benefit.
And then I think, yeah, if you frame it differently,
again, I think it's, the other benefit is alleviating
problems with the other stuff, right?
As I touched on before, it was like,
if EPBS, current EPBS proposals come
with a free option problem,
then hopefully, touch- encryption can can solve it
mark anything dad um yeah no i Censorship resistance is definitely the main other thing.
I just want to highlight how it would interact with fossil,
because fossil is the main censorship resistance solution
which is being proposed.
Fossil does kind of provide
censorship resistance on its own,
but when used also in conjunction with encrypted mempools,
it can give you some extra benefits.
And I think there's kind of two different benefits there.
So the first one is that if you just use Fossil,
then essentially you can get the sensor resistance but without front running
so before you could go through some like private mempool and then you can actually you know avoid
getting front run just by trusting the builder but to get the benefits of fossil you actually
have to go through the public mempool so then you don't have any kind of front running protection
so if you use fossil with the encrypted mempools then you're going have any kind of front running protection so if you use fossil with the encrypted
mempools then you're going to actually get that front running protection as well using the
encrypted mempool and the other benefit i think is that fossil relies on 16 includers so these are 16
kind of people who are looking at the mempool for censored transactions and then kind of forcing
the builder to include them.
So normally they would just be looking and there would be a bunch of, you know, unencrypted transactions that they're going to put in this list.
But when used in conjunction with encrypted mempools, like now they would be potentially including just some encrypted cipher text.
So the difference there is, you know, if for whatever
reason the includer didn't want to
include your transaction,
now they don't actually know what it is, so
there's less of a reason for them not to
include it, and they could also have
plausible deniability if they were kind of
worried about getting in trouble for
including a certain transaction.
So yeah, just to summarize,
it just gives even more censorship resistance
than just phospholid zone.
Awesome.
So yeah, before I move on to the next question,
I just wanna open the ground to the audience.
So is there any questions that you guys wanna ask?
Any questions that you guys want to ask?
Please raise your hand.
Please raise your hand.
Okay, so yeah, I guess you guys can ask questions later.
So as long as we have time.
So yeah, my next question is like,
so critics is that encryption actually
as yet another moving part to an already like complex R1.
So why is that complexity worth it?
And where can we abstract away?
So Mark, would you mind start?
Yeah, so I think it depends
how you implement the encrypted mempool.
But generally kind of, as we were speaking about before,
I think a lot of it can actually be done outside of the main L1 protocol.
So in that case, it doesn't add too much complexity there.
In terms of complexity on the user side, I think all of this should just be abstracted away from them in their wallet.
So their wallet will handle the encryption or maybe a smart wallet kind of module
will handle the encryption
and the user won't have to think about it, ideally.
Okay, Luis.
So maybe that's two questions, right?
How can we sort it away and how, and why is it worth it?
So maybe let's, let me tackle the first one.
Other than that, how can we extract it away?
I think Mark gave a really good answer.
I just want to add that I think
the ideally we would have a generalized encrypted
mempool interface or generalized
kind of mempool encryption interface
where it doesn't matter which type of encryption method is used, right?
So that all the encryption stuff is, yeah,
is obstructed away, it doesn't have to bother,
burden the protocol itself, right?
So, and then people could build different
test-roll encryption type methods, people could build different traditional encryption type methods,
people could build verifiable delay types,
time lock encryption, encryption methods,
maybe in the future, you know,
homomorphic encryption or TEs.
Yeah, so I think that's one way to abstract it away.
And then why is it worth it?
Yeah, I think it's because of the censorship resistance.
I think that's kind of the main value.
Why would you have a public blockchain?
Is to me is about censorship resistance.
And that's why I think it's worth it.
If it levels up, if it levels up sensitive resistance just by a little bit,
that's the biggest value add kind of you could have as a chain.
And I think in the past, or if you just think about Ethereum as, you know,
maybe just serving kind of Western interests or something,
maybe just serving kind of Western interests or something,
or let's say in a smaller world,
then sense resistance might not even be that important.
But the more it becomes sort of global
and the more you'll have things like, you know,
strategic, national strategic reserves,
including Ethereum and like,
and having sort of countries that might be opposed to each other, might be enemies or, including Ethereum, and like, and having sort of countries that might
be opposed to each other, might be enemies, or, you know, big institutions that might
not trust each other, because it's really like a global level.
And there is even maybe not even legal recourse for them on this kind of supranational level.
I think the more it becomes really important to have sensitive and just simply speaking
sort of like China won't want to deploy
their national reserve on a network
that might be controlled by entities
that are only in the US or something like that.
So I think that that's why it needs to be really neutral,
right, and it needs to be sensitive to this thing.
Yeah, I think that's a good point to bring up
that we're not just the United States of Ethereum.
We need to be more globally minded with these things
and add to the censorship resistance.
So with all this added complexity, kind of infrastructure costs and latency, who foots
the bill and how do we ensure that validators don't lose revenue?
And do we incentivize any actors to be running this infrastructure?
Do you guys see this as like a validator duty or do you see this as like a out of protocol
goodwill actors in the space?
I think two answers depending on which,
how we would implement it, right?
So I think longer term, to me,
it is a, it should be just part of the fee, right?
You're paying for transaction ordering,
you're paying for transaction kind of validation,
but you're paying for,
but you're just paying for,
essentially you're paying for sales resistance, right?
And then, and for a trustworthy exchange
in the marketplace.
Right?
So that should just be sort of part of the fee.
And just like you don't think about
what everything is happening,
what all the validation steps or whatever consensus steps
that are happening in Ethereum,
just like that, you shouldn't also as a user care
about what transaction ordering
or encryption steps
are happening in between.
Yeah, so that to me that longer term is just sort of like,
yeah, just part of the fee, I would say.
And again, I think it provides value
because that's the value that Ethereum provides
is sensitive resistance and kind of a fair
and trustworthy marketplace.
And then shorter term, let's say, if we talk about this,
including the building the encrypted mempool
in such a way that it plugs into the already
existing PBS supply chain,
then I think there's the interesting point to make
that basically there is a little bit of an,
if it's not really forced upon people, right, if it's voluntary, then there is an intrinsic,
there might be an incentive for some people, or overall it might reduce the amount of MEV,
which then reduces short term, it reduces the income for validators or builders.
So on that global level,
it seems that it could be even sort of like,
it could be a disincentive if we build it
in this out of protocol PBS way.
But the interesting part there is
it might not be, right?
So it might also be, you might also just think about it
from the other perspective and say,
well, it'll be a new way, it'll be a new transaction type
that those builders or validators, depending on how you build it,
proposals can accept and can get paid for, right?
So, and then it just, people just need to pay for it.
And then as an individual entity, including transactions
from that perspective, it's just an additional flow
of transactions that you can process because you have
the capability to process encrypted transactions.
So on that level, yeah, the user will pay, right?
And then this might actually be even like attractive
to those individual transaction supply chain actors
that are then being able to process
this new transaction flow.
Mark, any thoughts on the kind of like the payment dynamics for this?
Yeah, so in terms of who pays for it, I think it would be the user.
Kind of just having some kind of small extra tip in order to use the encrypted mempool.
And I don't think that, well, I mean,
validators I think would generally have an incentive to run it
because they're going to get essentially additional order flows
or just more transactions paying tips that they can include
in their block and potentially some kind of rewards
from participating in the encrypted memple.
So this is the kind of extra tip, which could go to the validator as well.
Cool.
Oh, yeah, sorry.
There's also about the extra latency, I think you asked about,
which I also don't think is necessarily a big problem
so I think that normally in kind of most designs I've thought about there would be one extra slot
of latency so in the first slot you put your encrypted transaction on chain and then in the
second slot the unencrypted one would be included so i think
generally you know for if you're really worried about getting front run then this would be kind
of worth the wait um and you can also consider that sort of once even just once the first
slot's happened once the encrypted transaction is on chain then you actually still have a very
strong guarantee that will be included in the next slot. So you can kind of have some confidence that, yeah.
Nice.
This actually reminds me, I want to ask another question.
It's kind of along these lines.
If we do an out-of-protocol encrypted mempool first,
do you guys see any centralization risks on there
where order flow could land?
And what would be the, where would it centralize? If there's only a single entity providing
the encrypted mempool support or transaction encryption,
do you see that as a centralization risk or less so
if that and
more so just another feature of an OFA?
I'm not worried about that centralization risk, right?
Because, yeah, it's not like other centralization risk where it would sort of enshrine and
where it would sort of enshrine
and kind of provide extraordinary opportunities
to someone sort of like,
so I don't see that,
that's less about decentralization risk.
I think that's more about just the,
will it work well for the user or not, right?
So if there's very, very few validators
accepting transactions, it would mean,
or builders, depending on how you do it again,
then that increases the time that your transaction
election takes until it's processed.
takes until it's processed.
In terms of kind of centralization, I mean, if the concern is that it would just be the
same, everyone using the same encrypted memple, I don't think it's a problem as long as the
threshold set.
So that's the kind of group of parties who will kind of collectively own the key
and can collectively kind of when two-thirds of them to come together are able to decrypt the
transactions if that set is kind of sufficiently decentralized then I don't think the system is
centralized as a whole and also potentially you could have different encrypted memples emerge
so someone else could start a new one with a different threshold set
so if you prefer to use that then you can trust that threshold set
but I think it doesn't kind of make sense to bring that into the protocol at the moment
because really I think the only way
to actually accomplish this is using threshold encryption.
So if we're thinking about Ethereum L1,
I don't think it's possible to run threshold encryption
kind of with all of the validators at the moment.
So you kind of have the question of who would,
who would this threshold set be for L1?
Like how would you set it
up and i just think that the technology is not really there yet that we could do that
so it makes more sense to have you know different smaller kind of individual encrypted memples
with their own threshold set and then you just choose the one that you trust
Although there is that ability with the silent
intershoring encryption that you can sort of set up
the DKG with a really large set of nodes
and then later subsample and have subsets of this
to collaborate.
Right. So, so I think cryptographically,
there is a solution to that problem as well.
Yeah, I think that could be useful,
but potentially it's still might be difficult to pull on,
pull off on sort of L1 at the moment.
And I think there's like, you know,
trusted setup ceremonies and like various things that would make it difficult. yeah I mean that's kind of a way that say for instance
Shuttle or anyone else could have like a they had a really large threshold set then that can add a
lot of trust but of course you you always have to have this trust that two-thirds of the the current
threshold set aren't going to collude. That's kind of the fundamental trust assumption.
Yeah, that won't go away, but I think that even the setup,
I think that's what this called,
a silent threshold encryption means
you don't need a setup or something.
I don't know, it's like,
I think there's some pretty cool stuff to,
yeah, I think that will be possible at some point too, or not even like will be possible, some pretty cool stuff to, yeah.
I think that will be possible at some point too.
Or not even like, will be possible.
The cryptography for that works already,
just needs to be implemented.
Okay, my last question is like,
to make an incredible man-poser a reality on Ethereum,
so what concrete milestones,
a bit like testnet pilots or EIP drafts
or cross client standards,
what kind of milestones should be the community rally
around in the next 12 months?
So Luis, when you might start.
Definitely as the next milestone on our side,
the one that Ben has hinted on before.
So this, so the idea there is leveraging
builder and proposal commitments to implement
an encrypted mempool out of protocol
into the PBS transaction supply chain essentially.
And then we would leverage PrimeEv's MEV commit.
And we're currently building a POC for that
together with the PrimeV team, right?
So it'll essentially look like that Shutter
would be a sequence or provider in their system
and that it can, yeah, it can,
it will sort of encrypt transactions
and then try to offer them to the builders in the system
and receive first a builder commitment.
And then later hopefully we can extend it
to also receive proposal commitments
that your transaction will be included
and the builders and proposals would commit
to the inclusion of these.
That's it, and that would be a really cool milestone
to be able to say, hey, we can build an auto protocol
and then making also the case that
if we can build it out of protocol,
that's also a good case to build it in protocol
down the road.
So then the next milestone,
the next big milestone I would see really is this,
what we talked about before this,
how does Fossil, EPBS, and Accomptive Mempool
work together at the protocol level
to provide this really high level of sensitive resistance
and in front-running protection together.
So yeah, that's the longer term milestone.
And I think in terms of EIPs,
I think that we definitely need to coordinate a little more.
So definitely Mark has written some really cool EIPs.
We haven't done one yet.
So I think we should align these EIPs.
Ideally have sort of like maybe one or two big ones
that we could rally around, that we can present.
Yeah, so we're just not at that stage yet
to have an EIP ready,
but I think that'll also be something
that we should work on and coordinate around
and then kind of bring that into these cool lists,
the Glamis, whatever, or whatever the next one will be.
Yeah.
Nice.
Mark?
Yeah, so the main thing for me is this EIP, so it's EIP 7793.
And the aim of this is to kind of give better support for encrypted memples.
So it can kind of generally give like a much higher kind of bar or like reduce a lot the
kind of trust.
So to give context, at the moment in Shutter, the proposer is trusted.
So that means that when your transaction is decrypted,
then you're trusting the proposer is actually going to still not front run you.
And that's what Lursa is about with the kind of proposer commitments
as a solution to this.
This kind of goes some of the way
because now if the proposer kind of attempts to front run
so they like kind of reorder the transactions
and don't put them in the order that they should have,
and they can actually get slashed and lose some money.
But then with this EIP,
it goes to kind of an even higher level
of security where now whatever the proposer does it's actually impossible for them to reorder and
include your transactions um so otherwise you could always have the case that say the proposer
is going to get slashed i don't know a few thousand dollars for reordering the transactions
but they can see that from the MEV
they can actually make more money then they might just kind of rug everything and do it anyway
whereas with this it becomes actually impossible to execute those transactions if you're going to
reorder them. So yeah that's proposed for Glamsterdam and yeah if anyone's interested
then it'd be great to get more support or any more feedback on that EIP.
OK, EIP7793.
Yes, anybody interested, please go search it and check it out.
OK, so yeah, is there any more questions from the audience here?
So please raise your hand.
All right.
That's it.
Thank you guys for being here.
And very much thank you for Luis and Mark
for being our great speakers and sharing all their viewpoints
on Korean pools.
Hopefully, it will be implemented into the protocol
and let everybody
don't need to worry about the same chain. So okay, thank you guys. Thank you for being here.
Thanks so much. Thanks for being here.
