Works best when
- Miner Extractable Value 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
- The committee liveness dependency is unacceptable for the target use case.
- Decryption latency is incompatible with the workload.
- A single trusted operator is acceptable, in which case a private relay is simpler.
I2I vs I2U — context differences
Institution to institution
I2IThe protocol-level design treats every participant identically, so institutional submitters get the same guarantee as anyone else. Institutions may still prefer bilateral private-relay integrations where contractual recourse is available, but the threshold scheme removes any single-operator trust.
Institution to end user
I2UEnd 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.
Post-quantum exposure
Risk · high- Vector
- Pairing-based threshold encryption schemes rely on elliptic-curve primitives broken by a CRQC; pre-inclusion ciphertext collected today has Harvest-Now-Decrypt-Later exposure.
- Mitigation
- Lattice-based threshold encryption schemes. See Post-Quantum Threats.
Components
- Threshold encryption scheme: a k-of-n construction so that k committee members must cooperate to decrypt.
- 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.
Protocol
- operator Keypers run distributed key generation to produce a threshold public key and individual key shares.
- operator The threshold public key is published so users can encrypt transactions to it.
- user The user encrypts a transaction under the threshold public key and submits the ciphertext to the mempool.
- operator The block builder includes the ciphertext in a block without seeing its contents.
- contract The block is proposed and finalized; slot commitment is now immutable.
- operator At least k keypers release their decryption key shares for the slot.
- operator Shares are aggregated into the slot decryption key, which reveals the transactions, and execution proceeds on the decrypted payloads.
Guarantees & threat model
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.
- Post-decryption auditability: once the slot key is released, transaction history becomes public and fully verifiable.
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.
- 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.
- 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.