What are Flow Perps?

Why we coined the term

Most perpetual futures DEXes fall into one of two camps. Continuous central limit orderbooks like Drift and Hyperliquid match orders the moment they arrive, with maker-taker fees, queue position, and a relentless race to be the first message in the matching engine. Pool-based perp venues like Jupiter Perps, GMX, and dYdX-style synthetic markets quote against an LP pool at oracle price minus borrow fees, with no orderbook at all. Both designs work, both have been battle-tested, and both leave wide-open lanes for MEV — sandwiches, priority-gas auctions, oracle-front-running, and toxic order flow.

Sour is neither. It is a discrete batch auction running once per 1.8-second slot. Orders flow into the slot. When the slot closes, the matching engine sorts by price-time priority, computes a single uniform clearing price, and settles every fill at that price atomically inside one Solana block. Then the next slot opens. We coined the term Flow Perps to capture exactly that rhythm: orders flow in, the batch clears, repeat. It is shorter than "discrete-time uniform-price batch-auction perpetual futures" and it points at the design choice that matters.

The naming is deliberate. We did not want yet another "fast" or "next-gen" label. The point of the design is the batch — what the trader sees as a smooth flow of fills, the protocol implements as a sequence of fair auctions. If you remember one thing about Flow Perps, remember that there is no continuous matching loop. There is a slot, and at the end of the slot, everyone fills at the same price.

How a batch clears

Inside each 1.8-second batch slot, traders submit limit and market orders. The orders accumulate in the program’s open-orders state on chain. Cancels and amendments are processed in the same window — there is no off-chain queue and no privileged sequencer. When the slot closes, the protocol runs price-time priority sorting (by price first, then by submission timestamp recorded on the prior block), walks the resulting book, and computes the single uniform price at which the maximum cleared volume crosses. Every matched order — bid or ask, maker or taker — fills at exactly that price.

Settlement happens inside the same Solana transaction that closes the batch. Trader collateral, position state, oracle-anchored mark, and funding accrual are all updated atomically. There are no separate settlement transactions, no "trade then later settle" gap, no half-filled state visible to other programs. Funding is computed inside every batch as part of the same handler that clears trades, so there is no off-chain cron job, no funding keeper, and no surprise hourly payment moment. Liquidations are structural too: if a position fails its margin check at the clearing price, it is closed in the same batch, again with no off-chain liq bot.

Fees are flat at 3 bps per fill, charged on notional and credited 100% to the SOUR LP vault that backs all markets. There is no maker rebate, no taker premium, no tiered VIP schedule. The fee model is the simplest expression of the design: if you trade, the LPs that backstop your counterparty risk get paid the same fraction every time.

What this changes

Most of the second-order properties of Flow Perps fall directly out of the batch-clearing primitive. None of them are bolted on.

• NO FRONT-RUN LANE
  Front-running requires a continuous matching loop where an attacker can insert their order between the victim’s broadcast and the victim’s fill. Inside a 1.8-second batch, every order in the slot fills at the same price, regardless of arrival order. There is nothing to front-run.
• NO BACK-RUN OR SANDWICH
  A sandwich requires a price impact that the attacker can capture between two of the victim’s adjacent fills. Uniform clearing eliminates the per-fill price impact: there is one price for everyone in the slot. The classic two-sided sandwich does not have a place to land.
• NO PRIORITY-GAS ADVANTAGE
  Solana priority fees buy block inclusion, not in-slot ordering. Once a transaction lands in the slot containing the batch, paying more priority fee does not move you up in the matching engine. Price-time priority is computed from order parameters, not from gas tips.
• FUNDING INSIDE THE BATCH
  There is no separate funding cron, no off-chain rate calculator, and no keeper that you must trust to call settle_funding. Funding accrues against the oracle-anchored mark inside every batch handler, deterministically.
• STRUCTURAL LIQUIDATION
  A position that fails its margin check at the clearing price is closed inside the same batch. There is no liquidation keeper to bribe, time, or out-race. The same matching engine that fills you also closes you.
• ATOMIC PER-BLOCK SETTLEMENT
  The batch close, fill assignment, collateral update, and funding accrual all run inside one Solana transaction. Other programs reading Sour state never observe a partial batch. Composability is exact.

When Flow Perps are not the right answer

Flow Perps optimize for fairness, MEV resistance, and structural simplicity. They do not optimize for sub-100ms cancel-replace latency, exotic order types, or the kind of microstructure you build a market-making firm around. If your strategy depends on having queue position in a continuous limit book, on iceberg or hidden orders, or on round-tripping a trade in less than a Solana slot, Flow Perps are the wrong fit. A continuous CLOB will give you those affordances. Sour will not.

Sour is also USDC-quoted with USDC collateral. There is no cross-margin against SOL, BTC, or ETH spot balances, no LST collateral, and no multi-asset margin engine. Traders who hold non-stable collateral and do not want to convert to USDC should look at venues with a richer collateral model. Max leverage on Sour is 50×; if you need 100× or 250× — and you have decided that the additional liquidation tail risk is acceptable — Sour will not give you that knob either.

Finally, the protocol has not been through a third-party security audit yet. Sour is formally verified — eighteen Kani proofs, a Lean specification of the aggregate margin model, and fifteen property tests — and the verification repository is public. Formal verification is a stronger correctness signal than most audits, but the two are not substitutes. We will commission an audit; we have not yet. Trade accordingly.

At a glance

PROGRAM ID

souryQgnM1xiNuGcmVYLPGT3MKqnGN8QTqP8zk8eape

NETWORK

Solana mainnet-beta

BATCH SLOT

1.8 seconds

FEE

3 bps flat per fill, 100% to SOUR LP vault

MAX LEVERAGE

50× isolated

COLLATERAL

USDC

LAUNCH MARKETS

SOL-PERP, BTC-PERP, ETH-PERP

FUNDING

Computed inside every batch — no off-chain cron

LIQUIDATION

Structural at clearing price — no liq keeper

VERIFICATION

18 Kani proofs · Lean spec · 15 property tests

SOURCE

github.com/GageBachik/sour

WHITEPAPER

sour.finance/docs/sour-flow-perps-whitepaper.pdf