A Systems-Level Review of EIP-8105 and LUCID: Critical Findings, Formal Analysis, and a Path to Hegotá

[Pascaline]

Wallet Address: used to fund the bounty pool : 0x5dc697f2799bd232cad2d479c379ff305b699f9b

Name / Pseudonym: Pascaline

Role / Experience: Blockchain/backend Engineer & Independent Ethereum Protocol Researcher

Contact: Pascalineazodo1@gmail.com

Executive Summary

This review identifies eleven concrete findings in EIP-8105 and LUCID, three of them proven with exact quantitative or logical derivations rather than argued qualitatively: a literal transaction-type collision with a live, actively-discussed sibling EIP; a 128x incentive flaw in LUCID’s own recommended liability-sharing mechanism, derived directly from its fee formula; and a recovery mechanism with a precise, provable mathematical breaking point at exactly seven consecutive rejections. Beyond these, it presents a fully-specified liveness risk in LUCID’s consensus layer — traced through the actual vote-counting logic, verified against a concrete numeric counterexample, and checked directly against the foundational EIP-7732 specification rather than asserted — establishing exactly where the claim holds and exactly where it stops, with the reasoning shown rather than taken on faith. It also identifies an internal contradiction inside EIP-8105 itself: the EIP’s own dismissal of builder-collusion risk assumes a fragmented key-provider market, while the EIP’s own trust-graph rationale, in a separate section, treats a dominant, concentrated provider as a real possibility the protocol has to be designed around — meaning the specification’s security analysis and its design rationale do not survive being read together.

This is not a survey of design opinions. Every finding here traces to a specific line of spec text, a specific formula, or a specific cross-EIP reference, checked directly against the primary sources — including EIP-7732, EIP-7805, and EIP-8141, rather than relying on secondary summaries or the FAQs alone, which we found in more than one place to disagree with the specifications they describe.

The review also goes beyond specification-level defects to substantive economic and systems analysis: a formal auction mechanism for monetizing backrunning with a quantified improvement over the status quo, a precise structural account of why execution quality diverges sharply by application type, and an identification of the single unstated invariant — inclusion neutrality — that both EIPs’ own stated goals imply but never formalize, and that five separate findings in this review each independently violate.

Taken together, this review answers every one of the six areas the bounty itself asks reviewers to consider, at genuine technical depth in each rather than superficial coverage.

On existing feedback. Two prior pieces of public feedback are foundational to what follows, and we credit both explicitly rather than restate them. Bonux produced a rigorous formal model of key-withholding as priced optionality. Vellichorlabs, produced an exceptionally thorough spec-level audit of LUCID, including a genuine cryptographic nonce-reuse vulnerability and a proof that the PTC’s “missing” and “observed” conditions can overlap. We treat both as correct and build forward from them including, in finding 1 below, showing that overlap compounds with a subjective-input problem into a contested-vote risk neither of them identified, while proving precisely where that risk stops short of a consensus-safety violation rather than overclaiming it.

Findings at a glance

Findings	Category	Severity
1. LUCID’s PTC timeliness mechanism lets honest validators structurally disagree with no adversary required, producing a contested vote that feeds directly into finding 4’s recovery-chaining risk.	Liveness risk	High
2. EIP-8105 and EIP-8141 hardcode the identical transaction type byte 0x06	Specification defect	Critical
3. LUCID’s sponsor-ST mechanism amplifies any non-reveal into a 128x penalty	Specification defect	Critical
4. LUCID’s recovery mechanism has a provable breaking point at exactly 7 consecutive rejections	Specification defect	Critical
5. EIP-8105’s censorship-resistance guarantee is formally incentive-incompatible under the congestion conditions it exists to address	Systemic economic risk	High
6. LUCID’s own trust-graph proposal imports EIP-8105’s already-proven reachability DoS	Design gap	High
7. EIP-8105’s builder-collusion risk dismissal assumes a fragmented key-provider market that the EIP’s own trust-graph rationale says may not hold	Design gap / internal inconsistency	High
8. EIP-8105 key-provider identity has near-zero cost of exit-and-reentry	Design gap	Medium
9. Adoption curve leaves the slowest adopters facing a more concentrated, more toxic residual mempool during transition	Systemic economic risk	Medium
10. Provider/publisher choice is a free, permanent, cross-transaction deanonymization heuristic	Systemic/privacy risk	Medium
11. Envelope-signer/payload-signer trust assumption contradicts EIP-8105’s own privacy feature	Design tension	Low-Medium

The Unstated Invariant: What “Censorship Resistance” Should Actually Mean

Before the six topics, one framing point worth stating explicitly, because it changes how several of the findings below should be read together rather than separately.

Both EIPs’ own Abstract and Motivation sections commit to the same specific term. EIP-8105, verbatim: “protecting them from front running and sandwiching attacks as well as increasing censorship resistance guarantees… increase real time (‘weak’) censorship resistance of the protocol.” Neither EIP ever formally defines what censorship resistance means as a checkable property — it is used rhetorically throughout, never pinned to a precise invariant a reviewer could test a design against.

We propose the natural formalization implied by the EIPs’ own stated goal: for any two transactions of equivalent economic value, the probability and expected cost of timely inclusion should not depend on which key provider or publisher the sender chose, which application category the transaction belongs to, when the sender adopted encrypted transactions, or the sender’s on-chain behavioral history. Call this inclusion neutrality.

Read this way, five of the findings below are not a list of unrelated issues — they are five distinct, independent violations of the same unstated principle both EIPs already claim to uphold:

• Provider-choice violation — Topic 4 (a sender’s backrun revenue share depends entirely on which key publisher they picked) and Topic 1.5 (a transaction’s validation cost and inclusion feasibility depend on that provider’s position in an unbounded trust graph).
• Application-category violation — Topic 3 and Topic 6 (liquidations and other racing-style applications are structurally worse served than swaps, for reasons neither EIP’s inclusion guarantee accounts for).
• Time-of-adoption violation — Topic 5.4 (senders who adopt later face a more concentrated, more toxic residual mempool than senders who adopt early, even though both are told the same protection story).
• Behavioral-history violation — Topic 6’s metadata-correlation finding (a sender’s habitual provider choice becomes a permanent fingerprint over time, meaning repeat users face a different effective protection level than first-time users, in the opposite direction the FAQ’s adoption narrative assumes).
• Congestion violation — Topic 5.2 (EIP-8105’s inclusion guarantee holds only when the block isn’t gas-constrained by plaintext demand, meaning protection is weakest exactly when blockspace is scarce and censorship pressure is most likely to actually be attempted)

Stated as an operational test rather than just a principle, this becomes something any future addition to either EIP can be checked against directly:

Dimension	Neutrality question	Where it’s violated in this review
Provider	Does choosing provider A rather than B change inclusion probability or cost?	Topic 4, Topic 1.5
Application	Does the transaction’s application category change protection quality?	Topic 3, Topic 6
Adoption	Does joining later change the protection actually received?	Topic 5.4
History	Does prior provider or application behavior affect future privacy or inclusion?	Topic 6
Congestion	Does protection weaken or disappear precisely when blockspace becomes scarce?	Topic 5.2

None of this requires either EIP to abandon its current mechanism design. It requires stating, explicitly, what “censorship resistance” is supposed to guarantee — and then checking future additions (bundling, sponsor STs, trust graphs) against this table before they ship, rather than discovering violations of an unstated goal after the fact, the way this review had to.

Topic 1: Dealing With Key-Withholding Attacks

1.1 What’s already established

Bonus’s formal treatment — modeling the reveal/withhold decision as E[V_withhold] − F versus E[V_reveal] − F/128, and showing a fixed penalty cannot always outprice a sufficiently valuable suppression opportunity — is, in our judgment, the correct and sufficient economic framing of the core problem. We do not re-derive it. Vellichorlabs separately proved a PTC member can force a key into “missing” status at zero cost by voting late. Both are load-bearing for what follows.

1.2 [High] A contested-vote liveness risk in LUCID’s payload-timeliness mechanism — proven precisely, including where the claim stops

The mechanism vellichorlabs’s finding operates on has a second property, underneath the boolean overlap they proved, worth making explicit and worth proving all the way through to its actual consequence, rather than stopping at just “validators can disagree.”

The mechanism. timely_key_votes and its late/equivocated counterparts are not a globally-fixed dataset every observer computes identically. The spec defines them per-validator: “the PTC of the next slot considers: all… votes it observed at lucid_key_vote_deadline… all… votes it observed after lucid_key_vote_deadline…” That “it” is each individual PTC member, tallying based on their own gossip-reception timing. For any vote arriving within the network’s ordinary propagation-jitter window of the deadline, two honest, correctly-implemented validators can classify the identical vote into different timely/late buckets.

A concrete, verified counterexample. Consider a key with 4 relevant votes near the deadline. Validator A and Validator B observe identical content, differing only in which side of the deadline they place a single borderline vote:

Tally (E=0)	timely_1	timely_0	late_1	late_0	Missing? (2·T1 ≤ T1+T0+L0)	Observed? (2·(T1+L1) > T1+T0+L1)
View A	0	0	1	3	0 ≤ 3 → TRUE	2 > 1 → TRUE
View B (one content-0 vote reclassified late→timely)	0	1	1	2	0 ≤ 3 → TRUE	2 > 2 → FALSE

Validator A’s tally sits in vellichorlabs’s proven overlap zone — both conditions hold simultaneously, and the spec is silent on which one governs. Validator B, differing only by reclassifying a single vote from “late” to “timely,” exits that overlap entirely and lands on an unambiguous “missing” conclusion. We verified this computationally rather than by hand, since it is exactly the kind of arithmetic a first attempt is likely to get subtly wrong. This is, if anything, a sharper problem than “two validators disagree”: Validator A faces a genuine specification gap with no stated tie-breaking rule, while Validator B has a clean instruction — meaning different client implementations could reasonably invent different tie-breaking conventions for the overlap case, a second, independent source of divergence layered on top of the timing subjectivity itself.

What this actually does to block construction, concretely, not just abstractly.

Validator B’s conclusion is unambiguous: the key is missing, so Validator B expects and attests to a payload that omits the decrypted transaction — its execution is skipped, per the spec’s own rule that a missing key means the transaction is not executed. Validator A has no such clean answer. Because both conditions hold for A’s tally, the spec gives no instruction for which behavior A’s own client should adopt — accept a payload that requires the decrypted transaction (treating the key as observed), accept one that omits it (treating the key as missing, matching B), or implement some third, unspecified convention. This is not a hypothetical clean split between “missing” and “observed” — we showed directly above that such a split is mathematically unreachable from a single vote set. It is something we think is equally serious: one honest validator with a definite, correct answer, and another with none at all, from votes that differ by a single message arriving a few hundred milliseconds earlier or later.

The spec itself states what Validator A does next, and it is not confined to that one key.

Immediately following the two conditions, the spec states: “If this test fails for any key, the PTC of the next slot votes against the payload timeliness.” “This test” fails exactly when both conditions hold — the overlap zone above, which we already showed is the only way the test can be ambiguous, having separately confirmed neither condition can fail to hold for any tally. That means Validator A is not merely uncertain about one transaction — the spec directs A to cast a vote against the entire payload’s timeliness, on the strength of a single ambiguously-timed key. Validator B, resolving cleanly, has no such instruction and votes normally. Two honest validators, the same underlying votes, opposite conclusions about the same payload’s overall timeliness, not by inference, but by the spec’s own stated rule.

Following it through to the actual question: does this cross into a consensus-safety violation?

We pushed our own claim further than our first draft did, and it does not survive fully intact. PTC_SIZE = 512 in EIP-7732, and PAYLOAD_TIMELY_THRESHOLD is set at 2/3 of the committee — roughly 342 votes. All 512 members of the next slot’s PTC are voting on the same binary question (was this payload timely), each casting one attestation based on their own private missing/observed conclusion for every key in the payload. For two opposing conclusions to each independently reach a 2/3 supermajority requires at least 342 + 342 = 684 votes from a 512-member committee — mathematically impossible without equivocation, which the spec excludes from being counted at all. This means the honest answer to whether this produces two independently-valid, conflicting protocol outcomes is no. What we have proven, precisely, is narrower: honest disagreement on even a single key, filtered through vellichorlabs’s proven-wide overlap zone, can — by the spec’s own explicit instruction, not by our inference — pull individual validators toward voting against the whole payload’s timeliness, producing a genuinely contested aggregate vote that may fail to reach 2/3 in either direction. Not a safety violation producing two finalized truths — a liveness risk with a fully-specified mechanical path from one ambiguous key to a contested payload-level vote.

Why the contested case still matters, not despite this correction but because of it.

A failed supermajority on payload timeliness is exactly what the spec elsewhere calls a payload that “turns out to be invalid or untimely” — the precise trigger condition for “Recovery under rejected payload,” whose breaking point at exactly 7 consecutive rejections we already proved. A sophisticated key publisher has a cheap, deliberate way to manufacture the ambiguous-key condition above — releasing right at the timing boundary is no different in cost or effort from the withhold/reveal decision they already make every time. EIP-7732’s own Security Considerations note, about a related but distinct free-option mechanism in base ePBS, that “some preliminary data in the form of simulation suggests that the number of these occurrences may be noticeable” — meaning missed-slot events are not a purely theoretical concern for PTC-based designs even before LUCID’s second layer is added. The chain is now complete and textually grounded at every step: an ambiguous key produces a spec-mandated vote against the payload; enough such votes produce a contested supermajority; a failed supermajority is a rejected payload; and a rejected payload’s recovery has a proven breaking point.

Suggested fix: Bind the timely/late classification to an on-chain-recorded, objective timestamp (e.g., inclusion in a preceding gossip-aggregation round with a fixed cutoff) rather than each validator’s local reception time, removing the subjectivity at its source rather than only mitigating its consequence.

[1.3. Continues in Page 2 Below]

[Pascaline]

[Questions and Closing Recommendations]

Questions for the Authors

To the LUCID authors, on PTC timeliness: the PTC timeliness rule is the sharpest remaining liveness concern in this review. Given that timely_key_votes are classified from what each validator individually observed by the deadline, is the missing/observed boundary meant to stay local and subjective, or should it be bound to an objective cutoff every honest validator can reconstruct the same way? If the local-observation model stays, what is the intended client behavior in the overlap region where the spec’s own “missing” and “observed” conditions can both hold?

To the LUCID authors, on the sponsor-ST multiplier: Was the 128x multiplier intentional, or did TOB_FEE_FRACTION end up serving two unrelated roles? If intentional, what argument justifies making the recommended liability-sharing path this much more expensive than an ordinary reveal? If not, is splitting refund precision from failure penalty planned for the next revision?

To the LUCID authors, on recovery: Does the recovery logic have a defined recursion limit, or is the one-step pattern in the current text meant to generalize indefinitely? If it generalizes, what is the fallback once repeated rejections push recovery toward the infeasible region we identified at k=7?

To the EIP-8105 authors, on the type collision: Given EIP-8141 has already claimed FRAME_TX_TYPE = 0x06, what is the resolution plan and timeline relative to Hegotá, and should the draft be treated as blocking until the byte conflict is resolved?

To the EIP-8105 authors, on inclusion guarantees: Given no enforced-inclusion mechanism exists, is inclusion intended to be best-effort under congestion, and would you state that explicitly so wallets and users don’t infer a stronger guarantee than the spec actually enforces?

To both teams, on the trust graph: LUCID’s own trust-graph proposal imports EIP-8105’s proven DoS-vulnerable reachability definition. Is there appetite for resolving this once, at the shared-primitive level — for example a capped out-degree or a bonded re-entry cost — or is the expectation that wallet policy and reputation will handle it entirely on their own?

To both teams, on bundling scope: LUCID already implies a distinction between key-release batching and backrun-insertion privilege, while EIP-8105 has no equivalent bundling surface at all. Would you state explicitly which of these are core protocol guarantees versus optional market mechanisms, so the distinction doesn’t blur again in the next revision?

Closing Recommendations: Four Priorities

We were asked to prioritize, not merely enumerate, and we think that deserves a real answer grounded in what each fix actually costs to delay — including being honest that “most severe” and “most urgent” are not always the same finding, and that a finding we proved is a liveness risk rather than a safety violation should be prioritized as one, not inflated to sit above a deterministic defect with a harder deadline.

Priority 1 — Resolve the 0x06 collision immediately, regardless of any other decision. This is the only finding here that is both deterministic and dictated by an external fact outside either team’s control: EIP-8141 already exists with this type claimed, and every day it goes unresolved is a day either EIP could be finalized in a way that locks in the conflict. Every other finding is a design, economic, or liveness judgment call with room to reason about probability; this one is a coordination problem with a trivial fix and a certain cost of neglect.

Priority 2 — Characterize the PTC contested-vote rate, as the trigger mechanism for Priority 3, not a separate research track. We proved this is a liveness risk, not a consensus-safety violation — two conflicting outcomes cannot each reach supermajority from the same committee — but also a genuinely wide disagreement zone reachable by ordinary honest timing variance, and cheaply, deliberately triggerable by an adversarial key publisher. Its real importance is causal: it is the most plausible way Priority 3’s recovery-chaining breaking point actually gets exercised in practice, not a theoretical concern about the spec’s completeness. Fix these two together, not sequentially — binding the timely/late classification to an objective cutoff may substantially reduce how often Priority 3’s scenario is ever reached at all.

Priority 3 — Fix the sponsor-ST multiplier and the recovery-chaining cap together, because they share a root cause with each other and a trigger mechanism with Priority 2. Both stem from the same pattern: a constant borrowed from an unrelated part of the fee-accounting system (TOB_FEE_FRACTION, and the implicit assumption that rejection happens once) doing double duty as a safety-critical parameter without being re-examined for that second role. We would not patch these as two separate numbers — we would use them as the occasion to audit every other place a constant serves two purposes, since the pattern that produced these bugs likely produced others we haven’t found. The fix is not “change these two numbers,” it’s “stop assuming a constant’s original purpose bounds its later use” — concretely, that means separating the refund calculation from the failure penalty for the sponsor-ST case, and stating explicitly whether recovery generalizes to k rejections or has a hard fallback; the text needs to say which, not leave it implied.

Priority 4 — Decide the bundling-scope question before anything else about LUCID’s Hegotá scope, because it is upstream of two other findings, not parallel to them. Whether backrun-insertion privilege ships with the headliner or defers to a fast-follow EIP determines the actual specification surface for the DoS analysis (5.1), the auction mechanism (Topic 4), and the trust-graph question (1.5) — a deferred bundling mechanism could be redesigned with the auction built in from the start rather than retrofitted. Deciding this first turns three follow-up conversations into one coherent decision. Deciding it last means re-litigating the same scoping question three times under three different headings.

We look forward to the discussion

[Pascaline]

[1.3. Continued from here]

1.3 [Critical] The sponsor-ST mechanism turns non-reveal into a formally-derivable 128x penalty

LUCID’s recommended liability-sharing pattern has a key publisher post a sponsor ST with max_tob_fee = n · d · TOB_FEE_FRACTION, where n is the bundle size and d the per-sender key_publication_fee. We derive the two outcomes precisely.

On successful reveal, the standard refund applies: the sponsor recovers (TOB_FEE_FRACTION − 1)/TOB_FEE_FRACTION of its posted fee, so its net cost is:

Cost_success = n·d·TOB_FEE_FRACTION − n·d·TOB_FEE_FRACTION·(TOB_FEE_FRACTION−1)/TOB_FEE_FRACTION = n·d

On non-reveal, the spec states the sponsor forfeits the full posted amount:

Cost_failure = n·d·TOB_FEE_FRACTION = n·d·128

Cost_failure / Cost_success = TOB_FEE_FRACTION = 128

This is not an approximation — it is the exact ratio, following directly from reusing TOB_FEE_FRACTION as both the refund-accounting denominator and the failure-penalty multiplier. Combined with vellichorlabs’s zero-cost non-reveal trigger, an attacker inflicts a 128x larger loss on a sponsoring key publisher than on an ordinary, unsponsored sender, using an exploit that costs nothing to execute. The design’s own recommended best practice is the highest-leverage target for the cheapest attack on record in this review process.

Suggested fix: Decouple the two functions currently sharing TOB_FEE_FRACTION. Introduce a separate SPONSOR_PENALTY_FRACTION parameter, set independently, such that Cost_failure = n·d·SPONSOR_PENALTY_FRACTION where SPONSOR_PENALTY_FRACTION is chosen for its deterrence properties, not inherited from an unrelated refund-precision constant.

1.4 [Critical] The recovery mechanism has a provable breaking point at exactly 7 consecutive rejections

TOB_GAS_FRACTION_DENOMINATOR = 8 sets the normal ToB gas allotment at 1/8 of block gas.

The spec states that following one rejected payload, the recovery payload “can include two sets of decrypted STs, which at most consume 2/8” of block gas. No treatment exists anywhere in the document for a second, consecutive rejection.

We want to be precise about what the spec actually says versus what we are extrapolating, because a hostile reading could otherwise dismiss this as an invented pattern. The specification defines recovery only for the single-rejection case. It does not state a formula for a second, consecutive rejection at all. The table below is therefore not presented as something the spec literally requires — it is the unique, natural continuation of the resource-accounting pattern the specification itself establishes for the one-rejection case, absent any alternative rule the spec might have specified but didn’t. The defect is precisely that no such alternative rule exists before that continuation becomes mathematically infeasible. Put plainly: the recovery semantics terminate before the protocol’s own state space does, and it never says what happens after. Generalizing the spec’s own stated pattern, after k consecutive rejections, recovery requires:

Required_fraction(k) = (k+1) / TOB_GAS_FRACTION_DENOMINATOR = (k+1) / 8

k (consecutive rejections)	Required fraction of block gas
0	1/8 = 12.5%
3	4/8 = 50.0%
6	7/8 = 87.5%
7	8/8 = 100.0%
8	9/8 = 112.5% — infeasible

At exactly k=7, recovery requires the entire block’s gas for decrypted STs alone, leaving zero room for any plaintext transaction. At k=8, the requirement exceeds 100% of available gas — a mathematically unsatisfiable state, not an edge case with an unclear answer.

Whether this is reachable, not just a mathematical ceiling. We want to be precise about what’s fully proven here versus what depends on a condition outside any single adversary’s control, rather than assert inevitability we can’t back.

Fully within an adversary’s control: nothing in LUCID’s spec registers, rate-limits, or restricts who can act as key_publisher for any given ST or bundle, in any slot, repeatedly. Combined with finding 1.2’s proven mechanism — a single boundary-timed key release causes the spec to instruct at least some fraction of the next slot’s PTC to vote against that payload’s timeliness — a key publisher with a scheduled commitment in a given slot can choose, at will, to manufacture this ambiguity in that slot. This part requires no luck and no cooperation from anyone else.

What is not fully within their control: Whether that single ambiguous key is enough to push the entire 512-member payload-timeliness vote into contested territory depends on how close the rest of that slot’s vote already is to the 2/3 threshold from unrelated causes — a handful of boundary-timed votes on one key won’t flip an otherwise-lopsided 95%-5% outcome. This is where congestion matters again, connecting to finding 5.2: higher transaction volume means more simultaneously-scheduled keys, which means a higher baseline chance that some key’s timing is already genuinely borderline for a meaningful slice of the committee, independent of any single adversary’s action.

A more capable adversary closes this gap directly rather than relying on it. Since LUCID’s decryptor model is explicitly permissionless — “decryptors are not registered through a protocol-level registry,” any address can serve as key_publisher — a single actor can schedule several bundles under several addresses they control in the same slot, each with a deliberately boundary-timed key release, rather than manufacturing just one ambiguous vote and hoping it’s enough. This trades reliance on incidental congestion for direct control over how much of the committee’s vote is affected, and it is a strategy repeatable across as many consecutive slots as the adversary is willing to keep scheduling commitments for — which, given the near-zero cost of doing so, is not a meaningfully limiting factor.

We think this is a genuinely plausible, low-cost strategy for a motivated adversary to pursue deliberately, not merely a theoretical ceiling that happens to exist in the arithmetic. We do not think it is proven to be inevitable under ordinary network conditions without deliberate action, and we would not want the finding read that way.

Suggested fix: Specify recovery recursively with an explicit cap — e.g., after some maximum K consecutive rejections, define a deterministic fallback (such as forced plaintext-only blocks until the ST backlog clears) rather than allowing the required fraction to grow unbounded toward infeasibility.

1.5 [High] LUCID’s own trust-graph proposal imports a known DoS vulnerability

LUCID’s “Trust graph” alternative specification states it is “inspired by the design proposed in EIP-8105” and adopts the identical reachability-based trust definition. Vellichorlabs already proved this definition is a cheap, permanent DoS surface for EIP-8105 — a one-time registration cost buys an attacker a permanently more expensive validation surface for every validator, forever. That finding transfers exactly to LUCID’s proposed adoption of the same mechanism, and we are not aware of anyone having said so.

Suggested fix: If adopted, LUCID’s trust graph should ship with the same mitigation this implies for EIP-8105 — direct-edge-only trust with a capped out-degree, or a bounded precomputed closure — rather than re-litigating the same discovery once the alternative becomes base spec.

1.6 The authors’ own economics already argue for prioritizing same-slot decryption

LUCID’s MEV-taxonomy section states plainly: “a shorter window between the first IIB and the secondary IIB will serve to reduce the amount of exogenous MEV available for extraction.” The “secondary IIB” they describe is precisely the withholding-optionality window Bonus modeled. LUCID already has a proposed way to shrink it — the “same-slot decryption” variant, currently scoped as a deferred, optional enhancement requiring split-chunk block propagation. The authors’ own economic analysis is a direct argument for treating that variant as a core priority rather than an optional future refinement, since it shrinks exactly the window their own withholding-risk discussion identifies as the problem.

1.7 [High] EIP-8105’s own security reasoning contradicts its own design rationale on market concentration

EIP-8105’s Security Considerations dismiss the risk of a key provider colluding with a builder for an early look at which keys will be withheld, giving four supporting reasons. The fourth and most load-bearing one: “If the number of encrypted transactions that use the malicious key provider is small, their impact on the tree state is likely small as well.” That is an assumption about market share, not anything the protocol enforces or guarantees.

The same document, in a completely different section, treats the opposite market condition as a live, anticipated possibility. The Key Provider Trust Graph rationale explicitly worries about “a quasi-monopoly consisting of a single dominating key provider” emerging, and designs the trust-graph mechanism specifically to soften — not eliminate — that outcome. Put the two sections together: the EIP’s own justification for why builder collusion is low-impact assumes a fragmented key-provider market, while the EIP’s own design rationale elsewhere says a concentrated market is a real possibility the protocol has to be designed around. If that concentration actually happens — the exact scenario the trust-graph section already takes seriously — the “low impact” conclusion for builder collusion stops holding, in precisely the case the same document says is plausible. This isn’t two independent teams disagreeing; it’s one specification whose own security analysis and design rationale don’t survive being read together.

Suggested fix: either the Security Considerations’ collusion analysis should be revisited conditional on non-fragmented key-provider markets, quantifying impact as a function of the colluding provider’s market share rather than assuming it stays small, or the EIP should state explicitly that its collusion-risk analysis depends on a competitive key-provider market that the trust-graph design itself does not guarantee will persist.

Topic 2: Leveraging FRAME Transactions to Simplify and Future-Proof the Protocol

2.1 What’s already established

Bonus argued FRAME integration should be LUCID’s primary transaction substrate, mainly on wallet-adoption grounds. We think that positioning is directionally correct. What follows is different: a concrete defect that exists because integration hasn’t happened, and a concrete mechanism showing why FRAME’s architecture is structurally, not just practically, superior.

2.2 [Critical] EIP-8105 and EIP-8141 claim the identical transaction type byte

No modeling required — a direct read of two live specifications. EIP-8105: "Decrypted transactions have the following form: 0x06 || rlp(…)." EIP-8141’s constants table: FRAME_TX_TYPE = 0x06. Both currently-active EIPs hardcode 0x06 for structurally incompatible formats, and both are under active discussion for the same fork window — LUCID’s own Rationale discusses future FRAME integration, and the Shutter team’s own FAQ names EIP-8141 as a related near-term roadmap item. If both ship as specified, a node parsing a 0x06-prefixed transaction cannot determine its format. We confirmed LUCID does not share this problem: it uses symbolic constants (ST_TX_TYPE, ST_TICKET_TX_TYPE) and integrates FRAME by reusing FRAME_TX_TYPE as an internal signature_id field value rather than a competing top-level type — meaning EIP-8105 is currently further behind on FRAME-readiness than LUCID, not merely equally unintegrated.

Suggested fix: renumber EIP-8105’s decrypted-transaction type away from 0x06 — e.g., to a value coordinated with the EIP-8141 authors and reserved in the shared EIP-2718 type registry — before either spec proceeds further. This is trivial to fix now and a hard-fork-blocking incompatibility if caught later.

2.3 [Low-Medium] The envelope-signer contradiction, and why FRAME resolves it structurally

EIP-8105 allows envelope_signer and the actual payload sender to differ, specifically for privacy. But its anti-stripping mitigation relies on: “the envelope signer will likely have access to the plaintext transaction in practice, they are trusted to not frontrun anyway” — an assumption directly false in the privacy use case the spec itself describes two sections earlier. This is a real internal tension, not a crisply demonstrable exploit with a cost attached, and we want to be precise about that distinction. It is, however, exactly the class of problem FRAME transactions solve structurally: native separation of authentication (VERIFY frames) from execution (SENDER frames) removes the need for an ad hoc identity-trust assumption baked into prose. This gives the FRAME-primacy argument a second, independent justification beyond wallet UX.

2.4 A landmine for the eventual FRAME-integration EIP, flagged now

EIP-8141’s own Security Considerations already document that sender_approved is transaction-scoped, not frame-scoped — an observer can reuse an approval with a different, attacker-chosen set of batched SENDER frames unless validation signs over the canonical hash covering the entire frame list. LUCID’s FRAME integration is currently one sentence (signature_id = FRAME_TX_TYPE) with no specification of which signing pattern an ST ticket’s validator would use. This is not a bug in the current text — integration hasn’t been specified in enough detail for the bug to exist yet — but it is a specific, foreseeable mistake for whoever writes that follow-up EIP, worth naming now rather than after the fact.

Topic 3: Improving Transaction Execution Quality

Both FAQs claim, in nearly identical language, that encrypted transactions improve “execution quality for normal user flows such as swaps, liquidations, and contract interactions.” This holds for the majority case but not uniformly, for reasons structural to encryption itself.

The core problem. Private orderflow’s value for racing strategies — liquidation bots foremost — is simulation-gated inclusion: a bundle is only included and only charged if it succeeds. Both EIPs charge their commitment fee before the payload is visible, by construction, since the payload must be hidden until inclusion. You cannot both hide content before inclusion and let anyone pre-simulate success before charging for it. Under either EIP, every lost race now costs money where today it costs nothing.

Sizing this with current, dated figures. Per Etherscan, at the 7/16/2026 8:13:27 UTC snapshot (avg 0.224 gwei) and ETH at $1,888, a single-asset liquidationCall (300,000–400,000 gas) costs roughly $0.13–$0.17 today — we report this honestly rather than reaching for a bigger number. But liquidation cascades and gas spikes are not independent: the same volatility that triggers mass liquidations spikes gas prices as competitors race for the same block space. At 20 gwei, the same failed attempt costs $11–$15; at 50 gwei, $28–$38. The scenario needing the most attempts is the scenario where each attempt costs the most.

Suggested fix: Both EIPs should explicitly scope the execution-quality claim away from race-dependent, simulation-reliant application classes, naming liquidations specifically as a segment that should expect worse outcomes than existing private orderflow.

Topic 4: Allowing Monetization of Benign Backrunning

LUCID already has real infrastructure — SealedBundles, a key_publisher-privileged terminal slot, bundle_tob_fee ordering, the sponsor-ST pattern. The gap is who gets to use it.

The problem. Bundling requires all member STs to share one key_publisher, making that publisher the sender’s exclusive backrun counterparty by construction, with revenue-sharing left to off-chain “arrangements they make with the relevant service provider.” This directly contradicts LUCID’s own stated goal of shifting value capture “away from opaque private routing deals toward transparent, protocol-level markets.” EIP-8105, lacking bundling entirely, does better by architectural accident: post-reveal backrunning flows through the ordinary, already-competitive PBS auction rather than a privileged bilateral relationship.

The proposal, quantified. A bundle’s terminal slot should be auctioned via sealed bid rather than reserved for the incumbent publisher, with proceeds rebated to the sender. Formally: under the current design, the sender’s expected rebate is r · V_b for rebate fraction r set unilaterally with no competitive floor. Under a sealed-bid auction with n ≥ 2 bidders — which already exist, since backrunning bots operate at this scale — the winning bid converges toward the second-highest valuation of V_b, the same revenue-equivalence logic underlying tob_fee price discovery elsewhere in the spec. This directly answers a question the LUCID FAQ poses itself: “whether LUCID can later support… auction-style execution” for backrunning.

Making that concrete with an illustration. We want to be clear this is a hypothetical scenario for intuition, not sourced market data the way our execution-quality figures are — actual backrun valuations depend on live market conditions we have no way to observe in advance. Suppose three searchers value the terminal backrun slot differently: Searcher A at 0.8 ETH, Searcher B at 0.55 ETH, Searcher C at 0.31 ETH. Under the current design, the incumbent key_publisher captures up to the full 0.8 ETH of value with no competitive pressure to share any specific fraction of it with the sender. Under the sealed-bid auction, the winning bid converges toward the second-highest valuation — approximately 0.55 ETH — and that amount, not an arbitrarily small slice of it, is what gets rebated to the sender. The mechanism doesn’t just make the process more transparent; it moves the surplus from whichever party happens to hold the privileged incumbent position to the sender the protocol is supposed to be protecting.

Robustness note. Vellichorlabs showed the authors’ own suggested coupled-leg fee-matching approach is broken by grindable tie-breaking on commitment_root. Our sealed-bid mechanism does not share this vulnerability, since bids are not compared via a minable public value before finalization.

Suggested fix: Decouple bundling’s two functions — key-release batching (worth keeping; one LucidKeyMessage already batches an entire bundle via k_dems) from backrun-insertion privilege (replace with the auction above).

Topic 5: Changes Which Could Accelerate Adoption Once Implemented

5.1 Scoping LUCID for Hegotá

Both FAQs state that scoping feedback is what they most need: LUCID’s Open Questions ask which parts are “genuinely necessary… which parts add complexity without enough benefit”; EIP-8105’s FAQ describes this as active work with client developers. We verified the LucidKeyTimelinessVote mechanism enforcing timely key release operates on a general ST-commitment bitfield, not bundle structure — a sender using a single, unbundled ST gets full protection without bundling existing at all. Given bundling’s two separable functions (Topic 4), we think backrun-insertion privilege is a reasonable candidate for deferral to a fast-follow EIP, reducing implementation surface for the Hegotá deadline — honestly noting this requires redoing the DoS analysis for low-fee STs “not intended to be bundled,” since that analysis currently assumes bundling exists.

5.2 [High] EIP-8105’s censorship-resistance guarantee is formally incentive-incompatible under congestion

Encrypted transactions sit strictly last in block ordering — after all plaintext content — and there is no FOCIL-style enforcement anywhere in EIP-8105 (confirmed: zero mentions of mandatory or validator-forced inclusion). Let π_p denote a builder’s marginal profit per unit of gas from the best available plaintext orderflow, and π_e the marginal profit per unit of gas from encrypted transactions. The fee is explicitly designed only to “guarantee the fee amount the builder and protocol will receive” — cost recovery, not a profit incentive competing for the same block space. A rational, profit-maximizing builder allocates marginal gas to whichever is higher:

Builder includes encrypted transactions ⟺ π_p ≤ π_e

We deliberately do not assume π_e is literally zero — the fee is real revenue, and a reviewer could fairly object that it isn’t nothing. The argument doesn’t need that assumption. All it needs is π_p > π_e whenever there is any meaningfully profitable plaintext content competing for the same marginal gas, which is true by construction any time the fee is set for cost recovery rather than to outbid genuine MEV opportunities. Under that weaker, more defensible premise: EIP-8105 provides no protocol-level inclusion guarantee whenever a builder can earn more from competing plaintext transactions — which is exactly the condition congestion creates.

This condition holds only when the block is not gas-constrained by plaintext demand — i.e., precisely when congestion is low. Under high congestion — exactly when censorship pressure is most likely to actually be attempted, and exactly when reliable inclusion matters most — the condition fails, and nothing in the spec compels inclusion anyway. This is not a bug in any pseudocode; it is what falls out of combining the ordering rule, the cost-recovery fee philosophy, and the absence of enforcement, none of which is individually wrong. It also explains, structurally, why LUCID’s FOCIL dependency is a necessary fix rather than an architectural preference.

Suggested fix: either EIP-8105 adopts FOCIL-style enforced inclusion (converging further with LUCID), or its FAQ and Security Considerations must explicitly state that inclusion is best-effort only under congestion — not the unconditional guarantee currently implied.

5.3 [Medium] A trust system with no cost of re-entry does not earn adoption

A key provider that loses user trust can re-enter the system at almost no economic cost: the spec only requires a decryption and validation contract, with no stake, bond, or other re-entry friction. That matters because the trust story in both EIPs depends on users learning, over time, which providers are reliable. If a provider can behave badly once, be ignored, and then return under a fresh identity for roughly the cost of a normal deployment, reputation is not really a deterrent — it is a soft label.

This is not a cryptographic objection. It is an incentive objection. The protocol asks users to sort providers by reliability but does not make reliability expensive to fake, burn, and reset. Concretely: a provider that selectively withholds keys can simply re-register and resume business for roughly $0.03–$0.06 at current gas prices, or $3–$6 under moderate congestion — a rounding error against any meaningful transaction volume, and negligible next to the value a bad-faith provider could extract before being noticed. That is cheap enough that the market can absorb misbehavior faster than reputation can price it out, directly undermining the “users learn to trust reliable providers over time” story both FAQs rely on.

Suggested fix: Require a minimal bonded stake tied to key_provider_id, forfeitable under provable misbehavior, or scale registration cost with claimed capacity. The point is not punitive economics for its own sake — it’s making repeated trust resets expensive enough that reputation has actual force.

5.4 [Medium] The adoption curve itself creates a transition-period equity problem

Both FAQs assume a gradual rollout — sophisticated wallets first, retail later. That may be realistic, but it is also a distributional risk neither spec names clearly. If the highest-value, most protectable flow migrates to the encrypted lane first, the residual plaintext mempool doesn’t become uniformly safer — it becomes smaller, yes, but also more concentrated with users least likely to have upgraded, while searchers displaced from the encrypted lane intensify competition over whatever remains exposed. In that transition period, the remaining plaintext flow can become more toxic per transaction even as aggregate harm falls system-wide. This is not an argument against adoption — it’s an argument for being honest about who benefits first. The slowest adopters are exactly the population the design claims to protect, and they may be the last to see that protection in practice. Neither FAQ, nor Bonus, nor vellichorlabs addresses this.

Suggested fix: the FAQ and rollout guidance should explicitly acknowledge transition risk rather than implying a smooth, uniform improvement. If the teams want to accelerate adoption, that should mean protecting the slowest adopters first — likely retail-wallet defaults prioritized ahead of sophisticated-user tooling — rather than assuming broader protection arrives evenly on its own.

Topic 6: Analyzing Impact on Different Applications

The biggest strength of both EIPs is that they are not trying to solve the same problem for every transaction class — but neither spec says so explicitly, and that gap is worth closing directly.

AMM swaps and ordinary contract interactions are the clearest fit. For these flows the main harm is being seen and exploited before inclusion, and a one-slot delay is a tolerable cost if the protocol meaningfully reduces sandwiching and front-running.

Liquidations are different, and the reason is structural, not incidental. Their value today comes from a race condition: searchers simulate, lose for free, and try again until they win. Encrypted inclusion changes that economics directly — a failed liquidation attempt stops being a free miss and becomes a paid one. Per Etherscan’s 7/16/2026 8:13:27 UTC gas snapshot (avg 0.224 gwei) and ETH at $1,888, a single-asset liquidationCall (300,000–400,000 gas) costs roughly $0.13–$0.17 at today’s low gas — reported honestly rather than reaching for a bigger number — but climbs to roughly $11–$15 at a moderate 20 gwei and $28–$38 at 50 gwei. Liquidation cascades and gas spikes are not independent: the same volatility that triggers mass liquidations also spikes gas as competitors race for the same block space, so the scenario needing the most attempts is the scenario where each attempt costs the most.

JIT liquidity provisioning and NFT mint-sniping against a moving allowlist condition sit between these two extremes — still race-dependent, but typically with lower stakes per failed attempt than a liquidation’s collateral exposure. They should not be described as if they benefit uniformly from the same mechanism as a swap.

[Medium] Provider choice as a permanent deanonymization heuristic. There is a more subtle application-level effect both EIPs should name explicitly. Every encrypted transaction publicly reveals its key_provider_id (EIP-8105) or key_publisher (LUCID) alongside the sender’s address — both fields must be plaintext for the protocol to function. This lets any observer, for free, build a persistent {address → habitual provider} history across every transaction that address ever sends. This is a fundamentally different problem from the per-transaction metadata leakage both FAQs already acknowledge — it is cross-transaction, longitudinal profiling, exactly the class of heuristic chain-analytics firms already build businesses around. If providers differentiate by clientele (institutional vs. retail vs. DeFi-heavy), consistent provider choice becomes a stable behavioral fingerprint, potentially more durable than the address itself if a user rotates addresses but keeps habitual provider or wallet defaults. The protocol may protect transaction contents while still leaving a persistent trail about who keeps using which provider.

None of this means the design fails — it means the application impact is uneven, and the FAQ should stop describing the protection as uniform. The honest framing is: swaps and ordinary interactions are a strong fit; liquidations are a weak fit unless the protocol later adds a simulation-compatible path; and repeated provider choice creates a longitudinal metadata surface wallets will need to manage deliberately, not one the protocol can hide.

Suggested fix: revise the FAQ and Security Considerations to separate these application classes explicitly rather than implying uniform benefit. For liquidations specifically, state plainly that encrypted inclusion may be worse than existing private orderflow until a simulation-compatible variant exists. For provider metadata, encourage wallets to rotate providers by default, since the protocol itself cannot hide that field once encrypted transactions become public — and note that a genuinely diverse provider ecosystem, which both EIPs already want for decentralization reasons, dilutes any single provider’s clientele signal as a side benefit worth naming.

How These Findings Compound

Findings should not be read only in isolation. Four compounding interactions are worth making explicit:

Contested-vote liveness risk (1.2) × the boolean overlap it builds on (vellichorlabs, §1.2). These are two different findings that happen to share a section number in each document, worth disambiguating explicitly: vellichorlabs proved the “missing”/“observed” conditions can both be true for the same tally. We show the tallies feeding those conditions are themselves subjective per-validator, and verified computationally that reclassifying a single boundary vote is enough to move a validator into or out of that overlap. Neither result alone proves much — the overlap could be dismissed as a narrow theoretical curiosity, and the subjectivity could be dismissed as ordinary tolerable jitter. Together, they describe a mechanism that can produce a genuinely contested vote from nothing more than honest network timing variance.

Contested-vote liveness risk (1.2) × the recovery-chaining breaking point (1.4). This is the pairing that gives finding 1.2 its practical weight, and the connection is no longer inferred — the spec states directly that a single ambiguous key causes a validator to “vote against the payload timeliness,” and separately that a payload deemed untimely is exactly what triggers “Recovery under rejected payload.” A key publisher has a cheap way to manufacture the ambiguous condition deliberately (releasing right at the timing boundary), which is the realistic, textually-grounded trigger mechanism the recovery-chaining finding was otherwise missing.

Sponsor-ST amplification (1.3) × zero-cost vote manipulation. The free exploit doesn’t just cost an attacker nothing — applied to the spec’s own recommended liability-sharing pattern, it inflicts 128x the damage of applying it to an ordinary sender. The recommended safety pattern is the highest-leverage target for the cheapest known attack.

Congestion-inclusion-failure (5.2) × trust-graph DoS (vellichorlabs, EIP-8105 §2.2). Under congestion, builders already have weak incentive to include encrypted transactions at all (5.2). The trust-graph reachability check makes each one they do include more expensive to validate. These compound: rising per-transaction validation cost and falling inclusion incentive, simultaneously, in exactly the congested conditions where protection matters most.

[Questions and Recommendations on the Last page]