LUCID encrypts Ethereum's mempool. Same-slot LUCID lets builders decrypt and include protected transactions in the same slot — no extra latency, no compromises.
key_publisher to the same-slot key publisher committeeFallback. If the builder doesn't commit or keys arrive late, standard N+1 decryption applies.
* Steps 3 and 4 happen out-of-protocol. The commitment layer operates before the ABB, breaking the builder/key-publisher circular dependency. Enforcement is hybrid: slashable commitments + FOCIL as the in-protocol backstop.
† Direct builder submission. Latency-sensitive STs can go straight to builders — still encrypted, so contents stay hidden until commit. Direct-to-builder for speed, FOCIL for the CR guarantee.
LUCID's baseline decrypts in slot N+1 — one full slot after submission. That's safe, but for mev-sensitive transactions, an extra slot isn't a fallback. It's the problem.
Price moves in 12 seconds. An extra slot means worse execution or failed trades. Same-slot keeps swaps competitive.
DeFi liquidations are time-critical. Waiting a slot means the position moves, the collateral shifts, the opportunity changes.
Trades conditioned on oracle updates need the current slot's state. N+1 means acting on stale information.
As Ethereum moves to shorter slots, intra-slot windows compress. Designs tied to slot timing break. Same-slot LUCID doesn't.
A pre-ABB economic commitment breaks the circular dependency between builder and key publishers — without touching LUCID's core encryption, inclusion, or mev protection guarantees.
The user encrypts their transaction as a sealed transaction (ST) and sets key_publisher to the same-slot key publisher committee — this is the opt-in for same-slot execution. The ST is broadcast to the LUCID mempool. Contents are hidden from all parties.
The ST propagates via FOCIL inclusion lists for censorship resistance. For latency-sensitive transactions, users can also send STs directly to builders — the ST is still encrypted, so builders cannot inspect contents before committing. Both paths can be used simultaneously: direct-to-builder for speed, FOCIL for the CR guarantee.
The builder identifies same-slot-opted STs (by key_publisher address) and signs a slashable commitment: "I will include STs [x, y, z] at top-of-block." This commitment is accompanied by a payment to the key publisher committee. Block builders commit in parallel — this is leaderless, with no need to know the auction winner. Participation is optional; builders who don't commit simply build N+1 blocks as usual.
The key publisher committee validates the commitment and payment, then releases decryption keys to the builder and broadcasts publicly. Keys are tiny (48 bytes) — they propagate across the network in ~200-500ms, arriving at attester nodes before the block does.
With plaintext access, the builder decrypts STs, inserts them at top-of-block, recomputes the state root, and constructs the Auditable Builder Bid (ABB) covering the complete payload. Full information means optimal block composition — back-running enabled as a price-discovery channel.
The proposer selects the ABB and publishes the beacon block. From the consensus layer's perspective: a normal LUCID block. The only spec change: decrypted_transactions can now carry same-slot STs when the builder demonstrates key availability before ABB construction.
Block builders commit in parallel. No need to know the winner. Compatible with ePBS where the winner is unknown pre-beacon block. Non-winners hold plaintext for transactions already ordered and finalized — no residual advantage.
In same-slot LUCID, builders bear the cost of key access — not users.
The builder pays because plaintext visibility is competitively valuable.
LUCID's base spec includes a small user-paid key_publication_fee for key publisher uptime,
but when users opt into same-slot execution, the builder's payment is the primary revenue signal and may fully subsidize the user's fee.
Three things that make same-slot LUCID work where other approaches don't.
Block builders commit in parallel — participation is optional. Compatible with ePBS where the winner is unknown pre-beacon block. No single builder is the bottleneck.
The commitment window lives outside the consensus path. Same design at 12s, 6s, 3s — doesn't degrade as slot times compress.
Builders pay for keys because it's profitable. Key publishers release because they're compensated. mev protection preserved via slashable commitments + FOCIL.
Builders bear the cost of key access — not users. The builder pays because plaintext visibility is competitively valuable. Users can set key_publication_fee = 0 for same-slot execution since the builder's payment subsidizes key publisher operations.
As Ethereum's slot times compress, this property becomes increasingly load-bearing.
mev protection is preserved. Toxic mev (frontrunning, sandwiching) remains fully prevented — the builder cannot see plaintext before committing. Back-running is preserved and improved: builders get plaintext at build time for more accurate back-run placement. Identical guarantees to N+1, with lower latency.
Keys are 2,300× smaller than a block. They arrive at attester nodes before the block does.
| What | Size | Propagation |
|---|---|---|
| Decryption key (assembled) | 48 bytes | ~200-500ms |
| Full key publisher shares (100 key publishers) | 4.8 KB | ~200-500ms |
| Typical Ethereum block | ~110 KB | 1-3s (98% under 4s) |
| Block with blobs | ~400 KB | 97% under 4s |
| Max blobs per block (Pectra) | ~1,152 KB | 97.1% sub-4s |
Same-slot encrypted execution touches every layer of the mev supply chain.
Back-running as a legitimate price-discovery channel. Strategies execute in the same slot, not delayed by one. Better execution quality, same mev protection for users.
Full state visibility before building solutions. No blind ordering means fewer reverts, better routing, tighter spreads for intent-based protocols.
Build with plaintext, not blind. Optimal block construction. Conditional commitments mean you only pay when you win. The economics work in your favor.
A same-slot path that's slot-time agnostic, ePBS-compatible, and incentive-complete. One minimal spec change to LUCID's decrypted_transactions.
Same-slot execution is part of the LUCID encrypted mempool initiative.
Full specification on ethresear.ch with timing analysis, game theory, and LUCID compatibility.
Accepted at Encrypt The Mempool #3 as a candidate same-slot path. LUCID authors aligned on direction.
Joint working session with the encrypted mempool community to finalize the path forward.
Proof of concept: A related implementation is deployed on Hoodi testnet using Shutter's threshold encryption (3-of-5 key publishers) and staked builder commitments. github.com/shutter-network/primev-sequencer →