Same-Slot Decryption for LUCID: Optional N Execution with N+1 Fallback

murat · April 1, 2026, 5:26pm

Abstract

Encrypted mempools eliminate toxic mev but introduce a timing problem. LUCID decrypts sealed transactions in slot N+1 (a full slot after submission) because the builder’s commitment (ABB) lives inside the beacon block and can’t be observed before the slot finalizes. This creates a circular dependency: builders must commit before seeing plaintext, but decryptors need to see commitment before releasing keys. The slot boundary resolves it, at the cost of ~12 seconds of latency and a block’s worth of state changes.

We observe that this dependency can be broken earlier. If the builder makes an economic commitment before constructing the ABB, backed by slashable collateral and a payment to the keyper committee, keypers can release decryption keys within the same slot. The builder decrypts, inserts at top-of-block, and constructs the ABB over the complete payload. From the consensus layer’s perspective: a normal LUCID block.

This requires one minimal spec change (decrypted_transactions carrying same-slot STs), no new fields, and no changes to LUCID’s encryption, inclusion, or mev protection guarantees. The new trust assumption is the liveness of keypers and slashing enforcement. Users opt in via decryptor_address and fall back to N+1 when conditions aren’t met.

Same-slot execution reduces latency, strengthens execution guarantees against stale state, and aligns builder incentives while preserving LUCID’s key properties.

1. Optimizing Execution Under LUCID with Slot N Optionality

LUCID’s N+1 design is driven by a circular dependency:

The builder must commit to including STs (via the Auditable Builder Bid) before seeing their plaintext, otherwise the builder could selectively exclude or reorder based on content.
Decryptors should release keys only after this commitment, otherwise the builder could see plaintext and equivocate.
The ABB lives inside the beacon block. By the time the ABB is observable on the network, slot N’s payload is finalized.

The slot boundary between N and N+1 resolves this cleanly. Our proposal resolves it differently: move the commitment signal earlier than the ABB.

Pre-ABB economic commitment

The builder already has the ST ciphertexts (FOCIL inclusion lists propagate them during slot N-1) and a block template under construction. What the builder lacks is the decryption keys.

If the builder signs an economic commitment backed by slashable collateral and accompanied by a payment to the keyper committee contract affirming inclusion of specific STs, keypers can treat this as a valid commitment signal and release keys before ABB construction. The builder pays for early key access because the back-running value and block composition advantage exceed the cost (see Section 5).

Flow

Slot N-1:  User encrypts tx as ST, broadcasts to LUCID mempool.
           FOCIL committee propagates ST in inclusion lists.
           Builder receives ciphertexts via ILs, builds block template
           with regular transactions.

Slot N:    Builder identifies STs whose decryptor_address is the
             same-slot keyper committee.
           Builder commits on out-of-protocol network with payment
             to keyper committee contract:
             "I will include STs [x, y, z] at ToB"
           Keypers validate commitment + payment, release decryption
             keys to builder AND broadcast publicly.
           Builder decrypts STs, inserts at ToB of existing template,
             recomputes state root.
           Builder constructs ABB covering complete payload.
           Proposer selects ABB, publishes beacon block.

           From the consensus layer's perspective: a normal LUCID block.

Fallback:  If builder did not commit, or keys arrived late,
           standard LUCID N+1 decryption applies. No degradation.

Same-slot decryption is an incremental update to an already-built block template; decrypt, insert at ToB, recompute state root: taking ~1-2 seconds.

Anti-equivocation and economic security

In N+1, the slot boundary prevents equivocation. In same-slot, economic slashing serves this role. The slashing condition is deterministic: a builder is slashed if they sign a commitment to include STs [x, y, z] but the winning block omits any of them. The commitment is self-authenticating (builder’s signature), and inclusion is verifiable on-chain via decrypted_transactions with no subjective judgment or committee vote.

FOCIL provides a protocol backstop: ST inclusion is mandated regardless. A builder who receives keys and omits STs faces both economic slashing (commitment network) and protocol penalties (FOCIL). The economic commitment reinforces what the protocol already requires.

Collateral must exceed the maximum extractable value from seeing plaintext and reneging. Since decrypted txs go at ToB with protocol-determined ordering, equivocation yields no reordering value. Enforcement is on-chain: a fraud proof contract verifies the builder’s signed commitment against the decrypted_transactions field in the finalized block; no committee or subjective dispute resolution. If keypers go offline, same-slot degrades to N+1. We get latency regression, not safety failure.

Why the builder

In ePBS, the proposer is a passive bid selector. The builder constructs execution payloads and is the only entity with the infrastructure for same-slot: persistent keyper connections, optimized decryption routines, and pre-staged block templates. As slot times compress, this sophistication becomes more essential.

3. Key Distribution and Attestation

Attesters’ EL clients must independently verify the decrypted_transactions field, which requires decryption keys. The primary engineering concern is whether keys propagate fast enough for attestation.

Key propagation feasibility

Public key release is safe: LUCID’s ToB placement is deterministic (ordered by tob_fee), so no participant gains an exploitable ordering advantage from early plaintext access. Keypers broadcast keys publicly alongside builder delivery.

How realistic is propagation within the attestation window? We compare decryption key sizes against payloads the network already handles.

Decryption key sizes. Shutter uses BLS12-381 threshold encryption. An assembled decryption key is one G1 point: 48 bytes compressed. For a realistic keyper committee (Shutter’s Gnosis deployment uses 7), the full share data before aggregation is 336 bytes to 1 KB. Even at 100 keypers: 4.8 KB total.

Payloads the network already handles:

Payload	Size	Propagation (p95)
Ethereum block (typical)	~110 KB compressed	1-3s, 98% under 4s
Ethereum block (with blobs)	~400 KB average	97% under 4s (relay-sourced)
Single blob (EIP-4844)	128 KB	Most under 2.5s
Max blobs per block (Pectra, 9×128KB)	~1,152 KB	97.1% sub-4s (home nodes)
Assembled decryption key	48 bytes	—
Full keyper share set (100 keypers)	4.8 KB	—

A decryption key is ~2,300× smaller than a typical block. On Ethereum’s gossipsub (D=8, ~6 hops), small messages propagate in ~200-500ms — dominated by per-hop latency (~70ms × 6 hops ≈ 420ms minimum), not bandwidth. Even worst-case (100 individual key shares, 4.8 KB total), the data is comparable to a handful of attestation messages — trivial for the gossip layer.

Timing analysis (12-second slots)

Attestation deadline is ~4 seconds into the slot. Timeline using measured propagation data:

t=0s:       Slot starts. Builder has ciphertexts + block template
            from previous slot. Identifies same-slot-opted STs
            (by decryptor_address). Signs economic commitment.

t=0.5-1s:   Keypers release keys to builder + begin public broadcast.
            (48 bytes assembled, ~1KB shares. Gossip: ~200-500ms.)

t=1-2s:     Builder decrypts locally (~50-200ms), inserts at ToB,
            recomputes state root (~500-800ms).

t=2-2.5s:   Block published (~110KB). Keys propagating for ~1.5-2s —
            likely at most nodes BEFORE the block arrives.

t=2.5-3.5s: Block propagates (1-3s typical per ethPandaOps).
            Keys arrived ~2s ago.

t=3.5-4s:   EL clients verify decrypted_transactions with
            already-received keys (~200-500ms).

t=4s:       Attestation deadline.

Keys arrive before the block. At 48 bytes, key gossip (~200-500ms) completes faster than block propagation (~1-3s). By attestation time, keys are already local. This mirrors blob behavior; 35.5% of blobs (128KB each) arrive before the slot starts post-Dencun. Decryption keys are ~2,700× smaller.

Multi-builder key distribution

In ePBS, multiple builders compete per slot. If builder A commits and receives keys but builder B wins, builder A holds plaintext of transactions that are already confirmed and ordered on-chain. The ordering is final and state has moved on as builder A cannot retroactively reorder or frontrun. In the next slot, those STs are already executed; the plaintext conveys no residual ordering advantage. (Builder A always had access to the ciphertexts via FOCIL ILs regardless.)

Keys can safely be released to all committed builders, providing redundancy: if the winning builder drops, another committed builder can step in.

4. 6s and Shorter Slots

As Ethereum moves toward shorter slot times, the attestation window compresses. At 6-second slots (attestation at ~t=2s), block propagation + verification margin shrinks to ~0.5-1s. Key propagation (48 bytes, ~200-500ms) still fits, but block verification timing becomes the constraint.

Optimistic verification

The most natural approach for shorter slots: attesters accept decrypted_transactions without independent real-time verification. Correctness is enforced asynchronously as any party can prove incorrect decryption within a challenge window, triggering builder slashing.

This removes key verification entirely from the critical attestation path. The builder’s economic commitment already guarantees inclusion; optimistic verification extends the same economic security model to decryption correctness. The pattern mirrors optimistic rollups: accept first, prove fraud later.

Notably, this pressure is not unique to same-slot. N+1 decryption at 6-second slots faces the same constraint; verifying previous-slot STs still requires keys and compute within a compressed window. Optimistic verification may be a general LUCID optimization as slot times decrease, independent of whether same-slot is adopted.

Additional approaches

Random sampling (PeerDAS-inspired): a rotating attester subset performs full verification each slot; others trust the subset’s signed confirmation. Decryption keys (48 bytes) and ciphertexts are far smaller than blob cells (~2 KB), so per-attester cost is trivial.
Dedicated committee: a smaller staked committee with direct keyper connections pre-validates, analogous to the sync committee. Rotates and subject to slashing.

These approaches are not exclusive to same-slot — they benefit N+1 equally by reducing attestation load as slot times decrease.

5. Builder Game Theory

Top-of-Block is the most valuable block real estate (CEX-DEX arbitrage). Why would a builder voluntarily place decrypted STs there?

In LUCID’s steady state, every builder inherits decrypted STs from the previous slot at ToB — protocol-mandated via FOCIL, unavoidable. ToB is already displaced in every slot. The question is not whether displacement occurs, but whether the builder is compensated for it.

	N+1 Regime	Same-Slot Regime
ToB displaced by decrypted STs?	Yes — from previous slot	Yes — from current slot
Builder gains from displacement?	No	Yes — back-running value from full plaintext visibility
Builder visibility into ToB contents?	Partial — keys arrive between slots	Full — keys arrive before block construction
Inherited from previous builder’s slot?	Always	Reduced — eliminated in full adoption equilibrium*

Dominant strategy. Same-slot decryption has identical ToB displacement cost to N+1 (the same STs occupy the same positions). The builder pays the keyper committee for early key access, but gains full plaintext visibility at block construction time — enabling optimal back-run placement and tighter block composition. The back-running value from complete information exceeds the key access cost. Same displacement, better blocks.

Coordination equilibrium. If all builders adopt same-slot, no one inherits accumulated decrypted transactions from previous slots. Each builder handles only their own slot’s STs at ToB — cleaner, more predictable composition than N+1’s variable inheritance.

Price discovery and anti-gaming

Can builders underpay and capture all back-running value? No — price discovery happens through ePBS block auction competition, not the key payment. A builder with decrypted plaintext builds a more valuable block (optimal back-runs, tighter gas estimation, complete state knowledge). This block wins the proposer’s auction more often and at higher bids. A builder who skips the key payment builds blind, producing a less competitive block.

The keyper committee sets a minimum payment threshold — fee-for-service, not a speculative auction. The actual value extraction flows into the ePBS bid, not the key payment. ePBS competition ensures no builder can pocket the full surplus without being outcompeted by builders who also have keys and bid more aggressively. FOCIL reinforces this: the choice is not “include or exclude” but “build with full information or build blind.”

6. Tradeoffs

Same-slot decryption is not strictly superior to N+1. It introduces tradeoffs.

Gains

~12s latency reduction for time-sensitive transactions — DeFi trades, liquidations, conditional executions.
Stronger execution guarantees. Same-slot execution means transactions settle against the current slot’s state, not state that has drifted for 12 seconds. This reduces failed transactions, unexpected reverts, and stale-price executions — particularly for liquidations and limit orders where state changes between N and N+1 can invalidate the transaction entirely.
User choice. Speed selection via decryptor_address at transaction creation, abstracted as a wallet toggle. Small decryptor_fee; builder pays the timing premium.
Aligned incentives. In N+1, builders absorb ToB displacement uncompensated. Same-slot compensates all participants: builders gain full plaintext visibility (back-running value, tighter gas estimation, optimal composition); keypers earn base fee + builder premium; users get faster execution.

Costs

Compressed attestation window. Key propagation compresses from ~12s (N+1) to ~3s. In practice, keys (48 bytes, ~200-500ms gossip) arrive before blocks (~1-3s) — but the margin tightens at shorter slot times.
Economic vs. protocol enforcement. N+1 uses the slot boundary (protocol guarantee). Same-slot uses economic slashing. FOCIL provides a protocol backstop regardless.
Trust assumption shift. Same-slot relies on keyper liveness, slashing correctness, and collateral sufficiency. Failure in any component → latency regression to N+1, not safety failure.

Opt-in only

These tradeoffs are borne only by participants who choose them. Users who set a standard decryptor_address get exactly LUCID’s N+1 experience. Builders who don’t commit build N+1 blocks as usual. No participant’s security properties change without explicit opt-in.

7. LUCID Compatibility

Same-slot decryption maps directly to LUCID’s existing specification with one minimal spec change.

Existing spec hooks

LUCID’s ST ticket already contains decryptor_address (the entity responsible for decryption) and decryptor_fee (paid to that entity upon execution). LUCID is decryptor-agnostic: the ST header is opaque and may contain any decryptor-specific metadata.

A same-slot keyper committee publishes its eon key (from DKG) associated with its decryptor_address. Wallets that want fast execution encrypt with these parameters. The committee identifies its STs by decryptor_address.

Economics. Two-tier, using LUCID’s existing fields plus an out-of-protocol payment:

decryptor_fee (L1, user-paid): Small base fee covering keyper operational costs — DKG, uptime, N+1 fallback. Ensures keypers are compensated regardless of builder adoption.
Builder key access payment: The builder pays the keyper committee for early key release. The builder pays because full plaintext visibility is competitively valuable (Section 5).

Wallets abstract this as a speed choice: standard (N+1) or fast (same-slot). The user’s decryptor_fee is small either way; the builder’s payment is the primary revenue signal.

The one spec change. decrypted_transactions currently references the previous slot. The minimal change: allow it to also carry same-slot STs when the builder demonstrates key availability before ABB construction.

Mev taxonomy alignment

Same-slot preserves LUCID’s mev guarantees. Toxic mev (frontrunning, sandwiching) remains fully prevented as the builder cannot see plaintext before committing, identical to N+1. Backrunning is preserved and improved: LUCID explicitly allows it (CEX-DEX arbitrage via conditional STs), and same-slot gives the builder plaintext at build time for more accurate back-run placement. OFA compatibility and probabilistic mev burn are unchanged as same-slot only affects when the builder sees plaintext, not what protections apply.

8. Current Status

A similar proof-of-concept is deployed on Hoodi testnet using Shutter’s threshold encryption (3-of-5 keypers) and staked builder commitments. It demonstrates commitment-conditional key release; event-triggered, not time-triggered, validating the core mechanism described above. This is not a 1:1 implementation of LUCID, or this proposal, but an adjacent encrypted mempool PoC.

Next step: extend to LUCID-compatible ST ticket formats, pre-ABB commitment triggers, and commitment-to-key-release latency benchmarks that directly validate the timing analysis.

Repository: github.com/shutter-network/primev-sequencer

Summary

N+1 is a sound default. Same-slot offers an optional alternative that resolves the same circular dependency using pre-ABB economic commitments, trading a compressed attestation window for reduced latency, stronger execution guarantees, and builder compensation. The two are complementary: same-slot falls back to N+1 when conditions aren’t met, and no participant’s security properties change without explicit opt-in.

The core technical question: does ~3 seconds of key propagation (at 12-second slots) provide sufficient attestation margin? At 48 bytes (2,300× smaller than a block, 2,700× smaller than a blob), the propagation data suggests keys arrive at attester nodes before the block does.

Open Questions for Discussion

LUCID spec compatibility. Does decrypted_transactions strictly reference the previous slot, or can it carry same-slot decrypted STs? What is the minimal spec change to allow optional same-slot execution when the builder demonstrates key availability?
Shorter slot verification. At 6-second slots, optimistic verification appears most natural — but should this be same-slot-specific or a general LUCID optimization that benefits both N and N+1 paths?