Private Mempool (Sealed Transactions)

Overview

Ashen supports a private mempool using sealed transactions. A sealed transaction is encrypted client-side and remains unreadable to validators until the network collectively decrypts it at inclusion time. This protects users from mempool sniffing and reduces the risk of front‑running.

At a high level:

1. The client encrypts the transaction using threshold identity‑based encryption (TIBE).
2. The encrypted payload enters the mempool; validators can’t read it.
3. When a sealed transaction is selected for a block, validators collaborate to decrypt it and execute it deterministically.

Why Sealed Transactions

• Privacy: Transactions aren’t visible in the mempool.
• Fairness: Validators can’t reorder based on contents.
• Safer trading: Reduced MEV‑style extraction from pending txs.

How It Works (Conceptual)

• Encryption: The client encrypts calldata with the current epoch’s TIBE public parameters.
• Mempool storage: The sealed payload is stored and gossiped like normal txs, but contents are opaque.
• Decryption at inclusion: Validators submit decryption shares; once enough shares are collected, the tx is revealed and executed.

Ordering and Selection

Sealed transactions are FIFO ordered by arrival in the mempool (design goal). This avoids content‑based ordering since the contents are not visible.

Limitations and Trade‑offs

• No mempool preview: Clients cannot inspect sealed tx contents once submitted.
• Simulation limits: Full simulation requires access to the plaintext transaction; clients should simulate locally before sealing.
• Decryption latency: Inclusion requires collecting threshold shares.

Related Docs

• Detailed protocol flow: /internals/flows/sealed-transactions/
• Txpool policy (sealed limits): /internals/txpool-policy/
• Intro overview: /getting-started/introduction/