Batch-cleared perpetuals

The history

Frequent batch auctions are not new. The mechanism traces back to the Walrasian tâtonnement in classical microeconomics, and modern interest in applying them to electronic markets crystallized around the 2015 paper by Eric Budish, Peter Cramton, and John Shim, "The High-Frequency Trading Arms Race: Frequent Batch Auctions as a Market Design Response." Their thesis was unsentimental: continuous matching creates a built-in arms race for speed advantages that has no welfare benefit, and discrete auctions priced uniformly within each window neutralize the race without sacrificing price discovery. The TradFi establishment did not adopt this — exchange revenue depends on the arms race — but the academic case has held up.

In DeFi, batch auctions arrived first in spot. CoW Protocol pioneered solver-based batch auctions for token swaps in 2021, where every swap in a batch settles against a single set of clearing prices computed by competing solvers. The result is a venue where MEV extraction by sandwich is structurally impossible because the prices are uniform across the batch. The model proved out at meaningful spot volumes.

Batch-cleared perpetuals are the natural extension of that idea to leveraged derivatives. Instead of a CLOB matching engine running on a sequencer, the venue runs a discrete auction every N milliseconds, settles every order at the clearing price, and accrues funding inside the same auction handler. Sour is the first production implementation of this design for Solana perpetuals, with a 1.8-second batch slot, uniform clearing, atomic per-block settlement, and a flat 3 bps fee credited entirely to the LP vault that backstops the markets.

Continuous orderbook vs batch-cleared perpetual

Sour falls in the right column. Drift, Hyperliquid, and Phoenix fall in the left.

How it differs from AMM perps

Pool-based perpetual venues — GMX-V1 / V2, Jupiter Perps, Gains Network — quote prices algorithmically rather than from an orderbook. A trader entering a position pays the oracle price plus or minus a borrow fee, with the LP pool taking the other side directly. There is no auction, no clearing price, and no orderbook depth — there is a single quoted mid plus fees, and the LPs absorb whatever directional flow shows up.

Batch-cleared perpetuals are not pool-quoted. The clearing price emerges from the actual book of bids and asks submitted into the slot. A market-determined uniform clearing price differs from an oracle-quoted price in two important ways. First, it expresses real trader demand at the moment of clearing rather than a synthetic mid pulled from spot. Second, it does not collapse to a single counterparty: traders match against each other directly, and the LP vault only steps in to backstop margin shortfalls or hold the residual skew. The vault is a collateral pool of last resort, not the quoting engine.

In practice, a batch-cleared perp venue feels closer to a CLOB than to an AMM at the trader interface — you place limit and market orders, you can rest on the book — while behaving like neither under the hood. It is a third design point.

Why 1.8 seconds

The batch slot length is the critical design parameter. Too long and traders feel the latency, mark drift accumulates between slots, and the venue is unusable for anything other than passive resting orders. Too short and the auction degenerates into something indistinguishable from continuous matching, with all the MEV surface that implies.

Solana blocks land roughly every 400 milliseconds. A 1.8-second batch covers approximately four to five blocks of order accumulation before the matching engine runs. This is long enough that a bot cannot reliably observe the inside of the slot, react to a competing order, and have a cancel land in the same slot. It is short enough that the trader UX is indistinguishable from instant fills — the user clicks buy, sees the order accepted, and within roughly two seconds sees the fill at a price they can verify against the on-chain clearing computation.

Importantly, the latency that matters in continuous orderbook trading — being first in the queue at a given price level — does not exist in a batch-cleared design. Submitting your order ten microseconds before someone else’s does not improve your fill if both orders land in the same slot. That single property eliminates the entire colocation, kernel-bypass, FPGA arms race that has eaten the welfare gains of electronic trading in TradFi over the last twenty years.

Common misconceptions

A handful of objections come up every time someone first encounters the idea of batch-cleared perpetuals. None of them survive contact with the actual mechanism.

• BATCH AUCTIONS = NO LIQUIDITY
  Wrong. Orders accumulate inside the slot and are matched together at the clearing time. Visible depth is the union of every open limit order at clearing, which is at least as deep as a comparable CLOB and frequently deeper because there is no queue-jumping incentive to keep orders shallow.
• 1.8 SECONDS IS TOO SLOW FOR REAL TRADING
  Wrong, in two senses. First, fills are uniform-price, so the user-facing latency that matters is "how long until I know my fill price," which is roughly the slot length plus block confirmation. Second, the latency that traders sweat in CLOBs — queue position — does not exist here. There is no queue inside a slot.
• BATCH AUCTIONS CAN’T HAVE LEVERAGE
  Wrong. Sour supports up to 50× isolated leverage on every market. Margin checks, funding accrual, and structural liquidation all run inside the same batch handler that clears trades.
• YOU NEED A FUNDING KEEPER
  Wrong. Funding is computed deterministically inside every batch against the oracle-anchored mark, with no off-chain cron and no privileged caller. The same is true of liquidations: a position that fails its margin check at the clearing price is closed in the same batch.
• BATCH AUCTIONS ARE A NEW AND UNPROVEN IDEA
  Wrong. The mechanism predates electronic trading. Frequent batch auctions for HFT venues were proposed in 2015 (Budish, Cramton, Shim), CoW Protocol has run them in production for spot since 2021, and Sour ports the design to leveraged derivatives on Solana.

Sour reference implementation

PROGRAM ID

souryQgnM1xiNuGcmVYLPGT3MKqnGN8QTqP8zk8eape

BATCH SLOT

1.8 seconds

FEE

3 bps flat, 100% to SOUR LP vault

MAX LEVERAGE

50× isolated

MARKETS

SOL-PERP, BTC-PERP, ETH-PERP (USDC-quoted)

VERIFICATION

18 Kani proofs · Lean spec · 15 property tests

AUDIT STATUS

No third-party audit yet. Verification repo is public.

SOURCE

github.com/GageBachik/sour

VERIFICATION REPO

github.com/GageBachik/sour-verification

APP

app.sour.finance/trade