Monetizing Benign Backrunning to Accelerate Adoption of Encrypted Mempools
Name: Dee
Wallet Address: 0x96e9025466a3e15dc2c3b28c1c6c71523a93f703
1. INTRODUCTION
Ethereum’s public mempool has made frontrunning and sandwich attacks a persistent problem for users. EIP-8105 and EIP-8184 address this by introducing encrypted transactions that keep transaction contents confidential until they are ready to be executed. I think this is a major step toward reducing harmful forms of MEV while improving transaction privacy.
While reading both proposals, though, I noticed what seems to be a practical design gap. Although they preserve the possibility of benign backrunning after decryption, neither proposal gives transaction senders a standardized way to say, “I’m happy for my transaction to be backrun, and I’d like to receive part of the value it creates.” That decision is currently left implicit.
My suggestion is not to change the security model of either proposal. Instead, I propose adding a lightweight signaling mechanism that lets senders explicitly opt into benign backrunning and specify how any resulting value should be shared. The goal is to make sender participation standardized without changing the confidentiality guarantees that encrypted mempools are designed to provide.
If adopted, I believe this could make encrypted mempool designs more attractive for wallets, decentralized applications, and other participants that already rely on benign MEV or MEV-sharing mechanisms today. Rather than replacing EIP-8105 or EIP-8184, I see this proposal as a small extension that builds on the goals they already set out to achieve.
2. BACKGROUND AND PROBLEM STATEMENT
Ethereum’s public mempool has always created opportunities for MEV because transactions are visible before they are executed. Anyone can observe a pending transaction and decide whether to frontrun it, sandwich it, or backrun it. While some of these strategies improve market efficiency, others come directly at the expense of users.
This is exactly the problem that EIP-8105 and EIP-8184 are trying to solve. By keeping transactions encrypted until the appropriate point in the protocol, they significantly reduce the information available to malicious actors before execution. That makes attacks like frontrunning and sandwiching much harder to carry out.
However, while reading both proposals, one question kept coming to mind:
What happens to beneficial backrunning after transactions are decrypted?
Both proposals still allow post-decryption backrunning, but they don’t define a standard way for transaction senders to participate in the value their own transactions create. In practice, that means a wallet or decentralized application moving to an encrypted mempool could lose access to revenue streams that are already possible through systems like MEV-Share or private orderflow arrangements.
To be clear, I don’t see this as a security issue. The encrypted mempool still achieves its primary objective of protecting users before execution. Instead, I see it as a practical design gap. The protocol protects users from harmful MEV, but it doesn’t give them a simple way to benefit from benign MEV when they want to.
I think that’s an opportunity worth addressing. If senders could explicitly authorize benign backrunning and define how any resulting value should be shared, encrypted mempool designs could preserve both their security benefits and some of the economic workflows that already exist today.
2.1 Relationship to Existing Work
Both EIP-8105 and EIP-8184 are designed to reduce harmful forms of MEV by keeping transaction contents confidential until the protocol’s designated reveal phase. Their primary objective is to prevent attacks such as frontrunning and sandwiching without changing the correctness of transaction execution.
Outside the encrypted mempool setting, systems such as Flashbots’ MEV-Share have already demonstrated that transaction senders can recover part of the value created by their own transactions. Rather than allowing searchers to retain all of the resulting MEV, MEV-Share enables senders to disclose limited transaction information and receive a share of the value generated through competitive backrunning.
My proposal builds on that general idea but adapts it to the security goals of encrypted mempools. While a wallet could theoretically disclose transaction hints through a separate mechanism, doing so would reintroduce pre-execution information that EIP-8105 and EIP-8184 are specifically designed to keep confidential. Instead, this proposal introduces an optional signaling mechanism that allows sender preferences to be expressed without revealing the transaction contents needed to perform harmful MEV before execution.
Rather than replacing either proposal, this mechanism extends them by introducing a standardized way for senders to authorize benign backrunning and participate in the value it creates while preserving the existing encrypted execution model.
3. PROPOSED MECHANISM
The idea itself is actually quite simple.
Instead of treating benign backrunning as something that’s only inferred after a transaction executes, I think senders should be able to state their preference up front. If someone is comfortable allowing a competitive backrun and wants to share in the value it creates, there should be a standard way to express that within the transaction itself.
My suggestion is to add a small set of optional fields to encrypted transactions. These fields wouldn’t reveal the transaction’s contents or weaken the confidentiality guarantees of either EIP. They would simply communicate the sender’s preference once the transaction is processed according to the protocol’s normal execution flow.
The three fields I propose are:
backrun_allowed: indicates whether the sender authorizes benign backrunning.
backrun_fee_share: specifies the percentage of realized backrunning value that should be returned to the sender.
backrun_commitment_hash (optional): commits to a coarse category of opportunity without revealing transaction details before execution.
One reason I prefer this approach is that it keeps participation entirely optional. If a wallet, application, or individual user doesn’t want to monetize benign backrunning, they simply leave these fields out and nothing changes. Existing encrypted transaction workflows continue to function exactly as they do today.
What this adds is a standardized way for wallets, decentralized applications, and searchers to coordinate around sender-authorized benign backrunning. Instead of relying on private arrangements or application-specific implementations, everyone can understand the sender’s intent through the same protocol-level signaling interface.
I also think this fits naturally with the goals of EIP-8105 and EIP-8184. The proposals already protect transactions before execution; this extension simply defines how users can participate in the value created after that protection has done its job.
Figure 1. Proposed sender-authorized benign backrunning workflow. The proposal extends encrypted transactions with optional signaling fields while preserving the existing encrypted execution process.
3.1 Illustrative Transaction Structure
The proposal intentionally avoids prescribing a specific serialization format for EIP-8105 or EIP-8184. Instead, the following structure illustrates one possible way the optional signaling fields could conceptually extend an encrypted transaction while remaining backward compatible.
backrun_allowed: bool (default: false)
backrun_fee_share: uint16 (basis points, e.g. 1500 = 15%)
backrun_commitment_hash: bytes32 (optional, salted per-transaction)
None of these fields require changes to the ciphertext itself, they sit alongside it, visible only as much as gas parameters already are today, and encrypted together with the rest of the envelope where the underlying EIP’s design calls for it.
This figure is illustrative rather than normative. The proposal only introduces the signaling interface itself; the exact serialization format can be determined by whichever transaction encoding is ultimately adopted by EIP-8105 or EIP-8184.
3.2 Interaction with Self-Decryption
One detail worth thinking through is what happens when the sender is also the one who decrypts their own transaction. LUCID allows for exactly this; a sender can act as their own key publisher and self-decrypt, without relying on a separate party at all.
In that case, the sender can backrun their own transaction the moment it’s decrypted. I don’t think this needs any special handling. If a sender chooses this path, setting backrun_fee_share to 100% simply reflects reality: there’s no competitive searcher to share value with, so the sender captures the entire opportunity themselves. The mechanism doesn’t need to prevent this or treat it as a special case, it falls out naturally from the same fields already proposed.
3.3 Precise Placement Within the LUCID Ticket Structure
One detail I initially left vague is exactly where these fields would sit within LUCID’s existing structure, and I think it’s worth being precise about that.
LUCID separates a sealed transaction into two parts: a signed ST ticket, which is visible in plaintext and charges the sender upfront, and a ciphertext envelope, which stays hidden until the key publisher releases the decryption key. For backrun_allowed and backrun_fee_share to do their job, searchers need to see them before the transaction decrypts, so they know it’s worth watching for the reveal. That means these two fields belong in the plaintext ST ticket itself, alongside fields LUCID already exposes there, such as the maximum ToB fee.
backrun_commitment_hash is different. Since its purpose is only to help post-decryption coordination, not to attract attention before the reveal, I think it could reasonably live in either location. Placing it in the ST ticket keeps things simple; placing it inside the ciphertext envelope would delay its visibility until decryption, which may be preferable if even a coarse, salted commitment is judged too sensitive to expose early. I lean toward the ST ticket for simplicity, but I don’t think this needs to be settled by this proposal, it can be left to whoever implements it.
It’s also worth checking whether these fields interact with max_preceding_commitments, LUCID’s existing knob for bounding a sender’s exposure to front-running by earlier, unrevealed commitments. They don’t. max_preceding_commitments governs ordering risk before a transaction executes; backrun_allowed and backrun_fee_share only become relevant after it has. A sender can set both independently a cautious max_preceding_commitments value to limit pre-execution exposure, and a separate backrun_fee_share value to monetize whatever benign backrunning follows execution. The two fields operate on opposite sides of the same transaction’s lifecycle and don’t constrain each other.
One more integration point worth checking, given that FRAME compatibility (EIP-8141) has come up elsewhere in this feedback thread as an important forward-looking constraint: none of the three proposed fields touch the ST ticket’s signature or signature_id byte. They sit alongside those fields, not inside them. That means whichever signature scheme a ticket uses; ECDSA today, or a FRAME-wrapped signature in the future via signature_id = FRAME_TX_TYPE; these fields carry over unchanged. This proposal doesn’t need its own FRAME migration path, since it was never coupled to the signature layer in the first place.
4. SECURITY ANALYSIS
One of the first things I thought about while developing this idea was whether it might accidentally weaken the security guarantees that EIP-8105 and EIP-8184 are trying to provide. Before going through specific attack types, it’s worth being precise about what an observer can actually see at each stage, since that’s really the crux of whether this proposal is safe.
Before decryption, an observer sees only the ST ticket: the sender’s address, the maximum fees they’re willing to pay, and, under this proposal, backrun_allowed and backrun_fee_share. They do not see the ciphertext contents, meaning the asset pair, trade direction, and size all remain hidden. After decryption, everything about the transaction becomes visible at once, exactly as it would for a plaintext transaction today, nothing about this proposal changes what becomes visible or when. The only thing that changes is that two additional, low-information fields are visible during the pre-decryption window, alongside fields LUCID already exposes there. Framed this way, the security question isn’t whether these fields are visible early, since visibility itself isn’t the problem; it’s whether what they reveal is enough to reconstruct the transaction’s economic position ahead of time. I don’t think it is, for the reasons below.
4.1 Sandwich Attacks
One obvious concern is whether allowing senders to opt into benign backrunning could make sandwich attacks possible again. Based on the current design, it doesn’t.
A sandwich attack depends on knowing what a transaction is going to do before it executes. The proposed signaling fields don’t provide that information. A field like backrun_allowed simply tells the network that the sender is willing to allow a benign backrun if an opportunity exists. It doesn’t reveal which tokens are being traded, the size of the trade, or the expected price movement.
Because the transaction remains encrypted until the protocol’s normal reveal phase, attackers still can’t position transactions before the user’s transaction. In other words, the signaling mechanism doesn’t change the protections that EIP-8105 and EIP-8184 already provide against frontrunning or sandwich attacks.
4.2 Metadata Exposure
One concern with this proposal is whether the signaling fields reveal enough information for someone to learn something useful about a transaction before it executes.
In practice, these fields reveal very little. The fields only tell the network whether the sender has opted into benign backrunning and, if they have, the fee-sharing percentage they selected. They don’t reveal the transaction itself, the assets involved, the trade size, or whether a profitable backrunning opportunity will even exist.
The optional backrun_commitment_hash needs a bit more care. If the same commitment value were reused across multiple transactions, it could make those transactions easier to correlate over time. A simple way to avoid that is to require a fresh random salt for every transaction, so the commitment changes even when the same category of opportunity is being referenced.
Overall, I think these fields reveal preference, not transaction intent. The information needed to carry out harmful MEV strategies remains hidden until the protocol’s normal reveal phase, so the confidentiality guarantees of the encrypted mempool are preserved.
4.3 Interaction with Existing Key-Withholding Risks
Another thing I wanted to check was whether this proposal changes any of the key-withholding assumptions already discussed in EIP-8105 and EIP-8184. After looking at how the mechanism fits into both designs, the existing key-withholding assumptions remain unchanged.
The signaling fields don’t affect how encryption keys are generated, distributed, or released. They also don’t change the responsibilities of validators, builders, or key providers, and they don’t interfere with the protocol’s transaction ordering rules. Everything related to encrypted execution continues to work exactly as described in the existing proposals.
The only new behavior happens after the transaction has been decrypted and executed. At that point, the sender’s signaling fields simply tell searchers whether benign backrunning is permitted and, if so, how any resulting value should be shared. They don’t introduce any new trust assumptions or change the protocol’s existing key management process.
It’s worth being precise about why this doesn’t add to that window. EIP-8105’s own Security Considerations describe the key provider’s withholding choice as giving them “one bit of influence over the pre-state of later transactions”, a window that closes the moment a key is published or withheld. The signaling fields in this proposal only become actionable after that window has already closed, once the transaction is decrypted and executed. There’s no point at which backrun_allowed or backrun_fee_share could be used to extend or amplify that one-bit window, since by the time they matter, the withholding decision has already been made and observed.
Because of that, I see this as an extension to the transaction format rather than a change to the underlying security model. The existing key-withholding risks remain exactly the same; they’re neither solved nor made worse by this proposal.
4.4 Orthogonality to FOCIL
LUCID relies on FOCIL for its inclusion-list machinery, so I also wanted to check whether this proposal interacts with that in any way. It doesn’t. The signaling fields don’t affect which sealed transactions get included in an inclusion list, how includers or proposers behave, or any of the censorship-resistance guarantees FOCIL is meant to provide. A sealed transaction with backrun_allowed set is included or excluded under exactly the same rules as one without it. The two mechanisms are simply addressing different problems: FOCIL is about guaranteeing inclusion, and this proposal is about what happens to value created after a transaction has already been included and executed.
5. ECONOMIC ANALYSIS AND INCENTIVE MODEL
One reason I think this proposal is worth considering is that it gives transaction senders a way to benefit from value their own transactions create, while still leaving enough incentive for searchers to compete. Instead of treating benign backrunning as value that only searchers can capture, this approach lets senders choose whether they want to participate in it.
That doesn’t mean every transaction suddenly becomes profitable, and it doesn’t guarantee that a searcher will always participate. What it does is provide a standard way to share value whenever a genuine benign backrunning opportunity exists.
5.1 Incentive Model
The incentive model is fairly straightforward.
Suppose a transaction creates a benign backrunning opportunity worth V, and the sender chooses a fee-sharing percentage f. A fraction of the realized value is returned to the sender, while the remaining value stays with the winning searcher after accounting for their costs.
The expected returns can be described as:
Sender Return = f · V
Searcher Return = (1 − f ) · V − C
where:
V = realized value of the benign backrun
f = sender-selected fee-sharing percentage
C = the searcher’s operational costs, such as gas fees and search expenses
I don’t see these equations as a complete economic model. They’re simply a way to explain how the value is divided between both participants. Real-world outcomes will still depend on factors like searcher competition, gas prices, network conditions, and the size of the available opportunity.
5.2 Relationship to Existing MEV-Share Systems
One reason I think thiis proposal is practical is that the basic idea has already been shown to work.
Flashbots’ MEV-Share allows transaction originators to recover part of the value their transactions create by sharing limited information with competitive searchers. That demonstrates there’s already demand for mechanisms that let users participate in benign MEV instead of losing all of it.
The difference is that MEV-Share operates in today’s transaction environment, where information can be shared before inclusion. EIP-8105 and EIP-8184 introduce encrypted transactions, so that same approach can’t simply be reused without modification.
My proposal isn’t trying to replace MEV-Share. Instead, it adapts the same general idea to encrypted mempools by giving senders a standardized way to authorize benign backrunning after the protocol’s normal confidentiality guarantees have been preserved.
5.3 Illustrative Examples
Here’s a simple example of how the mechanism would work in practice.
Imagine a user submits a swap that temporarily moves a liquidity pool about 0.4% away from the market price. After the transaction executes, a benign backrunning opportunity worth 0.18 ETH becomes available.
If the sender previously selected a fee-sharing percentage of 15%, the outcome would look like this:
Total backrunning value: 0.18 ETH
Returned to the sender: 0.027 ETH
Retained by the winning searcher: 0.153 ETH (before operational costs)
The searcher is still rewarded for identifying and executing the opportunity, while the sender receives part of the value their transaction created. If no profitable opportunity exists, or if no searcher decides it’s worth pursuing, the transaction still executes normally, and the signaling fields simply have no effect.
5.4 Practical Limitations
I don’t think this mechanism should be presented as a solution for every transaction. There are several situations where it simply won’t have any effect, and I think it’s important to acknowledge that upfront.
For example, not every transaction creates a profitable benign backrunning opportunity. If the available value is too small to cover a searcher’s costs, it’s perfectly reasonable for nobody to compete for it. In that case, the transaction still executes normally, and the signaling fields simply go unused.
There’s also the question of ecosystem adoption. Even if the signaling fields were standardized, wallets, searchers, and builders would need time to implement support for them. During that transition period, participation would likely be limited, even for transactions that could benefit from the mechanism.
Another limitation is market competition. On highly liquid markets with many searchers, competition should help produce efficient outcomes. On smaller or less active markets, however, fewer participants may reduce competition and make value sharing less effective.
I don’t see these as flaws in the idea itself. Instead, they’re practical realities that come with introducing any new protocol feature. The mechanism is designed to fail safely: if no profitable backrun exists or no searcher participates, nothing breaks and the transaction proceeds exactly as it would today.
5.5 Application-Specific Note: Liquidations
The worked example above focuses on a simple swap, but it’s worth briefly considering a different case: liquidations. Liquidation transactions are latency-sensitive and often themselves create a further backrunning opportunity, since a large liquidation can move a pool away from its equilibrium price in much the same way an ordinary swap does.
I don’t think liquidations require any special-casing under this proposal. A liquidator submitting a sealed transaction could set backrun_allowed and a fee share exactly as any other sender would, and if their liquidation creates a benign backrunning opportunity, it would be handled the same way. One difference worth noting is that liquidation bots are often themselves sophisticated searchers, so in practice they may be more likely to set backrun_fee_share to 0 and capture the follow-on opportunity through their own infrastructure rather than opening it to competition. I see that as a reasonable choice left entirely to the sender, not a gap in the mechanism.
6. IMPLEMENTATION AND DEPLOYMENT CONSIDERATIONS
By this point, the signaling mechanism is fairly straightforward. The harder part is deciding how it would fit into existing encrypted mempool workflows without making the protocol unnecessarily complicated.
I tried to keep the proposal as lightweight as possible. The new fields are optional, they don’t interfere with encrypted transaction processing, and applications that don’t need them can simply ignore them. From that perspective, the mechanism feels more like an extension to the existing transaction format than a redesign of either EIP.
That still leaves a few practical questions. The biggest ones are how the sender receives their share of the value, how existing wallets and applications remain compatible, and how the feature could be introduced gradually across the ecosystem.
6.1 Settlement Approaches
The mechanism itself is fairly easy to understand. Deciding how the sender actually gets paid is the more interesting design question.
After thinking through the possibilities, I ended up with two approaches that seem practical.
Bundle-Level Settlement
The first option is to make the sender’s payment part of the winning searcher’s execution bundle. Under this approach, the bundle would only be considered valid if it includes the agreed fee share for the sender.
What I like about this approach is that it builds on ideas that already exist in today’s MEV ecosystem. It keeps the protocol relatively simple while still allowing searchers to compete for profitable opportunities.
Protocol-Level Settlement
The second option is to let the protocol handle settlement directly. Once the backrun has been completed, the sender’s share would be distributed automatically according to the fee-sharing percentage included in the transaction.
This provides stronger guarantees that the sender is paid correctly, but it also requires additional protocol logic. That extra complexity makes it better suited to a future version rather than an initial implementation.
One reason I think protocol-level settlement is worth keeping as a future option, rather than dismissing it outright, is that LUCID already has a working precedent for exactly this kind of automatic value return. Successful key reveal already triggers a partial refund, returning unused base fee and a (TOB_FEE_FRACTION − 1) / TOB_FEE_FRACTION share of the posted ToB fee to the sender automatically. A future protocol-level settlement path for backrun_fee_share could plausibly piggyback on that same refund mechanism, rather than requiring entirely new machinery. I want to be careful not to overclaim this. I haven’t worked out the details, and there may be reasons this doesn’t extend cleanly, but the fact that LUCID already automates a conceptually similar value-return suggests protocol-level settlement isn’t as large a leap as it might first appear.
If I had to choose between the two, I’d probably start with bundle-level settlement. It introduces fewer protocol changes while still achieving the main goal of standardized value sharing.
It’s also worth putting a rough number on how “lightweight” this actually is. backrun_allowed is a single boolean, backrun_fee_share fits in two bytes, and backrun_commitment_hash, if used, is 32 bytes. Even accounting for calldata costs, this amounts to on the order of tens of bytes of additional data per transaction, a small fraction of what a typical encrypted transaction envelope already carries. I want to be careful not to overstate this: the exact cost will depend on calldata compression and the specific encoding either EIP ultimately adopts, so this is an order-of-magnitude estimate, not a benchmark.
6.2 Backward Compatibility
One aspect of this proposal that I appreciate is that it fits naturally into the way EIP-8105 and EIP-8184 are already designed. Since the signaling fields are optional, existing encrypted transactions wouldn’t need to change at all.
Wallets, decentralized applications, builders, and searchers could continue using the current workflow unless they decide to support sender-authorized benign backrunning. That means adoption can happen gradually instead of depending on a coordinated network-wide upgrade.
To me, that’s one of the advantages of extending the transaction format rather than changing the encrypted execution process itself. The existing workflow remains intact, while participants who see value in the mechanism can choose to adopt it over time.
6.3 Deployment Strategy
Rather than introducing everything at once, I think this kind of mechanism would benefit from a gradual rollout.
A prototype implementation would make it possible to evaluate both the technical design and the incentive model before wider adoption. From there, the mechanism could move to Ethereum testnets, where interoperability between wallets, builders, and searchers could be tested under realistic conditions.
If those results are encouraging, support could eventually be introduced on mainnet as an optional extension alongside encrypted mempool adoption.
Rolling the feature out in stages gives the community room to identify implementation issues, evaluate economic behavior, and refine the design before it becomes part of production workflows.
6.4 Comparison to Alternative Designs
Before settling on this approach, I considered two alternatives, and I think it’s worth explaining why I didn’t go with either of them.
The first alternative would be to make benign backrunning always allowed by default, without any signaling field at all. This would be simpler to specify, but it removes sender consent entirely. Some senders may prefer not to have their transactions backrun even when it’s economically benign, and a mandatory approach gives them no way to express that preference.
The second alternative would be to have the protocol itself run a formal auction for backrun rights, rather than relying on an off-chain competitive searcher market. This could plausibly capture more value in some cases, but it comes at a real cost: it would require new consensus-level auction logic, adding meaningful protocol complexity in an area where EIP-8105 and EIP-8184 have otherwise tried to stay minimal and scheme-agnostic.
I chose the opt-in signaling approach instead because it keeps the protocol changes small, relies on searcher infrastructure that already exists today through systems like MEV-Share, and leaves the choice of whether to participate entirely with the sender. It trades some theoretical efficiency for simplicity and backward compatibility, which feels like the right tradeoff for a first version of this kind of mechanism.
7. CONCLUSION
Reading through EIP-8105 and EIP-8184, I came away with the impression that they solve one of Ethereum’s biggest MEV problems by protecting transactions before execution. At the same time, they leave open an interesting question: if a transaction creates a legitimate backrunning opportunity after execution, should the sender have a way to participate in that value?
This proposal is my attempt to answer that question.