MEV-resistant by design

What MEV looks like on a continuous-CLOB perp DEX

On a conventional continuous-time orderbook — the model used by every major Solana perp DEX prior to Sour — orders arrive one transaction at a time and fill at whatever price is available at the moment of inclusion. That serial-arrival model is the precondition for sandwich extraction.

The pattern is well-documented. A searcher bot watches the mempool, the public RPC firehose, or a private orderflow feed for a sufficiently large incoming buy. It submits its own buy at a higher priority fee so that the validator orders it ahead of the user. The bot fills against the book, the user then fills at the new, worse price, and the bot immediately submits a sell that closes the position against the user’s slippage. The user pays the spread; the bot keeps it.

On Solana the execution channel is priority fees and Jito bundles rather than gas auctions, but the economic logic is identical. As long as inclusion order inside a block is auctionable and the matching engine fills sequentially, the surface exists. Encrypted mempools, threshold encryption, and commit-reveal schemes can blunt the edge, but they cannot remove it without changing the matching model itself.

Why batch clearing removes that surface

Sour replaces the continuous matcher with a 1.8-second batch auction. Three properties of that auction collapse the sandwich surface:

• UNIFORM CLEARING PRICE
  Every order accepted into a slot fills at the same clearing price, regardless of arrival time within that slot. Submitting a buy 200ms before the user does not improve the bot’s fill price. Submitting one 200ms after does not improve it either. The notion of being "ahead" or "behind" inside the auction window does not exist.
• ATOMIC SETTLEMENT
  All matches in the batch are computed and applied in a single Solana transaction, inside a single block. There is no inter-transaction window in which a bot could interleave its trades between the user’s submission and the user’s fill. The batch is opaque until cleared, then settled wholesale.
• PRICE-TIME ONLY AS A TIE-BREAKER
  Price-time priority is used inside the batch only to allocate partial fills at the marginal clearing band — i.e., when supply at the clearing price exceeds demand and a subset of orders at the boundary must be chosen. It is not a fee-paying queue. Paying a higher priority fee does not improve fill quality inside the auction.

Mitigation vs. by-construction

Most projects branded "MEV-resistant" mitigate ordering MEV — they reduce the information available to searchers or shuffle the order in which transactions land. Each adds latency, trust, or both:

• COMMIT-REVEAL
  Users submit a hash, then reveal in a second transaction. Doubles the round-trip and leaks the order at reveal time. The reveal window is the new sandwich window.
• ENCRYPTED MEMPOOLS / THRESHOLD ENCRYPTION
  Hide order content from validators until inclusion. Adds a key-management trust layer and additional latency. Reduces but does not eliminate ordering edges, especially against off-chain price moves.
• FAIR-ORDERING ORACLES
  Sort transactions by an external timestamp consensus. Adds an external dependency and is opaque about how sorting interacts with MEV-aware validators.
• BATCH AUCTION (SOUR)
  Removes ordering as a price-determining input. Nothing to encrypt, nothing to commit-and-reveal, no external sorter. The matching engine itself does not know what "first" means inside the slot.

What about the validator?

Honest framing: a Solana validator that produces a block containing a Sour batch could in principle censor specific orders by dropping them before they reach the program. That is a network-level threat — the same threat that exists for any program executing on Solana — and is not specific to perp DEXes.

The relevant property is that censorship cannot create an ordering edge. Even if a validator drops a subset of orders, the remaining orders still clear at one uniform price computed by the program from the orders that survived. The validator cannot rearrange orders to extract spread. The most it can do is reduce the participation set, which is observable and bounded by the leader rotation.

Reference

CLEARING MODEL

Frequent batch auction, uniform clearing price

BATCH SLOT

1.8 seconds

SETTLEMENT

Atomic, single Solana transaction per slot

TIE-BREAKER

Price-time priority at the marginal band only

PROGRAM ID

souryQgnM1xiNuGcmVYLPGT3MKqnGN8QTqP8zk8eape

SOURCE

github.com/GageBachik/sour

VERIFICATION

github.com/GageBachik/sour-verification