Key-Withholding Optionality as a Structural MEV Risk in EIP-8105 and LUCID: Analysis, Quantification, and Mitigation Proposals

Encrypt The Mempool POIDH Bounty: Provide feedback on the draft EIPs
1

Key-Withholding Optionality as a Structural MEV Risk in EIP-8105 and LUCID: Analysis, Quantification, and Mitigation Proposals

Wallet Address: 0x5e4e5ea537ce7e79b8a0fc4f0cb520e9b8b5dae5 Name / Pseudonym: Favor| Bonux Role / Experience: Independent Protocol Researcher & Builder Contact: Telegram: Contact @favor59

Executive Summary

This post provides technical feedback on EIP-8105 (Universal Enshrined Encrypted Mempool) and EIP-8184 (LUCID). Both proposals mark a significant step toward eliminating harmful MEV from Ethereum’s public mempool, and the convergence of both teams around a shared direction is encouraging.

My feedback is focused on a structural incentive problem that I believe is underweighted in both EIPs: key-withholding is not only a liveness concern — it is a mechanism that grants decryptors embedded economic optionality over state transitions. When this optionality is properly modeled, the existing penalty mechanisms in both proposals appear insufficient to neutralize it under adversarial conditions.

I also raise two secondary observations:

  • EIP-8184 already includes FRAME (EIP-8141) integration as an optional extension. I argue this integration should be treated as a primary design path rather than an alternative, particularly to simplify the wallet adoption story.
  • The PTC bribery surface introduced by LUCID’s per-key timeliness vote is qualitatively different from — and more granular than — the existing binary payload timeliness vote.

Part 1 — Key Withholding as Embedded MEV Optionality

1.1 How Both EIPs Currently Treat Withholding

EIP-8105 explicitly permits key withholding. The rationale states: “The protocol explicitly allows decryption key providers to withhold decryption keys under conditions of their choosing.”

It relies on the key-provider trust graph and reputation effects as deterrents, with no in-protocol economic penalty mandated.

EIP-8184 (LUCID) goes further by introducing the `tob_fee` mechanism. A key publisher who withholds forfeits the `tob_fee` posted at commitment time. The penalty is structured so that a publisher who withholds forfeits `tob_fee` (the full amount), while a publisher who reveals recovers `(TOB_FEE_FRACTION - 1) / TOB_FEE_FRACTION` of that fee — i.e., `127/128` of the fee is returned on successful reveal, and `1/128` is burned.

The LUCID authors state that “selective reveal is therefore priced both in expectation and ex post.” This is the right framing, and the mechanism is thoughtful. But I want to show that under adversarial conditions, the pricing may still be exploitable.

1.2 Modeling the Withholding Decision

Consider a key publisher who has committed to an ST with `tob_fee = F`. At key release time, the publisher observes information not available at commitment time — specifically, the decryption keys and execution results of other STs that have already been revealed.

The publisher’s decision at reveal time is binary:

  • Reveal → recover `F × (TOB_FEE_FRACTION - 1) / TOB_FEE_FRACTION = F × 127/128`. Net cost of withholding avoidance = `F/128`.
  • Withhold → forfeit full `F`. Net penalty = `F`.

The publisher will rationally withhold when:

E[V_withhold] − F > E[V_reveal] − F/128

Where `V_withhold` is the value captured by suppressing the transaction (e.g., a competing arbitrage that now succeeds because the user’s trade does not execute), and `V_reveal` is the value of simply letting the transaction execute.

Rearranging:

E[V_withhold] − E[V_reveal] > F − F/128 = F × 127/128

So withholding is rational when the marginal value of suppression exceeds `127/128 × F`. For a publisher posting a modest `tob_fee`, this is a relatively low bar when the underlying transaction carries high value.

1.3 A Concrete Example

Suppose a user submits an encrypted large-volume DEX trade. At commitment time, the publisher does not know the exact nature of the payload. At reveal time — after observing other decrypted STs — the publisher infers:

  • The trade will move the price of a token by approximately X%.
  • The publisher controls a separate account positioned to profit from the resulting price impact.
  • The marginal profit from suppressing the trade and executing instead = `V_suppress = 5 ETH`.

The publisher’s ST commitment had `tob_fee = F = 0.1 ETH`.

Withholding penalty = `F × 127/128 ≈ 0.099 ETH`. Profit from withholding = `5 ETH − 0.099 ETH ≈ 4.9 ETH`.

The publisher withholds. The current penalty structure does not deter this.

1.4 Why This Is Structurally Different from Builder MEV

This might seem analogous to a builder front-running — and in a sense it is. But there is an important structural difference:

Under the current (pre-encrypted-mempool) system, a builder who front-runs a user’s transaction takes on execution risk. The front-run trade competes with the user’s revealed transaction and the outcome depends on gas pricing and ordering competition. Multiple builders compete and the market has some self-correcting properties.

Under an encrypted mempool with key-withholding optionality, the key publisher holds a risk-free conditional option: if the state is favorable, reveal; if not, withhold at the cost of `F`. This is not a competitive market — it is a monopoly option granted to a single entity per transaction, with no competing mechanism to price the option fairly.

The protocol as currently designed replaces one MEV mechanism with another that is structurally less competitive.

1.5 Aggregate Optionality Accumulation

A sophisticated key publisher operating at scale could:

  1. Commit to many STs across a slot.
  2. Observe keys released by other publishers in sequence.
  3. Selectively withhold STs whose execution would be adverse to its off-chain positions.

As more decrypted transactions execute and reveal state, each subsequent withholding decision becomes more informed. Later STs in the ToB ordering are therefore exposed to higher-quality optionality than earlier ones, even if they posted identical `tob_fee` values.

LUCID’s `max_preceding_commitments` parameter allows users to bound how many commitments can precede them, which partially addresses this by limiting the amount of observable state at the time of their key release decision. But it does not directly price the value of that observable state — it only limits its quantity.

Part 2 — Proposed Mitigations

2.1 State-Adaptive Penalty Scaling

The current `TOB_FEE_FRACTION = 128` produces a fixed cost-of-withholding equal to `F/128 × 128 = F`. The problem is that `F` is set at commitment time, before the publisher knows the value of the withholding option.

A stronger design would make the penalty a function of observable state at reveal time, not just the pre-committed `tob_fee`. Concretely:

After all STs in a bundle are revealed, the protocol could compute the `gas_used` or aggregate `tx_value` of revealed STs and scale the non-reveal penalty for any withheld ST in the same bundle proportionally.

This is admittedly complex to implement cleanly without revealing payload contents prematurely. A simpler approximation: require publishers to post a bond scaled to the gas_limit of their committed STs, separate from and additive to the `tob_fee`. The bond is released only upon successful reveal. This is analogous to collateral in a lending protocol: sized to the potential value at risk, not the *committed fee*.

2.2 Threshold Key Release as a Default for High-Value STs

For STs above a value threshold (which could be estimated from `gas_limit × max_fee_per_gas`), the protocol could require that the decryption key be released via a k-of-n threshold mechanism rather than by a single publisher. This eliminates the single-entity withholding option entirely.

EIP-8105 is already scheme-agnostic and could accommodate this without modifying the transaction format — the `key_provider_id` could identify a threshold scheme. LUCID could likewise designate threshold-based key publishers in its trust registry.

The tradeoff: threshold schemes introduce latency and coordination complexity. But for high-value transactions where the withholding option has real economic value, this tradeoff is worth accepting.

2.3 Commit-Reveal Separation with Locked Reveal Timing

Both EIPs allow flexible reveal timing within a slot. EIP-8105 allows “immediate… or delay publication to a later point in the slot.” LUCID allows key release after observing the beacon block and “when the key publisher is confident that the beacon block will become canonical.”

This flexibility is the direct source of the information asymmetry that creates optionality. A publisher who delays revelation has more time to observe other keys and make a more informed decision.

Recommendation: Require that key reveal timing be committed to before ordering is finalized. Concretely, a publisher should be required to specify whether their key will be released immediately upon payload publication or at a specific sub-slot deadline, and this commitment should be binding. Late reveals (relative to the committed schedule) would be treated as withholds, forfeiting the full `tob_fee`.

This does not eliminate optionality entirely — a publisher can still choose to withhold — but it eliminates the information-gathering advantage of strategic delay.

2.4 Transparent Withholding Attribution On-Chain

Both EIPs have mechanisms for recording whether keys were present or absent (EIP-8105’s PTC bitfield; LUCID’s `LucidKeyTimelinessVote`). Neither EIP mandates that the specific publisher identity responsible for a withhold event be durably recorded on-chain in a publicly queryable form.

Recommendation: Emit an on-chain event or include in block header metadata the key publisher address and the `commitment_root` for any committed ST whose key was withheld. This enables:

  • Trustless verification of withholding history by anyone.
  • Integration with reputation systems and staking slash conditions.
  • Analytics to detect systematic patterns of selective withholding.

The data is small (32 + 20 bytes per event) and the informational benefit for ecosystem health is substantial.

Part 3 — PTC Bribery Surface in LUCID

3.1 The New Attack Vector

LUCID introduces a `LucidKeyTimelinessVote` cast by PTC members on a per-ST-commitment basis, in addition to the existing binary payload timeliness vote from EIP-7732. The EIP acknowledges:

“A coalition of PTC members… could be bribed to systematically vote ‘timely’ on keys originating from specific key publishers, artificially extending their permitted release window.”

This is correctly identified. I want to add that the attack surface here is structurally larger than the analogous bribery risk on the existing payload timeliness vote, for two reasons:

First, granularity. The payload timeliness vote is binary per slot: a corrupted vote affects one single yes/no question. The LUCID key-timeliness vote is cast per-commitment, and a slot may contain many commitments (up to `MAX_ST_COMMITS = MAX_ST_COMMITS_PER_IL × IL_COMMITTEE_SIZE`). Each vote can be individually targeted, meaning a bribe attack can be precisely scoped to benefit a specific key publisher without triggering broad anomaly detection.

Second, asymmetric observability. By the time PTC members cast their key-timeliness vote, they have already observed which keys were released and which were not. A bribed PTC member voting “timely” on a late key knows with certainty what outcome their vote produces. There is no execution uncertainty. This makes the bribe more predictable and therefore cheaper to execute than bribing validators in a context where execution outcomes are uncertain.

3.2 Proposed Mitigation

LUCID’s rationale section mentions “view-merge” as an alternative to separate PTC key-timeliness votes. Under view-merge, the next-slot builder merges differing views of released keys without a formal committee vote. The authors note this “reduces the direct per-key voting surface.”

I recommend the authors clarify whether view-merge is intended to be specified as a concrete alternative mechanism or remains at the level of a conceptual note. If the per-key PTC vote is retained, the per-commitment bribery surface should be explicitly modeled in the security considerations section, with a proposed detection or deterrence mechanism.

Part 4 — FRAME Integration as Primary Path, Not Alternative

4.1 Current Status

EIP-8184’s Rationale section already includes FRAME (EIP-8141) integration as an alternative specification:

“LUCID can be integrated with EIP-8141 by allowing `signature_id = FRAME_TX_TYPE`…”

This is correctly specified at a technical level. My feedback is about **positioning**, not technical gap.

4.2 Why Primary Matters

As currently scoped, FRAME integration is an optional extension — requiring a future EIP making coordinated additions. This means wallets and infrastructure providers are likely to implement the primary path (non-FRAME ST tickets) and treat FRAME integration as a later upgrade.

This matters for a specific reason: **wallet adoption is the single largest friction point for encrypted mempool deployment.** If wallets must implement separate integration flows for LUCID STs and potentially for EIP-8105-style encrypted envelopes, many will delay or implement only one path. Every wallet that does not support encrypted transactions is a user who cannot benefit from the mempool protection these EIPs are designed to provide.

EIP-8141 (FRAME) already unifies authentication, authorization, and execution intent into a composable abstraction. Making FRAME the primary — rather than optional — transaction substrate for both EIPs would:

  1. Reduce the number of distinct transaction lifecycle flows wallet developers must implement.
  2. Create a natural upgrade path to post-quantum signature schemes without requiring new encrypted-mempool-specific transaction formats.
  3. Allow LUCID and EIP-8105 users to share a unified wallet UX layer, even if the underlying key mechanisms differ.

4.3 Recommendation

The authors of both EIPs should coordinate explicitly on whether FRAME integration will be treated as a primary design goal for the Hegotá upgrade or deferred. If deferred, the deprecation path for the current non-FRAME formats should be documented, so wallet developers do not build against interfaces that will later be replaced.

Questions for the Authors

To EIP-8105 authors: The key provider trust graph allows users to implicitly trust providers designated by their chosen provider. But the trust graph is dynamic and can be updated after a user has already submitted encrypted transactions. What prevents a key provider from retroactively expanding its trust set to include a malicious provider after users have already chosen it — effectively reducing user guarantees without their knowledge?

To LUCID authors: The `tob_fee` mechanism prices withholding in expectation. But the penalty `F × 127/128` is fixed at commitment time, while the value of the withholding option accrues dynamically as other keys are revealed. Has the team considered dynamic penalty scaling — where the penalty increases as more state becomes observable post-commitment? If not, what is the strongest argument that fixed penalty scaling is sufficient?

To both teams: Given that EIP-8105 requires EIP-7732 (ePBS) while LUCID requires EIP-7805 (FOCIL), and both are being considered for Hegotá — what is the sequencing dependency? Does inclusion of LUCID in Hegotá require FOCIL to be finalized first, and how does the team plan to coordinate activation if one precedes the other?

Conclusion

EIP-8105 and LUCID represent the most credible path to eliminating harmful MEV from Ethereum’s public mempool. The convergence of the two teams is a positive development. The technical designs are thoughtful and clearly informed by years of real-world deployment experience.

The core risk I am flagging — key withholding as embedded economic optionality — is not a reason to reject either proposal. It is a reason to strengthen the economic penalty mechanisms before deployment. The asymmetry between a fixed commitment-time penalty and a dynamically accruing withholding option is a structural gap that adversarial key publishers can exploit at scale.

Addressing this directly, alongside the PTC bribery surface introduced by LUCID’s per-key vote and the wallet adoption friction created by optional FRAME integration, would make the resulting protocol significantly more robust.

I look forward to the discussion.

Feedback submitted as part of the POIDH Bounty: Provide Feedback on the Draft EIPs *Forum: [shutternetwork.discourse.group]( POIDH Bounty: Provide feedback on the draft EIPs - Shutter Forum *)

2

One thing i want to flag on the PTC bribery angle in part 3.

I pointed out that LUCID’s per-commitment key timeliness vote gives a briber a much smaller, more precise target than the existing binary payload vote. I still stand by that part. But I glossed over something. LUCID’s rationale mentions view merge as an alternative that removes the formal PTC vote entirely, and I never actually worked through whether that fixes the problem or just relocates it.

Under view merge, the next slot builder is the one merging different views of which keys got released. That means the decision that used to be distributed across a PTC committee now sits with one builder. A single builder is arguably an easier bribery target than a committee, since bribing one entity is operationally simpler than coordinating a committee bribe. So on the surface, view merge could make the attack easier to execute, just concentrated in a different role instead of removed.

The counterargument is that builders already hold significant MEV related power under ePBS, so this isn’t really a new trust assumption, just an extension of one that already exists. I think that’s a fair defense but the EIP doesn’t spell it out, and I’d rather flag the gap myself than leave it looking like my original post fully closed it.

If the authors do want view merge as the primary mechanism, one option worth considering is requiring the merge decision to come from a small rotating quorum instead of a single next slot builder, maybe 3 or 5 builders drawn from a lookahead window, with the merged view only final once a majority agree. That keeps most of the simplicity gain from dropping the full PTC vote while avoiding a single point of bribery. It’s a smaller committee than the current PTC, but a committee is still harder to buy off cleanly than one builder.

3

Revision 2

This reply formalizes the four mitigations from my original Part 2 and the rotating-quorum idea from my first reply into adoptable spec patches, then adds four new sections: a head-to-head comparison of the tradeoffs between those mitigations and the EIPs’ own alternative designs, a look at what each patch actually costs to build and ship, an annualized version of the withholding-EV model from my original §1.2/§1.3, and a couple of angles built directly from the authors’ own public statements.

Part A — My original mitigations, formalized as adoptable patches

Patch 1 — A withholding bond, separate from and additive to tob_fee

Current text (EIP-8184, “Constants and parameters”): TOB_FEE_FRACTION = 128

Current text (EIP-8184, “Block processing”): parent_ticket.signer.balance += parent.base_fee_per_gas * (parent_ticket.gas_limit - dual_gas_used) + parent_tob_fee * (TOB_FEE_FRACTION - 1) // TOB_FEE_FRACTION

Proposed addition: Add a withholding_bond field to the ST ticket, sized as bond_rate * ticket.gas_limit with bond_rate a protocol constant. The bond is charged alongside ticket_fee at commitment time. Upon successful reveal it is refunded in full, in the same block as the existing tob_fee refund. Upon non-reveal it is forfeited in full, in addition to the existing tob_fee forfeiture.

Rationale. TOB_FEE_FRACTION produces a fixed cost of non-reveal equal to tob_fee, and tob_fee is set at commitment time, before the publisher knows the value of the withholding option (§1.2 of my original post). Sizing a separate bond to gas_limit rather than to the fee the sender chose to post means the penalty tracks the size of what’s being protected rather than what the sender was willing to pay for priority.

Patch 2 — Threshold key release as the default above a value cutoff

Current text (EIP-8105, “Key Provider Registry”): “It allows any account to register a key provider and assigns them a unique ID. Registration requires specifying a contract with a decryption and a key validation function, each of which accept a key ID and a key message as byte strings.”

Current text (EIP-8184, ST ticket fields): key_publisher — “responsible for signing bundles before key release.”

Proposed addition: For STs whose ticket.gas_limit * ticket.max_fee_per_gas exceeds a protocol- or wallet-level HIGH_VALUE_THRESHOLD, the key_publisher field must resolve to a registered k-of-n threshold scheme rather than a single address. EIP-8105’s registry already accepts arbitrary decryption/validation contracts per key_provider_id, so a threshold scheme can register under the existing interface without a transaction-format change.

Rationale. A single-entity key publisher holds sole discretion over reveal for every ST routed through it (§1.4 of my original post, “risk-free conditional option”). Removing single-entity discretion for the highest-value transactions removes the incentive at the source rather than pricing it after the fact.

Patch 3 — Binding, committed reveal-timing deadlines

Current text (EIP-8184, “Key release”): “When the key publisher is confident that the beacon block will become canonical (for example after observing attestations for it), it releases its LucidKeyMessage.”

Current text (EIP-8105, “Key Provider Responsibilities”): “They may do so either immediately upon observing the execution payload or delay publication to a later point in the slot.”

Proposed replacement (LUCID): The ST ticket carries a reveal_deadline_offset, chosen at commitment time as either IMMEDIATE or a fixed number of seconds into the slot, up to a protocol maximum. A key released after its own ticket’s committed offset is treated identically to non-reveal for penalty purposes.

Rationale. “Confident that the beacon block will become canonical” is a judgment call, not a deadline. Making the publisher commit to a timing choice before it can observe anything doesn’t stop them from choosing to withhold, but it does stop them from getting a better-informed decision for free by waiting longer than they said they would.

Patch 4 — On-chain, per-publisher withholding attribution

Current text (EIP-8184, “Key timeliness”): “Each PTC member publishes a signed vote message indicating which valid keys, scheduled for the current slot, they have observed.”

Current text (EIP-8105, “Decryption Key Withholding”): “keys that have been withheld unjustifiably may be used in custom slashing mechanisms and reliability metrics (note that the protocol records which keys are present and which ones have not).”

Proposed addition: For every ST-commitment whose key is not observed by the relevant deadline, include a compact on-chain record, key_publisher address plus commitment_root, in the execution payload header, part of the block hash for both EIPs.

Rationale. Both EIPs already say non-reveal is recorded and can feed reputation or slashing, but neither specifies that the record is durable, on-chain, and attributable to a specific publisher address across blocks rather than dependent on a specific off-chain indexer.

Patch 5 — A rotating quorum instead of a single builder for view-merge

Current text (EIP-8184, Rationale, “PTC influence and state observation”): “An alternative is to avoid a separate PTC vote on keys and instead rely on view-merge. Under this approach, the next-slot builder merges differing frozen views of released keys… This reduces the direct per-key voting surface and therefore the scope for bribery.”

Proposed replacement: If view-merge replaces the per-key PTC vote, the merge decision should come from a small rotating quorum, three to five builders drawn from a lookahead window, rather than the single next-slot builder, with the merged view final only once a majority agree.

Rationale. This is the point I raised in my first reply on this thread: reducing the voting surface from a full PTC down to a single builder lowers coordination cost for an attacker, since bribing one entity is operationally simpler than coordinating a committee bribe. A small quorum keeps most of the simplicity gain of dropping the full PTC vote while avoiding a literal single point of bribery.

Part B — Tradeoffs between these approaches and the EIPs’ own alternatives

Enshrined penalty vs. off-chain reputation. EIP-8105’s baseline is explicit that it “does not enshrine a fee mechanism for key providers, nor punishments for misbehavior” (Rationale, “Lack of In-Protocol Key Provider Incentives”), leaving withholding deterrence to reputation and voluntary off-chain slashing. LUCID’s tob_fee mechanism, and my Patch 1 bond on top of it, go the opposite way: an enshrined, quantifiable, automatically-enforced cost. The tradeoff is real in both directions. Off-chain reputation is flexible and scheme-agnostic, it doesn’t require the protocol to define what “misbehavior” means for every possible key-provider technology, but it’s also slow to bite and non-fungible across addresses, a provider can simply rotate identities. An enshrined bond bites immediately and can’t be dodged by rotating addresses, but it requires the protocol to commit to specific numeric constants that may need tuning as market conditions change, and tuning a consensus constant is a much heavier process than a reputation score updating. My view is that EIP-8105 could adopt something bond-like from LUCID without much friction, since both EIPs already share the ePBS foundation and the PTC infrastructure for recording key presence, the main missing piece on the 8105 side is simply that nothing currently gets forfeited.

Threshold release (Patch 2) vs. my own bond (Patch 1). These aren’t competing so much as suited to different transaction classes. Bonding preserves the current single-publisher UX, fast, no coordination step, and simply raises the cost of misbehaving. Threshold release removes the single point of discretion entirely, but at the cost of the coordination latency a k-of-n scheme requires, which cuts against LUCID’s whole design premise of tight, one-slot key release windows. I’d only apply Patch 2 above a value cutoff for exactly this reason: routine flow should stay fast and bonded, only the transactions where the option value could plausibly exceed any reasonable bond should pay the latency cost of threshold coordination.

My threshold-release proposal vs. LUCID’s own trust-graph alternative. LUCID’s “Alternative specifications” section already sketches a related idea: replacing max_preceding_commitments with max_preceding_untrusted_commitments, where a preceding commitment from a publisher the sender’s own publisher trusts doesn’t consume the safety budget. This is a genuinely different lever from mine, it addresses front-running exposure from other senders’ publishers, where my Patch 2 addresses withholding exposure from a sender’s own publisher. They’re complementary rather than substitutes: the trust-graph idea reduces how much a sender needs to worry about who executes near them, while threshold release reduces how much a sender needs to worry about the one publisher they’re relying on directly. A protocol adopting both would let a sender lean on trusted publishers for ordering risk and threshold schemes for withholding risk, rather than needing one mechanism to do both jobs.

Binding reveal timing (Patch 3) vs. the current flexible standard. The current “confident” standard optimizes for liveness, a publisher who’s genuinely uncertain about canonical-chain status has room to wait rather than risk revealing into a reorg. A binding deadline trades some of that liveness margin for closing the information-gathering advantage of strategic delay. This tradeoff cuts differently across the two EIPs: EIP-8105 already has a Reorgs section addressing exactly this uncertainty (keys “can be invalidated by the key validation function” if a reorg occurs), while LUCID currently has no equivalent reorg-specific language for key release. A binding deadline is arguably safer to adopt in LUCID precisely because it doesn’t yet have another mechanism cushioning the reorg case.

Part C — Implementation complexity and deployment considerations

Patch 1 (bond). Adds one field to the ST ticket and one additional balance-escrow accounting step mirroring the existing tob_fee handling. Low incremental complexity, it reuses the exact charge/refund/forfeit pattern LUCID already implements for tob_fee, it’s the same code path with a second amount.

Patch 2 (threshold release). The heaviest patch to ship. It requires an actual k-of-n threshold decryption scheme to exist and be registered, which means a distributed key generation ceremony and ongoing liveness from a committee, not just a protocol-level field change. That’s a real operational dependency stacked on top of an already dependency-heavy rollout, EIP-8105 requires EIP-7732 and LUCID requires EIP-2718 and EIP-7805. Adding a threshold-crypto liveness requirement for high-value STs is a fourth moving part in a fork that already needs three to land together. I’d scope this as a follow-up EIP rather than bundle it into the same fork as the base design.

Patch 3 (binding deadlines). Cheap to implement, a new ST ticket field and a comparison at vote time, no new infrastructure. The main deployment question is picking MAX_REVEAL_DELAY correctly: too short and honest publishers with legitimate reorg-confidence concerns get penalized; too long and it barely constrains the strategic-delay behavior it’s meant to close.

Patch 4 (on-chain attribution). Bounded, predictable cost: at most MAX_ST_COMMITS records per slot (a constant already defined in LUCID), each a 20-byte address plus a 32-byte root, so worst-case state growth is fixed and small per slot regardless of network activity. The cheapest patch here to both build and reason about the cost of.

Patch 5 (rotating quorum). The most deployment-sensitive of the five. It replaces a single builder’s merge decision with a three-to-five-way agreement inside the same tight sub-slot window LUCID already operates in, which means the quorum members need low-latency communication with each other on a timeline that’s already constrained by the existing lucid_key_vote_deadline machinery. Worth flagging honestly as a real cost: it may not be viable without first confirming the quorum members can actually reach agreement inside the existing timing budget, which would need to be tested against real network latency before being written into a spec rather than assumed.

Part D — Economic analysis: annualizing the withholding-EV model

My original §1.2 gives the condition under which a publisher rationally withholds: E[V_withhold] - E[V_reveal] > F * 127/128. My original §1.3 works this through for one transaction. Worth extending to an aggregate, annualized figure, since a per-instance number is the right way to show the exploit is real but understates the case for why it’s worth fixing before deployment. This is a rough, illustrative model with every assumption labeled, not a forecast:

  • Ethereum DEX spot volume currently runs roughly $1.5 billion/day across venues (current trackers cluster between about $1.3B and $3.7B depending on the day and source, so $1.5B is a conservative midpoint).
  • Assume LUCID/EEM at maturity captures 5% of that flow as ToB-eligible sealed transactions: $75M/day.
  • Assume 10% of that flow qualifies as autogenous MEV in the sense of my original §1.3, a trade whose own execution reveals a signal worth suppressing to a party positioned to profit from suppression: $7.5M/day in suppressible-value transactions.
  • Assume that, across this pool, the realized suppression value exceeds my original threshold F * 127/128 in roughly 3% of cases, most routine flow posts a tob_fee that isn’t worth forfeiting against, but a small tail of unusually large or price-moving trades makes withholding profitable even at the full penalty.

That’s roughly $225,000/day, or ~$82M/year, in profitable withholding exposure under the tob_fee mechanism as currently specified, before any of the five patches above are applied. Patch 1 (the bond) directly attacks this number by raising the right-hand side of the inequality; halving any of the three percentage assumptions above still leaves a figure in the tens of millions annually, which is the strongest argument for adopting an enshrined, gas-scaled penalty rather than relying on tob_fee alone.

Engaging the authors’ own framing. On the LUCID Magicians thread, jannikluhn (for the Shutter/EIP-8105 team) answers “how does LUCID manage the free option problem?” directly: “Both ToB and Decryptor fees are forfeit for withholding either the key or the decrypted transaction. There are bundling concepts that are implementable in LUCID which are still being explored, and show potential for reducing the optionality available by combining transactions together under the same key.” My original §1.5 (aggregate optionality accumulation) already argues that a publisher observing several STs resolve in sequence gets more informed with each one, so bundling multiple STs under one key and one reveal decision should, if anything, concentrate the option rather than reduce it, since the publisher now makes one binary call gating a larger pool of value instead of several smaller independent ones. That “reduction” only works if a bundle’s forfeiture scales with bundle size (B * tob_fee_per_member) rather than the bundle’s current single aggregate bundle_tob_fee, which is “the aggregate of the tob_fee of all STs in the bundle with executable = 1,” per the spec’s Bundles section, exactly the quantity that doesn’t change the calculus in my original §1.5. Worth asking the authors directly, since the FAQ says the bundling concepts are “still being explored.”

The ToB fee market as a first-price auction. My original §1.4 argues the key publisher holds a monopoly option with no competing mechanism to price it fairly. The commitment_tob_fee ordering rule (descending fee) is a first-price sealed-bid auction for ToB position, run once per slot. The EIP’s own “Competition for the ToB” rationale section makes an information asymmetry explicit: a sender extracting exogenous MEV with value V_e can support a ToB fee of roughly pV_e/((1-p)+p/F), while a sender protecting autogenous MEV of value V_a posts closer to FV_a. These are structurally different bidding functions, professional MEV extractors are pricing a known opportunity against a known clearing rate, ordinary users are pricing protection for a trade whose value they may not have benchmarked against the going ToB rate that slot. That’s the classic first-price-auction problem: the less-informed bidder either overpays for safety or underbids and loses priority. Worth flagging as a reason wallets should surface a suggested tob_fee benchmarked against recent clearing fees rather than leaving senders to guess.

The EIP-8105 team’s own framing understates this. The EIP-8105 Magicians thread’s “Security & Open Questions” section states: “this influence is constrained to a single bit (key revealed or not)… The remaining risk is bounded, well-understood, and comparable to trust assumptions already present in MEV-aware block construction.” Worth pushing back on “bounded” specifically. The option value behind that single bit is not bounded by anything in-protocol for EIP-8105, since the EIP itself states plainly that “this proposal does not enshrine a fee mechanism for key providers, nor punishments for misbehavior.” A bit is binary, but the payoff attached to choosing one value of that bit over the other is exactly the quantity my original §1.2 and §1.3 model, and it is unbounded in EIP-8105’s own text as it stands today.