Sei Research Initiative

Encrypting the mempool can make perpetual funding easier to attack

Jul 15, 2026

TL;DR: Encrypted mempools and private transaction layers like Sei Giga's Sedna stop most front-running, but they can also raise the risk of funding rate manipulation. When an attacker authors the transaction that moves a funding input, encryption blinds the arbitrageurs who would normally minimize the distortion. Our new research measures what that is worth to the attacker and gives perp venues a fix.

The attack that encryption does not stop

Encrypted mempools exist to stop the attacks a public mempool makes possible, from front-running to sandwich attacks. A threshold-encrypted mempool keeps transaction contents secret until inclusion and ordering are fixed, so by the time anyone can read a trade, it is too late to act on it.

Some attacks survive this, and a few get worse. The problem case is an attacker who authors the transaction that changes application state and also holds a claim that pays out when that state changes. Perpetual futures funding is the clearest example.

Funding is the periodic payment that keeps a perp's price near spot. The gap between the perp and the index sets the rate, and open interest on the receiving side sets the base the rate is paid on. An attacker who holds a position on the receiving side, then nudges a funding input like the mark or index price, collects the transfer that follows.

A new Sei Labs paper by Benjamin Marsh, "Reveal, Correct, Then Pay: Encrypted Mempools and Perpetual Funding Security," works through this case in detail.

Why faster decryption does not fix it

The paper starts from a simple property of commit-then-reveal designs, which it calls the ordering barrier. Once a batch has closed and its order is fixed, no transaction written in response to the batch's contents can get into it. An arbitrageur who reads the attacker's trade after the batch commits can only respond in the next batch or the next application round.

The paper calls that delay the reaction gap: the time between the attack changing state and the first moment a corrective trade can execute. It exists even when decryption is instant. Faster threshold decryption cuts wall-clock latency, but it cannot reopen a committed batch. The encryption is not failing here. The application on top is paying out too early.

This changes what we should be benchmarking. Proposal-to-execution latency is the number systems papers report. For funding security the number that matters is different: the earliest point at which a transaction that depends on the revealed state can execute.

What funding rate manipulation is worth to an attacker

The paper models a price distortion that the market corrects at two different speeds. While the batch is closed, correction is slow: no trade that responds to the attacker's order can execute yet, so only blind arbitrage or an outside price move can push back. As soon as such a trade can execute in the simplest design, correction speeds up in the next batch because traders can now respond to the transaction itself.

The longer the market is stuck in the slow phase, the more of the distortion survives into the funding average, and the funding average is what sets the payment.

The paper's worked example: in a market where public correction would otherwise be fast, a reaction gap of one tenth of the funding window multiplies the measured distortion by about 1.8. Attack value scales with the square of the response factor, so that is roughly 3.2 times the value for an attacker whose information is unchanged. The effect is also strongest in exactly the markets where transparent arbitrage would have been fastest: a fixed one-block gap costs a fast market proportionally more than a slow one. These are model illustrations rather than venue estimates, and the paper is explicit about that. What they show is that one blocked reaction opportunity can outweigh a modest loss of attacker information.

Whether encryption helps or hurts comes down to that trade. Encryption takes information away from the attacker, but it also takes information away from the correctors. A sandwich attacker loses everything, since it can no longer see its victim, so privacy protects. A self-authored attacker still knows its own order and can still see the reference price, so it loses almost nothing, and the slower correction is pure gain.

The second channel: cheap hidden entry

Funding has two ledgers. The signal ledger sets the rate. The tax base ledger is the open interest that collects the payment.

The second channel is about who holds the receiving position when the payment lands. If eligibility comes down to a single timestamp, an attacker can open its position inside a concealed batch, after the transfer has become predictable. On a transparent venue that entry is expensive. Encryption hides the entry, so the attacker gets in cheap and keeps the payment.

The paper splits the overall effect of encryption into three multipliers: attacker blindness, plus correction shielding and capitalization shielding. The first works in the venue's favor, and the other two work against it. In one illustration, a transparent venue competes away 80% of the predictable funding while encrypted same-batch entry competes away none. With a reaction gap factor of 1.8, encryption pushes the venue toward the regime where the attack scales without bound once the attacker keeps just 11% of the effectiveness it had in public. This is a model illustration rather than a venue estimate, but it makes the point that hiding the recipient's entry behaves very differently from hiding a victim's order.

The fix: reveal, correct, measure, then pay

None of this argues against encrypted mempools. The problem is pairing one with an application that treats the first revealed state as a payment oracle. The fix is to put a real stage between reveal and payment.

The proposed sequence has four steps.

  1. Reveal. Close the encrypted batch, then reveal its contents and execute the state transition.

  2. Correct. Open a public reaction window, or run a protocol-native rebalancing step, that can act on the revealed state.

  3. Measure. Start the funding signal window only after the correction stage, so the transient around reveal never enters the average.

  4. Pay on an aligned tax base. Positions opened inside the concealed batch do not collect the upcoming payment. Alternatively, eligibility accrues over the same post-reveal window used to measure the signal, rather than at one final timestamp.

Both controls are needed because they cover different ledgers. The correction buffer shrinks the distortion in the signal. The eligibility rule removes the hidden-entry advantage on the tax base. Run only one and the other ledger stays open. The paper also derives how long the buffer has to be to cap the extra extraction below any chosen tolerance, so the wait is something a venue can size rather than guess.

A few design implications follow. Fast decryption is necessary but not sufficient, since the one-round ordering barrier remains even at zero decryption cost. Protocol-native correction is especially valuable under privacy, because a precommitted arbitrage module or solver auction is not blocked by the ordering barrier the way an off-chain searcher writing a fresh transaction is. And venues still need concentration limits, because every attack value in the model scales with the square of the attacker's receiving position. A funding rate cap limits the rate. The dollar transfer still scales with how much open interest one account can hold on the receiving side.

Why we did this work

Sei Giga is built for pre-execution privacy, and perps are among the most important applications a trading chain hosts. Making the two work together is a market-structure problem as much as a cryptographic one. That is the job this paper takes on: find the specific conditions where a primitive the industry is adopting interacts badly with a real financial application, then design around them without giving up the privacy.

Transaction privacy and market integrity can coexist. The condition is that the application is designed for the information schedule encryption creates, instead of paying against the first state it sees.

Sources