Jupiter Perps vs Sour

At a glance

Jupiter figures reflect the broad characterization of the product. Sour figures reflect the v1.0.7 mainnet protocol.

What Jupiter Perps is good at

Jupiter Perps is the largest perp product on Solana by cumulative volume — roughly $477B cleared — and that is not by accident. It is integrated into the Jupiter aggregator, which means a huge built-in user base lands on the perp surface from a wallet they already use. Distribution matters; Jupiter has it.

The pool-counterparty design has real ergonomic advantages. There is no orderbook to read, no slippage from thin liquidity at the price you want — the pool quotes against an oracle and you fill or you do not. For users who think in directional terms ("I want to be long SOL with leverage") rather than orderbook terms, this is a much simpler mental model.

JLP itself is a popular product. It exposes LPs to a basket of SOL, ETH, BTC, and USDC plus a cut of trader fees and borrow fees, and many users hold it as a yield-bearing position. The pool design lets Jupiter accept multiple collateral types natively, which Sour does not at v1.0.7.

And Jupiter Perps is audited and a known quantity inside a brand most Solana users already trust. That is a meaningful trust gap that Sour has not closed yet.

What Sour does that Jupiter Perps does not

These are structural differences in product type, not just feature variations.

• BATCH CLEARING IS MEV-RESISTANT BY CONSTRUCTION
  Inside a 1.8s batch, every order fills at one uniform clearing price, settled atomically. No transaction-ordering edge exists inside the auction window. Jupiter Perps does not match orders against each other, but it also does not give you orderbook price discovery — you take whatever the pool quotes. See /learn/mev-resistant-by-design.
• FUNDING INSIDE SETTLEMENT, NO BORROW-FEE DRIFT
  Sour computes funding inside every batch as part of settlement. Jupiter does not have a traditional funding rate; instead, holders pay a borrow fee that accrues on utilization while a position is open. That is a different cost surface — and on Jupiter it can dominate PnL on long holds. See /learn/no-funding-cron-perps.
• SETTLEMENT MATH IS FORMALLY VERIFIED
  18 Kani bounded model checks, a Lean specification of the aggregate-budget invariant, 15 property tests. Reproducible artifacts on the verification repo, run on every PR. See /learn/formally-verified-perp-dex.
• BOUNDED LP RISK, NOT UNBOUNDED POOL EXPOSURE
  Sour LPs are protected by a per-user OI cap that scales with LP NAV (defaults: 10× LP NAV per trader at launch). JLP holders are exposed to the aggregate PnL of the entire trader pool — when traders win, JLP pays. Different risk profile entirely. See /learn/per-user-oi-cap.
• FLAT 3 BPS, NO BORROW-FEE COMPOUNDING
  A Sour fill costs 3 bps. There is no utilization-dependent fee that accrues over time — the fee is assessed at fill and that is it. Holding a position through a low-liquidity weekend does not generate additional cost. See /learn/flat-fee-perp-dex.

When to pick Jupiter Perps

Pick Jupiter Perps if you want the simplest directional UX inside a wallet you already use. The pool-counterparty model removes orderbook complexity entirely; you set leverage, you set collateral, you long or short, and the pool quotes you. There is no slippage to model and no maker depth to read.

Pick Jupiter Perps if you want to post non-USDC collateral. The JLP-pool design accepts SOL, ETH, BTC, and USDC natively; Sour is USDC-quoted only at v1.0.7.

Pick Jupiter Perps if you are an LP looking for a yield-bearing basket exposure. JLP is a real product with real flows — it is not the same shape as a Sour LP position, and for some users the basket exposure plus fee revenue is what they want.

Pick Jupiter Perps if depth and audit posture matter more than matching-model purity. Cumulative volume of $477B and an audit lineage inside the Jupiter brand are credentials Sour does not have.

When to pick Sour

Pick Sour if you want orderbook price discovery — fills against other traders, not against an oracle-quoted pool. Sour aggregates intent into a 1.8s batch and clears at a uniform price. That is closer to what a CEX matching engine does than what a pool product does.

Pick Sour if MEV exposure on every fill is something you actually pay attention to. Sandwich-attack-resistance follows from the matching model itself, not a mitigation layer.

Pick Sour if you are bothered by utilization-dependent borrow fees compounding while you hold. Flat 3 bps at fill, no time-based cost. Backtests are honest.

Pick Sour if you want the settlement math mechanically verified rather than only audited. The 18 Kani proofs and Lean spec at github.com/GageBachik/sour-verification check the aggregate-budget invariant on every PR.

Pick Sour if you want Degen Mode, where max loss is capped at the bet size — the simplest possible perp UX for a newcomer. Pro Mode shares the same orderbook when you outgrow it.

Sour reference

PROGRAM ID

souryQgnM1xiNuGcmVYLPGT3MKqnGN8QTqP8zk8eape

NETWORK

Solana mainnet

BATCH SLOT

1.8 seconds

FEE

Flat 3 bps per fill, 100% to LP vault

COUNTERPARTY

Other traders, with LP backstop

COLLATERAL

USDC only

VERIFICATION

github.com/GageBachik/sour-verification

AUDIT

No third-party audit yet