Skip to content
~/sultan
Chapter 3 crest
Chapter 3 · § 3.3 · Recipe

Threshold Encryption

The leader cannot decrypt before commitment.

By · Originally published April 2026 · Next review October 2026 · ~5 min

Problem

How does the protocol prevent leaders from seeing transaction content before committing to ordering? The leader's information advantage is the structural cause of MEV.

Solution

t-of-n threshold encryption to the active validator set.

Transactions are encrypted to a t-of-n threshold of the active validator set on entry to the mempool. The leader proposes a block ordering over encrypted transactions. The block is finalized over the encrypted ordering. Decryption shares are then released by validators and combined to produce the cleartext for execution.

The encryption scheme is ECDH-based threshold in Phase 1, with migration to Kyber-based (FIPS 203) threshold in Phase 3. The t-of-n parameters are tuned to match the consensus committee structure and require active liveness from a supermajority of validators to decrypt — meaning validators cannot collude to selectively decrypt transactions before commitment without colluding to halt consensus.

Discussion

Threshold encryption is the operational difference between a chain that has MEV and a chain that does not. It is also the part of the design that ordinary validators are most concerned about, because it adds a per-block decryption round and complicates the validator runtime.

ℹ Note The current implementation adds approximately 200ms per block in the testnet conditions — meaningful but well below what most users would notice for non-HFT use cases.
△ Warning Validators are encouraged to look at the threshold-encryption layer as a feature, not a tax. The same primitive that imposes the latency is the one that closes the order-flow auction the validator set would otherwise be on the wrong side of. The economics of fair ordering favor most validators, not most extractors.

See Also

❦ ❦ ❦