LUCID encrypted mempool

Abstract

This EIP specifies LUCID, a mechanism for carrying encrypted transactions through Ethereum's public inclusion pipeline while keeping their contents hidden until after the scheduling decision has been fixed. By requiring commitment before reveal and delaying decryption until that point, LUCID protects MEV-sensitive order flow, limits probabilistic front-running by minimizing pre-execution information leakage, and broadens the practical censorship resistance of inclusion lists. The design remains open to different off-protocol decryption schemes, including trustless self-decryption, rather than coupling Ethereum to a single enshrined cryptographic construction.

Motivation

Transaction ordering power has, in practice, made the public mempool unusable for a large share of economically meaningful transactions on Ethereum. When pending transactions can be inspected before inclusion, sophisticated actors can front-run, sandwich, or simply copy profitable strategies, turning transparent block production into an industrialized market for toxic MEV.

The natural response has been a migration toward private order flow. Users, wallets, searchers, and applications increasingly route transactions through private relays, builder-run mempools, order flow auctions, and other trusted intermediaries that can shield transaction contents until inclusion. These arrangements replace a public and permissionless inclusion path with opaque bilateral relationships. They reward trust, access, and private dealmaking over open competition, starving the public mempool, entrenching incumbent builders, and leaving access to blockspace vulnerable to outages, policy changes, and discretionary blacklisting.

This is especially concerning because it pushes some of Ethereum’s most important activity away from the public, composable domain. Offchain market structures may provide reasonable local arrangements, but they are unlikely to constitute a sufficient long-run equilibrium for Ethereum on their own. The promise of DeFi is not merely that transactions settle onchain; it is that trading, competition, and execution themselves can occur permissionlessly onchain.

Another core property is censorship resistance (CR), but because EIP-7805 (FOCIL) relies on open propagation, it cannot provide CR for transactions subject to MEV extraction. A public encrypted mempool addresses this gap. If transactions can be propagated in encrypted form and committed to before their contents are revealed, users no longer need to choose between MEV protection and trustless access to blockspace. This broadens the practical censorship resistance of inclusion lists while reducing the importance of privileged private order flow in builder competition.

At the same time, Ethereum cannot presently enshrine a single encryption scheme for this purpose. A viable in-protocol scheme requires a silent setup with small public keys, non-interactive decryption, no trusted setup, practical ciphertext sizes, CCA2 security, and a credible path to quantum safety. No known construction fully satisfies these requirements at Ethereum’s scale, and waiting for cryptographic breakthroughs would impose an unacceptable delay.

LUCID extends the inclusion pipeline to sealed transactions (STs) that can be propagated in public without revealing their contents. Builders commit to them before decryption, and key publishers release keys only after the scheduling decision has been fixed. In doing so, it preserves a public, permissionless path to inclusion for MEV-sensitive transactions without coupling Ethereum to a specific encryption scheme. Transactions may be self-decrypted in a trustless manner or encrypted in an open design according to a key publisher's instructions. This broadens the practical CR afforded by FOCIL while reducing Ethereum’s dependence on centralized order-flow relationships. In the longer term, it helps preserve an Ethereum in which trading and transaction competition can take place onchain, in public, and under permissionless market structure.

Specification

Constants and parameters

TOB_GAS_FRACTION_DENOMINATOR = 8
TOB_FEE_FRACTION = 128
MAX_SIGNATURE_SIZE = 2**16
MAX_ST_COMMITS_PER_IL = 2
MAX_STS_PER_BUNDLE = 64
MAX_BYTES_PER_ST = 2**24 // 64 # Byte bound implied by EIP-7976 and EIP-7825
MAX_ST_COMMITS = MAX_ST_COMMITS_PER_IL * IL_COMMITTEE_SIZE # IL_COMMITTEE_SIZE defined in EIP-7805
MAX_ST_TICKETS = MAX_ST_COMMITS * MAX_STS_PER_BUNDLE
tob_gas_limit = block.gas_limit // TOB_GAS_FRACTION_DENOMINATOR
tob_gas_limit_per_il = tob_gas_limit // IL_COMMITTEE_SIZE

Overview: from submission to execution

This subsection provides an overview of the LUCID mechanism. LUCID relies on sealed transactions (STs), consisting of a signed ST ticket used for charging the sender and binding to a key publisher and a ciphertext_envelope. The ciphertext_envelope decrypts to a signed plaintext transaction (PT) that can have a different from field than the ST. Senders encrypt transactions to a key publisher in an open design following the key publisher's off‑protocol instructions (and if applicable, using its public key), or can otherwise self‑decrypt trustlessly. The ST can be propagated in the public mempool without revealing the PT until after commitment. Figure 1 provides a timeline for the design.

Figure 1. LUCID timeline. Bids are included in the beacon block to allow key publishers to release keys in a timely manner before the next slot starts. Decrypted transactions are executed in the next block.

• Before $T_1$ – Includers propagate ILs that, besides PTs, can incorporate STs. The STs are either included individually or in a bundle (dark blue background).
• $T_1$ – Attesters (purple) of slot $n$ freeze their view of propagated ILs as well as votes on the timeliness of decryption keys released during the previous slot.
• After $T_1$ – Once builders know which ILs and keys they must adhere to, they cast an expanded ExecutionPayloadBid for the right to build the block. The bid contains "ST-commitments" to the hash of STs and ST bundles.
• $T_2$ – At the start of slot $n$, the proposer selects a winning bid, which is at least as encompassing as its own view of required ILs for block $n$ and keys from slot $n-1$. It includes that bid in the beacon block.
• After $T_2$ – Upon observing the beacon block, nodes begin requesting any missing ILs as well as ST bytes that are referenced by the ST‑commitments. Senders and key publishers can also independently propagate those bytes now.
• $T_3$ – Attesters of slot $n$ cast a vote on the current head of the chain. If the beacon block is missing or if the bid fails their audit due to omitted ST-commitments in ILs from their frozen view, they indicate the preceding block that is the head of the chain in their view. If the bid passes their audit, they optimistically attest to the block.
• After $T_3$ (Payload) – The builder releases the payload which also carries ST tickets that are charged. The first transactions (white rectangle) are decrypted STs, previously committed to in block $n-1$. Regular PTs from the current slot follow (black rectangle).
• After $T_3$ (Keys) – Each key publisher observes the ST-commitments in the beacon block. It confirms correct data for its own ST-commitment (pertaining, e.g., to its gas_obligation specifying how much gas it consumes), that the aggregate of all gas_obligation entries is within the allotted share of the next payload (tob_gas_limit), and that the beacon block is attested to. It propagates the key(s) that reveal the STs. The key(s) are flooded P2P and observed by attesters of the next block before their deadline at $T_4$.
• $T_4$ – The payload timeliness committee (PTC) votes for the timeliness of the payload, including timely receipt of ST/ST-bundle bytes and adherence to the keys released in the previous slot. It further casts a separate bitfield vote confirming the ST-commitments that can now be decrypted, i.e., those with valid ST/ST-bundle bytes and keys released during the current slot.
• $T_5$ – Attesters of slot $n+1$ freeze their view of propagated ILs as well as the decryption key timeliness votes for the previous block. The process then follows the same trajectory as after $T_1$ (for the previous slot).

Sealed transactions

A sealed transaction (ST) is a transaction envelope which contains:

1. a signed ST ticket transaction (to later be included on-chain), and
2. a ciphertext envelope (not included on-chain).

It is encoded in SSZ when being included in FOCIL-style inclusion lists.

class SealedTransaction(Container):
    ticket: Transaction
    ciphertext_envelope: ByteList[MAX_BYTES_PER_ST]

It is encoded in RLP when propagating across the mempool, as a new EIP-2718 transaction.

ST_TX_TYPE || rlp([
  st_ticket,
  ciphertext_envelope
])

ST ticket

An ST ticket is a new EIP-2718 typed transaction. It is charged and consumes the sender's execution nonce, but is not executed as a normal EVM message call.

ST_TICKET_TX_TYPE || rlp([
    chain_id,
    nonce,
    max_priority_fee_per_gas,
    max_fee_per_gas,
    gas_limit,
    max_tob_fee,
    max_preceding_commitments,
    key_publisher,
    key_publication_fee_recipient,
    key_publication_fee,
    key_commitment,
    reveal_commitment,
    ciphertext_hash,
    signature_id,
    signature
])

Besides regular transaction fields, the ST ticket also has a:

• max_tob_fee that the sender is willing to pay.
• max_preceding_commitments executed before the ST, acting as an upper bound.
• key_publisher responsible for signing bundles before key release.
• key_publication_fee_recipient that receives the fee.
• key_publication_fee paid for timely decryption of the plaintext transaction.
• key_commitment that binds to the revealed key.
• reveal_commitment that binds to the revealed transaction.
• ciphertext_hash, where ciphertext_hash = keccak256(ciphertext_envelope) binds the ciphertext bytes.

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. In this case, the signature is to be interpreted as a (signature_y_parity, signature_r, signature_s)-triple. 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).

Ciphertext envelope

The ciphertext_envelope of the ST is defined as:

class CiphertextEnvelope(Container):
  header: ByteList[2**16 - 1]
  dem_ciphertext: ByteList[MAX_BYTES_PER_ST]

On the EL, ciphertext_envelope is:

rlp([header_len:u16 || header || dem_ciphertext])

The header_len is big-endian. The header is header_len bytes and is opaque to the protocol. This field is reserved for decryption scheme metadata.

The dem_ciphertext is the output of a DEM ChaCha20-Poly1305 AEAD encryption with:

• DEM key – k_dem (32 bytes).
• Nonce – keccak256(chain_id || ticket_from || ticket_nonce)[:12] for STs.
• Empty aad (b"").
• dem_ciphertext is ciphertext || tag (tag is 16 bytes).

The ciphertext_envelope decrypts to plaintext_tx, the raw bytes of an EIP-1559 transaction to be executed onchain.

The plaintext_tx must have:

• max_priority_fee_per_gas = 0
• max_fee_per_gas = 0
• gas_limit = ticket.gas_limit

The gas_limit must be sufficient to cover the calldata cost of the byte size of the SealedTransaction. EIP-7825 thus bounds the byte size of an ST.

To bind the key, the sender includes key_commitment = keccak256(k_dem) in the ST ticket.

The reveal_commitment binds the revealed plaintext payload to a specific ticket. ticket_from is the recovered sender address from the ticket signature.

class RevealCommitmentPreimage(Container):
    chain_id: uint256
    ticket_from: ExecutionAddress
    ticket_nonce: uint64
    plaintext_tx: Transaction

reveal_commitment = hash_tree_root(RevealCommitmentPreimage(...))

Bundles

Sealed transactions can be bundled together only if all contained ST tickets have the same key_publisher. The bundle is then signed by that key_publisher to authenticate that it formed it.

class SealedBundle(Container):
    sealed_transactions: List[SealedTransaction, MAX_STS_PER_BUNDLE]
    key_publisher_signature_id: uint8
    key_publisher_signature: ByteList[MAX_SIGNATURE_SIZE]

The key_publisher_signature is interpreted according to key_publisher_signature_id. The ticket_hash of an ST is keccak256(ticket_bytes). The only currently valid value for key_publisher_signature_id is EC_DSA_TYPE == 0x01.

The bundle_root is the hash of the list of ticket hashes: bundle_root = keccak256(keccak256(ticket_bytes[0]) || ... || keccak256(ticket_bytes[n])). The key publisher signs (chain_id, bundle_root) with an ECDSA signature that recovers key_publisher.

Bundles are assigned an executable bitfield when committed to by the builder (as described below). Bundles have a collective max_preceding_commitments which is set as the minimum max_preceding_commitments among STs with executable = 1. Each ST has a tob_fee computed as described below under the "Block processing" subsection. The bundle_tob_fee is the aggregate of the tob_fee of all STs in the bundle with executable = 1.

Extended payload bid with ST-commitments

The ExecutionPayloadBid is extended with ST commitments and canonical IL roots.

class STCommitment(Container):
    commitment_root: Bytes32
    commitment_key: Bytes32
    gas_obligation: uint64
    executable: Bitlist[MAX_STS_PER_BUNDLE]

class ExecutionPayloadBid(Container):
    ...
    st_commitments: List[STCommitment, MAX_ST_COMMITS]
    IL_roots: List[Bytes32, IL_COMMITTEE_SIZE]

The commitment_root is ticket_hash for non-bundles and bundle_root for bundles.

For a non-bundle commitment, executable is empty and gas_obligation = ticket.gas_limit. For a bundle commitment, executable has length equal to the number of tickets in the committed bundle, in bundle order. The executable[i] bit is set to 1 iff ticket i can pay ticket_fee (defined below) and passes the ticket.nonce check when ST tickets are processed in st_commitments order and bundle members are processed in bundle order.

The commitment_tob_fee is defined as the tob_fee of an ST and the bundle_tob_fee of a bundle. It is not included in the commitment since it can be computed deterministically and is not required at commitment time. or the same reason, the max_preceding_commitments is not included.

For STs, the commitment_key is the ticket's key_commitment. For bundles, the builder first generates the list key_commitments by iterating over the bundle in bundle order and appending each key_commitment with executable[i] == 1. It then sets commitment_key = keccak256(key_commitments).

The gas_obligation is the aggregate ticket.gas_limit for bundle members with executable[i] == 1.

Execution payload expansion

class DecryptedTransaction(Container):
    plaintext_tx: Transaction

The execution payload is prepended with st_tickets and decrypted_transactions:

class ExecutionPayload(Container):
    st_tickets: List[Transaction, MAX_ST_TICKETS]
    decrypted_transactions: List[DecryptedTransaction, 2 * MAX_ST_TICKETS]
    ...

Key message

Decryptors publish DEM key material in an unsigned message.

class LucidKeyMessage(Container):
    chain_id: uint256
    scheduling_beacon_block_root: Bytes32
    scheduling_slot: uint64
    commit_index: uint8
    k_dems: List[Bytes32, MAX_STS_PER_BUNDLE]

Key message validity and decryption

A LucidKeyMessage is valid if it:

1. resolves, for a non-bundle ST, keccak256(k_dems[0]) == commitment_key; resolves, for a multi-key bundle, keccak256(keccak256(k_dems[0]) || ... || keccak256(k_dems[n])) == commitment_key;
2. has a chain_id that matches the chain;
3. references a commitment present in the scheduling block;
4. has the length len(k_dems) == 1 for STs, and len(k_dems) == sum(executable) for bundles, with k_dems ordered by the bundle order filtered to executable[i] == 1;
5. successfully decrypts the transaction(s).

Decryption of a scheduled ST is defined as successful only if decrypting ciphertext_envelope yields a plaintext_tx whose:

• hash_tree_root(RevealCommitmentPreimage(...)) == ticket.reveal_commitment, and
• plaintext_tx decodes to a type-2 transaction with:
  • max_fee_per_gas = 0,
  • max_priority_fee_per_gas = 0,
  • gas_limit = ticket.gas_limit.

Key release

The key publisher observes ST-commitments from the ExecutionPayloadBid included in the beacon block. It verifies that the executable bitfield indeed produces the specified gas_obligation for its own ST-commitment and that the aggregate of all gas_obligation entries is within the tob_gas_limit. Given that these requirements are fulfilled, if the payload turns out to be invalid or untimely, the key publisher's ST-commitment will always fit within the tob_gas_limit. This means that the ST(s) can still be included ToB in the next valid payload, as further discussed in the section entitled "Recovery under rejected payload".

The key publisher further verifies that the order of the ST-commitment is consistent with its underlying max_preceding_commitments. When the key publisher is confident that the beacon block will become canonical (for example after observing attestations for it), it releases its LucidKeyMessage. In the case of a single ST, the sender may itself also release the LucidKeyMessage, even if it specified a key publisher other than itself.

Key timeliness

Each PTC member publishes a signed vote message indicating which valid keys, scheduled for the current slot, they have observed:

DOMAIN_LUCID_KEY_TIMELINESS = DomainType('TBD')

class LucidKeyTimelinessVote(Container):
    chain_id: uint256
    voting_slot: uint64
    validator_index: ValidatorIndex
    scheduling_beacon_block_root: Bytes32
    scheduling_slot: uint64
    keys_observed: Bitlist[MAX_ST_COMMITS]

class SignedLucidKeyTimelinessVote(Container):
    message: LucidKeyTimelinessVote
    signature: BLSSignature

A bit keys_observed[j] is set to 1 iff the voter observed, by the key observation deadline of the PTC, a valid LucidKeyMessage for (scheduling_beacon_block_root, scheduling_slot, commit_index=j). 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 PTC members of the next slot store received votes at the lucid_key_vote_deadline, but keep listening for new messages and equivocation until they vote.

Let timely_key_votes be a bitfield of observed votes on a key at lucid_key_vote_deadline and total_key_votes be a bitfield of observed votes on a key at the attestation time. The number of committee members who equivocated is tallied in equivocated_votes. These votes are not included in the key votes bitfields. Further define:

• timely_1 = sum(timely_key_votes),
• timely_0 = len(timely_key_votes) - timely_1,
• late_1 = sum(total_key_votes) - timely_1,
• late_0 = len(total_key_votes) - sum(total_key_votes) - timely_0

The PTC of the next slot considers:

• All non-equivocated votes it observed at lucid_key_vote_deadline to have been seen by the builder.
• All non-equivocated votes it observed after lucid_key_vote_deadline to have potentially been seen by the builder.
• All equivocated votes to potentially have been seen voting either 0 or 1.

The builder can thus treat a key as missing under condition:

• 2 * timely_1 <= (timely_1 + timely_0 + late_0 + equivocated_votes);

and treat a key as observed under condition:

• 2 * (timely_1 + late_1 + equivocated_votes) > (timely_1 + timely_0 + late_1 + equivocated_votes).

If this test fails for any key, the PTC of the next slot votes against the payload timeliness.

Inclusion lists with STs and bundles

The InclusionList container of EIP-7805 is extended with STs and ST bundles:

class InclusionList(Container):
    ...
    sealed_transactions: List[SealedTransaction, MAX_ST_COMMITS_PER_IL]
    sealed_bundles: List[SealedBundle, MAX_ST_COMMITS_PER_IL]

The IL must satisfy len(sealed_transactions) + len(sealed_bundles) <= MAX_ST_COMMITS_PER_IL.

An entry of a timely IL must still be excluded from the block if:

• it is an ST that already appears in the block via a bundle,
• it is a bundle with STs that already appear in another bundle with a higher aggregate gas_limit.

An entry of a timely IL may still be excluded from the block if:

• The aggregate gas_limit of all STs (including bundled STs) of the IL exceeds tob_gas_limit_per_il.
• It cannot be inserted in st_commitments at the position determined by the ST-commitment ordering rule (see Block processing)—without breaking its max_preceding_commitments stipulation.

Attesters check the second condition similarly to the post-execution check of FOCIL, for each entry in sealed_transactions or sealed_bundles in a timely observed IL that was excluded from the block. The attester iterates through the st_commitments starting from ToB, for bundles updating executable of the to-be-inserted commitment and aggregating the tob_fee over eligible STs to compute the bundle_tob_fee. If in any instance the ST-commitment could be placed in st_commitments at the position determined by the ST-commitment ordering rule without violating its max_preceding_commitments, but is not included, attesters vote against the block.

Block processing

Nodes match the STs/ST bundles with their ST-commitments in the beacon block, verify for each matched ST (whether standalone or in a bundle) that keccak256(ciphertext_envelope) == ticket.ciphertext_hash, and verify that the commitments are ordered by descending commitment_tob_fee, tie-breaking by descending gas_obligation and ascending commitment_root respectively; referred to as the "ST-commitment ordering rule". They further verify that ST tickets adhere to the order of the ST-commitments. The ST tickets of bundles must further be in the same order as in the bundle, which the key publisher is free to decide.

Each ST ticket is charged after first establishing a priority_fee and tob_fee based on the base_fee_per_gas:

# Initialize
max_priority_fee = ticket.max_priority_fee_per_gas * ticket.gas_limit
max_fee = ticket.max_fee_per_gas * ticket.gas_limit
base_fee = block.base_fee_per_gas * ticket.gas_limit

# Compute capped fees
assert max_fee >= base_fee + ticket.key_publication_fee
priority_fee = min(max_priority_fee, max_fee - (base_fee + ticket.key_publication_fee))
tob_fee = min(ticket.max_tob_fee, max_fee - (base_fee + ticket.key_publication_fee + priority_fee))

# Charge the ticket sender
ticket_fee =  base_fee + ticket.key_publication_fee + priority_fee + tob_fee
assert ticket.signer.balance >= ticket_fee
assert ticket.signer.nonce == ticket.nonce
ticket.signer.balance -= ticket_fee
ticket.signer.nonce += 1

All nodes validate key message validity as previously described for the PTC. They verify that decrypted_transactions contains the byte-identical transactions they derived via decryption, positioned in the same order as the corresponding charged ST tickets, with STs not decrypted left out from the decrypted_transactions list.

Upon successful decryption, the calldata cost of the decrypted transaction is computed using max(len(ciphertext_envelope), len(plaintext_tx.data)) bytes. The PT is then executed as a regular transaction, except that it bypasses the ordinary EIP-1559 fee-cap validation and no gas fee is charged, since the fee was already prepaid by the ST ticket. The gas_used is referred to as dual_gas_used to capture that it encompasses a broader interpretation of calldata. The unused gas, previously charged to the parent_ticket according to the base fee of the previous block, is then returned to the sender, together with the parent_tob_fee reserved for the penalty:

parent_ticket.signer.balance += parent.base_fee_per_gas * (parent_ticket.gas_limit - dual_gas_used) + parent_tob_fee * (TOB_FEE_FRACTION - 1) // TOB_FEE_FRACTION

The priority_fee is not reconciled with gas_used since the ST still took up bounded space upon commitment. The specified key publication fee recipient is further credited the key publication fee:

parent_ticket.key_publication_fee_recipient.balance += parent_ticket.key_publication_fee

The decrypted_transactions are executed against the header of the block in which their ST ticket was committed to, in order to prevent builders from being able to inject information into the block after having witnessed decrypted transactions. During processing, the SLOTNUM opcode introduced in EIP-7843 must always return the slot number which included the corresponding ST ticket. The addition of the parent block hash to the historical block registry defined in EIP-2935 is no longer done at the top of the block; it is deferred till after the last ST has been executed. Likewise, the addition of the parent block's beacon root to the historical root registry defined in EIP-4788 is no longer done at the top of the block; it is also deferred till after the last ST has been executed.

Recovery under rejected payload

Decrypted transactions shall be included if:

• The ST bytes (and, if bundled, the ST bundle bytes) and keys were and are validly available, as confirmed by the PTC vote.
• The ST-commitments were correctly formatted and the aggregate of all gas_obligation entries was within the tob_gas_limit (as also confirmed by the attestations).
• Their ST-commitment entry specified a correct gas_obligation and max_preceding_commitments, given the executable bitfield provided for bundles.

If payload $n$ is rejected, two sets of STs are affected:

• The STs with decrypted_transactions scheduled for payload $n$, with ST-commitments in beacon block $n-1$ and ST tickets in payload $n-1$.
• The STs with ST-commitments in beacon block $n$, scheduled for payload $n+1$.

Both sets of STs that shall be included must then be included in the next payload. That payload includes the ST tickets of the associated commitments from beacon block $n$, and decrypted_transactions for commitments from both beacon block $n-1$ and $n$. The decrypted_transactions must be ordered according to the ST-commitments: those derived from commitments in beacon block $n-1$ go before those from commitments in beacon block $n$.

The executable bitfield and gas_obligation for an ST-commitment are fixed by its associated scheduling beacon block, and the key-timeliness outcome for the ST-commitment and LucidKeyMessage is fixed by the corresponding LucidKeyTimelinessVote. If an ST-commitment was mis-specified with respect to the original scheduling state, its transactions MUST NOT be included under recovery. When a recovery payload includes commitments from multiple scheduling beacon blocks, they are processed in scheduling-block order, and max_preceding_commitments is enforced only with respect to commitments from the same scheduling beacon block.

The recovery payload must not commit to new STs, in order for the protocol to catch up. In the baseline specification, decrypted STs are allotted at most 1 / TOB_GAS_FRACTION_DENOMINATOR of the gas limit. The recovery payload can then include two sets of decrypted STs, which at most consume 2 / TOB_GAS_FRACTION_DENOMINATOR of the block's gas limit.

Engine API Changes

• Add engine_getInclusionListV2 endpoint to retrieve an IL which may contain STs and bundles from the ExecutionEngine.
• Add engine_updatePayloadWithInclusionListV2 endpoint to update a payload with the IL that may contain STs and bundles that should be used to build the block.
• Add engine_updateInclusionListV2 endpoint which consumes an updated InclusionList containing STs, and the 8-byte payload id being built.

Beacon Chain RPC API Changes

• Update /eth/v2/events endpoint to notify wallets that their ST has been included, and it is safe to publish the key.
• Update /eth/v2/events endpoint to notify clients and committees that a key has been released.
• Add /eth/v1/beacon/key endpoint to relay the key to the libp2p topic.

Rationale

Probabilistic front-running

Attackers may attempt to probabilistically front-run transactions by preparing various options, that are only executed if they turn out to be profitable upon observing revealed keys of other transactions. LUCID tackles non-reveal of ST-commitments and probabilistic front-running from five different angles:

1. The public mempool need not reveal the plaintext transaction, its calldata, or its signer. While the signed ST ticket is visible, the revealed plaintext_tx may be signed by a different account than the ticket signer, which is not revealed until after commitment, when the decryption key is released.
2. After commitment, an attacker cannot replace ciphertexts, change ordering, or inject new STs. It can only control the binary decision whether to release valid keys for STs/ST bundles it already committed to. A multi-key bundle either fails, or all executable STs are revealed.
3. The decrypted_transactions are executed against the header of the block in which their ST ticket was committed to. This prevents builders from being able to inject information into the block after having witnessed decrypted transactions.
4. ST-commitments are ordered by ToB fee, a fraction of which is returned upon reveal. Selective reveal is therefore priced both in expectation and ex post. Concretely: (a) In the case that the front-runner consistently posts ST-commitments which it intends to use for front-running under advantageous circumstances, it must also consistently pay the part of the ToB fee that is not returned upon reveal – tob_fee / TOB_FEE_FRACTION. (b) In the case that the front-runner happens upon an advantageous circumstance, it must pay the higher penalty for every bit of information it communicates upon non-reveal – tob_fee.
5. Each ST specifies the max_preceding_commitments that may execute before it. This allows users to balance their need for protection from probabilistic front-running with their willingness to pay a high ToB fee. If a sender allows at most $m$ preceding commitments, then an adversarial party can choose between at most $2^{m-1}$ distinct patterns to be executed before the sender—if it purchases all $m$ commitments by paying a higher tob_fee than the sender for each one. Deliberations concerning max_preceding_commitments are more important for senders that self-decrypt, whereas bundled STs can leverage the joint ToB fee of all STs of the bundle to reduce the viability of probabilistic front-running (see "Alternative specifications" for further improvements).

The builder also has one bit of reveal optionality. It can elect to either release or not release its payload, upon observing some of the keys. This alters the pre-state which the decrypted transactions are executed against, just like how a non-reveal of an earlier ST-commitment also changes the pre-state. Since the builder is staked, it can also trivially be penalized for a non-reveal at an appropriate level.

MEV and welfare

The objective of LUCID is to restore a public, permissionless inclusion path for MEV-inducing transactions. Some users may prefer this inclusion path, whereas others continue using trusted private inclusion paths. The welfare claim of LUCID is therefore comparative and optional: it gives users an additional path that trades some private-intermediary conveniences for trustlessness and CR. At the protocol level, welfare is further strengthened by shrinking the share of economic activity that must route through trusted intermediaries—reducing exposure to discretionary exclusion, lowering barriers to builder entry, and keeping trading and competition within Ethereum's public, composable domain.

To understand the MEV landscape and how it affects encrypted mempools, it is useful to distinguish between:

• Exogenous MEV – induced by information external to the protocol, such as changes in CEX prices, prices on other chains, or other offchain information not yet reflected in the protocol state.
• Endogenous MEV – induced by the protocol state itself, such as imbalances between pools, available liquidations, or other imbalances internal to the protocol.
• Autogenous MEV (i.e., transaction-induced MEV) – induced when a transaction's own execution creates or reveals a new public signal, such as a large repricing trade or other state transition.

LUCID lands new information onchain trustlessly, which is useful when dealing with all three types of MEV, since it prevents front-running. However, differences regarding when the MEV opportunities become public and when they can be acted upon affect their relationship to the encrypted mempool. For example, a common objection to encrypted mempools is that they will reproduce the onchain searching observed on L2s with deterministic sequencing rules. However, LUCID differs materially from L2 sequencing in how new information enters the chain and in the bounded scope of decrypted transactions, making a direct comparison misguided. What follows is first a classification of exogenous/autogenous/endogenous MEV, which then informs a discussion of user and protocol welfare.

Exogenous MEV

MEV emerges exogenously when conditions outside of the protocol change such that its state becomes imbalanced relative to the rest of the world. Traders then rush to include transactions onchain in order to restore balance between the protocol state and the outside world. A prominent instance is CEX-DEX arbitrage, in which a price movement on a centralized exchange renders an onchain pool stale. Only the DEX leg is directly visible to Ethereum, while the offsetting leg is executed or hedged on a CEX or other offchain venue. From Ethereum’s perspective, the scarce object is therefore priority access for the onchain leg against stale protocol state. By restoring balance, traders extract value.

On an L1 like Ethereum, exogenous MEV is captured at the "information ingress boundary" (IIB)—the point at which new information enters onchain as the builder commits to a new block. In trusted offchain flow, builders or upstream intermediaries can privately simulate and filter candidate transactions, rely on order matching, private inventory, and other offchain liquidity arrangements. The builder takes in bids on onchain legs for restoring balance relative to the outside world, and includes only the most profitable ones—those that pay the most for the opportunity to execute in the block. In other words, transactions that cannot profitably execute are filtered out or revert offchain. Offchain reverts are beneficial in that transaction intent then does not become public.

When an L2 sequencer that receives private orderflow follows a deterministic scheduling rule, for example ordering by priority fee or on a first-come first-served (FCFS) basis, searchers attempting to extract exogenous MEV without guarantees about the exact state they execute against may instead probe the state during execution. Filtering, fallback logic, and/or reverts then move onchain. Many L2s do not have one discrete IIB per block. The detached relationship between trader and sequencer means that each new transaction acts on exogenous MEV as visible to the sender at submission time. Furthermore, an L2 may utilize sub-blocks, each allowing new information to enter the state, or FCFS ordering such that, from a transaction-ordering perspective, new information may continuously enter and trade against the state.

For the decrypted transactions in LUCID, the relevant point at which new information still can affect internal ordering (the IIB) is the scheduling decision in slot $n$ rather than the moment of execution in slot $n+1$; the relative ordering of decrypted transactions is fixed one slot before they execute (see also the same-slot design, where the decrypted transactions indeed execute toward the end of the block). Most exogenous MEV observable at the IIB of block $n$ is therefore expected to have been captured in block $n$'s own post-ToB segment, before the committed decrypted transactions execute ToB in $n+1$, just as today with offchain builder filtering applied. Onchain searching for exogenous MEV is thus expected to be more limited among decrypted transactions, so conditions on L2s do not translate to LUCID.

There is a narrow secondary IIB in LUCID worth pointing out: key publishers (or self-decrypting senders) can infuse limited new information onchain, by releasing or withholding keys. Since keys are released later than the block commitment time, new exogenous MEV may have emerged in the meantime. Decryptors can therefore selectively withhold or release keys so that only the most profitable (as of the key PTC deadline) pre-committed trades execute. We can expect such trades to be concentrated among the latest decrypted transactions, where the penalty for non-reveal is limited by lower ToB fees. This type of non-reveal does not consume additional blockspace in the way blind searching on an L2 does, since withheld transactions can be replaced by regular transactions in block $n+1$. In essence, it is a form of probabilistic MEV burn. It can be noted that a shorter window between the first IIB and the secondary IIB will serve to reduce the amount of exogenous MEV available for extraction.

Endogenous MEV

Endogenous MEV is MEV internal to the protocol state itself, such as DEX pool imbalances that can be rebalanced by arbitrage. On the L1, once the pre-state is known, searchers can identify endogenous MEV opportunities generated in the previous block, for example by transactions not fully internalizing their own backruns, and simulate trades targeting this MEV. Likewise, searchers or the builder may attempt to do so for any other opportunities implied by publicly visible candidate transactions for the current block. Under an idealized model of LUCID, most endogenous MEV observable at the IIB is therefore competed away during block construction, leaving little remaining after the regular transactions have been executed.

The decrypted transactions may produce new endogenous MEV, as, e.g., DEX pools are unbalanced by decrypted transactions. The sender can with the assistance of searchers or other intermediaries still prepare routing and backrunning options offchain, but these cannot be further simulated and filtered after commitment. The exact settlement or backrunning operation can therefore instead be determined onchain after querying the state, whereas candidate routing and backrunning options still can be precomputed offchain at commitment time. This does not reproduce a trusted intermediary's ability to simulate many candidate backruns against the exact evolving pre-state, but it does preserve a path for pre-committed, targeted backrunning. Importantly, it will lead to increased onchain routing, moving execution competition into the public, composable domain, away from centralized offchain intermediaries that compete on private access and trust.

The sender can place backrunning transactions directly after its trade within a bundle if it is expected to leave residual MEV on the table. The key publisher may also place backrunning transactions there, or at the end of a bundle. Since the backrunning transaction knows the precise operations performed by the MEV-inducing transaction, any required onchain queries can be highly targeted, querying only the most relevant trading pairs or venues before executing the backrunning leg.

Just as for exogenous MEV, in most L2 designs there is no comparable block-level clearing step at the IIB in which sophisticated searchers compete offchain against a known pre-state and the winning opportunities are filtered before execution. Transactions aiming to extract endogenous MEV then need to make queries onchain across the full block. Furthermore, residual opportunities may also emerge between exogenous-MEV-extraction transactions executed across the block. These properties should lead to more onchain searching for endogenous MEV in L2s than in LUCID.

Autogenous MEV

An important reason for using the LUCID encrypted mempool is to safeguard transaction-induced autogenous MEV. The transaction may itself reveal a new public signal or opportunity via a large repricing trade or other state transitions whose informational content may not have been observable beforehand. It may also for example atomically settle a series of coincidences-of-wants, or unwind a large lending position whose side effects, such as triggering liquidations or shifting borrowing rates, would be exploitable if disclosed in advance. Thus, the transaction's own informational or state-changing content can make it vulnerable to being traded around.

The autogenous MEV transaction's value derives from the information or matching it carries rather than from capturing an existing onchain imbalance. The private nature makes it less sensitive to the exact pre-state than transactions that compete to capture publicly available MEV (exogenous or endogenous), though execution quality still depends on the state of any pool or market touched. LUCID is therefore particularly suitable for allowing these transactions to enter the public inclusion pipeline without first disclosing information to a privileged intermediary.

The content of the transaction becomes public at key release, but the transaction that generates it was already committed to one slot earlier. Later decrypted transactions can react to it only through pre-committed contingent logic, whereas unrestricted competition over the revealed signal can begin among transactions executing after the decrypted transactions. It is assumed that autogenous MEV transactions from LUCID will capture their own endogenous MEV as outlined in the previous subsection.

Additionally, the builder has full control over the state under which the first decrypted bundle executes. At commitment time, the builder can therefore communicate relevant pre-state information to the key publisher (without full disclosure), enabling the first ST-commitment to provide offchain revert protection.

A comparison between L2s and LUCID is the most appropriate for transactions capturing autogenous MEV, given similar properties of the inclusion path. However, it should be noted that onchain searching is particularly appealing under low fees, and that the blockspace available to decrypted transactions is limited, setting an upper bound on how much settlement can move fully onchain.

Competition for the ToB

Competition for ToB positions revolves around the conditional value $V$ that senders assign to execution at a given position. The sender of an autogenous MEV transaction (with value $V_a$) that always reveals can under a TOB_FEE_FRACTION of $F$ post a ToB fee close to $FV_a$, given that it recoups a $(F-1)/F$ share of the fee after successful reveal. An aggregated bundle of size $B$ of such senders can likewise post a ToB fee approaching $FBV_a$. A sender extracting exogenous MEV, with average value $V_e$ in the states where reveal is chosen and reveal probability $p$, can support a ToB fee of roughly $pV_e/((1-p)+p/F)$. The sender would prefer to reveal with a high probability to keep forfeited ToB fees rare, but such setups require a conservative trade that correspondingly should tend to reduce $V_e$. The sender must commit against a post-state of block $n$ that will be close to equilibrium relative to the outside world, and can only profit from shifts taking place after commitment and before the PTC vote on key timeliness.

As an illustrative benchmark, the analysis will use $p=0.5$, which produces $pV_e/((1-p)+p/F) \approx V_e$. In this case, senders of autogenous MEV transactions can outcompete a sender extracting exogenous MEV roughly when $FBV_a > V_e$, where $V_e$ is the exogenous MEV conditional upon a reveal. Besides fixing $p$, this is also a simplification in that it abstracts from the distribution of exogenous opportunities across positions and states. Under this simplified model, the separation in value that can be assigned to the ToB position is therefore roughly $FB$.

Senders can further leverage max_preceding_commitments, $m$, to tolerate some preceding commitments, depending on sensitivity to be placed later in the ToB. The additional value separation created under this setup can generally be expressed as $FBf(m)$, where $f(m)$ is increasing, capturing that the marginal value of each additional earlier commitment that could outcompete should be decreasing. The gains are to some extent two-sided, both types of senders can allow the other to precede it.

It should here be noted that the same selector strategy outlined for probabilistic front-running can also be used for extracting exogenous MEV. The sender acquires $m$ earlier commitments and uses the first $m-1$ as binary selectors over $2^{m-1}$ precommitted execution patterns, where the final commitment executes the profitable pattern identified. This allows for constructing a more versatile exogenous MEV arbitrage transaction, with fewer withheld keys per option. The earlier outlined separation in $F$, $B$ and $f(m)$ can therefore be compressed.

In essence, senders targeting exogenous MEV can outbid senders of autogenous MEV in terms of ToB fees if the value of the exogenous MEV is sufficiently larger than the value assigned to autogenous MEV transactions. The issue is that the autogenous MEV sender cannot identify whether someone executing before them extracts exogenous MEV or tries to front-run. The protocol would then need to leverage other means to give room to senders of autogenous MEV transactions, such as for example a trust graph as suggested in EIP-8105 (see Alternative specifications).

Senders who strictly extract exogenous MEV and do not pursue probabilistic front-running can then execute before autogenous MEV senders, if they are trusted by them. Trusted autogenous or endogenous MEV senders can likewise execute before exogenous MEV senders, when they do not compete for the same opportunities. Even so, the differential of $FBf(m)$ is important for establishing a baseline of functionality while reining in monopolistic tendencies in any trust graph.

It can be noted that a sender that does not wish to belong to a bundle, requires absolutely ToB execution, and cannot leverage trust, indeed has a much lower value separation relative to a sender extracting exogenous MEV.

User welfare

MEV captured via both offchain and onchain paths for both regular and encrypted transactions may be shared with the sender according to the arrangements they make with the relevant service provider (e.g., searchers, MEV-Share nodes, key publishers, applications, or any software developed for facilitating routing and backrunning). The sender accounts for many factors when deciding whether it wishes to use the encrypted mempool or not. These include the expected difference in execution quality—including route quality, liquidity access, and residual MEV capture—between offchain and onchain paths; potential costs (searcher fees, gas fees, key publication fees, etc.); its requirement for CR; the risks associated with having plaintext visible to various trusted parties; its requirements for revert protection; and its fear of probabilistic front-running, etc. Under equilibrium, usage will depend on the importance of these various factors.

Users that need to land MEV-inducing transactions permissionlessly onchain without being front-run or sandwiched are the clearest candidates to use the encrypted mempool. For other users, the encrypted mempool inclusion path comes with both benefits and drawbacks. The welfare claim is not that the encrypted mempool dominates private inclusion on every dimension. Trusted intermediaries can offer, e.g., offchain revert protection, that the public path cannot replicate. Rather, it is that users benefit from having an alternative path whose properties—trustlessness, censorship resistance, and independence from any single intermediary—are not available through private channels. In particular, the ability to land autogenous MEV onchain without disclosing intent to a trusted intermediary is an important capability that no private channel provides by construction. Further more, even modest adoption improves welfare if LUCID gives users a credible outside option that disciplines the terms on which private inclusion is offered.

Protocol welfare

LUCID protects autogenous MEV, offers a viable path for capturing endogenous MEV produced by decrypted transactions through pre-committed onchain routing and backrunning, and defers a large fraction of exogenous MEV competition to the post-ToB portion of the block where builder filtering already operates today. This is a gradual introduction of encrypted execution into the block, and can be adjusted further going forward. User welfare improves due to the outside option of a trustless, censorship-resistant inclusion path that complements rather than replaces private channels, and diciplines the terms on which those channels are offered.

At the protocol level, the encrypted mempool yields additional structural benefits. It shrinks the share of economically meaningful activity that must route through trusted intermediaries, reducing Ethereum's exposure to discretionary exclusion, single-point-of-failure outages, and opaque bilateral relationships that entrench incumbent builders. By lowering barriers to builder entry and weakening the competitive advantage conferred by exclusive order-flow access, LUCID helps preserve a level playing field in block construction.

A consequence of commit-before-reveal execution is that some computation previously performed offchain by builders—settlement simulation, route selection, targeted state queries—moves onchain during the bounded ToB segment of the block. This may consume additional gas relative to a world in which a single intermediary filters and optimizes every transaction privately. However, this aligns well with Ethereum's plans to scale compute over the next few years, and the cost is bounded by the tob_gas_limit. It is thus a limited cost for restoring public, composable, and permissionless competition over transaction execution. When the encrypted mempool is underutilized, the unused gas allocation does not encroach on the block gas limit, so regular transactions face no capacity reduction.

In sum, LUCID increases protocol welfare by providing a public inclusion path that protects MEV-sensitive transactions—especially those carrying autogenous MEV whose informational content would be exploitable if disclosed in advance—while preserving full blockspace availability and keeping both inclusion paths open for users to choose between according to their own requirements.

Key publisher liability for non-reveal

To keep the first version of the design simple, there is no protocol-level mechanism for having key publishers of multi-key bundles assume liability (and thus incur the penalty) in place of the sender for failing to decrypt. Such a mechanism can be added in a subsequent upgrade. However, key publisher-sponsored liability can be approximated out-of-protocol by including a key publisher-funded sponsor ST in the bundle with the user STs.

Each sender provides some agreed-upon key_publication_fee = d, and a minimal or 0 max_tob_fee. The key publisher includes in the bundle its own minimum-gas transaction with a max_tob_fee at a level of n * d * TOB_FEE_FRACTION, where n is the number of STs in the bundle, each paying d. Because bundle ordering uses the aggregate tob_fee of executable STs, the bundle now ranks as if the key publisher had posted that ToB fee on behalf of the users.

If the bundle is revealed successfully, the sponsor ST receives back (TOB_FEE_FRACTION - 1) / TOB_FEE_FRACTION of its tob_fee, so its net ToB-fee burn is n * d. That exactly matches the aggregate key publication fees paid by the users. If the bundle is not revealed, the sponsor ST forfeits the full n * d * TOB_FEE_FRACTION, so the key publisher economically absorbs the non-reveal penalty.

Since the sender still sets the max_preceding_commitments, it does not assume additional risks if the key publisher reneges on its pledge to sponsor the ToB fee of the bundle as agreed upon. The mempool must naturally protect against spam and reject STs that have no chance of getting included. However, any ST can be validly included even with max_tob_fee = 0, and key publishers that encourage senders to produce STs relying on ToB fee sponsorship for inclusion—without performing such sponsorship—can also easily be filtered out.

PTC influence and state observation

A coalition of PTC members, potentially utilizing forked validator clients, could be bribed to systematically vote "timely" on keys originating from specific key publishers, artificially extending their permitted release window. An analogous concern exists today with the PTC vote on payload timeliness, but the payload vote is binary per slot: a few dishonest votes only affect the single question of whether an entire payload is accepted. In LUCID, key-timeliness votes are cast per ST-commitment, and multiple commitments may have keys arriving near the deadline. A few strategic votes can therefore tip the outcome more frequently, amplifying the expected value of bribery. The committee cannot alter the contents of a commitment, change the ordering of ST-commitments, or inject new transactions after commitment.

Once the PTC key-timeliness votes have been observed, the builder knows which decrypted transactions must be included top-of-block. This fully determines the pre-state for the remainder of the block. The PTC vote on keys can realistically be positioned slightly earlier than the vote on the payload, given the small size of key messages, giving the builder additional construction time when the payload arrives well within its deadline.

An alternative is to avoid a separate PTC vote on keys and instead rely on view-merge. Under this approach, the next-slot builder merges differing frozen views of released keys—for example by including missing keys in the block or by otherwise flagging adherence to them. This reduces the direct per-key voting surface and therefore the scope for bribery or collusive deadline extension by the PTC. The trade-off is that builders may have slightly different pre-states. They may then communicate their intended pre-state to relevant parties, and otherwise proceed with offchain filtering and reverts just like today.

Alternative specifications

Same-slot decryption

A same-slot variant of LUCID is possible if the block is split into two independently propagated chunks. The first chunk contains the ST tickets and all ordinary transactions, and is delivered by the primary payload deadline. The second chunk contains decrypted transactions corresponding to ST-commitments already fixed in the bid and potentially additional regular transactions, and is delivered by the secondary payload deadline. Alternatively, ticket charging can be delayed until the second chunk. The builder still publishes its bid with ST-commitments in the beacon block, but would only construct the second chunk after key publishers have released keys.

The design is inspired by semantic block chunking and the flow is as follows: The builder constructs the bid and the first chunk with ST tickets and regular transactions—including the BAL for executing them—without knowing the ST plaintexts. Once the scheduling beacon block becomes available, the first chunk is released and key publishers publish keys as in the baseline design. The builder decrypts the committed STs, constructs the second chunk including its own BAL, and propagates it while attesters are already validating or executing the first chunk. Decrypted transactions are ordered according to the same pattern as in the baseline design, matching the ST-commitments. The builder may be given the opportunity to include additional regular transactions in the second chunk, ensuring full block utilization under withheld keys. This would turn the design into a mix of block-auction and slot-auction ePBS.

Once attesters have finished executing the first chunk, they switch over to executing the second chunk. The block is valid only if both chunks are timely, which is determined by a singular PTC vote at the deadline of the second chunk. Since the first chunk is committed to in the bid, the builder cannot change the regular transactions upon observing released keys. A benefit of the design is that the builder has responsibility for its included STs, from commitment to execution. A drawback is increased design complexity, requiring semantic block chunking.

Frame transaction integration

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. In this mode, the frame transaction has a fixed layout: the first frame is a VERIFY frame that authenticates the outer frame transaction, and the second frame is a new ST frame whose data is the full SealedTransaction bytes. P2P nodes extract the SealedTransaction from the ST frame and otherwise validate it as they do today. The EL extracts the ST ticket from the ST and derives ticket_from and ticket_nonce from tx.sender and tx.nonce of the enclosing frame transaction respectively.

Bundles can be supported similarly by introducing a reserved ST_BUNDLE frame whose data is the full SealedBundle bytes and adding FRAME_TX_TYPE as a valid key_publisher_signature_id in SealedBundle. Integration requires a future EIP making coordinated additions to both EIP-8141 and LUCID.

Censorship resistance without FOCIL

The design does not strictly require coupling with FOCIL for achieving a reasonable level of censorship resistance for MEV-inducing transactions. Such an integration can therefore be left out from the first implementation. Since the plaintext sender is hidden until reveal, a builder cannot generally censor based on the contents of the plaintext transaction or the identity of its eventual signer. Builders may still rely on a whitelist for visible ticket signers, but absent offsetting external incentives such a builder would be at a competitive disadvantage. It should also be noted that the key publisher is visible in the ST ticket, and some builder may decide to censor based on key publisher identities.

Additional bundle and key options

Two additional bundle and key options can be highlighted: single-key bundles that require all STs to be successfully decrypted, and multi-key bundles that allow any ST decryption to fail.

• The single-key bundles can be useful for more elaborate schemes, for example under threshold decryption. TODO: expand upon various ideas under consideration.
• Multi-key bundles that allow any ST decryption to fail are also viable. One example is again threshold decryption, where the key publisher cannot beforehand guarantee that the sender provided a correct decryptable ST. For these bundles, max_preceding_commitments would count each committed ST in the bundle as a commitment.

In the interest of forward-compatibility, a schemeID byte may be added to the ciphertext_envelope to facilitate decryption optionality.

Trust graph

One way to reduce the fee pressure created by max_preceding_commitments is to distinguish between trusted and untrusted key publishers, inspired by the design proposed in EIP-8105. The main residual front-running risk comes from earlier commitments whose key publishers the sender does not trust to avoid strategic withholding. Earlier commitments from trusted key publishers need not consume the same safety budget.

A future version can therefore replace or complement max_preceding_commitments with max_preceding_untrusted_commitments. Decryptors would be nodes in a directed trust graph maintained in a canonical registry of key publisher addresses and trust edges. A key publisher A trusts key publisher B if there is a path from A to B in that graph. For an ST or bundle using key publisher A, an earlier commitment from key publisher B counts toward the limit only if A does not trust B. Trust is directional: commitments from B may precede A without consuming A’s bound when A trusts B, but not vice versa unless B also trusts A.

This allows users to delegate trust selection to their chosen key publisher instead of listing trusted third parties in every ST. It also reduces pressure toward a single dominant key publisher. For example, a small key publisher can trust a larger, widely used key publisher, allowing its users to be placed after that key publisher's commitments without requiring those commitments to count against their safety bound. The difference to EIP-8105 is that there is no hard requirement that only trusted key publishers may execute before the transaction, unless max_preceding_untrusted_commitments = 0. This expansion is viable because of the additional steps that the design takes against probabilistic front-running, including the offchain decryption process. A few untrusted key publishers are therefore unlikely to be a concern for most users.

Backwards Compatibility

This EIP introduces backward-incompatible changes to both the consensus and execution layers and therefore requires a hard fork. It extends block validity rules, ExecutionPayloadBid, ExecutionPayload, InclusionList, the Engine API, beacon-chain RPC interfaces, and the P2P handling of inclusion lists, sealed transactions, bundles, keys, and key-timeliness votes. Clients that are not upgraded will not be able to validate or construct post-fork blocks correctly.

This EIP does not remove or alter the semantics of existing plaintext transaction types. Legacy transactions and other non-LUCID transactions remain valid and retain their ordinary execution semantics. Users that do not opt into sealed transactions may continue to use the public mempool as before. Wallets, builders, relays, indexers, tracers, and RPC implementations that wish to support LUCID must add support for the new transaction types, commitment rules, and key-propagation flows, etc.

Security Considerations

Denial-of-service vectors for STs are instances with a low ToB fee and low max_preceding_commitments, particularly STs with these characteristics that are not intended to be bundled. Given that the utilization of the encrypted mempool is unknown—and may vary going forward—there are no fixed settings that can be established at this point for STs that should or should not be propagated. Furthermore, key publishers that establish a pattern of sponsorship as outlined in the Rationale may garner more permissive bounds during filtering.

Users and wallets must treat the choice of key publishers as a security decision. They should prefer key publishers and encryption instructions that are publicly documented and audited.

The DEM uses ChaCha20-Poly1305, which must not reuse the same (k_dem, nonce) pair across different ciphertexts. In this EIP, the DEM nonce is protocol-defined rather than chosen by the encryptor: for STs it is derived from (chain_id, ticket_from, ticket_nonce). Decryptors and self-decrypting senders should therefore ensure that the released k_dem is bound to the intended ticket or bundle context, and that any reusable secret recovered from the opaque header is not itself revealed. Since the protocol fixes aad = b"", this binding must come from key derivation rather than AEAD associated data. Reuse of a (k_dem, nonce) pair can break confidentiality and integrity.

Copyright

Copyright and related rights waived via CC0.