Sedna versus the world: MEV protection without the encryption tax.

Okay maybe not the world. But the world of encrypted mempools for sure. Sei Research Initiative has previously spoken about Sedna [1] and how it approximates an encrypted mempool in some settings but we’ve treated it relatively hand wavily so far. Today we’ll spend a bit of time comparing Sedna to common encrypted mempool approaches in a little more detail, we’ll stay away from the real technical details though if that is interesting to folks we can do a more technical review in the near future.

To some a public mempool is crypto’s original sin as they make user intent visible before execution, allowing others to exploit that intent for profit. A liquidation can be seen as not just call data but as an invitation to race. The industry has spent years trying to patch this. Private relays [2]. Commit reveal schemes [3,4]. Threshold encryption [5,6]. Batched threshold encryption [7]. Trusted execution environments [8]. Time lock encryption [9]. FHE [10]. MPC [11]. Each approach tries to hide transaction contents until it is too late for a searcher, builder, validator, or sequencer to exploit them.

MEV is not only about reordering inside a block. It is about information asymmetry before a transaction lands. If a privileged actor sees a transaction early, they can front-run it, back-run it, sandwich it, copy it, censor it, or delay it. The Flash Boys 2.0 paper [12] documented how arbitrage bots and priority gas auctions turned public transaction visibility into a fee bidding and ordering game, with implications for consensus security as well as user losses. The obvious fix is to simply hide the transaction. That gives us the encrypted mempool family of designs. Users submit encrypted transactions. The chain, committee, sequencer, or hardware environment commits to inclusion and order. Only then does decryption happen. In principle, nobody can front-run what they cannot see. The hard part of this though is not the encryption, but the decryption. How do you ensure incentives align to decrypt? Who controls the key? When is the transaction decrypted? How much extra bandwidth is needed? Who pays?

Commit reveal is the oldest and simplest answer, and a general sketch of an approach can be seen in references 3 and 4, below. First, a user commits to a hash of their transaction or intent. Later, they reveal the plaintext. The commitment proves the reveal was fixed in advance and cannot be gamed later. There are three key downsides here. The first two being UX and latency, as the entire process now requires two phases, and the user must remain interactive to reveal. The bigger issue is the incentive to reveal. If you now see other transactions and know that you’ll lose money when you’re executed, why would you ever reveal?

Threshold encryption is the standard “serious” encrypted mempool design. Users encrypt transactions under a public key controlled by a committee. No single committee member can decrypt. Once ordering or inclusion is fixed, enough committee members release decryption shares, and the transaction becomes executable. Shutter’s design, for example, uses Keypers and distributed key generation so transactions stay encrypted until block producers or sequencers have committed to inclusion and order. The protocols tend to be a bit of a pain though. You need a key committee. You need DKG or some setup mechanism. You need a key release protocol. You need accountability for early decryption and liveness for late decryption. You need to decide whether the committee is validator aligned, separately elected, permissioned, slashable, or app specific. You need to handle the ugly case where ciphertexts are included but keys are not released on time. Threshold encryption also does not solve multi-proposer dissemination by itself. If a user wants censorship resistance across many proposers, they may still need to send an encrypted full transaction to many places. The transaction is hidden, but the byte duplication remains.

Batched threshold encryption improves the basic threshold approach by amortizing decryption across a block or batch, primarily because naive threshold decryption tends towards the expensive side. Numerous debates exist here, around the security models, whether they should be epoched or not, how to reduce the common reference string sizes. The BEAT-MEV work [13] suggests a decryption time of ~440ms for around 500 transactions. Naively for a 200k TPS chain that’s minutes of decryption overhead for every second of block production, and that number is significantly better than the 3.5s per 500 transaction batch proposed by Choudhuri et al. Although BEAT is clearly the most promising pure crypto approach today, we’re still some way from something that’s realistic. 

TEEs. Trusted execution environments take the opposite trade. Instead of relying purely on distributed cryptography, TEEs involve running sensitive code inside hardware isolated enclaves. The machine operator cannot see the plaintext, remote attestation tells users what code is running. At least in theory. In practice they have a habit of breaking [14,15] and you fall back to a standard operator trust model where you claim something along the lines of the TEE is in company x’s data center and they won’t leak anything. If we ignore the security aspects for a second then the appeal is clear though. They can preserve a near normal transaction pipeline and are already attractive in rollup sequencing, private block building, confidential compute, and off-chain execution settings.

The time lock approach attempts to avoid committees. You encrypt the transaction so that it becomes decryptable only after some amount of time or sequential work. This is philosophically clean. No Keypers. No trusted hardware. No decryption cartel. But blockchains need predictable latency. Delay encryption is hard to calibrate across heterogeneous hardware, adversarial optimization, and changing network conditions. Too short, and attackers decrypt early. Too long, and users wait. Research on timed release encryption repeatedly runs into the cost and predictability problem, that solving time lock puzzles can consume substantial computation, and predicting real world solve time is difficult [9,16].

Fully homomorphic encryption is the dream version. Keep data encrypted not only in the mempool, but during computation. Validators or coprocessors could execute logic without seeing private inputs. Zama’s fhEVM technical report [17], for example, describes FHE as enabling computations directly on encrypted data, with threshold MPC used for key management and decryption. For general private smart contracts, this is a fair long term direction. For plain pending transaction MEV protection, it is usually too much machine for the job. FHE adds large ciphertexts, expensive computation, specialized infrastructure, and complex key management. FHE is useful for solving private execution rather than private dissemination before execution.

Sedna starts from a multi-concurrent proposer chain. In an MCP chain, many proposer lanes can include data in the same slot. That helps censorship resistance because no single leader has a complete veto. But it creates a practical submission problem, how should users send transactions to proposers? The naive answer is replication. Send the whole transaction to many proposers. If some censor, at least one honest proposer includes it. This is simple, but expensive. Sedna replaces whole transaction replication with rateless erasure coding. A user commits to the payload, derives a transaction ID, generates an unbounded stream of small coded symbols, bundles different symbols for different lanes, and privately sends each lane only its addressed bundle. Validators check signatures, accounting, and bundle validity. They do not need to decode the transaction immediately. Once enough verified symbols appear in finalized history, the payload is reconstructed, the commitment opening is checked, and execution order is determined by the first height at which decoding succeeds. In plain English you could say something along the lines of Sedna makes the transaction unavailable to everyone until the chain itself has accumulated enough pieces. That gives Sedna “until-decode privacy.” Before the decode threshold is reached, an adversary learns the public header and whatever symbols it has observed, but not the full payload unless it gathers enough symbols. The paper formalizes this as leakage bounded by observed symbols and gives an early decode probability based on how many adversarial lanes receive enough symbols. This is not the same as threshold encryption. There is no global decryption key. There is no decryption committee. There is no post-order key release phase. Privacy comes from dispersion alone as no single proposer gets the whole thing.

Traditional encrypted mempools introduce a new cryptographic role to the protocol; someone, or some committee, must eventually decrypt. That role must be selected, funded, monitored, and punished if it misbehaves. If the design is enshrined, the consensus protocol must understand encrypted transaction formats, key publication, validity rules, and failure cases. Ethereum’s EIP-8105 [18] explicitly stays scheme agnostic because possible key providers include threshold encryption, MPC committees, TEEs, delay encryption, and FHE. EIP-8184 [19] similarly avoids coupling the protocol to a single encryption scheme and notes that no known construction satisfies all Ethereum scale requirements at once. Sedna has complexity, but it is a different kind. It needs coding, commitments, bundle signatures, deterministic deduplication, symbol accounting, and parameter selection. That is real engineering. But it does not require every chain to adopt a global decryption service. 

Commit-reveal adds phase delay. Threshold encryption adds key release latency. Batched threshold encryption reduces communication, but still requires post-commit decryption. TEEs are fast, but trade cryptographic trust for hardware trust. Sedna’s latency depends on symbol accumulation. In the good case, if enough honest lanes publish enough distinct symbols in the target slot, decoding happens immediately after finalization. If not, the sender can resample lanes and continue sending symbols across slots. Our paper models single slot inclusion and multi-slot inclusion under resampling, with the number of slots dominated by a geometric random variable when the per-slot success probability is high enough. The surprising result is that coding overhead does not necessarily make Sedna slower. The evaluation reports that rateless coding can have lower end-to-end latency than naive replication because reduced network transmission can dominate the extra symbol generation and verification work.

Encrypted mempools hide bytes. They do not automatically reduce bytes. If you encrypt a full transaction and send it to ten proposers, you still sent ten full transactions. You may even add ciphertext overhead, key provider metadata, proofs, or decryption shares. On the other hand Sedna directly attacks byte duplication. In the Sedna paper we compare naive replication, fixed-rate MDS coding, and rateless coding. For naive replication, total published bytes scale as m full copies. For MDS, each lane gets a share. For rateless Sedna, each lane gets a bundle of symbols. As payload size grows and metadata becomes negligible, rateless coding approaches an overhead floor of (1 + ε) / (1 - ce/n), where ce/n is the effective censor fraction and ε is the rateless coding overhead.

Sedna also has a slightly less obvious security story, though I will claim that the BTE security story is less obvious than many claim. You should keep an eye out for more on that soon. With Sedna there is no threshold key to steal or release. Instead, the adversary must gather enough symbols to decode early. If adversarial lanes receive too few symbols, early decode is impossible. If they receive enough, they can reconstruct before the honest chain does. The sender controls parameters, number of lanes, symbols per bundle, symbol size, and failure target, so the adversary cannot tweak things at will. This is weaker than ideal encryption in one sense, Sedna leaks partial linear information through observed symbols and exposes public header metadata. It is stronger in another sense, there is no special decryption committee that becomes the obvious cartel target. The more subtle issue is strategic withholding. A cartel of proposer lanes might include some bundles privately, withhold them publicly, and try to gain an information lead. Our follow up Sedna mechanism design paper [20] studies this exact issue, identifies a delay event controlled by the slack parameter Δ = t* m - κ, and proposes PIVOT-K, a pivotal-bundle bounty that rewards the bundles that actually trigger decoding. And we estimate that, for realistic parameters, Sedna can reduce MEV protection costs to 0.04% of transaction value.

[1] A. Ranchal-Pedrosa, B. Marsh, L. Kokoris-Kogias, A. Sonnino. "Sedna: Sharding Transactions in Multiple Concurrent Proposer Blockchains." arXiv:2512.17045 [cs.CR], 2025.

[2] Flashbots. "Flashbots Protect". docs.flashbots.net/flashbots-protect/overview, 2021.

[3] L. Breidenbach, P. Daian, A. Juels, F. Tramèr. "To Sink Frontrunners, Send in the Submarines." hackingdistributed.com, 2017.

[4] L. Breidenbach, P. Daian, F. Tramèr, A. Juels. "Enter the Hydra: Towards Principled Bug Bounties and Exploit-Resistant Smart Contracts." 27th USENIX Security Symposium, 2018, pp. 1335–1352. Cryptology ePrint Archive 2017/1090.

[5] J. Bebel, D. Ojha. "Ferveo: Threshold Decryption for Mempool Privacy in BFT Networks." Cryptology ePrint Archive 2022/898, 2022.

[6] Shutter Network. shutter.network.

[7] A. R. Choudhuri, S. Garg, J. Piet, G.-V. Policharla. "Mempool Privacy via Batched Threshold Encryption: Attacks and Defenses." 33rd USENIX Security Symposium, 2024, pp. 3513–3529. Cryptology ePrint Archive 2024/669.

[8] C. Hager, F. Paape. "Block Building inside SGX." Flashbots, 2023. writings.flashbots.net/block-building-inside-sgx.

[9] R. L. Rivest, A. Shamir, D. A. Wagner. "Time-lock Puzzles and Timed-release Crypto." Technical Report MIT/LCS/TR-684, MIT Laboratory for Computer Science, February 1996.

[10] C. Gentry. "Fully Homomorphic Encryption Using Ideal Lattices." 41st ACM Symposium on Theory of Computing (STOC), 2009, pp. 169–178. DOI 10.1145/1536414.1536440.

[11] Flashbots. "Backrunning Private Transactions Using Multi-Party Computation." 2023. writings.flashbots.net/backrunning-private-txs-MPC.

[12] P. Daian, S. Goldfeder, T. Kell, Y. Li, X. Zhao, I. Bentov, L. Breidenbach, A. Juels. "Flash Boys 2.0: Frontrunning in Decentralized Exchanges, Miner Extractable Value, and Consensus Instability." IEEE Symposium on Security and Privacy (S&P), 2020, pp. 910–927. DOI 10.1109/SP40000.2020.00040.

[13] J. Bormet, S. Faust, H. Othman, Z. Qu. "BEAT-MEV: Epochless Approach to Batched Threshold Encryption for MEV Prevention." Cryptology ePrint Archive 2024/1533, 2024; USENIX Security 2025.

[14] J. Van Bulck, M. Minkin, O. Weisse, D. Genkin, B. Kasikci, F. Piessens, M. Silberstein, T. F. Wenisch, Y. Yarom, R. Strackx. "Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution." 27th USENIX Security Symposium, 2018, pp. 991–1008.

[15] K. Murdock, D. Oswald, F. D. Garcia, J. Van Bulck, D. Gruss, F. Piessens. "Plundervolt: Software-based Fault Injection Attacks against Intel SGX." IEEE Symposium on Security and Privacy (S&P), 2020, pp. 1466–1482. DOI 10.1109/SP40000.2020.00057.

[16] F. Yang, X. Yuan. "Toward Timed-Release Encryption in Web3 An Efficient Dual-Purpose Proof-of-Work Consensus." arXiv:2205.09020, 2022.

[17] M. Dahl, C. Danjou, D. Demmler, T. Frederiksen, P. Ivanov, M. Joye, D. Rotaru, N. Smart, L. Tremblay Thibault. "Confidential EVM Smart Contracts using Fully Homomorphic Encryption (fhEVM)." Technical Report, Zama, 2023.

[18] J. Luhn. "EIP-8105: Universal Enshrined Encrypted Mempool [DRAFT]." Ethereum Improvement Proposals, no. 8105, December 2025.

[19] A. Elowsson, J. Florentine, J. Ma. "EIP-8184: LUCID Encrypted Mempool [DRAFT]." Ethereum Improvement Proposals, no. 8184, March 2026.

[20] B. Marsh, A. Ranchal-Pedrosa. "A Mechanism Design Overview of Sedna." arXiv:2603.17614 [cs.GT], 2026.