Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
WTF is an Encrypted Mempool?
Recorded: March 23, 2026 Duration: 0:40:36Space Recording
Full Transcription
Thank you. Thank you. Hmm. Thank you. Thank you for having us. Yeah, of course. So I'm going to wait waiting a few minutes for some more folks to triple in uh trickle in and uh if uh you guys
are able to please consider sharing the room Thank you. For those of you that just tuned in, thanks for joining.
I'm just waiting a couple more minutes.
Sucks that we can't replay the intro music.
But GMGM, welcome to this Monday morning, March 23rd.
I'm pretty excited about encrypted transactions on Ethereum.
I think this is an EAP that impacts most end users and we'll dive into it shortly. Thank you. All right, I guess we'll go ahead and get started.
Thank you everyone for joining. This is one of my first X spaces here.
So if you could like and share this space,
that would help out a lot.
And this should be recorded,
so it'll be available afterwards.
And I'll clean this up and put it into a podcast episode
for ETH Daily. That way you guys can tune into it.
And so this is Xspace about encrypted transactions. With us today we have
Luis Bezenberger from Shutter Network and we have Julian Ma from the Ethereum Foundation
Robust Incentives Group. So guys, welcome. We'll start with Luis,
can you give us a quick intro about yourself?
Awesome, man, thanks for having me.
I am Luis, I'm product manager
at this company called BrainBot,
which is kind of the developer,
the main developer behind Shutter Network.
And Shutter Network is a special encryption
as a service mechanism.
And we, I would say the primary focus
is definitely encrypted mempools
and serving kind of encryption decryption services
to encrypted mempools.
But we also apply it to,
well, we make it available via the shutter api
to any other use cases and maybe the most prominent one aside from recruitment pools is
voting so it's implemented into snapshot as the only kind of privacy option in in snapshot and
so um kind of protects and shields, downloads.
Awesome.
Several privacy initiatives that Shudder's working on.
Julian, thank you for coming on.
I believe the Robust Incentives Group is a newer team at the EF.
So if you could tell us a little bit about yourself
and the team from the Ethereum Foundation.
Yeah, thanks for having me.
So I'm Julian.
I'm a researcher at the Ethereum Foundation.
I joined about four years ago already, so that's quite long.
And that's also when I joined the robust consensus group.
So it's not a very new team.
We do mostly economics, and my role was always market design.
So I worked on the transaction fee market, the builder market,
and recently won the prover market.
And then last year I switched more to doing a product type of focus work with the platform team,
which is a very new team, so maybe that's what you had in mind.
And that's also where my interest from encrypted mempools comes.
So I've worked previously on PBS, which I think is how Ethereum's market structure was defined. And now recently taking a more public focus stance on what market structure there should be
to ensure that DeFi flourishes as well as it can on Ethereum,
I think we came to the conclusion that we need encrypted mumbles.
Awesome. And then both you guys and Shudder kind of joined forces recently on this initiative. So let's start with
the very beginning. Maybe we'll run through this. Either Luis or Julian, how does the transaction
order pipeline work today on the public mempool? Say user sends a transaction. Can you walk us
through kind of who are the different parties involved and how that
pipeline works? Yeah, I'm happy to take this one. So for users sending a transaction to the public
mempool, what they do is they sign a transaction from their wallets and the wallet decides where
to route it. Most wallets today route transactions to private mempools, but I guess
there could be exceptional circumstances in which they are routed to the public mempool immediately,
or later on the wallet decides to route it to the public mempool. So what happens is first of all
there's a wallet making a decision of where to route it, and the user can have some agency on
that decision potentially. Then if the transaction runs into the public mempool,
what it effectively means is that it goes to one Ethereum node,
which is running the consensus and execution layer clients.
That node checks whether the transaction is valid and everything,
and then forwards it to other nodes.
And eventually it should reach one node,
which is the leader for a slot, who builds the build.
That's basically all that happens in the public mempool.
Awesome. And so since it's the public mempool, everything is visible.
So that's, you know, anybody can see anybody's transactions. That's where MVV bots get their strategies
or arbitrages from.
And now
we have private
order flow. So how does
private
order flow work
and how's that compared to the public
mempool?
Maybe I can continue from there um so i think the the
depending on which for example you use but essentially the the idea is you find uh let's
say a builder that um they had that where you know that they have that they will be able to
build a block at some point and if you have if you have some way of sending the transaction directly to the
to the builder and get some kind of promises from from them to let's say not um
not front run you right uh so you have to trust a certain intermediary along the way there or
someone to to not not to front run you basically.
But if you can do that, then you're limiting essentially, you can send it directly and the builder can pick it up and build it in.
And that way you're circumventing, you're not going to the public mempool.
So you're not exposing your transaction and intent to everyone.
So not everyone can see can see it and so it's it's that
you're limiting the amount of people who can confront run it basically essentially from let's
say everyone to maybe just one or two people and then if you have some sort of trusted relationship
with this with these people or if they have an economic interest maybe not to not to exploit you then uh i think that's that's
a good sort of like that's a it's a good quick fix i would say for everyone who wants to trade
because yeah you're you're going to not get front run
got it so uh you limit the number of of of uh i, who can see your transaction.
But there is that trust assumption.
And I believe that's maybe one reason why you're proposing encrypted mempoles.
But private order flow has been around for several years now.
What have been some of the issues with them or challenges
with using something like a Flash
or using
an out-of-protocol
solution for MVV like the
CalProtect RPC?
What are some
of the challenges with those that
have led you guys to want
to bring an encrypted mempool
i think those trust assumptions kind of at the core i would say right so you're you are creating
kind of pockets of exclusive order flow and you have to trust certain intermediaries um and that
is yeah again like introducing a trust assumption where, which can work well
if you do trust this intermediary,
but there's no guarantee on that.
And they could be, they could not at some point
sort of betray your trust, right?
I think the other reason is that you kind of censorship, right?
So if you have just one or two people that you are trusting there,
it increases censorship a little bit.
And with that also, I would say centralization,
an MEV is a centralizing force in itself, right?
The more autoflow goes to one single builder
or intermediary, the more powerful they become,
the more money they make, the more,
and that's just an entrenching force in itself, right?
So MEV I'd say is an entrenching force itself.
So ideally we could decentralize and reduce
the trust assumptions.
And maybe one simple reason also is just fragmentation, right? So like if right now you have a bunch of these private mempools and a bunch of different routes to bring your transaction in in this way.
But it means you're not even sure anymore what's the best place.
And there's like 15 or even maybe a lot more actually routes to choose from and it's
just a little bit annoying because in the past we had this public mempool which at least for a window
in time worked pretty well so I think one one case would be let's try to bring back the the public
mempool and reduce fragmentation decentralized those stress assumptions
while having this level of privacy i'd say right that you can get with private mempools
so that's where i think these these ideas come from how can we get get the same level of privacy
via encryption right it's ideally kind of like self-encryption you encrypt yourself or via
ideally kind of like self-encryption,
you encrypt yourself or via some form of decentralized
encryption method like threshold encryption
or other methods.
But essentially you don't want to trust a single person
and you want to ideally enshrine it at the protocol level
such that you reduce the fragmentation.
Yeah, that'll be an interesting talk point to get into is
everything has turned into kind of relationships
between different parties. And it looks like
encrypted mempools, I like how you put it, bring back the public mempool
so it'll be the public encrypted mempool or maybe not.
Well, let's break down encrypted memple.
What exactly is an encrypted memple,
and how does it differ from the public memple?
I think encrypted memple, the idea is, in principle, very basic.
As in, it's public, which means that all nodes have access to
it and there isn't anyone gatekeeping it. And it's encrypted in the form that instead
of submitting your transactions in plain text, so instead of saying that, for example,
you'd like to trade one ETH for a certain amount of UTC on this Unithub pool with all
the specifics filled in there, you're committing to some encrypted ciphertext,
which will then be included in the block.
And only when the order is determined of your transaction in some block,
you release either the description key or the plaintext version of your transaction,
which will then be included.
So I guess the main parts are that it's public, all nodes have access to it,
it's encrypted before commitment. So before it's known in which order your transaction is included,
no one knows exactly what the transaction contains, and then later there's a reveal phase
where you reveal what exactly your transaction does.
So since it's a public mempool, does this mean it brings privacy by default for everybody transacting on Ethereum?
To an extent, yes. As in, it gives everyone the option to use private mempools.
And this is actually what I think we should be pushing for.
The default is that everyone uses encrypted mempools
and everyone has some pre-trade privacy for their transactions.
But the important thing is that we're not taking away any options.
So if people do want to use either sending it in plain text
or using private mempools because they want to use some builder services,
that's still possible as well.
Got it. So in terms of implementation of the encrypted mempool, does it come down to
kind of like wallet providers supporting encrypted mempools in order for the end user to send an encrypted mempool transaction?
Yeah, you would need kind of,
if you want to enshrine it,
you'd need the protocol change, right?
But you would also need, let's say,
the wallet to a certain degree to support this as well.
So yeah, and ideally the wallet would, I mean,
the default can probably think that the wallet
makes these choices, right?
And we don't want the user to overburden the user
with this choice of like, should they
use a private mempool or a public mempool or encrypted mempool?
So my best guess would be if we can enshrine it
in the protocol and make it, as Julian said,
make it a feature of the protocol that we
can then get a really strong pull on the wallets we'd say okay if it's part of protocol we might
might as well just offer it to our users as an additional feature for for their wallets
and then i think there's a good chance for it to be one of the better places to trade and getting good prices for certain subset of transactions.
So I would hope that it becomes also a de facto default, at least for some subset of transactions that makes sense.
Just to add on to there, I think adoption, I'm not going to lie, I think it will be hard in the beginning,
just because there's a lot of inertia and people are used to the way that they're interacting today.
I think importantly though, to me, encrypted mempools is not necessarily about removing the trust assumption between a user and a builder today.
And this might sound controversial, but I think that works fairly well for today's users.
And it's similar to how we have one-event trust assumptions throughout the protocol.
So, for example, you need to trust that there's an RPC provider willing to give you the correct state information to even craft your transaction,
and in the end someone needs to include your transaction as well.
Why I'm such a proponent of encrypted mempools is not so much about removing this particular trust assumption,
it's more about looking forward, and I think we are actually losing out on more adoption because we don't have encrypted
mempools.
If you're a retail bank thinking about adopting a decentralized exchange instead of a centralized
one, there are just so many points now where Ethereum fails and I think we could do so
much better.
And one of these is the transaction supply chain.
So if you're a retail banker, you're not going to send your users' transactions to
the public mempool because they'll get sandwiched.
So you think about sending them to a private one, in which case you're going to need to
do due diligence on your counterparty and you need to ensure that they are in compliance
with your local jurisdictions.
Builders maybe are, but the compliance barrier could be quite high.
And I think it would be a lot easier if there were an alternate option.
And you could imagine a retail bank saying to their wallet provider,
we're fine with using encrypted mempool because it just saves us a lot of compliance work.
And secondly, to me, it's definitely about the developer experience.
So today, if you're building a DeFi app,
you need to take into account the whole Solver networks and builders and how the transaction supply chain works.
This is all today's building blocks. And I think encrypted mempools are the building blocks of the future.
So if we wanted to build DeFi that's future compatible for Ethereum, we should give building blocks of the future already and ensure that DeFi evolves with Ethereum as we do as well.
already and ensure that DeFi evolves with Ethereum as we do as well.
Yeah, I agree 100%. So what types of, you mentioned providing a better experience for
not just users but also institutions, so what type of MEV does an encrypted mempool protect users against?
Primarily just the front running, right?
And just that part where someone jumps in front of you
or sensors your transaction based on the contents.
So if the builder, right? So if they can't see what the,
the builder for example can't see what's in the transaction,
it's also really hard for them to censor.
So these two, I would say,
types of it, it prevents,
where it doesn't, it can't really,
or it doesn't prevent backgrounding.
So at some point still,
the transactions will be available,
which means someone will have the,
someone will see these transactions
and they will be able to put,
have the kind of the mandate to have the execution slot
after that basically,
and they will be able to exploit all our,
to utilize all our, to utilize all the,
exploit all the arbitrage opportunities for back running.
So roughly speaking, front running, not possible anymore.
And back running still possible.
And then there's nuances on the back running as well.
What type of back running?
And roughly speaking, people would say that,
that's roughly is sort of like
the split of front running is the the mv that people don't like the background is the mv that
people are either either okay with or even benefit from if there is a rebate right a refund going from
wherever gets that backgrounding profit and pays it back to the user. So that can actually be a positive form of an EV as well.
Great.
And this is encrypted mempools is a proposed feature upgrade for Ethereum,
potentially in the I-Star upgrade.
But this is a protocol level solution.
Can you explain what that means and what are the benefits of that over out of protocol solutions?
Yeah, so we've been proposing as well as an out of protocol solution for the the auto protocol PBS supply chain, which would work to a certain degree.
But I think that there's one major drawback,
you can't, if you don't enforce it on the proposal level,
you're not really getting the full,
I would say you're not actually getting
the full kind of censorship resistant properties
and the full benefits of it from a censorship
point of view.
And then number two, I think just sort of having it enshrined and having it
part of the protocol, I think, makes it a more important feature and makes
adoption also easier, I would personally say.
But also, yeah, there might be advantages.
I think we should try both as well.
We should also have this type of encrypted mempool
also on the out-of-protocol, PBS, to pension.
So you've mentioned censorship resistance,
and Ethereum's Hegel to upgrade has Fossil, which is huge for censorship resistance and ethereum's hego to upgrade has fossil which is huge for censorship
resistance um i've heard the term the holy trinity for censorship resistance uh can you speak to that
and uh explain what what is the holy trinity for censorship resistance yeah so um so fossil is inclusion list, right?
Foss choice inclusion list.
So that's a list which mandates the builders to include these transactions.
And then the holy trinity is fossil, ePBS, which is entrant PBS, right?
And encrypted mempools is a term that people use to describe this.
And why are they doing this?
Because in the end, we need all three to have the full level of censorship resistance.
So we need the occlusion list to force the ability to include it in the worst case, right?
We need EPBS because right now we have,
out of protocol PBS, we have the trust assumption
and the relay, which can still censor, right?
And we see some relays in the past have been censoring
according to the OPAC list.
So EPBS removes the relay and encrypted,
encrypted ramp pool really helps with censorship resistance
because if you don't see what's in the transactions,
it's very hard to censor based on the contents.
So just encryption by itself provides
censorship resistance.
And then it's especially strong censorship resistance
if you were to combine it with Fossil and say,
transaction is encrypted and forcedOS through via FOSCAL.
All right. So another question is why now? Why is this encrypted mempools being proposed for
Ethereum at this time? I think you just highlighted the whole eternity of censorship resistance.
There's already censorship resistance features that encrypted mempools built upon.
But Julian, I think you also touched upon kind of missing out on potential interest
from institutions just because making transactions on Ethereum for very large transactions can be a complex
complex thing to do and you do need to build relationships so you don't get, you know, MAV exploited.
So can you speak to the urgency of why this is a proposed feature for Ethereum?
why this is a proposed feature for Ethereum?
Yeah, definitely.
So indeed, I think it's good to get it in early.
One, because it means that we can adopt more institutions
who are then more willing to use Ethereum
because there's less counterparty risk.
And secondly, because it improves the developer experience
and we really want DeFi innovation to happen on Ethereum
and this encrypted mempool proposal will make that easier.
I think for me actually I've been looking at encrypted mempools for a while but I've been
mostly looking at the the forms that enshrine a specific encryption scheme into the protocol.
Importantly, Lucid actually doesn't do so so it leaves that out of protocol and gives users a few
options. Before I was looking at doing an in-protocol, but now I
realize that this actually isn't a viable approach for Ethereum because the cryptography simply isn't
ready. And that's why I've seen for myself at least more urgency to get encrypted memples in there,
because I know that we've done the research, we know what shape encrypted memples should have.
And to Shutter's credit, they've been at this for way longer, and I guess so they figured that out longer before already.
Great. And you, touching upon the EAP briefly, EAP 8184 Lucid Encryptation's Action,
so both Luis and Julian, can you talk about the collaboration between Shutter Network and the Ethereum Foundation on this proposal?
I know Shutter Network had a separate proposal earlier for encrypted mempools and now kind of joined forces to push this forward for Ethereum in a future upgrade.
Yeah, I just wanted to add one more thing to the urgency real quick is I think that
the more we can get a level playing field for other traders, the more we'll include everyone, right?
It's a much broader amount of people.
And I think that just increases who Ethereum is applicable to,
and then just increases potential to that kind of just market demand for Ethereum, right?
And the other piece of urgency to me is also just from, I think Julian has touched on it as well,
because just it become, the real world sort of has still has the edge here over
Ethereum to a certain degree. The front running is just illegal and is kind of
eliminated through a regulation and other
mechanisms in the real world to a certain degree the real world is safer in that regard right and
I think just I mean they're kind of stepping up and becoming the same providing as good or even
better safety guarantees in this respect and lower trust assumptions, I think is just really
important for Ethereum to compete with traditional banks.
And then there's a question on sort of how this EIPs, sort of how they relate to each
other. So yeah, we proposed EIP 8105 end of last year,
which we called a universal enshrined encrypted mempool.
Which came out of basically our work from a couple of years ago.
So deploying it on an encrypted mempool
out of protocol on Gnosis chain,
but also proposing
a shutterized beacon chain in the past.
That's just the continuation of that.
And then I think added to what was really nice to mention
this not enshrining a particular encryption method,
I think was really key to this as well.
And some other components.
And then we saw, they were already in touch
with the robots incentive group since a long time.
But then we saw the C transactions proposal,
and then the Lucid proposal as well, VIP.
And that's where we got in touch on that and said,
OK, where are actually, ideally we wouldn't, let's say,
like confuse the core devs and other community members
about like having different encrypted mempool proposals.
And then we noticed that both of them are kind of have
the same, I would say overarching goal
of a sense of resistance and about fairness
and about level playing field
and then introduction supply chain.
And also technically there were some differences definitely,
also some more structural differences,
but we noticed that they're not insurmountable
and we actually could have sort of converged the designs
and made changes to EIP-8105 as well.
And then I think technically, the differences are technically,
are really just technical rather than,
let's say, big economic differences.
So essentially the two designs
are already pretty close technically,
and especially in kind of the values and technical design.
So then we said, okay, for us,
it certainly doesn't make sense for for the eap8105 to
compete with um with lucid in the the vote for the headliner so definitely we drew that from
from there to say like let's put all our um let's put our sort of uh support behind lucid for the headliner
vote um and i think in general we're collaborating a lot a lot behind the scenes on behind the scenes
and also on this on the scene where with the uh the bi-weekly um calls in the bi-weekly um
included input calls uh just to just to to make sure that we're not fragmenting
and just collaborating on this conceptually.
And I think going forward,
we, there are even more proposals, right?
We've seen, we've seen from the last,
we've seen this encrypted frame transactions proposal.
So I think going forward,
it would just make sense to take all the best aspects of all the encrypted mempool
proposals and the IPs, and maybe even modify it further
to really bring kind of the best combined proposal.
And that should be the one that Ethereum could get.
Awesome.
And this is, I saw that encrypted mempools was in the straw map, Ethereum roadmap, which outlines major
things for Ethereum from now to 2030.
Is the proposal ready to ship soon?
Do you see this?
Is it like... or are there still things to work on?
Yeah, so as I said, I think the research work is done.
We know what direction encrypted memples should go in. After research,
there's a section of, I would say, applied research slash applied engineering, maybe,
which is making encrypted memples work in the context of Ethereum so that it fits with
all of the other ERPs. And in particular, the block level access list ERP, which is
a new one being implemented, is quite tricky to get right.
We've made a lot of projects with this, and I think Lucid is in a very good shape, and it could be shipped.
The thing is, since we're now looking at iStar, we have a bit more room to work with,
and so while it's pretty much ready to be shipped, we're definitely still working behind the scenes
to ensure that it's as minimal and as optimal as possible.
Great. So, Julian, if you still have time, we can chat about where the market structure for Ethereum is headed.
structure for Ethereum is headed. Can you tell us a little bit about that and kind of why you
you think we should maybe go for a minimal market structure as opposed to say a builder
net with trusted execution environments? Yeah, so I think how the market structure came about
is definitely from the PBS angle.
And the PBS angle was always how do you prevent validated set concentration because of MEV.
The market structure wasn't designed with DeFi as the first goal, basically. The first goal was
never to ensure that it would be optimal for decentralized exchanges to work on Ethereum.
And I think that we're revisiting that.
And to me, fitting with the current institutional era,
where it's important to make stuff relatively simple
and ensure that there are just fewer counterparties that need to be compliant
and need to pass all sorts of checks.
To me, the good solution is to go for an as simple as possible market structure,
which means that we would have encrypted mempools and potentially FOSL that could be extended to some sort of
multiple concurrent proposer setup very easily. I think that would work better and gives us basically 90% of
the way there and would do so very quickly so that we can build on top of that.
And I read your post about this earlier.
Do you... you wrote a little bit about...
You may have accidentally hit mute.
I'm not sure if we lost the host there.
If we did, let me tell you guys a little fun fact. Front running
isn't actually illegal in Europe. It's called pre-hedging, and it's legal to some extent.
If a dealer or an OTC shop gets a request from one of their clients, or they want to
settle a very large trade, the dealer is allowed to trade in front of their clients
as long as they do their client's best interest at heart.
And this is of course quite a hard thing to verify.
But I think it's interesting because it shows that
Ethereum could actually be better than
lots of centralized alternatives where,
for example, pre-hedging or front running would be allowed.
Yeah. Yeah, and both can be true.
I think front-running in a strict sense would be illegal.
If it's defined as front-running, I think it would be illegal and market abuse.
But yeah, it doesn't mean that technically some form of this wouldn't be possible or wouldn't be allowed.
And I think both't be allowed.
And I think both can be true.
Me saying that Ethereum needs to catch up is more to pressure Ethereum to be a lot better than traditional finance,
especially because in traditional finance, you're not actually solving the problem,
you're just implementing regulation that, again, as we said, very hard to verify,
or you're just relying on strong levels of trust in right, in centralized exchanges and traditional finance.
Whereas, yeah, in Ethereum, we have the opportunity
to build decentralized systems, use cryptography,
use decentralized market mechanisms to fix it.
So, yeah, we like to do clarification. Thank you.
