Encrypted Mempool

Overview

An encrypted mempool accepts transactions whose sensitive contents are concealed before block ordering. Decryption may occur after a threshold committee acts, a time condition is met, or the proposer commits to an ordering that cannot be changed.

The design can reduce copy trading, sandwich attacks, targeted censorship, and other manipulation based on public pending data. It introduces new dependencies involving key generation, decryption shares, availability, denial of service, and handling transactions that reveal as invalid. Protocols must define who holds keys, when decryption occurs, how failed members are replaced, and how liveness survives withheld shares. Wallets need compatible submission and status reporting. Users should understand that encryption protects pre-inclusion visibility, not contract bugs, harmful execution, or all metadata leakage.

These records allow a later rescan to reconstruct the result when an endpoint, webhook, or local index becomes unreliable. Operational records should retain the raw transaction, network identifier, sender and destination, asset and amount, block reference, execution status, and observed timestamps. User-facing status should describe what is known without overstating settlement. Unknown, pending, included, failed, replaced, and finalized conditions need separate handling, together with a recovery procedure for transactions whose observed state conflicts across providers.

Submission, peer acceptance, block inclusion, execution, confirmation, and finality provide different evidence, and a transaction can advance, stall, be replaced, or disappear from the canonical chain between those stages. Encrypted Mempool should be represented as a sequence of observable states rather than one success flag. Implementation note: Encrypted mempools conceal pending intent, while threshold key security, timely decryption, availability, and invalid-transaction handling remain critical.