A mechanism design overview of Sedna

TL;DR: Sedna's mempool privacy holds up as an economic guarantee. It hides each transaction by shattering it into coded fragments across parallel proposals, so no single party can read the transaction before its order is irreversible. Paired with a mechanism that rewards proposers that include their coded fragments timely, we show that Sedna is effective in protecting from MEV. For realistic parameters against a strong adversary interested in breaking privacy to extract MEV, Sedna delivers mempool privacy and MEV protection at 0.04% of the transaction value.

Why mempool MEV protection is an incentive problem

Most of the industry treats a private mempool as an encryption problem: encrypt the transaction, then decrypt it after ordering. Sedna takes a different route. It shatters each transaction into rateless coded fragments and spreads them across multiple concurrent proposers. The payload stays unreadable until enough fragments are revealed, so no single proposer can decode until it sees enough fragments on-chain, at a time that is too late to front-run the transaction. This is "until-decode" privacy, and it buys high useful throughput at the same time, because the proposers work in parallel for different fragments, reducing duplicates.

But until-decode privacy creates a new risk vector. A number of colluding proposers can decide to privately share their fragments instead of proposing them, in order to reveal transactions before their inclusion. If they gain something by sitting on the fragments addressed to them, the privacy guarantee is only as strong as their willingness to cooperate.

That is the question this paper answers. Not "can we hide the transaction," but "do the parties holding the pieces actually want to reveal them?" It is the gap Rondelet and Kilbourn named for threshold-encrypted mempools: privacy has to be analyzed as incentives, not only as cryptography. Sedna's privacy is combinatorial rather than encrypted, so the incentive question lands even harder.

Below, we speak of a lane as one of the parallel proposer slots in a Sedna slot, and a bundle as a number of fragments the sender hands a contacted lane. A transaction decodes and executes the moment enough bundles are finalized to cross the decode threshold.

What is the withholding attack?

The withholding attack is a cartel of lanes stalling the fragments addressed to them so they can decode the transaction privately, significantly faster than decoding derived from finalized fragments. Here is the mechanism.

In each slot the sender contacts m proposers and gives each one a bundle. Once enough bundles are finalized on chain (call it kappa bundles), the payload decodes. Under honest behavior that threshold is crossed at a fixed slot, the honest horizon.

A cartel that controls some of the lanes can delay past the honest horizon. The cartel receives its bundles, but it withholds them from finalization while keeping the symbols privately. Now the cartel's information set is every public fragment plus the ones it is hiding. If its withholding slows decoding past the honest horizon, the cartel crosses its own private decode threshold first. That head start is the MEV opportunity. The cartel reads the pending transaction, front-runs it, and only then releases.

The attack has a sharp edge the paper calls the knife edge. There is usually slack between the fragments finalized by the honest horizon and the number strictly needed to decode. That slack is a buffer. When the decode threshold is an exact multiple of the contact rate, the slack is zero, and a single withheld bundle is enough to push decoding into the next slot. On a zero-slack instance with a cartel holding 20% of lanes and a one-slot horizon, decoding is delayed with probability about 0.993. Almost certain.

We also prove the pessimistic case is the clean one to design against. Across every dynamic strategy a cartel could run, full withholding maximizes the delay probability. So the worst case is a single, analyzable baseline rather than an open-ended search over clever schedules.

How PIVOT-K makes including more profitable than withholding

PIVOT-K is a sender-funded bounty paid only to the bundles that actually trigger decoding. The sender escrows a reward alongside the transaction. On decode, the protocol identifies the first kappa bundles that supplied the symbols used to reconstruct the payload. That set is the decoding prefix, and the bounty splits evenly among exactly those lanes. Bundles outside that prefix are not paid any additional bounty.

The design targets the precise weakness of a plain fee. A flat per-bundle fee does not distinguish a fragment that mattered for decoding from a redundant one. Withholding a redundant fragment costs the cartel almost nothing. PIVOT-K changes that math. Withhold a fragment that would have been decisive and you forfeit both the fee and a bounty share, with no offsetting gain unless the withholding actually causes a delay.

We prove PIVOT-K to be an effective way to spend a fixed bounty budget. Among every rank-based rule that pays out the prefix, uniform per-bundle payments are minimax-optimal. They maximize the worst-case reward a withholder gives up when it deletes fragments from the prefix. Concentrating payments on early ranks looks tempting but is strictly weaker, because an attacker just targets the cheaper ranks. Flat payments leave no cheap rank to target.

There is a second effect. When there is any slack at all, one lane acting alone cannot cause a delay, so a single withholder sacrifices fee and bounty for nothing. Delay then requires a coordinated coalition, and we show the total revenue that coalition gives up exceeds the entire MEV it could extract from the transaction. The attack stops being an individual option and becomes a coordination problem that does not pay.

How the adaptive sender ratchet shrinks the cost

Transactions split across bundles are not always expected to be revealed in one slot, whether by construction of the sender creating and disseminating bundles or as a result of a coordinated attack delaying past the honest horizon. The ratchet is a strategy a sender can use in these cases, whereby the sender watches which lanes include their bundles and permanently drops any lane that stalls. Because honest lanes always include (they earn the fee and have no reason to hide), a lane that fails to include is a clean signal of cartel behavior. The sender excludes it from every future contact for that transaction.

This makes withholding self-revealing. Every fragment a cartel holds back burns one of its lanes' cover. A cartel that wanted to spread its withholding across several slots to stay hidden cannot, because each withheld slot flags a lane and shrinks the cartel's effective share of the pool. We show the ratchet collapses a multi-slot withholding strategy into a first-slot problem.

The practical payoff is cost. The ratchet does most of the deterrence work through exclusion, so the sender needs far less bounty to close the remaining gap. The required bounty drops by orders of magnitude compared to the static sender. Real networks are noisy, so honest lanes occasionally miss for benign reasons like jitter or downtime. We model this with a per-contact miss rate and show the guarantee degrades gracefully rather than breaking.

One honest limit stays on the table. Within a single slot, a cartel that receives enough fragments could in principle decode in the window between its last fragment arriving and the slot sealing. Unfortunately, no finalization-based payment rule can remove that within-slot race. We bound it and give parameter guidance to keep it small, and we name this as the irreducible residual rather than papering over it.

What does this cost in practice?

Here are the parameters behind the number. The evaluation runs 100 lanes with 20 contacted per slot, and a cartel controlling 20 of those 100 lanes. The operating point is a decode threshold of 30 bundles, which takes two slots to reach and leaves a slack of 10. Proposers earn $0.10 per included bundle, and the sender discounts each slot of delay at 0.99.

The adversary gets handed every advantage the model can give it. It knows the sender's dissemination parameters exactly, including the slack, which is conservative: in practice kappa stays hidden until decode, so a cartel has to commit to withholding before it learns how much buffer it is fighting. It also wins the within-slot race with certainty, meaning any cartel that receives enough fragments before the slot seals is assumed to decode and act in time. Even with both concessions, the race is feasible in only 6.5 of every 10,000 transactions at this operating point, and the multi-slot delay probability falls from 0.136 under a static sender to 0.00008 under the ratchet.

Against that adversary, the bounty a sender has to post looks like this.

Protecting a $5,000 liquidation costs $2. A static sender pays $3,400 for the same protection, roughly 68% of the value at risk, which is why the adaptive sender is the operationally decisive lever rather than a refinement. The ratio holds across all three tiers, so a sender can price protection as a fixed fraction of what is at risk instead of re-deriving it per transaction. That is the number that matters, because it turns a qualitative privacy promise into a priced, incentive-compatible guarantee.

One configuration to avoid is the knife edge. When the decode threshold is an exact multiple of the contact rate, a single lane can cause the delay on its own, the coalition argument no longer applies, and the required bounty jumps to $250 for a threshold of 20 bundles and $1,000 for a threshold of 100. Choose a threshold that leaves slack and the problem disappears.

The full derivation lives in the paper: the large-deviation bounds on the delay probability, the coalition budget constraints, the minimax proof for PIVOT-K, and the within-slot race analysis. The result for a builder is simpler. Sedna's privacy is an economic equilibrium, where the parties holding your transaction are paid more to reveal it than they could ever earn by hiding it.

Sources

• A mechanism design overview of Sedna, arXiv:2603.17614: https://arxiv.org/abs/2603.17614

• Full paper (PDF): https://arxiv.org/pdf/2603.17614v1.pdf