From 0fec299814343b3234d96aae5f1a18dbd57ec36e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?David=20Nu=CC=81n=CC=83ez?= Date: Tue, 27 Oct 2026 23:36:32 +0100 Subject: [PATCH 1/3] Review of Private Transaction Broadcasting approach and related cards --- CHANGELOG.md | 2 + GLOSSARY.md | 14 +++ approaches/approach-private-broadcasting.md | 104 ++++++++++++------ domains/trading.md | 4 +- patterns/pattern-focil-eip7805.md | 10 +- patterns/pattern-network-anonymity.md | 2 +- .../pattern-pretrade-privacy-encryption.md | 10 +- ...attern-private-transaction-broadcasting.md | 10 +- .../pattern-threshold-encrypted-mempool.md | 37 ++++--- ...ern-verifiable-dkg-threshold-decryption.md | 10 +- use-cases/private-bonds.md | 2 + use-cases/private-derivatives.md | 2 + use-cases/private-fx.md | 2 + use-cases/private-stablecoins.md | 2 + use-cases/private-stocks.md | 2 + vendors/flashbots.md | 55 +++++---- vendors/iexec.md | 2 +- vendors/shutter.md | 39 ++++--- 18 files changed, 208 insertions(+), 101 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 56ca9c7..5d8550d 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,8 @@ All notable changes to the EthSystems Map are documented here. ## [Unreleased] +- fix(approach): Phase 1 review of [Private Transaction Broadcasting](approaches/approach-private-broadcasting.md) for the encrypted mempool cycle, with a new Private Relay sub-approach. +- fix: review of the patterns, vendors and use cases it links. [Threshold-Encrypted Mempool](patterns/pattern-threshold-encrypted-mempool.md) censorship resistance moves from `high` to `medium`. - fix: factual audit of the [Private FX](use-cases/private-fx.md) entry. - fix: factual audit of the [Private Repo](use-cases/private-repo.md) entry and the Private Trade Settlement cards it builds on. - fix: factual audit of the [Private Identity](use-cases/private-identity.md) entry and the cards one hop out. diff --git a/GLOSSARY.md b/GLOSSARY.md index f5527b1..f16561a 100644 --- a/GLOSSARY.md +++ b/GLOSSARY.md @@ -39,6 +39,14 @@ A dedicated network or service that publishes and stores the data required for D **Relayer**: Third party that submits transactions on behalf of users to hide identity +**Mempool**: The set of signed transactions a node holds before they are included in a block. The public mempool is gossiped between nodes, so pending transactions are visible to anyone running one. + +**Block Builder**: Entity that orders transactions into an execution payload and bids for a proposer to publish it. Under ePBS ([EIP-7732](https://eips.ethereum.org/EIPS/eip-7732)) builders are staked in-protocol participants. + +**MEV (Maximal Extractable Value)**: Value a block builder or searcher can capture by including, excluding or reordering transactions, for example by front-running or sandwiching a pending trade. + +**Private Relay**: Endpoint that accepts signed transactions and forwards them to selected block builders instead of the public mempool. It hides pending transactions from public observers, not from the relay or the builders. + **Paymaster**: ERC-4337 entity that defines how gas fees for user operations are paid or sponsored. It allows us to implement controlled gasless flows or internal fee routing. ### L2 Categories @@ -81,6 +89,10 @@ A dedicated network or service that publishes and stores the data required for D **[EIP-7805](https://eips.ethereum.org/EIPS/eip-7805)**: Fork Choice Inclusion Lists (FOCIL) standard for censorship resistance through committee-enforced transaction inclusion +**[EIP-7732](https://eips.ethereum.org/EIPS/eip-7732)**: Enshrined Proposer-Builder Separation (ePBS). The proposer commits to a builder's signed bid in the beacon block, and the builder reveals the payload afterwards. Scheduled for the Glamsterdam upgrade. + +**[EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)**: LUCID, a Draft proposal for an encrypted mempool on Ethereum. Sealed transactions are committed in a block before their decryption keys are released. + **[EIP-7701](https://eips.ethereum.org/EIPS/eip-7701)**: Native account abstraction standard enabling custom account validation logic, institutional key management, and ZK-based privacy systems **[ERC-7945](https://ercs.ethereum.org/ERCS/erc-7945)**: Standard for confidential token transfers using cryptographic commitments to hide balances and amounts @@ -103,6 +115,8 @@ A dedicated network or service that publishes and stores the data required for D **Shielded Pool**: Privacy mechanism using cryptographic commitments to hide transaction details +**Encrypted Mempool**: Mempool in which transactions stay encrypted until their ordering is committed. A threshold committee, or another key publisher, releases the decryption key afterwards. + **Confidential Contract**: Smart contract that operates on encrypted state while maintaining verifiability **Circom/Groth16**: Popular zero-knowledge proof system and domain-specific language diff --git a/approaches/approach-private-broadcasting.md b/approaches/approach-private-broadcasting.md index 0ed76a6..4773e53 100644 --- a/approaches/approach-private-broadcasting.md +++ b/approaches/approach-private-broadcasting.md @@ -1,25 +1,28 @@ --- title: "Approach: Private Transaction Broadcasting" status: ready -last_reviewed: 2026-06-24 +last_reviewed: 2026-10-27 use_case: private-stocks related_use_cases: [private-derivatives, private-fx, private-bonds, private-stablecoins] primary_patterns: + - pattern-private-transaction-broadcasting + - pattern-threshold-encrypted-mempool - pattern-pretrade-privacy-encryption - pattern-privacy-l2s supporting_patterns: - pattern-shielding - pattern-network-anonymity + - pattern-focil-eip7805 open_source_implementations: - url: https://github.com/flashbots/suave-geth description: "SUAVE private-intent execution (suave-geth archived May 2025; Flashbots migrated to BuilderNet)" language: Go - - url: https://github.com/shutter-network/shutter - description: "Shutter Network (threshold-encrypted mempool)" - language: Rust / Go + - url: https://github.com/shutter-network/rolling-shutter + description: "Shutter Network keyper (threshold-encrypted mempool, production on Gnosis Chain)" + language: Go - url: https://github.com/AztecProtocol/aztec-packages description: "Aztec privacy-native L2" language: TypeScript / Noir @@ -31,7 +34,7 @@ open_source_implementations: ### Scenario -A trading desk routes large institutional orders against on-chain venues. Visible transactions in the public mempool enable front-running, sandwiching, and intent inference; the spread cost on a EUR 25M order is large enough to dominate fees for the year. The desk needs broadcasting infrastructure that hides the order content, the timing, or both, while preserving validity and ordering guarantees. +A trading desk routes large institutional orders against on-chain venues. Visible transactions in the public mempool enable front-running, sandwiching, and intent inference; the spread cost on a EUR 25M order is large enough to dominate fees for the year. The desk needs broadcasting infrastructure that hides the order content, the timing, or both, while preserving validity and ordering guarantees. An issuer faces the same exposure with compliance actions: a pending freeze or blocklist update in the public mempool lets the affected holder move funds first with a higher priority fee. ### Requirements @@ -46,9 +49,42 @@ A trading desk routes large institutional orders against on-chain venues. Visibl - Public mempool is the default; opting out incurs operational complexity - Sequencer or builder trust is the typical price of privacy at this layer - Cross-network coordination amplifies MEV exposure unless each leg is privatized +- On Ethereum L1 no encrypted mempool is live, and FOCIL's inclusion guarantee (Hegotá) covers only the public mempool ## Approaches +### Private Relay + +```yaml +maturity: production +context: both +crops: { cr: medium, o: partial, p: partial, s: medium } +uses_patterns: [pattern-private-transaction-broadcasting, pattern-network-anonymity] +example_vendors: [flashbots] +``` + +**Summary:** Send the signed transaction to a private RPC endpoint or straight to contracted builders instead of the public mempool. Content stays hidden from mempool observers, not from the relay or the builders. + +**How it works:** The wallet or custody stack submits to a private endpoint ([Flashbots](../vendors/flashbots.md) Protect, MEV Blocker) or to builders under bilateral agreements. Builders include the transaction without rebroadcasting it. See [Private Transaction Broadcasting](../patterns/pattern-private-transaction-broadcasting.md). + +**Trust assumptions:** +- Relay and builders do not leak, copy-trade or front-run the transaction +- Builders the relay reaches win enough slots for timely inclusion + +**Threat model:** +- A relay or builder that sees the order can trade ahead of it; contracts and reputation are the only enforcement +- Inclusion waits for a reached builder to win a slot; three builders produced about 88% of blocks in late September 2026 +- Once FOCIL ships, privately routed transactions do not get its inclusion guarantee +- A fallback to the public mempool on relay failure leaks the transaction + +**Works best when:** +- The institution already has relay or builder agreements with contractual recourse +- Hiding content from public observers is enough, and builders may see it + +**Avoid when:** +- The builder that sees the order may also trade against it +- A protocol-level inclusion guarantee is required + ### OTC / Off-chain Matching ```yaml @@ -61,7 +97,7 @@ example_vendors: [renegade, flashbots] **Summary:** Match orders off chain through a private venue or block-builder relationship; settle as a single transaction or bundle that bypasses the public mempool. -**How it works:** Counterparties or solvers match orders in a private venue ([Renegade](../vendors/renegade.md), [Flashbots](../vendors/flashbots.md)) and submit the matched trade directly to a block builder, bypassing the public mempool. Settlement runs on chain; pre-trade content is not seen by mempool observers. +**How it works:** Counterparties or solvers match orders in a private venue ([Renegade](../vendors/renegade.md)) and submit the matched trade as a bundle through a [Private Relay](#private-relay), such as [Flashbots](../vendors/flashbots.md) Auction, bypassing the public mempool. Settlement runs on chain; pre-trade content is not seen by mempool observers. **Trust assumptions:** - Private venue or builder honesty (no copy-trading from order content) @@ -87,32 +123,34 @@ example_vendors: [renegade, flashbots] ```yaml maturity: prototyped context: both -crops: { cr: high, o: yes, p: full, s: high } -uses_patterns: [pattern-pretrade-privacy-encryption] +crops: { cr: medium, o: partial, p: partial, s: medium } +uses_patterns: [pattern-threshold-encrypted-mempool, pattern-pretrade-privacy-encryption] example_vendors: [shutter] ``` -**Summary:** Transactions are encrypted before submission. Decryption happens after ordering is fixed, never before. See [Pre-trade Privacy Encryption](../patterns/pattern-pretrade-privacy-encryption.md) for the underlying primitive. +**Summary:** Transactions are encrypted before submission. Decryption happens after ordering is fixed, never before. See [Threshold-Encrypted Mempool](../patterns/pattern-threshold-encrypted-mempool.md) for the underlying primitive and [Pre-trade Privacy Encryption](../patterns/pattern-pretrade-privacy-encryption.md) for its use with RFQ flows. -**How it works:** The user encrypts the transaction or expresses an intent under a private execution environment ([Shutter](../vendors/shutter.md); the earlier SUAVE design has been superseded by Flashbots BuilderNet). The proposer orders submissions before any decryption. A threshold committee decrypts afterwards network. Content is not visible until the ordering is committed. +**How it works:** The user encrypts the transaction to a key held by a threshold committee (in LUCID, a key publisher the user chooses) and submits the ciphertext. Builders and proposers commit to an ordering without seeing content; the key holders then release the key, and the transactions execute in the committed order. [Shutter](../vendors/shutter.md) runs this on Gnosis Chain. On Ethereum no encrypted mempool is live: LUCID ([EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)) is a Draft not scheduled for Hegotá, and out-of-protocol designs depend on builders opting in. On a permissioned chain where one operator sequences, the same construction hides transactions from the operator until the ordering is fixed. **Trust assumptions:** -- Threshold key holders (t-of-n) for decryption -- Liveness of the threshold network for the reveal step -- Proposer respects the encrypt-then-order discipline +- Key holders: a t-of-n committee, or a key publisher the user chooses +- Liveness of the key holders for the reveal step +- Builders and proposers include ciphertexts and respect the encrypt-then-order discipline **Threat model:** - Threshold compromise (t collusions) reveals transactions before ordering - Threshold liveness failure stalls transactions; stalled transactions may eventually leak -- Proposer can still censor-by-omission even without seeing content +- Builders and proposers can still censor by sender, or drop ciphertexts altogether +- Key holders see the committed ordering first and can withhold the key **Works best when:** - MEV protection is the primary concern and venue trust is unattractive - The chain or rollup supports ordering primitives that run over encrypted payloads - Threshold network trust is administratively manageable +- A permissioned chain's operator sequences transactions and should not see them before ordering **Avoid when:** -- Threshold network is not deployed for the target chain +- No threshold network or key publisher is deployed for the target chain (Ethereum L1 as of October 2026) - Latency budget cannot accommodate the encrypt-decrypt round trip ### Private Rollups @@ -151,28 +189,28 @@ example_vendors: [aztec, fhenix, zksync, ey] ## Comparison -| Axis | OTC / Off-chain Matching | Encrypted Mempools | Private Rollups | -|---|---|---|---| -| **Maturity** | production | prototyped | prototyped | -| **Context** | i2i | both | both | -| **CROPS** | CR:med O:y P:full S:med | CR:hi O:y P:full S:hi | CR:med O:part P:full S:med | -| **Trust model** | Venue or builder | Threshold key holders | Sequencer + bridge | -| **Privacy scope** | Pre-trade content only | Pre-inclusion content | Mempool + state + execution | -| **Performance** | Minimal latency | Encrypt-decrypt round trip | L2-internal latency | -| **Operator req.** | Venue / builder | Threshold network | Sequencer | -| **Cost class** | Low | Low | Low (L2-internal) | -| **Regulatory fit** | Strong (audit via venue) | Strong (post-decrypt audit) | Strong (per-rollup view keys) | -| **Failure modes** | Venue compromise; builder centralization | Threshold compromise; liveness | Sequencer outage; bridge exploit; operator capture (enterprise) | +| Axis | Private Relay | OTC / Off-chain Matching | Encrypted Mempools | Private Rollups | +|---|---|---|---|---| +| **Maturity** | production | production | prototyped | prototyped | +| **Context** | both | i2i | both | both | +| **CROPS** | CR:med O:part P:part S:med | CR:med O:y P:full S:med | CR:med O:part P:part S:med | CR:med O:part P:full S:med | +| **Trust model** | Relay and builders | Venue or builder | Key holders (threshold committee) | Sequencer + bridge | +| **Privacy scope** | Pre-inclusion content, hidden from the public only | Pre-trade content only | Pre-inclusion content, hidden from builders too | Mempool + state + execution | +| **Performance** | Waits for a reached builder to win a slot | Minimal latency | Key-release step; next block in LUCID | L2-internal latency | +| **Operator req.** | Relay / builders | Venue / builder | Threshold network | Sequencer | +| **Cost class** | Low | Low | Low | Low (L2-internal) | +| **Regulatory fit** | Strong (unchanged on-chain record) | Strong (audit via venue) | Strong (post-decrypt audit) | Strong (per-rollup view keys) | +| **Failure modes** | Builder front-running; low builder coverage; public fallback | Venue compromise; builder centralization | Threshold compromise; liveness; key withholding | Sequencer outage; bridge exploit; operator capture (enterprise) | ## Persona perspectives ### Business perspective -For institutional desks executing large trades on public chains, OTC / Off-chain Matching is the default for production deployments: Flashbots-class infrastructure is mature, Renegade and similar dark-pool venues offer ZK-backed matching, and the operational integration with custody is well-trodden. Encrypted Mempools win where venue trust is unattractive and the chain supports threshold-encrypted ordering. Private Rollups are the suitable choice when comprehensive privacy across mempool, state, and execution is required and the institution accepts the rollup operator model. The hybrid is to route by trade size and venue: large blocks through OTC, mid-size through encrypted mempools, comprehensive flow through a private rollup. +For institutional desks on public chains, a Private Relay is the production default for orders that must reach the chain: private RPCs and direct builder submission are mature and integrate with custody. OTC / Off-chain Matching suits size-sensitive trades, with Renegade and similar dark-pool venues offering ZK-backed matching. Encrypted Mempools win where builder or venue trust is unattractive and the chain supports threshold-encrypted ordering, which on Ethereum L1 waits for an enshrined design. Private Rollups are the suitable choice when privacy across mempool, state, and execution is required and the institution accepts the rollup operator model. The hybrid is to route by trade size and venue: large blocks through OTC, mid-size through encrypted mempools, flow that needs full privacy through a private rollup. ### Technical perspective -OTC / Off-chain Matching is the lightest engineering integration: connect to a venue or builder relay, ship signed bundles. Encrypted Mempools require integrating with the threshold network (Shutter SDK) and tolerating the encrypt-decrypt round trip. Private Rollups are the heaviest commit: deploy or join a privacy-native rollup, integrate with its sequencer model, and accept the bridge boundary as a liquidity surface. None of the three offers cryptographic ordering atomicity across builders or rollups; cross-domain MEV remains an open frontier for chains that have multiple block builders or sequencers competing for inclusion. +A Private Relay is the lightest engineering integration: point the submission path at a private RPC or builder endpoint. OTC / Off-chain Matching adds a venue integration and ships signed bundles. Encrypted Mempools require a threshold network on the target chain (Shutter on Gnosis Chain; none on Ethereum L1 yet) and tolerating the encrypt-decrypt round trip. Private Rollups are the heaviest commit: deploy or join a privacy-native rollup, integrate with its sequencer model, and accept the bridge boundary as a liquidity surface. None of the three offers cryptographic ordering atomicity across builders or rollups; cross-domain MEV remains an open frontier for chains that have multiple block builders or sequencers competing for inclusion. ### Legal & risk perspective @@ -182,13 +220,14 @@ This is a perspective for legal review by the deploying desk, not legal advice. ### Default -For institutional desks on public chains, default to OTC / Off-chain Matching through Flashbots-class infrastructure for large blocks and Renegade-class ZK dark-pool matching for size-sensitive trades. Pair with venue-side compliance reporting and custody integration. For chains with mature threshold-encrypted mempools, layer Encrypted Mempools as the second-line protection for orders that must reach the public chain. +For institutional desks on public chains, default to a Private Relay for orders that must reach the chain, and Renegade-class ZK dark-pool matching for size-sensitive trades. Pair with venue-side compliance reporting and custody integration. For chains with mature threshold-encrypted mempools (none on Ethereum L1 as of October 2026), layer Encrypted Mempools as the second-line protection for orders that must reach the public chain. ### Decision factors - If venue trust is unacceptable and the chain supports threshold-encrypted ordering, choose Encrypted Mempools. - If comprehensive privacy across mempool, state, and execution is required and the rollup operator model is acceptable, choose Private Rollups. -- If trading must remain on a public chain and threshold-encrypted ordering is unavailable, OTC is the only option that has reached production at this layer. +- If builders may see the order, a Private Relay is enough. +- If trading must remain on a public chain and threshold-encrypted ordering is unavailable, a Private Relay and OTC matching are the options in production; both trust builders or venues with the content. ### Hybrid @@ -201,4 +240,7 @@ Tier the privacy stack by trade size: large blocks (>EUR 5M-equivalent) through 3. **Cross-chain coordination.** Maintaining privacy when broadcasting across multiple networks; cross-builder MEV is unresolved. 4. **Timing analysis.** Sophisticated adversaries may still extract information from transaction-timing patterns even under encrypted mempools. 5. **Builder market structure.** Concentration at the builder layer creates a censorship and copy-trading risk that economic competition alone may not bound. +6. **Inclusion or privacy.** Until inclusion lists can carry sealed transactions, a private route gives up FOCIL's inclusion guarantee. How should a sender weigh that for compliance-critical transactions such as freezes? +7. **Key publishers.** Who may hold decryption keys for regulated flow, and how is a key holder that withholds after seeing the ordering penalised? +8. **Permissioned operators.** On a permissioned chain the operator that sequences sees every pending transaction. Encrypted submission hides it until ordering, not after. Is that enough without application-layer confidentiality? diff --git a/domains/trading.md b/domains/trading.md index 1cb978e..1d9f64b 100644 --- a/domains/trading.md +++ b/domains/trading.md @@ -20,9 +20,11 @@ description: "Execute and settle without leaking intent, size, or counterparties ## Approaches - [Approach: Atomic DvP Settlement](../approaches/approach-dvp-atomic-settlement.md) - [Approach: Private Trade Settlement](../approaches/approach-private-trade-settlement.md) +- [Approach: Private Transaction Broadcasting](../approaches/approach-private-broadcasting.md) ## Shortest-path patterns -- [Pre-trade privacy (Shutter/SUAVE)](../patterns/pattern-pretrade-privacy-encryption.md) +- [Pre-trade privacy (encrypted order flow)](../patterns/pattern-pretrade-privacy-encryption.md) +- [Threshold-encrypted mempool](../patterns/pattern-threshold-encrypted-mempool.md) - [Atomic DvP via ERC-7573](../patterns/pattern-dvp-erc7573.md) - [Shielding](../patterns/pattern-shielding.md) - [Commit-and-Prove fallback](../patterns/pattern-commit-and-prove.md) diff --git a/patterns/pattern-focil-eip7805.md b/patterns/pattern-focil-eip7805.md index a392c2f..c94dcc2 100644 --- a/patterns/pattern-focil-eip7805.md +++ b/patterns/pattern-focil-eip7805.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: standard layer: L1 -last_reviewed: 2026-06-18 +last_reviewed: 2026-10-27 works-best-when: - Censorship resistance is critical and must not depend on builder honesty. @@ -27,7 +27,7 @@ crops_profile: crops_context: cr: "Reaches `high` through a 1-of-16 committee honesty assumption: a single honest IL committee member suffices to force-include a transaction. Drops if the P2P gossip network is partitioned or if committee selection is subverted." o: "Fully open specification (EIP-7805) implemented in consensus layer clients. Any staked validator rotates through the committee, and any node can verify IL satisfaction." - p: "No privacy: transaction details remain fully visible in the mempool and on chain. Could reach `partial` by combining with encrypted mempools so inclusion lists carry ciphertexts rather than plaintext transactions." + p: "No privacy: transaction details remain fully visible in the mempool and on chain. Would reach `partial` if inclusion lists carried sealed transactions, as LUCID (EIP-8184, Draft) proposes." s: "Inherits the security of Ethereum consensus. Fork-choice enforcement means non-compliant blocks cannot become canonical, so the guarantee is as strong as the underlying finality mechanism." post_quantum: @@ -50,7 +50,7 @@ open_source_implementations: ## Intent -Prevent censorship of Ethereum transactions by sophisticated block builders. A committee of 16 validators per slot can force-include transactions in the next block; non-compliant blocks fail fork-choice and cannot reach finality. The pattern provides no privacy on its own: transactions remain fully visible in the mempool and on chain. It guarantees only that a transaction cannot be censored once it reaches the public mempool. +Prevent censorship of Ethereum transactions by sophisticated block builders. A committee of 16 validators per slot can force-include transactions in the next block; non-compliant blocks fail fork-choice and cannot reach finality. The pattern provides no privacy on its own: transactions remain fully visible in the mempool and on chain. It guarantees only that a transaction cannot be censored once it reaches the public mempool. FOCIL is scheduled for inclusion in the Hegotá upgrade, estimated for mid-2027. ## Components @@ -85,7 +85,7 @@ Threat model: - At least one honest and well-connected IL committee member per slot; the P2P network reliably delivers their list before the view-freeze deadline. - Non-malicious builder with sufficient bandwidth between view freeze (t=9s) and block broadcast; builders disconnected from the committee can miss IL transactions. - No privacy protection. Transaction details remain publicly visible throughout the process. -- Out of scope: builders that censor the entire mempool before any committee member sees a transaction; encrypted mempools are required to defend against that. +- Out of scope: transactions sent privately to builders never reach the public mempool, so inclusion lists do not cover them. Until sealed transactions can be listed (LUCID), a sender chooses between pre-inclusion privacy and FOCIL's inclusion guarantee. ## Trade-offs @@ -103,3 +103,5 @@ A bank submits a €5M stablecoin transfer to the public mempool at t=0s of slot - [EIP-7547: forward inclusion lists](https://eips.ethereum.org/EIPS/eip-7547) for a one-slot-delay alternative - [Private Payments Approach](../approaches/approach-private-payments.md) +- [EIP-8184: LUCID encrypted mempool](https://eips.ethereum.org/EIPS/eip-8184), which extends inclusion lists to sealed transactions +- [Private Transaction Broadcasting Approach](../approaches/approach-private-broadcasting.md) diff --git a/patterns/pattern-network-anonymity.md b/patterns/pattern-network-anonymity.md index 13e5218..fe79bc8 100644 --- a/patterns/pattern-network-anonymity.md +++ b/patterns/pattern-network-anonymity.md @@ -4,7 +4,7 @@ status: ready maturity: concept type: meta layer: offchain -last_reviewed: 2026-04-22 +last_reviewed: 2026-10-27 works-best-when: - Metadata leakage (IP, timing, query patterns) is a threat model concern. diff --git a/patterns/pattern-pretrade-privacy-encryption.md b/patterns/pattern-pretrade-privacy-encryption.md index c4b026a..ff5f1f3 100644 --- a/patterns/pattern-pretrade-privacy-encryption.md +++ b/patterns/pattern-pretrade-privacy-encryption.md @@ -4,7 +4,7 @@ status: ready maturity: testnet type: meta layer: hybrid -last_reviewed: 2026-06-17 +last_reviewed: 2026-10-27 sub_patterns: - name: "Threshold-encrypted mempool" @@ -60,9 +60,9 @@ related_patterns: see_also: [pattern-private-pvp-stablecoins-erc7573, pattern-dvp-erc7573] open_source_implementations: - - url: https://github.com/shutter-network/shutter - description: "Threshold-encrypted mempool reference implementation" - language: "Rust, Go" + - url: https://github.com/shutter-network/rolling-shutter + description: "Threshold-encrypted mempool reference implementation (Shutter keyper, production on Gnosis Chain)" + language: Go - url: https://github.com/flashbots/suave-geth description: "Private builder and confidential compute environment for order flow (archived 2025; historical reference)" language: "Go" @@ -123,5 +123,5 @@ Threat model: ## See also - [Shutter Network docs](https://docs.shutter.network/docs/shutter/research/the_road_towards_an_encrypted_mempool_on_ethereum) -- [SUAVE overview](https://writings.flashbots.net/the-future-of-mev-is-suave) +- [SUAVE overview](https://writings.flashbots.net/the-future-of-mev-is-suave) (historical: SUAVE is archived) - [Flashbots documentation](https://docs.flashbots.net/) diff --git a/patterns/pattern-private-transaction-broadcasting.md b/patterns/pattern-private-transaction-broadcasting.md index 3e30ca7..feca9a9 100644 --- a/patterns/pattern-private-transaction-broadcasting.md +++ b/patterns/pattern-private-transaction-broadcasting.md @@ -4,7 +4,7 @@ status: ready maturity: production type: standard layer: hybrid -last_reviewed: 2026-06-17 +last_reviewed: 2026-10-27 works-best-when: - Transaction content must stay hidden from the public mempool until block inclusion to prevent MEV extraction. @@ -84,18 +84,18 @@ Guarantees: Threat model: -- In the relay variant: a colluding relay or builder can observe content; protection reduces to contractual and reputational enforcement. +- In the relay variant: a colluding relay or builder can observe content; protection reduces to contractual and reputational enforcement. The relay or RPC endpoint also sees the submitter's IP address unless submission goes through a network anonymity layer. - In the threshold variant: a committee above the decryption threshold can reveal content before inclusion, defeating the guarantee. - Sender address and gas payer are typically visible during the pending phase. +- FOCIL inclusion lists are built from the public mempool, so once FOCIL ships (Hegotá) a privately routed transaction does not get its inclusion guarantee. - A fallback to the public mempool on relay unavailability can silently leak the transaction; the fallback policy must be explicit. - Post-inclusion transaction details are fully public; this pattern does not provide shielded amounts or counterparties. ## Trade-offs -- Block-inclusion latency overhead in the tens to low hundreds of milliseconds, plus a decryption step for the threshold variant. -- Inclusion priority depends on the relay's agreements with builders; private routes may see higher variance in inclusion time than direct builder submissions. +- A privately routed transaction is included only when a builder it reached wins the slot. Three builders produced about 88% of Ethereum blocks in late September 2026 ([relayscan](https://www.relayscan.io/)), so the relay's builder coverage sets inclusion latency. - Relay coverage varies over time; users should monitor live coverage metrics rather than assume a fixed figure. -- The threshold variant requires a decryption committee infrastructure and adds a liveness dependency. +- The threshold variant adds a key-release step after commitment, a decryption committee to operate, and a liveness dependency. - Cost model varies: some relay services are free, others take a share of MEV or charge fees. ## Example diff --git a/patterns/pattern-threshold-encrypted-mempool.md b/patterns/pattern-threshold-encrypted-mempool.md index a6f45c4..ecbb0a9 100644 --- a/patterns/pattern-threshold-encrypted-mempool.md +++ b/patterns/pattern-threshold-encrypted-mempool.md @@ -4,10 +4,10 @@ status: ready maturity: testnet type: standard layer: L1 -last_reviewed: 2026-06-17 +last_reviewed: 2026-10-27 works-best-when: - - Miner Extractable Value protection is needed at the protocol level rather than through a trusted relay. + - Maximal extractable value (MEV) protection is needed at the protocol level rather than through a trusted relay. - Users cannot or do not want to trust a private relay as a single point of trust. - Censorship resistance must be combined with pre-inclusion content privacy. avoid-when: @@ -21,13 +21,13 @@ context_differentiation: i2u: "End users are protected by the same k-of-n threshold as institutions, which is the main user-facing benefit: MEV protection does not require trusting a sequencer or a private-order-flow relay. The guarantee is only as strong as the committee's independence, so a committee captured by institutional interests degrades the user-side protection." crops_profile: - cr: high + cr: medium o: partial p: partial s: medium crops_context: - cr: "Censorship resistance is `high` because encrypted transactions can be included by any block builder without inspecting content, and no single relay can suppress them." + cr: "Builders cannot censor by content, but the sender stays visible and a builder can refuse ciphertexts altogether. Outside the protocol, inclusion depends on builders that opt in. Reaches `high` once inclusion lists can carry sealed transactions, as LUCID (EIP-8184, Draft) proposes." o: "Reference implementations are open source; keyper-network governance and participation criteria vary by deployment and may be gated." p: "Content privacy is `partial`: the payload is hidden until decryption, but sender address, gas limit, and transaction size remain visible pre-inclusion, and post-decryption MEV on the resulting state is still possible." s: "Security rides on the k-of-n honest-committee assumption, correct distributed key generation, and timely key release after block commitment. Premature decryption reduces the guarantee to that of a transparent mempool." @@ -46,14 +46,17 @@ related_patterns: see_also: [pattern-network-anonymity, pattern-modular-privacy-stack] open_source_implementations: - - url: https://github.com/shutter-network/shutter - description: "Shutter threshold-encryption toolkit for Ethereum-compatible chains" - language: "Rust, Go" + - url: https://github.com/shutter-network/rolling-shutter + description: "Shutter keyper and threshold-encryption framework, in production on Gnosis Chain" + language: Go + - url: https://github.com/commonwarexyz/simple-bte + description: "Batched threshold encryption research prototype" + language: Rust --- ## Intent -Prevent miner-extractable-value extraction by encrypting transaction content before mempool submission and releasing the decryption key only after block ordering is committed. A distributed committee holds threshold key shares, so no single party can decrypt prematurely. The result is cryptographic protection against front-running, back-running, and sandwich attacks, without handing trust to any one relay. +Prevent maximal extractable value (MEV) extraction by encrypting transaction content before mempool submission and releasing the decryption key only after block ordering is committed. A distributed committee holds threshold key shares, so no single party can decrypt prematurely. The result is cryptographic protection against front-running, back-running, and sandwich attacks, without handing trust to any one relay. Shutter runs this in production on Gnosis Chain. On Ethereum no encrypted mempool is live: LUCID ([EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)), the leading proposal to enshrine one, is a Draft and is not scheduled for Hegotá. This pattern is the cryptographic sub-pattern of private transaction broadcasting. The trust-based private-relay variant is documented as a related pattern (see related_patterns.requires). @@ -63,8 +66,8 @@ This pattern is the cryptographic sub-pattern of private transaction broadcastin - Distributed key generation: the committee jointly produces the threshold public key without any party ever holding the full private key. - Keyper committee: a distributed set of key holders drawn from validators, independent operators, or a delegated governance process. - Block builder integration: the builder accepts encrypted payloads and includes them without inspecting contents. -- Decryption oracle: publishes decryption key shares after block commitment so execution can proceed. -- Identity-based encryption or timelock-encryption variants are optional when slot-based decryption is required without a committee round trip. +- Key release: key holders publish decryption shares once the ordering is committed. LUCID generalises this to a key publisher the sender chooses: a committee, a single operator, or the sender itself. +- Variants: identity-based keys per slot or epoch (Shutter), or batched threshold encryption, where each key holder publishes one share for a whole batch. ## Protocol @@ -72,7 +75,7 @@ This pattern is the cryptographic sub-pattern of private transaction broadcastin 2. [operator] The threshold public key is published so users can encrypt transactions to it. 3. [user] The user encrypts a transaction under the threshold public key and submits the ciphertext to the mempool. 4. [operator] The block builder includes the ciphertext in a block without seeing its contents. -5. [contract] The block is proposed and finalized; slot commitment is now immutable. +5. [contract] The block is published; the ordering of the ciphertexts is now committed. 6. [operator] At least k keypers release their decryption key shares for the slot. 7. [operator] Shares are aggregated into the slot decryption key, which reveals the transactions, and execution proceeds on the decrypted payloads. @@ -82,7 +85,7 @@ Guarantees: - Pre-inclusion content privacy: transaction contents are hidden from block builders, searchers, and validators until after block commitment. - Cryptographic enforcement: no single party can decrypt, so front-running and sandwiching at the mempool stage are prevented without trusting a relay. -- Censorship resistance: encrypted payloads carry no application-layer signal, so content-based censorship is not possible at the builder. +- Censorship resistance: encrypted payloads carry no application-layer signal, so content-based censorship is not possible at the builder. Censorship by sender, or of all ciphertexts, remains possible. - Post-decryption auditability: once the slot key is released, transaction history becomes public and fully verifiable. Threat model: @@ -90,23 +93,27 @@ Threat model: - Honest-threshold assumption: fewer than k honest keypers allows premature decryption and restores mempool-stage MEV. - Liveness: fewer than k online keypers leaves encrypted transactions stuck; operators must decide between a longer liveness timeout and forfeiting the transactions. - Collusion: keypers colluding with block builders can front-run after decryption, so economic penalties and reputation controls are required. +- Key withholding: a key holder sees the committed ordering first and can decline to release, a free option on the transaction. Designs bound it with fees or penalties. - Metadata leakage: size, gas limit, and sender address remain visible before decryption and can still enable inference attacks on large or identifiable trades. - Coverage gap: only the mempool phase is protected; ordering-based extraction that happens after decryption on the public state is out of scope. ## Trade-offs -- Decryption adds latency after block inclusion, typically sub-second, which can be acceptable for settlement but borderline for latency-sensitive trading. -- Infrastructure complexity is significant: distributed key generation, keyper-network operation, and decryption oracle must all be built and kept live. +- Decryption adds a key-release step after commitment. In LUCID, decrypted transactions execute at the top of the next block, one slot later: acceptable for settlement, borderline for latency-sensitive trading. +- Infrastructure complexity is significant: distributed key generation, keyper-network operation, and key release must all be built and kept live. - Committee capture is the primary attack surface; diverse keyper sets, time-bounded rotations, and economic bonding mitigate but do not remove the k-of-n trust assumption. - Common failure modes, such as a compromised share, a distributed key generation ceremony flaw, or an offline committee, must be addressed with key rotation, verifiable distributed key generation, and redundancy with timeout fallbacks. - Cryptographic protection stops at the mempool boundary; integration with shielding or stealth-address patterns is needed to close the post-decryption visibility gap. ## Example -A trading desk submits a large stablecoin trade on a chain that runs a threshold-encryption layer. The desk encrypts the transaction under the current-epoch threshold public key and submits it to the public mempool. Validators include the ciphertext in the next block without seeing the destination or amount. After finalization, the keyper committee releases its shares and the trade is decrypted and executed; competing searchers have no opportunity to front-run or sandwich the trade during the mempool phase. On the same chain, a retail swap user encrypts a token swap to the same public key and obtains the same pre-inclusion privacy without having to trust a specialised private relay. +A trading desk submits a large stablecoin trade on a chain that runs a threshold-encryption layer. The desk encrypts the transaction under the current-epoch threshold public key and submits it to the public mempool. Validators include the ciphertext in the next block without seeing the destination or amount. Once the block is published, the keyper committee releases its shares and the trade is decrypted and executed; competing searchers have no opportunity to front-run or sandwich the trade during the mempool phase. On the same chain, a retail swap user encrypts a token swap to the same public key and obtains the same pre-inclusion privacy without having to trust a specialised private relay. ## See also - [Shutter Network overview](https://shutter.network/) - [Shutter documentation](https://docs.shutter.network/) - [Gnosis Chain Shutter integration](https://docs.gnosischain.com/about/specs/shutter/) +- [EIP-8184: LUCID encrypted mempool](https://eips.ethereum.org/EIPS/eip-8184) +- [EIP-8105: Universal Enshrined Encrypted Mempool](https://eips.ethereum.org/EIPS/eip-8105) +- [Batched threshold encryption (eprint 2024/669)](https://eprint.iacr.org/2024/669) diff --git a/patterns/pattern-verifiable-dkg-threshold-decryption.md b/patterns/pattern-verifiable-dkg-threshold-decryption.md index 7655cdf..7f8f433 100644 --- a/patterns/pattern-verifiable-dkg-threshold-decryption.md +++ b/patterns/pattern-verifiable-dkg-threshold-decryption.md @@ -4,7 +4,7 @@ status: draft maturity: testnet type: standard layer: offchain -last_reviewed: 2026-07-21 +last_reviewed: 2026-10-27 works-best-when: - Decryption authority must be distributed across independent operators so no single party can unilaterally expose private inputs. @@ -48,9 +48,9 @@ open_source_implementations: - url: https://github.com/theinterfold/interfold description: "The Interfold protocol: threshold BFV, PV-TBFV, DKG and decryption aggregator circuits" language: "Rust, Noir, Solidity" - - url: https://github.com/shutter-network/shutter - description: "Shutter threshold-encryption toolkit with on-chain keyper verification" - language: "Rust, Go" + - url: https://github.com/shutter-network/rolling-shutter + description: "Shutter keyper implementation: DKG and threshold decryption for encrypted mempools" + language: Go --- ## Intent @@ -108,6 +108,6 @@ A sealed-bid auction protocol requests a committee of 5 nodes with a threshold o ## See also -- [The Interfold Documentation: Cryptography](https://docs.theinterfold.com/cryptography) +- [The Interfold Documentation: Cryptography](https://docs.theinterfold.com/learn/cryptography) - [Shutter Network: Threshold Encryption](https://docs.shutter.network/) - [PVSS: Publicly Verifiable Secret Sharing (Stadler, 1996)](https://link.springer.com/chapter/10.1007/3-540-68697-5_15) diff --git a/use-cases/private-bonds.md b/use-cases/private-bonds.md index b4eb874..508fc56 100644 --- a/use-cases/private-bonds.md +++ b/use-cases/private-bonds.md @@ -44,6 +44,8 @@ See [Approach: Atomic DvP Settlement](../approaches/approach-dvp-atomic-settleme **PoC Implementation:** [Private Bond PoC](https://github.com/ethsystems/pocs/tree/master/pocs/private-bond); three approaches: Custom UTXO (EVM), Privacy L2 (Aztec), and FHE (Zama fhEVM). +To keep orders and settlement transactions out of the public mempool before inclusion, see [Approach: Private Transaction Broadcasting](../approaches/approach-private-broadcasting.md). + ## 6) Open Questions _Notes below reference the PoC implementation._ diff --git a/use-cases/private-derivatives.md b/use-cases/private-derivatives.md index 27bc9fd..6b26231 100644 --- a/use-cases/private-derivatives.md +++ b/use-cases/private-derivatives.md @@ -40,6 +40,8 @@ Visible daily cashflows and buffer levels expose risk appetites and strategies, See detailed solution architecture and trade-offs in [**Approach: Private Derivatives**](../approaches/approach-private-derivatives.md). +For the mempool side channel (pending margin and settlement transactions), see [Approach: Private Transaction Broadcasting](../approaches/approach-private-broadcasting.md). + ## 6) Open Questions - Trust model for **valuation oracle** under privacy diff --git a/use-cases/private-fx.md b/use-cases/private-fx.md index 91c4b4e..6ee5861 100644 --- a/use-cases/private-fx.md +++ b/use-cases/private-fx.md @@ -59,6 +59,8 @@ See [approach-private-trade-settlement.md](../approaches/approach-private-trade- - Cross-network settlement options and their recovery paths in [Approach: Atomic DvP Settlement](../approaches/approach-dvp-atomic-settlement.md) - Stablecoin privacy patterns from [private-stablecoins.md](private-stablecoins.md) +To keep trading intent out of the public mempool before inclusion (Problem 1), see [Approach: Private Transaction Broadcasting](../approaches/approach-private-broadcasting.md). + ## 6) Open Questions - How does privacy interact with real-time gross settlement requirements? diff --git a/use-cases/private-stablecoins.md b/use-cases/private-stablecoins.md index a664918..c23fb83 100644 --- a/use-cases/private-stablecoins.md +++ b/use-cases/private-stablecoins.md @@ -45,6 +45,8 @@ Institutions need practical paths to onboard their users (corporates, funds, cou See detailed solution architecture and trade-offs in [**Approach: Private Payments**](../approaches/approach-private-payments.md). +Pending transfers and compliance actions (freezes, blocklist updates) are visible in the public mempool before inclusion; see [Approach: Private Transaction Broadcasting](../approaches/approach-private-broadcasting.md). + **Jurisdiction-Specific Implementations:** - **China:** Stablecoins are out of scope; the state-sanctioned analogue is e-CNY, a centrally operated PBoC system distributed through licensed operator banks rather than a public ledger. Permissioned enterprise chains (BSN) are a separate programme and are not an access channel to e-CNY, so these patterns apply only where an approved operator admits them diff --git a/use-cases/private-stocks.md b/use-cases/private-stocks.md index d2f1b80..3822dd5 100644 --- a/use-cases/private-stocks.md +++ b/use-cases/private-stocks.md @@ -56,6 +56,8 @@ See [approach-private-trade-settlement.md](../approaches/approach-private-trade- - Privacy-preserving beneficial ownership registries - Hybrid on-chain/off-chain settlement models +To keep orders out of the public mempool before inclusion, see [Approach: Private Transaction Broadcasting](../approaches/approach-private-broadcasting.md). + ## 6) Open Questions - How do privacy requirements interact with securities law disclosure obligations? diff --git a/vendors/flashbots.md b/vendors/flashbots.md index 8b3da77..868735a 100644 --- a/vendors/flashbots.md +++ b/vendors/flashbots.md @@ -4,16 +4,18 @@ status: ready maturity: production --- -# Flashbots – MEV Infrastructure & SUAVE +# Flashbots – MEV Infrastructure ## What it is -Flashbots develops MEV infrastructure including private mempools, block building, and SUAVE (Single Unifying Auction for Value Expression), a decentralized platform for private intent expression and execution. Flashbots Auction is in production on Ethereum mainnet; SUAVE is under development. +Flashbots develops MEV infrastructure for Ethereum: MEV-Boost, which validators use to source blocks from builders; Flashbots Protect, a private RPC that keeps transactions out of the public mempool; MEV-Share, which lets users share hints with searchers and capture part of the MEV their transactions create; and BuilderNet, a block-building network run by several operators. SUAVE, its earlier design for a decentralized intent platform, is archived. ## Fits with patterns -- [Pre-trade Privacy](../patterns/pattern-pretrade-privacy-encryption.md): private intent expression via SUAVE -- [Private Broadcasting](../approaches/approach-private-broadcasting.md): MEV protection through private mempools +- [Private Transaction Broadcasting](../patterns/pattern-private-transaction-broadcasting.md): Protect is a private relay +- [Pre-trade Privacy](../patterns/pattern-pretrade-privacy-encryption.md): private order flow through Protect and MEV-Share +- [Private Broadcasting](../approaches/approach-private-broadcasting.md): the Private Relay sub-approach +- [TEE-Based Privacy](../patterns/pattern-tee-based-privacy.md): BuilderNet's services that run in TEEs ## Not a substitute for @@ -24,41 +26,54 @@ Flashbots develops MEV infrastructure including private mempools, block building ## Architecture -**Flashbots Auction:** transactions are submitted directly to builders, bypassing the public mempool; MEV-Share lets users capture a portion of the MEV from their transactions; competitive block construction handles MEV extraction. +**MEV-Boost:** open-source middleware for proposer-builder separation. Validators run it to take the most profitable block offered by builders through relays, which hold each block's contents until the proposer signs its header. Flashbots operates one of the relays. A privately sent transaction needs a builder that received it to win the block. ePBS (EIP-7732, scheduled for Glamsterdam) moves proposer-builder separation into the protocol. -**SUAVE (under development):** a universal intent pool for cross-domain intent expression and matching, programmable privacy (selective revelation of intent information), and decentralized execution across multiple environments. +**Flashbots Auction:** searchers and users send bundles of transactions directly to block builders with the `eth_sendBundle` RPC, bypassing the public mempool. It runs on MEV-Boost. The documentation now files it under "Flashbots Builders", though its pages and URLs still call it Flashbots Auction. + +**Flashbots Protect:** a private RPC. By default it sends transactions only to the Flashbots builder. Users can add builders, which means trusting those builders too; a fast mode shares transactions with all registered builders. + +**MEV-Share:** an operator-run node shares configurable hints about pending transactions with searchers, who may only backrun them. In Protect's fast mode, searchers running in TEEs receive the full transaction whatever the hint settings. + +**BuilderNet:** a block-building network operated by several parties. Since September 2026 its documentation says it is "transitioning to a new security model": during this period its nodes do not run in TEEs, while its backrunning and routing services still do. + +**SUAVE (archived):** a planned decentralized intent and block-building platform. The suave-geth repository was archived in May 2025. + +## Privacy domains + +- **Bundle submission (Auction):** bundles reach the builders the sender chooses and skip the public mempool. +- **Private submission (Protect):** pending transactions are hidden from the public mempool, not from the builders that receive them. +- **Hint sharing (MEV-Share):** the user chooses which transaction fields searchers see before inclusion. ## Enterprise demand and use cases - Private transaction submission bypassing the public mempool - MEV protection through direct builder relationships - Revenue sharing via MEV-Share -- Cross-chain intent expression (SUAVE) ## Technical details -- **Networks:** Ethereum mainnet (Flashbots Auction); multi-chain (SUAVE) -- **Developer tools:** MEV-Share SDK, Flashbots Auction APIs -- **Builder network:** requires integration with participating builders -- **Intent standards:** SUAVE is developing cross-chain intent standards +- **Networks:** Ethereum mainnet +- **Developer tools:** Protect RPC, MEV-Share SDK, bundle APIs +- **Code:** [mev-boost](https://github.com/flashbots/mev-boost) (Go), [rbuilder](https://github.com/flashbots/rbuilder) (Rust) ## Strengths -- Established MEV mitigation with significant adoption -- Strong relationship with the Ethereum ecosystem -- Active development of new infrastructure (SUAVE) -- Revenue-sharing mechanisms align user incentives +- MEV-Boost is the block-sourcing path for most Ethereum validators +- Protect needs only an RPC change in the wallet or submission stack +- Revenue-sharing mechanisms return part of the MEV to users +- Open-source relay and builder software ## Risks and open questions -- Centralization concerns around builder relationships -- SUAVE still in development -- Limited privacy guarantees (trust-based model) +- Trust-based privacy: the builders a transaction reaches can read it +- Inclusion depends on the share of blocks won by the builders a transaction reaches +- BuilderNet's TEE-based security model is in transition (September 2026) - Regulatory uncertainty around MEV redistribution ## Links - [Flashbots](https://flashbots.net/) -- [MEV-Share](https://docs.flashbots.net/flashbots-mev-share/overview) -- [SUAVE](https://writings.flashbots.net/the-future-of-mev-is-suave) +- [Flashbots Protect settings](https://docs.flashbots.net/flashbots-protect/settings-guide) +- [MEV-Share](https://docs.flashbots.net/flashbots-mev-share/introduction) +- [BuilderNet documentation](https://buildernet.org/docs/) - [Documentation](https://docs.flashbots.net/) diff --git a/vendors/iexec.md b/vendors/iexec.md index f4bc0aa..ca4143d 100644 --- a/vendors/iexec.md +++ b/vendors/iexec.md @@ -16,7 +16,7 @@ iExec provides privacy-preserving computation, data governance, and trusted exec - [Pattern: Attestation verifiable on-chain](../patterns/pattern-verifiable-attestation.md) - Cryptographic attestation proves expected code ran in a genuine enclave; verified results are consumed on-chain. - [Pattern: Hybrid TEE + ZK Settlement](../patterns/pattern-tee-zk-settlement.md) - Private settlement and matching inside TEEs with ZK proofs for on-chain verifiability; compatible with hybrid TEE + ZK approaches. - [Pattern: TEE key manager](../patterns/pattern-tee-key-manager.md) - Keys and secrets are used inside secure enclaves, supporting confidential execution models. -- [Pattern: Pre-trade privacy (Shutter/SUAVE/private RFQ)](../patterns/pattern-pretrade-privacy-encryption.md) - Sealed-bid and private RFQ flows; bids processed confidentially off-chain in TEEs, with settlement revealed on-chain. +- [Pattern: Pre-trade privacy (encrypted order flow, private RFQ)](../patterns/pattern-pretrade-privacy-encryption.md) - Sealed-bid and private RFQ flows; bids processed confidentially off-chain in TEEs, with settlement revealed on-chain. - [Pattern: Low-cost L2 + Off-chain Encrypted Audit Log](../patterns/pattern-l2-encrypted-offchain-audit.md) - Off-chain encrypted execution with verifiable audit trail; compatible with confidential compute and attested logs. - [Pattern: Permissioned Ledger Interoperability](../patterns/pattern-permissioned-ledger-interoperability.md) - Bridges enterprise systems and permissioned ledgers with confidentiality and compliance using TEE-based workflows. diff --git a/vendors/shutter.md b/vendors/shutter.md index ddb3c5a..83cdbf9 100644 --- a/vendors/shutter.md +++ b/vendors/shutter.md @@ -8,12 +8,14 @@ maturity: production ## What it is -Shutter Network provides encrypted-mempool infrastructure that prevents MEV extraction and front-running by encrypting transactions until they are included in blocks, using threshold cryptography for decryption. It is live on Gnosis Chain, with Ethereum integration planned. +Shutter Network provides encrypted-mempool infrastructure that prevents MEV extraction and front-running by encrypting transactions until their ordering is committed, using threshold cryptography for decryption. Brainbot develops it. Shutterized Gnosis Chain has been live since July 2024, opt-in through a Shutter RPC. On Ethereum mainnet no Shutter encrypted mempool is live as of October 2026. ## Fits with patterns +- [Threshold-Encrypted Mempool](../patterns/pattern-threshold-encrypted-mempool.md): Shutter is the reference implementation - [Pre-trade Privacy](../patterns/pattern-pretrade-privacy-encryption.md): encrypted mempool with threshold decryption -- [Private Broadcasting](../approaches/approach-private-broadcasting.md): intent signaling protection +- [Private Broadcasting](../approaches/approach-private-broadcasting.md): the Encrypted Mempools sub-approach +- [Publicly Verifiable DKG & Threshold Decryption](../patterns/pattern-verifiable-dkg-threshold-decryption.md): the keyper committee's key generation and decryption layer ## Not a substitute for @@ -23,32 +25,40 @@ Shutter Network provides encrypted-mempool infrastructure that prevents MEV extr ## Architecture -Shutter uses threshold encryption: users encrypt transactions with a shared public key; a network of validators collectively decrypts them after block inclusion; searchers cannot see transaction content during the vulnerable mempool phase; ordering protection prevents front-running while maintaining transaction validity. +A committee of keypers runs a distributed key generation and publishes a shared public key. Users encrypt a transaction to that key for an identity, such as a slot. Once the ordering of the encrypted transactions is committed, at least a threshold of keypers release shares of the decryption key for that identity, and the transactions execute in the committed order. Searchers and builders cannot read content during the mempool phase. + +## Privacy domains + +- **Encrypted mempool (Gnosis Chain):** transactions sent through a Shutterized RPC stay encrypted until the keypers release the slot's key. +- **Shutter API:** a commit-and-reveal (timelock) encryption service on Gnosis Chain and Chiado, with its own keyper sets, for applications such as sealed-bid auctions and private voting. ## Enterprise demand and use cases - Encrypted mempool preventing MEV extraction during broadcasting - Threshold decryption with no single point of failure -- Censorship resistance through distributed key management +- Sealed-bid and timelocked submissions through the Shutter API ## Technical details -- **Networks:** live on Gnosis Chain; Ethereum integration planned +- **Networks:** Gnosis Chain mainnet (encrypted mempool, 7 keypers with a threshold of 4); Shutter API on Gnosis Chain and Chiado +- **Ethereum:** an out-of-protocol proof of concept with Primev's mev-commit was announced for the Hoodi testnet in December 2025 (3-of-5 keypers, builders commit before keys are released). The mainnet launch had not happened as of September 2026. +- **Enshrinement:** Shutter authored [EIP-8105](https://eips.ethereum.org/EIPS/eip-8105) (Draft), an enshrined encrypted mempool. Its bid to headline the Hegotá upgrade was withdrawn in February 2026 in favour of LUCID ([EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)), which the team now supports for the upgrade after Hegotá. +- **Code:** [rolling-shutter](https://github.com/shutter-network/rolling-shutter) (Go, MIT) is the active keyper implementation; the original `shutter` repository is legacy. - **Compatibility:** works with standard Ethereum transactions -- **Validator requirements:** requires a network of threshold key holders -- **Developer experience:** minimal changes to existing dApp integration ## Strengths -- Proven solution with mainnet deployment -- Strong cryptographic foundations (threshold encryption) -- Minimal impact on existing Ethereum workflows -- Effective MEV prevention during the critical mempool phase +- Production deployment on Gnosis Chain since 2024 +- Threshold decryption: no single keyper can read pending transactions +- Open-source keyper software +- Active in the Ethereum protocol process for an enshrined encrypted mempool ## Risks and open questions -- Limited to supported networks (Gnosis Chain currently) -- Adds latency due to the threshold decryption process +- No production deployment on Ethereum mainnet +- On Gnosis Chain, users trust the Shutter RPC that receives their transaction, and validators are not slashed for misbehaviour +- A transaction re-sent after its key was released can be front-run +- Adds latency due to the key-release step - Requires coordination among threshold key holders - No protection against MEV after transaction execution @@ -57,3 +67,6 @@ Shutter uses threshold encryption: users encrypt transactions with a shared publ - [Shutter Network](https://shutter.network/) - [Documentation](https://docs.shutter.network/) - [GitHub](https://github.com/shutter-network) +- [Shutterized Gnosis Chain launch (July 2024)](https://shutternetwork.discourse.group/t/shutterized-gnosis-chain-debuts-in-july/444) +- [Threshold-encrypted mempools with mev-commit preconfirmations](https://ethresear.ch/t/threshold-encrypted-mempools-with-mev-commit-preconfirmations/23588) +- [Shutter API](https://github.com/shutter-network/shutter-api) From 6d5bf179cf8b75fe12c17d07163d4c3a32afc552 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?David=20Nu=CC=81n=CC=83ez?= Date: Fri, 30 Oct 2026 12:49:08 +0100 Subject: [PATCH 2/3] Address RFCs from ac --- approaches/approach-private-broadcasting.md | 14 +++++++------- .../pattern-private-transaction-broadcasting.md | 2 +- patterns/pattern-threshold-encrypted-mempool.md | 6 +++--- vendors/flashbots.md | 4 ++-- vendors/shutter.md | 4 ++-- 5 files changed, 15 insertions(+), 15 deletions(-) diff --git a/approaches/approach-private-broadcasting.md b/approaches/approach-private-broadcasting.md index 4773e53..1be2ff7 100644 --- a/approaches/approach-private-broadcasting.md +++ b/approaches/approach-private-broadcasting.md @@ -58,7 +58,7 @@ A trading desk routes large institutional orders against on-chain venues. Visibl ```yaml maturity: production context: both -crops: { cr: medium, o: partial, p: partial, s: medium } +crops: { cr: low, o: partial, p: partial, s: medium } uses_patterns: [pattern-private-transaction-broadcasting, pattern-network-anonymity] example_vendors: [flashbots] ``` @@ -73,7 +73,7 @@ example_vendors: [flashbots] **Threat model:** - A relay or builder that sees the order can trade ahead of it; contracts and reputation are the only enforcement -- Inclusion waits for a reached builder to win a slot; three builders produced about 88% of blocks in late September 2026 +- Inclusion waits for a reached builder to win a slot; three builders produced about 88% of MEV-Boost blocks in late September 2026 - Once FOCIL ships, privately routed transactions do not get its inclusion guarantee - A fallback to the public mempool on relay failure leaks the transaction @@ -133,7 +133,7 @@ example_vendors: [shutter] **How it works:** The user encrypts the transaction to a key held by a threshold committee (in LUCID, a key publisher the user chooses) and submits the ciphertext. Builders and proposers commit to an ordering without seeing content; the key holders then release the key, and the transactions execute in the committed order. [Shutter](../vendors/shutter.md) runs this on Gnosis Chain. On Ethereum no encrypted mempool is live: LUCID ([EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)) is a Draft not scheduled for Hegotá, and out-of-protocol designs depend on builders opting in. On a permissioned chain where one operator sequences, the same construction hides transactions from the operator until the ordering is fixed. **Trust assumptions:** -- Key holders: a t-of-n committee, or a key publisher the user chooses +- Key holders: a t-of-n committee, or a key publisher the user chooses; a single publisher is one trusted party, as a relay is - Liveness of the key holders for the reveal step - Builders and proposers include ciphertexts and respect the encrypt-then-order discipline @@ -193,7 +193,7 @@ example_vendors: [aztec, fhenix, zksync, ey] |---|---|---|---|---| | **Maturity** | production | production | prototyped | prototyped | | **Context** | both | i2i | both | both | -| **CROPS** | CR:med O:part P:part S:med | CR:med O:y P:full S:med | CR:med O:part P:part S:med | CR:med O:part P:full S:med | +| **CROPS** | CR:low O:part P:part S:med | CR:med O:y P:full S:med | CR:med O:part P:part S:med | CR:med O:part P:full S:med | | **Trust model** | Relay and builders | Venue or builder | Key holders (threshold committee) | Sequencer + bridge | | **Privacy scope** | Pre-inclusion content, hidden from the public only | Pre-trade content only | Pre-inclusion content, hidden from builders too | Mempool + state + execution | | **Performance** | Waits for a reached builder to win a slot | Minimal latency | Key-release step; next block in LUCID | L2-internal latency | @@ -206,11 +206,11 @@ example_vendors: [aztec, fhenix, zksync, ey] ### Business perspective -For institutional desks on public chains, a Private Relay is the production default for orders that must reach the chain: private RPCs and direct builder submission are mature and integrate with custody. OTC / Off-chain Matching suits size-sensitive trades, with Renegade and similar dark-pool venues offering ZK-backed matching. Encrypted Mempools win where builder or venue trust is unattractive and the chain supports threshold-encrypted ordering, which on Ethereum L1 waits for an enshrined design. Private Rollups are the suitable choice when privacy across mempool, state, and execution is required and the institution accepts the rollup operator model. The hybrid is to route by trade size and venue: large blocks through OTC, mid-size through encrypted mempools, flow that needs full privacy through a private rollup. +For institutional desks on public chains, a Private Relay is the production default for orders that must reach the chain: private RPCs and direct builder submission are mature and integrate with custody. OTC / Off-chain Matching suits size-sensitive trades, with Renegade and similar dark-pool venues offering ZK-backed matching. Encrypted Mempools win where builder or venue trust is unattractive and the chain supports threshold-encrypted ordering, which on Ethereum L1 waits for an enshrined design. Private Rollups are the suitable choice when privacy across mempool, state, and execution is required and the institution accepts the rollup operator model. The hybrid is to route by trade size and venue: large blocks through OTC; mid-size through a Private Relay, or an encrypted mempool on chains that run one; flow that needs full privacy through a private rollup. ### Technical perspective -A Private Relay is the lightest engineering integration: point the submission path at a private RPC or builder endpoint. OTC / Off-chain Matching adds a venue integration and ships signed bundles. Encrypted Mempools require a threshold network on the target chain (Shutter on Gnosis Chain; none on Ethereum L1 yet) and tolerating the encrypt-decrypt round trip. Private Rollups are the heaviest commit: deploy or join a privacy-native rollup, integrate with its sequencer model, and accept the bridge boundary as a liquidity surface. None of the three offers cryptographic ordering atomicity across builders or rollups; cross-domain MEV remains an open frontier for chains that have multiple block builders or sequencers competing for inclusion. +A Private Relay is the lightest engineering integration: point the submission path at a private RPC or builder endpoint. OTC / Off-chain Matching adds a venue integration and ships signed bundles. Encrypted Mempools require a threshold network on the target chain (Shutter on Gnosis Chain; none on Ethereum L1 yet) and tolerating the encrypt-decrypt round trip. Private Rollups are the heaviest commit: deploy or join a privacy-native rollup, integrate with its sequencer model, and accept the bridge boundary as a liquidity surface. None of the four offers cryptographic ordering atomicity across builders or rollups; cross-domain MEV remains an open frontier for chains that have multiple block builders or sequencers competing for inclusion. ### Legal & risk perspective @@ -231,7 +231,7 @@ For institutional desks on public chains, default to a Private Relay for orders ### Hybrid -Tier the privacy stack by trade size: large blocks (>EUR 5M-equivalent) through OTC; mid-size and time-sensitive flow through an encrypted mempool; comprehensive privacy flows (consortium or institutional desk) on a private rollup. Bridge balances out by routing all settlement to a shielded pool boundary so cross-tier movement does not re-expose history. +Tier the privacy stack by trade size: large blocks (>EUR 5M-equivalent) through OTC; mid-size and time-sensitive flow through a Private Relay, or an encrypted mempool on chains that run one; comprehensive privacy flows (consortium or institutional desk) on a private rollup. Bridge balances out by routing all settlement to a shielded pool boundary so cross-tier movement does not re-expose history. ## Open questions diff --git a/patterns/pattern-private-transaction-broadcasting.md b/patterns/pattern-private-transaction-broadcasting.md index feca9a9..1fcc987 100644 --- a/patterns/pattern-private-transaction-broadcasting.md +++ b/patterns/pattern-private-transaction-broadcasting.md @@ -93,7 +93,7 @@ Threat model: ## Trade-offs -- A privately routed transaction is included only when a builder it reached wins the slot. Three builders produced about 88% of Ethereum blocks in late September 2026 ([relayscan](https://www.relayscan.io/)), so the relay's builder coverage sets inclusion latency. +- A privately routed transaction is included only when a builder it reached wins the slot. Three builders produced about 88% of MEV-Boost blocks in late September 2026 ([relayscan](https://www.relayscan.io/)), so the relay's builder coverage sets inclusion latency. - Relay coverage varies over time; users should monitor live coverage metrics rather than assume a fixed figure. - The threshold variant adds a key-release step after commitment, a decryption committee to operate, and a liveness dependency. - Cost model varies: some relay services are free, others take a share of MEV or charge fees. diff --git a/patterns/pattern-threshold-encrypted-mempool.md b/patterns/pattern-threshold-encrypted-mempool.md index ecbb0a9..ae26475 100644 --- a/patterns/pattern-threshold-encrypted-mempool.md +++ b/patterns/pattern-threshold-encrypted-mempool.md @@ -9,7 +9,7 @@ last_reviewed: 2026-10-27 works-best-when: - Maximal extractable value (MEV) protection is needed at the protocol level rather than through a trusted relay. - Users cannot or do not want to trust a private relay as a single point of trust. - - Censorship resistance must be combined with pre-inclusion content privacy. + - Resistance to content-based censorship must be combined with pre-inclusion content privacy. avoid-when: - The committee liveness dependency is unacceptable for the target use case. - Decryption latency is incompatible with the workload. @@ -66,7 +66,7 @@ This pattern is the cryptographic sub-pattern of private transaction broadcastin - Distributed key generation: the committee jointly produces the threshold public key without any party ever holding the full private key. - Keyper committee: a distributed set of key holders drawn from validators, independent operators, or a delegated governance process. - Block builder integration: the builder accepts encrypted payloads and includes them without inspecting contents. -- Key release: key holders publish decryption shares once the ordering is committed. LUCID generalises this to a key publisher the sender chooses: a committee, a single operator, or the sender itself. +- Key release: key holders publish decryption shares once the ordering is committed. LUCID generalises this to a key publisher the sender chooses: a committee, a single operator, or the sender itself. A single operator is one trusted party, as a relay is. - Variants: identity-based keys per slot or epoch (Shutter), or batched threshold encryption, where each key holder publishes one share for a whole batch. ## Protocol @@ -84,7 +84,7 @@ This pattern is the cryptographic sub-pattern of private transaction broadcastin Guarantees: - Pre-inclusion content privacy: transaction contents are hidden from block builders, searchers, and validators until after block commitment. -- Cryptographic enforcement: no single party can decrypt, so front-running and sandwiching at the mempool stage are prevented without trusting a relay. +- Cryptographic enforcement: with a threshold committee, no single party can decrypt, so front-running and sandwiching at the mempool stage are prevented without trusting a relay. - Censorship resistance: encrypted payloads carry no application-layer signal, so content-based censorship is not possible at the builder. Censorship by sender, or of all ciphertexts, remains possible. - Post-decryption auditability: once the slot key is released, transaction history becomes public and fully verifiable. diff --git a/vendors/flashbots.md b/vendors/flashbots.md index 868735a..f04e4eb 100644 --- a/vendors/flashbots.md +++ b/vendors/flashbots.md @@ -8,7 +8,7 @@ maturity: production ## What it is -Flashbots develops MEV infrastructure for Ethereum: MEV-Boost, which validators use to source blocks from builders; Flashbots Protect, a private RPC that keeps transactions out of the public mempool; MEV-Share, which lets users share hints with searchers and capture part of the MEV their transactions create; and BuilderNet, a block-building network run by several operators. SUAVE, its earlier design for a decentralized intent platform, is archived. +Flashbots develops MEV infrastructure for Ethereum: MEV-Boost, which validators use to source blocks from builders; Flashbots Protect, a private RPC that keeps transactions out of the public mempool; MEV-Share, which lets users share hints with searchers and capture part of the MEV their transactions create; and BuilderNet, a block-building network. SUAVE, its earlier design for a decentralized intent platform, is archived. ## Fits with patterns @@ -34,7 +34,7 @@ Flashbots develops MEV infrastructure for Ethereum: MEV-Boost, which validators **MEV-Share:** an operator-run node shares configurable hints about pending transactions with searchers, who may only backrun them. In Protect's fast mode, searchers running in TEEs receive the full transaction whatever the hint settings. -**BuilderNet:** a block-building network operated by several parties. Since September 2026 its documentation says it is "transitioning to a new security model": during this period its nodes do not run in TEEs, while its backrunning and routing services still do. +**BuilderNet:** a block-building network. Since September 2026 its documentation says it is "transitioning to a new security model": during this period its nodes do not run in TEEs, while its backrunning and routing services still do. The same documentation change removed the operator pages, since BuilderNet has no external operators. **SUAVE (archived):** a planned decentralized intent and block-building platform. The suave-geth repository was archived in May 2025. diff --git a/vendors/shutter.md b/vendors/shutter.md index 83cdbf9..95eee2f 100644 --- a/vendors/shutter.md +++ b/vendors/shutter.md @@ -41,8 +41,8 @@ A committee of keypers runs a distributed key generation and publishes a shared ## Technical details - **Networks:** Gnosis Chain mainnet (encrypted mempool, 7 keypers with a threshold of 4); Shutter API on Gnosis Chain and Chiado -- **Ethereum:** an out-of-protocol proof of concept with Primev's mev-commit was announced for the Hoodi testnet in December 2025 (3-of-5 keypers, builders commit before keys are released). The mainnet launch had not happened as of September 2026. -- **Enshrinement:** Shutter authored [EIP-8105](https://eips.ethereum.org/EIPS/eip-8105) (Draft), an enshrined encrypted mempool. Its bid to headline the Hegotá upgrade was withdrawn in February 2026 in favour of LUCID ([EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)), which the team now supports for the upgrade after Hegotá. +- **Ethereum:** an out-of-protocol proof of concept with Primev's mev-commit was announced for the Hoodi testnet in December 2025 (3-of-5 keypers, builders commit before keys are released). The mainnet launch had not happened as of September 2026, and Brainbot's [September 2026 update](https://shutternetwork.discourse.group/t/976) says the out-of-protocol work is blocked by Primev resource constraints. +- **Enshrinement:** Shutter authored [EIP-8105](https://eips.ethereum.org/EIPS/eip-8105) (Draft), an enshrined encrypted mempool. Its bid to headline the Hegotá upgrade was withdrawn in February 2026 in favour of LUCID ([EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)), which the team now supports. The same update sets the goal of an encrypted mempool EIP ready to propose as headliner for I*, the upgrade after Hegotá. - **Code:** [rolling-shutter](https://github.com/shutter-network/rolling-shutter) (Go, MIT) is the active keyper implementation; the original `shutter` repository is legacy. - **Compatibility:** works with standard Ethereum transactions From 63614e091139dc1946af8b4fcee0676639d6d56f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?David=20Nu=CC=81n=CC=83ez?= Date: Wed, 4 Nov 2026 11:32:36 +0100 Subject: [PATCH 3/3] Address RFCs from oskarth --- CHANGELOG.md | 2 +- approaches/approach-private-broadcasting.md | 12 ++++++------ patterns/pattern-focil-eip7805.md | 2 +- patterns/pattern-pretrade-privacy-encryption.md | 2 +- patterns/pattern-private-transaction-broadcasting.md | 4 ++-- patterns/pattern-threshold-encrypted-mempool.md | 6 +++--- vendors/shutter.md | 8 ++++---- 7 files changed, 18 insertions(+), 18 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 5d8550d..f3dd1ce 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,7 +4,7 @@ All notable changes to the EthSystems Map are documented here. ## [Unreleased] -- fix(approach): Phase 1 review of [Private Transaction Broadcasting](approaches/approach-private-broadcasting.md) for the encrypted mempool cycle, with a new Private Relay sub-approach. +- fix(approach): review of [Private Transaction Broadcasting](approaches/approach-private-broadcasting.md), with a new Private Relay sub-approach ([#213](https://github.com/ethsystems/map/pull/213)). - fix: review of the patterns, vendors and use cases it links. [Threshold-Encrypted Mempool](patterns/pattern-threshold-encrypted-mempool.md) censorship resistance moves from `high` to `medium`. - fix: factual audit of the [Private FX](use-cases/private-fx.md) entry. - fix: factual audit of the [Private Repo](use-cases/private-repo.md) entry and the Private Trade Settlement cards it builds on. diff --git a/approaches/approach-private-broadcasting.md b/approaches/approach-private-broadcasting.md index 1be2ff7..203f04f 100644 --- a/approaches/approach-private-broadcasting.md +++ b/approaches/approach-private-broadcasting.md @@ -21,7 +21,7 @@ open_source_implementations: description: "SUAVE private-intent execution (suave-geth archived May 2025; Flashbots migrated to BuilderNet)" language: Go - url: https://github.com/shutter-network/rolling-shutter - description: "Shutter Network keyper (threshold-encrypted mempool, production on Gnosis Chain)" + description: "Shutter Network keyper (threshold-encrypted mempool, deployed on Gnosis Chain from July 2024)" language: Go - url: https://github.com/AztecProtocol/aztec-packages description: "Aztec privacy-native L2" @@ -73,7 +73,7 @@ example_vendors: [flashbots] **Threat model:** - A relay or builder that sees the order can trade ahead of it; contracts and reputation are the only enforcement -- Inclusion waits for a reached builder to win a slot; three builders produced about 88% of MEV-Boost blocks in late September 2026 +- Inclusion waits for a reached builder to win a slot; three builders produced over 90% of MEV-Boost blocks on each day from 22 to 30 September 2026 ([relayscan](https://www.relayscan.io/stats/day/2026-09-25)) - Once FOCIL ships, privately routed transactions do not get its inclusion guarantee - A fallback to the public mempool on relay failure leaks the transaction @@ -90,7 +90,7 @@ example_vendors: [flashbots] ```yaml maturity: production context: i2i -crops: { cr: medium, o: yes, p: full, s: medium } +crops: { cr: low, o: yes, p: full, s: medium } uses_patterns: [pattern-network-anonymity] example_vendors: [renegade, flashbots] ``` @@ -130,7 +130,7 @@ example_vendors: [shutter] **Summary:** Transactions are encrypted before submission. Decryption happens after ordering is fixed, never before. See [Threshold-Encrypted Mempool](../patterns/pattern-threshold-encrypted-mempool.md) for the underlying primitive and [Pre-trade Privacy Encryption](../patterns/pattern-pretrade-privacy-encryption.md) for its use with RFQ flows. -**How it works:** The user encrypts the transaction to a key held by a threshold committee (in LUCID, a key publisher the user chooses) and submits the ciphertext. Builders and proposers commit to an ordering without seeing content; the key holders then release the key, and the transactions execute in the committed order. [Shutter](../vendors/shutter.md) runs this on Gnosis Chain. On Ethereum no encrypted mempool is live: LUCID ([EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)) is a Draft not scheduled for Hegotá, and out-of-protocol designs depend on builders opting in. On a permissioned chain where one operator sequences, the same construction hides transactions from the operator until the ordering is fixed. +**How it works:** The user encrypts the transaction to a key held by a threshold committee (in LUCID, a key publisher the user chooses) and submits the ciphertext. Builders and proposers commit to an ordering without seeing content; the key holders then release the key, and the transactions execute in the committed order. [Shutter](../vendors/shutter.md) ran this on Gnosis Chain from July 2024; Gnosis archived its Shutter docs in September 2026. On Ethereum no encrypted mempool is live: LUCID ([EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)) is a Draft not scheduled for Hegotá, and out-of-protocol designs depend on builders opting in. On a permissioned chain where one operator sequences, the same construction hides transactions from the operator until the ordering is fixed. **Trust assumptions:** - Key holders: a t-of-n committee, or a key publisher the user chooses; a single publisher is one trusted party, as a relay is @@ -193,7 +193,7 @@ example_vendors: [aztec, fhenix, zksync, ey] |---|---|---|---|---| | **Maturity** | production | production | prototyped | prototyped | | **Context** | both | i2i | both | both | -| **CROPS** | CR:low O:part P:part S:med | CR:med O:y P:full S:med | CR:med O:part P:part S:med | CR:med O:part P:full S:med | +| **CROPS** | CR:low O:part P:part S:med | CR:low O:y P:full S:med | CR:med O:part P:part S:med | CR:med O:part P:full S:med | | **Trust model** | Relay and builders | Venue or builder | Key holders (threshold committee) | Sequencer + bridge | | **Privacy scope** | Pre-inclusion content, hidden from the public only | Pre-trade content only | Pre-inclusion content, hidden from builders too | Mempool + state + execution | | **Performance** | Waits for a reached builder to win a slot | Minimal latency | Key-release step; next block in LUCID | L2-internal latency | @@ -210,7 +210,7 @@ For institutional desks on public chains, a Private Relay is the production defa ### Technical perspective -A Private Relay is the lightest engineering integration: point the submission path at a private RPC or builder endpoint. OTC / Off-chain Matching adds a venue integration and ships signed bundles. Encrypted Mempools require a threshold network on the target chain (Shutter on Gnosis Chain; none on Ethereum L1 yet) and tolerating the encrypt-decrypt round trip. Private Rollups are the heaviest commit: deploy or join a privacy-native rollup, integrate with its sequencer model, and accept the bridge boundary as a liquidity surface. None of the four offers cryptographic ordering atomicity across builders or rollups; cross-domain MEV remains an open frontier for chains that have multiple block builders or sequencers competing for inclusion. +A Private Relay is the lightest engineering integration: point the submission path at a private RPC or builder endpoint. OTC / Off-chain Matching adds a venue integration and ships signed bundles. Encrypted Mempools require a threshold network on the target chain (none on Ethereum L1 yet, and Gnosis archived its Shutter docs in September 2026) and tolerating the encrypt-decrypt round trip. Private Rollups are the heaviest commit: deploy or join a privacy-native rollup, integrate with its sequencer model, and accept the bridge boundary as a liquidity surface. None of the four offers cryptographic ordering atomicity across builders or rollups; cross-domain MEV remains an open frontier for chains that have multiple block builders or sequencers competing for inclusion. ### Legal & risk perspective diff --git a/patterns/pattern-focil-eip7805.md b/patterns/pattern-focil-eip7805.md index c94dcc2..4adc150 100644 --- a/patterns/pattern-focil-eip7805.md +++ b/patterns/pattern-focil-eip7805.md @@ -50,7 +50,7 @@ open_source_implementations: ## Intent -Prevent censorship of Ethereum transactions by sophisticated block builders. A committee of 16 validators per slot can force-include transactions in the next block; non-compliant blocks fail fork-choice and cannot reach finality. The pattern provides no privacy on its own: transactions remain fully visible in the mempool and on chain. It guarantees only that a transaction cannot be censored once it reaches the public mempool. FOCIL is scheduled for inclusion in the Hegotá upgrade, estimated for mid-2027. +Prevent censorship of Ethereum transactions by sophisticated block builders. A committee of 16 validators per slot can force-include transactions in the next block; non-compliant blocks fail fork-choice and cannot reach finality. The pattern provides no privacy on its own: transactions remain fully visible in the mempool and on chain. It guarantees only that a transaction cannot be censored once it reaches the public mempool. FOCIL is scheduled for inclusion in the Hegotá upgrade ([EIP-8081](https://eips.ethereum.org/EIPS/eip-8081)); no date is set, and [Forkcast](https://forkcast.org/upgrade/hegota) lists 2027. ## Components diff --git a/patterns/pattern-pretrade-privacy-encryption.md b/patterns/pattern-pretrade-privacy-encryption.md index ff5f1f3..8434888 100644 --- a/patterns/pattern-pretrade-privacy-encryption.md +++ b/patterns/pattern-pretrade-privacy-encryption.md @@ -61,7 +61,7 @@ related_patterns: open_source_implementations: - url: https://github.com/shutter-network/rolling-shutter - description: "Threshold-encrypted mempool reference implementation (Shutter keyper, production on Gnosis Chain)" + description: "Threshold-encrypted mempool reference implementation (Shutter keyper, deployed on Gnosis Chain from July 2024)" language: Go - url: https://github.com/flashbots/suave-geth description: "Private builder and confidential compute environment for order flow (archived 2025; historical reference)" diff --git a/patterns/pattern-private-transaction-broadcasting.md b/patterns/pattern-private-transaction-broadcasting.md index 1fcc987..265d3a6 100644 --- a/patterns/pattern-private-transaction-broadcasting.md +++ b/patterns/pattern-private-transaction-broadcasting.md @@ -47,7 +47,7 @@ open_source_implementations: description: "MEV-Boost relay infrastructure used by the majority of Ethereum validators" language: Go - url: https://github.com/shutter-network/rolling-shutter - description: "Threshold-encrypted mempool reference stack (production on Gnosis Chain)" + description: "Threshold-encrypted mempool reference stack (deployed on Gnosis Chain from July 2024)" language: Go --- @@ -93,7 +93,7 @@ Threat model: ## Trade-offs -- A privately routed transaction is included only when a builder it reached wins the slot. Three builders produced about 88% of MEV-Boost blocks in late September 2026 ([relayscan](https://www.relayscan.io/)), so the relay's builder coverage sets inclusion latency. +- A privately routed transaction is included only when a builder it reached wins the slot. Three builders produced over 90% of MEV-Boost blocks on each day from 22 to 30 September 2026 ([relayscan](https://www.relayscan.io/stats/day/2026-09-25)), so the relay's builder coverage sets inclusion latency. - Relay coverage varies over time; users should monitor live coverage metrics rather than assume a fixed figure. - The threshold variant adds a key-release step after commitment, a decryption committee to operate, and a liveness dependency. - Cost model varies: some relay services are free, others take a share of MEV or charge fees. diff --git a/patterns/pattern-threshold-encrypted-mempool.md b/patterns/pattern-threshold-encrypted-mempool.md index ae26475..87a6dae 100644 --- a/patterns/pattern-threshold-encrypted-mempool.md +++ b/patterns/pattern-threshold-encrypted-mempool.md @@ -47,7 +47,7 @@ related_patterns: open_source_implementations: - url: https://github.com/shutter-network/rolling-shutter - description: "Shutter keyper and threshold-encryption framework, in production on Gnosis Chain" + description: "Shutter keyper and threshold-encryption framework, deployed on Gnosis Chain from July 2024" language: Go - url: https://github.com/commonwarexyz/simple-bte description: "Batched threshold encryption research prototype" @@ -56,7 +56,7 @@ open_source_implementations: ## Intent -Prevent maximal extractable value (MEV) extraction by encrypting transaction content before mempool submission and releasing the decryption key only after block ordering is committed. A distributed committee holds threshold key shares, so no single party can decrypt prematurely. The result is cryptographic protection against front-running, back-running, and sandwich attacks, without handing trust to any one relay. Shutter runs this in production on Gnosis Chain. On Ethereum no encrypted mempool is live: LUCID ([EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)), the leading proposal to enshrine one, is a Draft and is not scheduled for Hegotá. +Prevent maximal extractable value (MEV) extraction by encrypting transaction content before mempool submission and releasing the decryption key only after block ordering is committed. A distributed committee holds threshold key shares, so no single party can decrypt prematurely. The result is cryptographic protection against front-running and sandwich attacks, without handing trust to any one relay; back-running after decryption stays possible. Shutter ran this on Gnosis Chain from July 2024; Gnosis archived its Shutter docs in September 2026. On Ethereum no encrypted mempool is live: LUCID ([EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)), the leading proposal to enshrine one, is a Draft and is not scheduled for Hegotá. This pattern is the cryptographic sub-pattern of private transaction broadcasting. The trust-based private-relay variant is documented as a related pattern (see related_patterns.requires). @@ -113,7 +113,7 @@ A trading desk submits a large stablecoin trade on a chain that runs a threshold - [Shutter Network overview](https://shutter.network/) - [Shutter documentation](https://docs.shutter.network/) -- [Gnosis Chain Shutter integration](https://docs.gnosischain.com/about/specs/shutter/) +- [Gnosis Chain Shutter specification](https://github.com/gnosischain/specs/tree/master/shutter) - [EIP-8184: LUCID encrypted mempool](https://eips.ethereum.org/EIPS/eip-8184) - [EIP-8105: Universal Enshrined Encrypted Mempool](https://eips.ethereum.org/EIPS/eip-8105) - [Batched threshold encryption (eprint 2024/669)](https://eprint.iacr.org/2024/669) diff --git a/vendors/shutter.md b/vendors/shutter.md index 95eee2f..820b565 100644 --- a/vendors/shutter.md +++ b/vendors/shutter.md @@ -8,7 +8,7 @@ maturity: production ## What it is -Shutter Network provides encrypted-mempool infrastructure that prevents MEV extraction and front-running by encrypting transactions until their ordering is committed, using threshold cryptography for decryption. Brainbot develops it. Shutterized Gnosis Chain has been live since July 2024, opt-in through a Shutter RPC. On Ethereum mainnet no Shutter encrypted mempool is live as of October 2026. +Shutter Network provides encrypted-mempool infrastructure that prevents MEV extraction and front-running by encrypting transactions until their ordering is committed, using threshold cryptography for decryption. Brainbot develops it. Shutterized Gnosis Chain went live in July 2024, opt-in through a Shutter RPC. In September 2026 Gnosis archived its Shutter docs, saying Shutter is no longer part of Gnosis Chain ([Gnosis docs](https://github.com/gnosischain/documentation/blob/main/archives/Shutter/README.md)); Brainbot's September update still reports an active keyper set. On Ethereum mainnet no Shutter encrypted mempool is live as of October 2026. ## Fits with patterns @@ -29,7 +29,7 @@ A committee of keypers runs a distributed key generation and publishes a shared ## Privacy domains -- **Encrypted mempool (Gnosis Chain):** transactions sent through a Shutterized RPC stay encrypted until the keypers release the slot's key. +- **Encrypted mempool (Gnosis Chain):** transactions sent through a Shutterized RPC stay encrypted until the keypers release the slot's key. Gnosis archived its Shutter docs in September 2026. - **Shutter API:** a commit-and-reveal (timelock) encryption service on Gnosis Chain and Chiado, with its own keyper sets, for applications such as sealed-bid auctions and private voting. ## Enterprise demand and use cases @@ -40,7 +40,7 @@ A committee of keypers runs a distributed key generation and publishes a shared ## Technical details -- **Networks:** Gnosis Chain mainnet (encrypted mempool, 7 keypers with a threshold of 4); Shutter API on Gnosis Chain and Chiado +- **Networks:** Gnosis Chain mainnet (encrypted mempool, 7 keypers with a threshold of 4, 6 online in September 2026; Gnosis archived its Shutter docs that month); Shutter API on Gnosis Chain and Chiado - **Ethereum:** an out-of-protocol proof of concept with Primev's mev-commit was announced for the Hoodi testnet in December 2025 (3-of-5 keypers, builders commit before keys are released). The mainnet launch had not happened as of September 2026, and Brainbot's [September 2026 update](https://shutternetwork.discourse.group/t/976) says the out-of-protocol work is blocked by Primev resource constraints. - **Enshrinement:** Shutter authored [EIP-8105](https://eips.ethereum.org/EIPS/eip-8105) (Draft), an enshrined encrypted mempool. Its bid to headline the Hegotá upgrade was withdrawn in February 2026 in favour of LUCID ([EIP-8184](https://eips.ethereum.org/EIPS/eip-8184)), which the team now supports. The same update sets the goal of an encrypted mempool EIP ready to propose as headliner for I*, the upgrade after Hegotá. - **Code:** [rolling-shutter](https://github.com/shutter-network/rolling-shutter) (Go, MIT) is the active keyper implementation; the original `shutter` repository is legacy. @@ -48,7 +48,7 @@ A committee of keypers runs a distributed key generation and publishes a shared ## Strengths -- Production deployment on Gnosis Chain since 2024 +- Production deployment on Gnosis Chain from July 2024 - Threshold decryption: no single keyper can read pending transactions - Open-source keyper software - Active in the Ethereum protocol process for an enshrined encrypted mempool