Encrypt The Mempool! - Provide feedback on the draft EIPs (8105 & 8184)

EIPs EIPs core
1

This topic is for submitting claims to the Encrypt The Mempool! bounty on POIDH

10 Likes
2

Okay, I already have a research I want to publish on this

1 Like
4

Title: Feedback on EIP‑8105 + EIP‑8184: key‑withholding optionality, the trust graph, and avoiding “one decryptor to rule them all”

I read both drafts (plus the Security Considerations / Rationale sections), and I want to focus on the part I think is easiest to underestimate: conditional execution optionality — the publish‑vs‑withhold / reveal‑vs‑don’t‑reveal choice. If we don’t tame that, we risk rebuilding MEV in a new shape and quietly pushing users back toward centralized “trusted” paths, which is the exact thing both EIPs are trying to fix.

1) Key withholding isn’t just a liveness footnote — it’s an options market

EIP‑8105 is explicit that a key provider can publish a decryption key or a withhold notice after observing the payload, and that this gives them “one bit of influence over the pre‑state of later transactions” in a block — and that maliciously chosen decryption schemes can make this “much stronger,” effectively enabling front running.[1]

Even “one bit” matters a lot when state has discontinuities. A concrete example:

  • Tx A is an encrypted swap that nudges a price just across a liquidation threshold.

  • Tx B only profits if that threshold is crossed.

The provider for A (or anyone they collude with) can effectively choose A’s inclusion conditional on what else shows up, and reveal only in the states where their downstream position wins. That’s state shaping, not just unreliability.

LUCID embraces the right mental model: an adversary can buy multiple preceding commitments and use them as selectors over ~2^(m-1) pre‑states, with the ToB fee (and the non‑refunded fraction on non‑reveal) pricing that behavior.[2]

The design goal I’d like stated explicitly: make that branching optionality either (a) expensive enough that it doesn’t pencil out, or (b) bounded tightly enough that it isn’t expressive.

2) Concrete suggestions

2.1 The trust graph (8105) is a real centralization vector — possibly the opposite of its intent

Reading 8105’s block‑ordering rule closely: if encrypted tx A is preceded by encrypted tx B, then A and B must share a key provider, or B’s provider must be trusted by A’s provider via the registry’s directed trust graph. The EIP frames this as a compromise so small providers can compete and you don’t get “one provider per block.”[1]

But I think it cuts the other way in equilibrium. The EIP itself says a small provider stays includable next to a dominant one “as long as the small key providers trust the major one.”[1] That makes the dominant provider a de facto required trust anchor: to avoid losing blockspace priority, smaller providers are pushed to point their trust edges at the biggest one — which entrenches the incumbent rather than competing it away. And this “trust” isn’t cosmetic: per §1, trusting an upstream provider means accepting their 1‑bit (or worse) influence over your users’ pre‑state.

Suggestions:

  • The trust graph already lives in state — so make its topology and concentration observable/measurable (e.g., share of encrypted volume whose includability depends on the top provider).

  • Consider giving users a cap on how many distinct preceding providers they implicitly trust (closer in spirit to LUCID’s max_preceding_commitments), so “includability” doesn’t silently require trusting the incumbent.

2.2 Make key‑provider accountability a first‑class (but minimal) option

8105 deliberately leaves provider incentives/punishments off‑chain — its “Lack of In‑Protocol Key Provider Incentives” rationale notes providers only may subject themselves to slashing for unwarranted withholding.[1] I get the desire to keep the core neutral, but “optional, fully off‑chain, per‑provider” accountability is exactly the kind of thing that fragments and then re‑centralizes around whoever markets trust best.

Since the chain already records key presence/absence via the PTC bitfield, a thin standardized layer is cheap:[1]

  • Keep unbonded providers fully permissionless (innovation lane).

  • Add an opt‑in bonded class: post bond B, accept penalties tied only to already‑attested facts (missing/invalid keys for items they were obligated to serve).

A deliberately parameterized sketch:

  • Track missing_key_count / total_key_count over a rolling window W.

  • If missing_rate > r, apply penalty p(missing_rate, volume) (burn or redistribute) and/or suspend bonded status for T epochs.

Wallets can then default to bonded providers without anyone maintaining a private allowlist. Tradeoff: this adds consensus surface area, so it must be strictly objective (PTC‑observed facts only), never a subjective “was the withholding justified?” judgment.

2.3 Make “anti‑branching” defaults wallet‑friendly (especially LUCID)

max_preceding_commitments is a great knob, but if it’s fully free‑form, wallets/apps will pick unsafe defaults and users won’t understand the trade.[2] I’d like a small set of recommended presets (security vs cost), or an enum that maps to safe values. On the 8105 side, since availability is already observable, a canonical “provider reliability score” would let wallets auto‑avoid strategic withholders.

2.4 Execution quality + “benign” backrunning (so users don’t run back to private orderflow)

One worry: “encrypted by default” can feel like worse execution if it kills the benign backrunning/arbitrage that keeps prices honest. I’d like the drafts to explicitly bless benign backrunning and (optionally) a lightweight, advisory sender hint like “backrun allowed” / “backrun‑share allowed” — not protocol‑enforced — so apps adopt encrypted txs without rebuilding a private‑RPC dependency.

3) Deployment notes (and a fairness point between the two)

Credit where due: LUCID already specifies fairly concrete limits — a top‑of‑block gas fraction (tob_gas_limit = block.gas_limit / 8) and a small cap on ST‑commitments per inclusion list (MAX_ST_COMMITS_PER_IL = 2) — which makes its worst case legible.[2] 8105 is lighter here: beyond a “hardcoded small gas limit per key” for PTC validation, I didn’t find explicit caps on encrypted‑tx count or total key‑validation work per block.[1] Since the PTC bitfield + key‑listening duties are now core infrastructure (not an edge case), I’d push 8105 to specify those caps plus a worst‑case gossip/bandwidth story. Yes, caps reduce encrypted throughput early — but they make rollout realistic.

4) My “8105 vs 8184” take (no need to be tribal)

The strongest path, to me, combines:

  • 8105’s neutral, scheme‑agnostic interface + on‑chain observability (PTC‑attested key presence/absence) as the base, and

  • 8184’s explicit economics (pricing selective reveal/branching via ToB fee + max_preceding_commitments) as the safety layer,

while converging toward FRAME (EIP‑8141) over time — LUCID already sketches a FRAME integration path via signature_id, and FRAME generalizes validity/gas payment, which would avoid maintaining multiple bespoke encrypted‑tx types long term.[2][3]

5

Title: Technical Feedback on EIP-8184 (LUCID): On-Chain Resource Pricing, Reveal Optionality, and Trust Assumptions

Having reviewed the specifications for EIP-8105 (Universal Enshrined Encrypted Mempool) and the design progression toward EIP-8184 (LUCID Encrypted Mempool), I would like to offer some constructive technical feedback regarding the implementation trade-offs, potential attack vectors, and game-theoretic dynamics.

1. The Challenge of “Reveal Optionality” and Block Space Spam

One of the most significant challenges in a commit-before-reveal paradigm is reveal optionality. Under LUCID, a user submits a Sealed Transaction (ST) with an associated ST ticket for payment.

  • The Free Option Attack: If users can submit STs and later choose not to reveal the decryption key (or withhold it via off-chain coordination), they effectively gain a “free option” to cancel their transactions if market conditions shift unfavorably between commitment and execution.

  • DoS Vector: If the protocol does not penalize unrevealed/undecrypted transactions, the public mempool can be spammed with sealed payloads, exhausting the network’s processing bandwidth without generating gas fees.

  • Mitigation Trade-off: If the protocol does charge gas for unrevealed transactions (e.g., using the ST ticket’s collateral), it introduces risk for honest users. If a user’s key propagation fails due to temporary network latency or RPC failure, they are penalized financially for a transaction that never executed. EIP-8184 should define strict parameters on how gas is metered for failed/withheld reveals.

2. Cryptographic Scheme Agnosticism vs. Consensus Complexity

LUCID’s decision to remain scheme-agnostic (not enshrining a single encryption technology) is design-friendly but shifts substantial complexity to the consensus and execution clients.

  • Distributed Key Generation (DKG): If threshold cryptography is used, the communication overhead of DKG amongst a large validator set is massive. In a 12-second slot pipeline, threshold decryption latency can easily lead to missed slots or increased block reorg rates.

  • TEEs (Trusted Execution Environments): TEE-based decryption (e.g., SGX) provides low latency but reintroduces hardware centralization and side-channel vulnerability risks.

  • Protocol Enshrining: If execution clients must support multiple pluggable decryption modules dynamically, this broadens the client attack surface. The spec should clarify whether execution clients should enforce a restricted registry of approved cryptographic schemes or support arbitrary external providers.

3. Integration with inclusion lists (FOCIL) and ePBS

LUCID’s integration with FOCIL is logical, but the timing requirements are tight.

  • Latency in Block Construction: Builders must build bids containing commitments to STs before the keys are revealed. Once the block is proposed, keys are released, and execution occurs.

  • Atomic Bundling Risks: If searchers/builders cannot see the contents of STs, they cannot simulate state changes. This prevents traditional MEV searchers from building optimal bundles and could incentivize builders to construct private, un-encrypted side-mempools to maintain execution certainty, undermining the public encrypted mempool’s utility.

Overall, EIP-8184 represents a vital step forward for user protection, but formalizing the penalty rules for reveal failures and optimizing key release latency are crucial hurdles for mainnet viability.

6

Comparative Analysis: EIP-8105 vs EIP-8184 (LUCID)

Submitted to: Ethereum Magicians — “Encrypt The Mempool! — Provide feedback on the draft EIPs (8105 & 8184)”
Category: Technical analysis, tradeoff discussion, implementation critique, economic analysis

Thanks to the authors of both EIPs for the careful proposals. Below is a comparative analysis that maps the design space of enshrined encrypted mempools against three concrete dimensions:

Key-withholding economics (where the trust actually lives)
FRAME / signature-scheme compatibility (a gap I think EIP-8105 has not yet closed)
Execution-quality tradeoffs introduced by max_tob_fee vs. trust-graph ordering
I think both EIPs solve the encryption problem correctly. They differ meaningfully in how they constrain the extractability problem, and I want to argue that the community should converge on a hybrid before either ships in isolation. Specific section references use the EIP as it stands on the master branch of ethereum/EIPs.

  1. Key Withholding: Same Detection, Different Slashing Surface
    1.1 EIP-8105’s model (Rationale: “Decryption Key Withholding”; Security: “Trusted Key Providers”)
    8105 explicitly states:

“The protocol explicitly allows decryption key providers to withhold decryption keys under conditions of their choosing.” (§ Rationale / Decryption Key Withholding)
PTC members attest to a binary bitfield: “did the key provider publish a valid key for envelope i or not?” (§ Specification / Additional Payload Timeliness Committee Responsibilities). The protocol records which keys were withheld, but the EIP defers slashing to off-chain:
“This proposal does not enshrine a fee mechanism for key providers, nor punishments for misbehavior. This allows for a variety of incentive models to be implemented off-chain.” (§ Rationale / Lack of In-Protocol Key Provider Incentives)
1.2 EIP-8184’s model (Specification: “Key timeliness”; Rationale: “Key publisher liability for non-reveal”)
LUCID also does not enshrine slashing in v1, but the structure is richer. PTC votes a per-ST-bitfield keys_observed: Bitlist[MAX_ST_COMMITS] (Specification / Key timeliness) and equivocation is propagated as “first two distinct signed votes”:
“Nodes treat equivocated LucidKeyTimelinessVote messages the same way they do for equivocated ILs in FOCIL: they propagate the first two distinct signed votes they have observed for the same key to signal equivocation.”
The Key publisher liability for non-reveal Rationale proposes a “sponsor ST” pattern as v2 — i.e. a third party can post collateral backing a key publisher’s ST, claim it back on timely reveal, lose it on non-reveal.
1.3 The shared gap
Both EIPs detect withholding but neither punishes in-protocol. I think this is the single biggest open design question, and the framing in both EIPs is too optimistic. Concretely:
Pseudocode — the missing slashing check:

# What the protocol SHOULD do but currently does not (any of):
def process_ptc_vote(slot, key_provider_address, st_index, observed):
    if not observed:
        # LUCID: just record in keys_observed bitfield
        # 8105: just record in PTC payload attestation
        record_withholding(slot, key_provider_address, st_index)
        # MISSING in both EIPs:
        #   slash_stake(key_provider_address, collateral_amount)
        #   demote_kp_in_registry(key_provider_address, trust_score -= 1)
        #   emit_event("KP_DISHONEST", slot, key_provider_address)

The 8105 trust graph (Key Provider Trust Graph, § Rationale) does not demote misbehaving KPs automatically — a user can refuse to use them, but the registry holds no counter. The 8184 sponsor ST punishes users who picked the dishonest KP (they lose the ST fee), not the KP itself. Neither is a credible deterrent for a well-capitalized attacker who runs multiple KPs and rotates identities.
Concrete suggestion (8105): add a slashing_contract address to the KP registry entry. The contract must implement slash(misbehavior_proof) -> uint256. The protocol forwards PTC-derived misbehavior_proof bytes to it. The slash amount is per-KP, optional, but the call must succeed for the key to be valid in the next slot. This is a tiny addition to the registry interface.
Concrete suggestion (8184): keep the sponsor ST pattern, but add a protocol-level minimum commitment: minimum_sponsor_collateral = 0.1 ETH (or equivalent). Below this, the key publisher is not in the active set. The 0.1 ETH is slashed on any equivocating PTC vote, and refunded after N slots of clean behavior. This is a protocol rule, not a contract pattern, and removes the off-chain-reputation assumption.
1.4 The 1-bit attack: 8105’s “TPB” vs 8184’s “post-T₃ window”
8105’s Security Considerations note that a malicious KP can use 1 bit of influence per slot to manipulate the pre-state of later transactions:

“This option gives them one bit of influence over the pre-state of later transactions. Maliciously chosen ‘decryption’ schemes may make this attack much stronger by allowing directly modifying specific parts of the decryption results using crafted decryption keys or setting it outright.” (§ Security Considerations / Trusted Key Providers)
This is qualitatively worse than 8184, because in 8105 the attack window is unbounded within the slot (the KP can withhold as long as the PTC has not yet voted). In 8184, the key publisher only sees the plaintext after T₃ (beacon attestation), at which point the next slot is already beginning. The 1-bit window is therefore compressed to roughly 1/3 of a slot (T₃ → next slot’s T₁).
Concrete suggestion (8184): explicitly bound the “key release window” to [T₃, T₃ + 2s] in the spec, with a hard cutoff enforced by the PTC’s key_observation_deadline. Currently the spec only says “after observing attestations” (§ Specification / Key release), which is vague.

  1. FRAME Compatibility: LUCID’s Quiet Win, 8105’s Open Gap
    2.1 LUCID’s signature_id field (Specification: “ST ticket”)
    LUCID’s ST ticket includes a signature_id: uint8 byte:

“The signature_id is one byte and the signature is interpreted according to signature_id. The only currently valid value for signature_id is EC_DSA_TYPE == 0x01. [
] This design ensures that we do not enshrine non-PQ-safe ECDSA signatures (see further discussion on the relationship to EIP-8141 in the Rationale).” (§ Specification / ST ticket)
And the FRAME integration in the Rationale is explicit:
“LUCID can be integrated with EIP-8141 by allowing signature_id = FRAME_TX_TYPE to indicate that the ST ticket has no standalone signature and must instead appear inside an enclosing frame transaction.” (§ Rationale / Alternative specifications / Frame transaction integration)
This means: when Ethereum L1 migrates to FRAME (EIP-8141) — which the All Core Devs pipeline anticipates for PQ safety — LUCID’s STs work without protocol change, just by setting signature_id = FRAME_TX_TYPE. Wallets and KPs do not need coordination beyond the standard FRAME upgrade.
2.2 8105’s envelope signature (§ Specification / Transaction Types)
8105’s envelope is:

0x05 || rlp([chain_id, envelope_nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_amount,
            key_provider_id, key_id, encrypted_payload,
            envelope_signature_y_parity, envelope_signature_r, envelope_signature_s])

The signature is ECDSA-only, hardcoded by RLP layout (y_parity, r, s triple). There is no signature_id byte. Migrating to FRAME requires re-defining the RLP tuple, which is a hard fork for envelope parsing — every wallet, every KP, every RPC endpoint, every block explorer needs to be re-deployed in lockstep.
This is a deal-breaker for me as a long-term maintainer of a wallet codebase. 8105 effectively enshrines ECDSA into the encrypted mempool layer, and 8141 enshrines post-quantum into the base transaction layer, and the two don’t compose.
Concrete suggestion (8105): add a single byte to the envelope:

0x05 || rlp([chain_id, envelope_nonce, ..., encrypted_payload,
            signature_id, signature_bytes])

Where signature_id = 0x01 is ECDSA (current behavior) and signature_id = 0x02 is FRAME-wrapped. The signature_bytes length is bounded by [MAX_SIGNATURE_SIZE]. This is a 2-line change to the spec and it makes 8105 FRAME-compatible for free. It is by far the highest-leverage change I can ask for.
2.3 Pseudocode side-by-side

# 8105 envelope (current):
class EnvelopeTx:
    chain_id: uint256
    envelope_nonce: uint64
    max_priority_fee_per_gas: uint256
    max_fee_per_gas: uint256
    gas_amount: uint32
    key_provider_id: uint32
    key_id: Bytes32
    encrypted_payload: ByteList[MAX_ENCRYPTED_SIZE]
    envelope_signature_y_parity: uint8
    envelope_signature_r: uint256
    envelope_signature_s: uint256
    # ^^ hardcoded ECDSA; FRAME migration requires re-encoding


# 8184 ST ticket (current):
class STTicket:
    chain_id: uint256
    nonce: uint64
    max_priority_fee_per_gas: uint256
    max_fee_per_gas: uint256
    gas_limit: uint32
    max_tob_fee: uint256
    max_preceding_commitments: uint32
    key_publisher: ExecutionAddress
    key_publication_fee_recipient: ExecutionAddress
    key_publication_fee: uint256
    key_commitment: Bytes32
    reveal_commitment: Bytes32
    ciphertext_hash: Bytes32
    signature_id: uint8                  # <-- key abstraction
    signature: ByteList[MAX_SIGNATURE_SIZE]   # <-- signature scheme is selected by signature_id
    # ^^ FRAME-ready: just set signature_id = FRAME_TX_TYPE

The signature_id byte is the single most important abstraction in LUCID. I would strongly suggest 8105 adopt it.

  1. Execution Quality: Three Designs Side-by-Side
    3.1 The three execution-ordering regimes
    (A) 8105: trust-graph + envelope order
    From § Specification / Block Structure:

“Additionally, if an encrypted transaction A is preceded by another encrypted transaction B, then A and B must either specify the same key provider or B’s key provider must be trusted by A’s key provider.”
So within a block, encrypted txs are ordered by the KP trust graph first (a KP A’s envelopes must come after A’s trusted predecessors), and by envelope order within a trust class. There is no in-band priority signal. The “decrypted txs at the start” rule means the post-state of decrypted txs is visible to plaintext txs but not to later encrypted txs.
(B) 8184: max_tob_fee + max_preceding_commitments
From § Specification / ST ticket:
“max_tob_fee that the sender is willing to pay.”
“max_preceding_commitments executed before the ST, acting as an upper bound.”
These two fields together implement a prioritization auction inside the encrypted mempool. Higher max_tob_fee ⇒ earlier position (subject to max_preceding_commitments not being violated). From § Rationale / Competition for the ToB:
“Senders of autogenous MEV transactions can outcompete a sender extracting exogenous MEV roughly when FBV_a > V_e.”
Where F = TOB_FEE_FRACTION, B = bundle size, V_a = autogenous value, V_e = exogenous value. This is a clean economic model.
(C) Hybrid: 8105 trust graph + 8184 max_tob_fee (with trust-graded commitment count)
This is what I’d like to see discussed. From § Rationale / Trust graph in 8184:
“A future version can therefore replace or complement max_preceding_commitments with max_preceding_untrusted_commitments.”
I think this is the right direction. Concretely:

# Hybrid design
def compute_preceding_position(st: STTicket, block_context: BlockContext) -> int:
    trust_graph = get_trust_graph_at(block_context.slot)

    preceding_untrusted = sum(
        1 for c in block_context.st_commitments_before(st)
        if not trust_graph.is_trusted(st.key_publisher, c.key_publisher)
    )

    preceding_trusted = sum(
        1 for c in block_context.st_commitments_before(st)
        if trust_graph.is_trusted(st.key_publisher, c.key_publisher)
    )

    # Only untrusted commitments count against the sender's bound
    if preceding_untrusted > st.max_preceding_untrusted_commitments:
        revert("too many untrusted preceding commitments")

    # Final position: by max_tob_fee, with trust-trusted commitments not blocking
    return rank_by_tob_fee_descending(st, block_context)

This is the design I think the community should converge on: 8105’s trust graph as the structural anti-MEV primitive, plus 8184’s ToB fee as the expressivity primitive, with max_preceding_untrusted_commitments as the safety knob.
3.2 Timeline diagram (same-slot decryption alternative)
For both EIPs, the commit–reveal timeline differs. Here is a side-by-side ASCII diagram for the baseline design (8184’s Alternative specifications / Same-slot decryption is also relevant for 8105):

                    slot N              slot N+1            slot N+2
                    ──────              ────────            ────────
8105 baseline:
  T0 (slot start)   ─ encrypt & gossip envelope
  T1 (4s)           ─ builder proposes payload w/ envelope
  T2 (~50% slot)    ─ builder publishes exec payload
  T2+Δ              ─ KP observes payload, publishes keys
  T3 (attestation)  ─ PTC votes (keys present: yes/no per envelope)
  T4 (next slot)    ─ decrypted txs (0x06) at start of block N+1 ✓
                     ENCRYPTED ────→ DECRYPTED (1-slot lag)

8184 baseline:
  T0                ─ user broadcasts ST ticket + ciphertext (public)
  T1                ─ beacon block w/ ST_commitments in payload bid
  T2                ─ builder constructs exec payload w/ commitment hash
  T3 (attestation)  ─ beacon block becomes canonical
  T3+Δ              ─ key publisher releases LucidKeyMessage
  T4 (next slot)    ─ decrypted_tx at start of payload N+1 ✓
                     COMMIT-HASH ──→ KEY-RELEASE ──→ DECRYPTED (1-slot lag)

Both have a 1-slot lag. 8184’s commit-before-reveal is slightly more robust because the key publisher cannot see the plaintext until after T₃ (so they cannot front-run a similar plaintext from a different user who submitted at T0+Δ), whereas 8105’s KP sees the plaintext at T2+Δ (before attestation), giving them a marginal MEV window during which to act on it.

Concrete suggestion (both): explicitly commit to a mandatory delay between plaintext observation and reveal. For 8105, this means moving the key publication to after T₃ (attestation), not at T2. For 8184, this is already true but should be specified more strictly.

  1. Application-Specific Impact (Brief)
    I will keep this short, but the EIPs both underspecify application-level walkthroughs.
    Liquidations (Aave, Compound, Morpho): these need priority. 8105’s trust-graph ordering gives liquidators no expressivity. 8184’s max_tob_fee does, but the auction winner is determined by FBV_a > V_e (§ Rationale / Competition for the ToB), which is not a fee-maximization, it’s a value-maximization. In practice this means a searcher with better state queries wins, not a searcher with higher fee. This is a subtle but important point worth spelling out in the spec.
    L2 → L1 withdrawals: these are time-sensitive (7-day fraud window on Optimism, 7-day on Arbitrum, etc.). Sealing them is necessary (front-running is documented and well-understood), but ordering matters because the first withdrawal in a block can be the only one to land before the slot fills. Both EIPs need an explicit walk-through of L2-anchor-tx ordering with the encrypted mempool enabled.
    NFT mints (gas wars): the trust graph (8105) becomes a new attack surface: “who trusts whom” leaks information. LUCID’s max_preceding_commitments is more honest about it. I would lean toward LUCID for this use case despite the centralization concerns, and would love to see a worked example in 8184.
  1. Adoption Path: Phase 1 / Phase 2
    I think these two EIPs are complementary, not competing, and the community should converge on a combined design rather than ship either in isolation.
    Phase 1 (2026-2027, on a sidechain): 8105 ships first because Shutter has a live implementation on Gnosis Chain. Add the signature_id byte (§ 2.3) and a slashing_contract field (§ 1.3) before mainnet consideration. Use this period to gather real-world KP-rotation data, PTC vote distributions, and attack vectors.
    Phase 2 (2027-2028, on L1 with ePBS + FOCIL): 8184’s design (commit-before-reveal, ToB fee, FRAME integration) is the natural L1 fit. A combined EIP would inherit 8105’s trust graph (§ 1.1) and 8184’s max_tob_fee (§ 3.1), using the hybrid max_preceding_untrusted_commitments (§ 3.1) as the safety knob.
    Mainnet activation requires coordination with EIP-7732 (ePBS) and EIP-7805 (FOCIL), which themselves depend on CL/EL client roadmaps. Neither EIP addresses the migration path from Phase 1 to Phase 2, and I would like to see a section in both addressing whether Phase 1 KPs can volunteer as Phase 2 key publishers (trust model compatibility) or whether the role and trust assumptions are different enough to require re-onboarding.
  1. Summary of Concrete Suggestions

EIP Suggestion Section

1 8105 Add slashing_contract to KP registry § 1.3
2 8184 Add minimum_sponsor_collateral protocol rule § 1.3
3 8184 Bound key release window to [T₃, T₃ + 2s] § 1.4
4 8105 Add signature_id: uint8 byte to envelope § 2.3
5 Both Move plaintext observation to after T₃ § 3.2
6 Both Discuss hybrid trust-graph + max_tob_fee § 3.1
7 Both Walk-through of liquidation / L2 / NFT use cases § 4
8 Both Address Phase 1 → Phase 2 migration § 5
Happy to discuss any of these in more detail. The two open questions I am most curious about are (a) whether the 8105 authors would consider the signature_id byte addition, and (b) whether the 8184 authors have a view on the protocol-level (not sponsor-ST) slashing floor. I think both are tractable and would make either EIP significantly more robust to deployment.
— Submitted for the Encrypt The Mempool! bounty on POIDH

7

Key withholding seems like the biggest liveness risk in EIP-8105/EIP-8184. If decryption keys are delayed or selectively released, users could face censorship or failed execution. I suggest adding a clear timeout/fallback rule so encrypted transactions can safely expire or move to an explicit fallback path with user consent.