Sedna: Mempool Privacy Without Encryption

Crypto has spent years trying to fix the mempool. We have dark pools running on the side of the core infra. We have a bunch of literature, especially as of late, on how to build encrypted mempools. The reason for it is pretty clear, even if a large portion of the community doesn’t necessarily want to face it. MEV [7] is contentious at best, and at its worst it's a major threat for unprepared users transacting onchain. The public mempool is where a user’s transaction sits before it is finalised. It is also where everyone else gets a preview. For ordinary transfers this may not matter much. For trading, liquidations, auctions, NFT mints, governance, and cross-chain actions, it matters a lot. A visible pending transaction is an invitation to copy it, frontrun it, sandwich it, censor it, or delay it. This is the basic MEV problem that we all know at this point. Block producers, builders, searchers, and other actors can extract value by controlling whether transactions are included, excluded, or reordered. Ethereum’s own documentation [9] defines MEV in exactly those terms, value extracted from block production beyond normal rewards by changing inclusion and ordering. The standard response from the blockchain world is the same, encrypt the mempool and commit to the allocation before decryption [2,8]. And it’s a response that makes a lot of sense. It solves the key problem even if encrypted mempools tend to be unwieldy. The recent stream of batched threshold literature has started to make encrypted mempools look tractable in the real world but for a Giga style setting there’s still work to be done [1, 3, 4, 5, 6, 10]. And the research team at Sei Labs is doing that work. We have 2 papers under review right now. We have another 2 that are WIP and will be submitted later this year. But right now, we don’t see an encrypted mempool proposal we’d want, or even be able to, use in production. So what are we to do?

We should first start with a quick recap of Giga [12] as I feel with the setting clear in your head we should be able to move towards our current thinking quite easily together. Giga uses Autobahn [11], and in any given tick of the system each validator is able to propose one or more blocks which will be executed asynchronously off the consensus hotpath. One of the key benefits, and equally key downsides, of such a protocol is the ability to submit multiple transactions for censorship resistance, though that does mean multiple copies may end up existing even though only a single copy is ever executed. Is there a nice way to get similar censorship resistance without the need for duplicates? What if everyone only got a small portion of the transaction, so malicious censorship resistance is more difficult as the validator doesn’t know what they’re including? Think of it as a bit like sharing the pages of a book out amongst your friends. You might have chapter one but without all of the others with their chapters you don’t have the full book. But then we have another issue. What happens if someone isn’t around to give us their pages? We need redundancy. And that redundancy comes from ensuring that no single individual holds all the copies of a single page. In Sedna [14] we achieve this through erasure coding and Sedna allows us to achieve low cost, low latency, censorship resistance in Giga. But why are we talking about censorship resistance?

If everyone can only see a few bytes of a transaction we have something that, in our setting, acts as a pseudo-encrypted mempool. I should be clear though, it’s not an encrypted mempool, Sedna does not encrypt a transaction under a threshold key and then wait for a committee to decrypt it. It does not claim that no one can ever learn anything before finalisation. It is not a replacement for every encrypted mempool design or setting. But for our setting it’s sufficient for now, and necessary on the low latency and cost censorship resistance side.

So what actually happens? A sender takes a transaction payload, commits to it, splits it into many coded symbols, and sends small addressed bundles of those symbols to different proposer lanes. A single proposer does not receive the whole transaction. A small coalition should not receive enough to reconstruct it. The chain only reconstructs the transaction once enough verified symbols have appeared in finalized history. In other words, before decoding, proposers see fragments. After enough fragments are finalised, everyone can decode the transaction and execute it deterministically as per usual. In our paper "Sedna: sharding transactions in multiple concurrent proposer blockchains" we describe this as replacing whole transaction replication with verifiable, rateless coding. Users privately deliver addressed symbol bundles to subsets of proposers, execution happens once enough symbols are finalized to decode. We call this privacy property “until-decode privacy.” 

In a little more detail you can think of it in the following way. A Sedna transaction has two parts, a public header and a private payload. The header contains the information needed for admission, fees, and accounting [13]. The payload is the thing the user does not want to reveal early. The sender commits to the payload, derives a transaction identifier, and produces a stream of coded symbols. Those symbols are grouped into bundles. Each bundle is addressed to a particular proposer lane and signed, so validators can check that the bundle really belongs to the claimed transaction and lane. Validators do not need to know the payload to admit the bundle. They check the header, signature, accounting predicate, and bundle validity. If the bundle is valid and pays for its bytes, it can be included. As blocks finalise, the chain accumulates verified symbols. Once there are enough distinct symbols, validators decode the payload, check that it matches the commitment, and execute the transaction in a deterministic order. The important part is that execution order is not left to whoever decodes first. Sedna assumes a deterministic ordering rule based on the inclusion height and transaction identifier. The paper proves that, for a fixed finalized ledger, the decoded payload and execution position are uniquely determined except for negligible decoding failure.

Consider a large swap. In a public mempool, the whole swap is visible before execution. In a private relay model, the swap is hidden from the public mempool but revealed to the relay, builder, or private orderflow path. In a threshold encrypted model, the swap is encrypted until a decryption process happens after ordering. In Sedna, the transaction is not wholly sent  to anyone. It is scattered as coded pieces. Each piece is useful for eventual reconstruction, but not enough on its own to reveal the payload. This has three immediate benefits. First, it reduces pre-inclusion leakage. With naive replication, any adversarial proposer who receives the transaction sees the whole payload. With Sedna, an adversary needs enough symbols to decode. Our work developing the Sedna protocol argues that coded approaches keep early decode probability near zero across tested configurations when parameters are chosen appropriately, while naive replication trivially reveals the payload to any adversarial lane that receives it. Second, it reduces bandwidth waste. In naive replication, if a user wants to tolerate censorship by many proposers, they may need to send full copies to many lanes. Sedna sends useful fragments instead. In our benchmarking we found a 2-3x efficiency improvement over naive replication and the rateless version approaches the information-theoretic lower bound up to a small coding overhead. Third, it gives users control. A market maker, a liquidator, and an ordinary transfer do not need the same privacy, latency, and censorship resistance profile. Sedna lets the sender choose how many lanes to contact and how many symbols to put in each bundle. That means different users can make different tradeoffs without forcing the whole chain into one global mempool policy. And it does all of that with far less computational overhead than an encrypted mempool.

Sedna is a key part of the Giga upgrade. First, Sei's execution and storage layers will individually be upgraded. Following that, Sei Mainnet will be upgraded to multi-proposer Autobahn consensus, dramatically increasing throughput and time to finality. Sedna will go live on Autobahn mainnet. Sei's upgrade velocity will be sustained beyond the Giga upgrade, and we will continue to explore ways of improving the mempool and potential successors to Sedna.

References

[1] Agarwal, A., Das, S., Poorebrahim Gilkalaye, B., Rindal, P. and Shoup, V. (2026) 'BTX: simple and efficient batch threshold encryption', Cryptology ePrint Archive [Preprint], Paper 2026/754. Available at: https://eprint.iacr.org/2026/754 (Accessed: 9 June 2026).

[2] Bebel, J. and Ojha, D. (2022) 'Ferveo: threshold decryption for mempool privacy in BFT networks', Cryptology ePrint Archive [Preprint], Paper 2022/898. Available at: https://eprint.iacr.org/2022/898 (Accessed: 9 June 2026).

[3] Boneh, D., Laufer, E. and Tas, E.N. (2025) 'Batch decryption without epochs and its application to encrypted mempools', Cryptology ePrint Archive [Preprint], Paper 2025/1254. Available at: https://eprint.iacr.org/2025/1254 (Accessed: 9 June 2026).

[4] Bormet, J., Faust, S., Othman, H. and Qu, Z. (2025) 'BEAT-MEV: epochless approach to batched threshold encryption for MEV prevention', in 34th USENIX Security Symposium (USENIX Security 25). Seattle, WA: USENIX Association, pp. 3457–3476. Available at: https://www.usenix.org/conference/usenixsecurity25/presentation/bormet (Accessed: 9 June 2026).

[5] Choudhuri, A.R., Garg, S., Piet, J. and Policharla, G.-V. (2024) 'Mempool privacy via batched threshold encryption: attacks and defenses', in 33rd USENIX Security Symposium (USENIX Security 24). Philadelphia, PA: USENIX Association, pp. 3513–3529. Available at: https://www.usenix.org/conference/usenixsecurity24/presentation/choudhuri (Accessed: 9 June 2026).

[6] Choudhuri, A.R., Garg, S., Policharla, G.V. and Wang, M. (2025) 'Practical mempool privacy via one-time setup batched threshold encryption', in 34th USENIX Security Symposium (USENIX Security 25). Seattle, WA: USENIX Association, pp. 3477–3495. Available at: https://www.usenix.org/conference/usenixsecurity25/presentation/choudhuri (Accessed: 9 June 2026).

[7] Daian, P., Goldfeder, S., Kell, T., Li, Y., Zhao, X., Bentov, I., Breidenbach, L. and Juels, A. (2019) 'Flash Boys 2.0: frontrunning, transaction reordering, and consensus instability in decentralized exchanges', arXiv [Preprint]. Available at: https://arxiv.org/abs/1904.05234 (Accessed: 9 June 2026).

[8] Dziembowski, S., Faust, S. and Luhn, J. (2024) 'Shutter Network: private transactions from threshold cryptography', Cryptology ePrint Archive [Preprint], Paper 2024/1981. Available at: https://eprint.iacr.org/2024/1981 (Accessed: 9 June 2026).

[9] ethereum.org (2026) Maximal extractable value (MEV). Available at: https://ethereum.org/developers/docs/mev/ (Accessed: 9 June 2026).

[10] Fernando, R., Policharla, G.-V., Tonkikh, A. and Xiang, Z. (2025) 'TrX: encrypted mempools in high performance BFT protocols', Cryptology ePrint Archive [Preprint], Paper 2025/2032. Available at: https://eprint.iacr.org/2025/2032 (Accessed: 9 June 2026).

[11] Giridharan, N., Suri-Payer, F., Abraham, I., Alvisi, L. and Crooks, N. (2024) 'Autobahn: seamless high speed BFT', arXiv [Preprint]. Available at: https://arxiv.org/abs/2401.10369 (Accessed: 9 June 2026).

[12] Marsh, B., Landers, S. and Jog, J. (2025) 'Sei Giga', arXiv [Preprint]. Available at: https://arxiv.org/abs/2505.14914 (Accessed: 9 June 2026).

[13] Marsh, B. and Ranchal-Pedrosa, A. (2026) 'A mechanism design overview of Sedna', arXiv [Preprint]. Available at: https://arxiv.org/abs/2603.17614 (Accessed: 9 June 2026).

[14] Ranchal-Pedrosa, A., Marsh, B., Kokoris-Kogias, L. and Sonnino, A. (2025) 'Sedna: sharding transactions in multiple concurrent proposer blockchains', arXiv [Preprint]. Available at: https://arxiv.org/abs/2512.17045 (Accessed: 9 June 2026).