Why
The briefing reads as if the question is still open — developers will meet, encryption is being considered, no scheme is ready. Two of those are true and one is not. There are already two competing drafts on the table: EIP-8105, which enshrines a technology-agnostic key-provider layer, and EIP-8184 (LUCID), which makes the builder commit to sealed payloads before it can read them. So the design space is no longer "should we"; it is "which failure do we accept." And the failure worth naming is not cryptographic strength. EIP-8105's envelope stays in the clear by construction — chain ID, nonce, priority fee, max fee, gas amount, key provider ID, key ID, and the signature components, which means the sender is recoverable. Ethereum's own pattern documentation states the consequence without hedging: size, gas limit, and sender address remain visible before decryption and can still enable inference attacks on large or identifiable trades. A sandwich bot does not need your calldata to know that a known DEX router address just posted an unusually large gas limit and bid aggressively to get in. It needs to know that a big trade is coming and roughly how big. Encryption removes the exact number and leaves the shape. So the claim worth testing is not whether encrypted mempools work; it is how much of the extracted profit the leftover metadata still funds. That number decides whether this is a fix or a tax.
How it works
Three measurements, cheapest first. One, the residual-MEV replay. Take a window of historical mainnet blocks, strip every transaction down to only the fields EIP-8105 leaves in plaintext — sender, nonce, gas amount, priority fee, max fee — and try to select the sandwichable ones from that alone. Score the selection against the sandwiches actually extracted in the same window; the relay and bundle plumbing the live pbs card already built is the labelling path, so this is analysis on top of existing infrastructure rather than new infrastructure. The output is one fraction: the share of extracted profit a metadata-only adversary could still have targeted. Publish it whichever way it comes out — a low number is the strongest possible argument for the EIPs, and a high one is the strongest argument against calling this solved. Two, the two-block bill. EIP-8105 executes the envelope in one block (nonce incremented, fees paid) and the decrypted payload in the next, and the fee is paid even when decryption fails. So encryption costs a block of latency plus a failure mode where the user pays for nothing, against a status quo where routing through a private relay costs zero at the point of use. Model the crossover: at what trade size does the sandwich you avoid exceed the latency and failure cost you accept? Below that line, users rationally keep using private relays, and an encrypted mempool that the largest traders route around has not fixed the centralization it was meant to fix. Three, the failure nobody can attribute. The unresolved item on the call was that the protocol cannot establish why a key failed to arrive, or whether a provider sold it early. Build the smallest possible simulator — n key providers, threshold k, one colluding subset — and generate three traces: a key withheld deliberately, a key leaked early, and a key that was merely late. Then ask the only question that matters for enforcement: from outside, are the three distinguishable? If they are not, slashing has nothing to attach to, and the honest-threshold assumption is not an assumption but the entire security model. Reads against the live pbs card, which sits on the extraction side of the same market, and alongside third-party-blast-radius, which asks the same committee-capture question of every threshold scheme.