OmnipairDocs

Introduction

Trade, borrow and earn in markets that price their own tokens and risk, for any token pair, with no whitelist and no oracle required.

Updated Nov 9, 2026

Omnipair is a Solana protocol where one market does the work of an exchange and a lending market at once. Each market holds one token pair. Traders swap against its reserves, liquidity providers earn both swap fees and borrow interest, and borrowers post one asset to take a loan in the other.

Prices and risk come from the market's own curve, so no listing committee or risk council stands between a token and its first market, and no oracle is required. A market can run on its own trading history alone, or opt into a price feed that guides its curve within set limits.

The problem

An automated market maker, a lending market and a liquidation route usually hold three separate views of the same asset. The lender marks collateral at a linear price, but when a position fails, its collateral has to be sold into finite liquidity. For a thinly traded token the gap between that mark and what a sale actually recovers can be larger than the loan's entire economics.

An external price feed can improve the mark, but it cannot create the inventory a liquidation needs.

The usual answer is to allow credit only for tokens with deep, curated markets. That keeps money markets safe and keeps most of the tokens people actually trade out of them. Meanwhile the liquidity that does exist sits idle in swap pools, earning only when someone trades.

The solution

Omnipair's answer is the Generalized Automated Market Maker: exchange and credit share one pair-local balance sheet. Borrowing replaces available cash with a debt claim of the same size; trading changes the inventory. Because both happen on the same reserves, collateral is valued by what the curve would actually pay for it, the lender's inventory and the liquidator's inventory are the same tokens, and every market is isolated from every other one.

  • Liquidity providerPuts in both tokens · gets srLP, or first-loss jrLP
  • TraderPuts in one token · gets the other, along the curve
  • BorrowerPuts in collateral · gets a loan in the other token
  • hLP depositorPuts in one token · gets hLP, a hedged LP share
  • Leverage traderPuts in margin · gets an isolated long or short

Three separations make this work once a market contains debt, concentrated liquidity and leveraged ownership at the same time:

  • Claims are not cash. The stored reserve records who owns what; only the cash part can leave the vault in a swap or a withdrawal.
  • The share coordinate is not the trading coordinate. srLP is minted and burned against the live reserve with unpaid interest left to the holders who earned it, while a swap executes on the ordinary liquidity tranche, which also takes hLP ownership out.
  • Admission, eligibility and recovery use different valuations. A borrow is admitted against conservative price and depth, liquidation eligibility uses a smoothed mark, and settlement is bounded separately for atomic external fills or the internal EMA-and-depth fallback.

Native and oracle-guided markets

A native market never reads an external price feed. It keeps internal observations: the spot price, a symmetric and a directional exponential moving average, a depth measurement and a persistent concentration centre. Their quality depends on the market's own trading history.

An oracle-guided market also reads one configured feed on every price-sensitive instruction, checks its age and confidence, and lets it pull the curve's price toward the feed, by a set weight and never past a set cap. Everything else, from swaps to collateral values, still runs on the curve; the feed never values a loan on its own. Either way, market-local accounting contains a loss inside the market that took the risk; it does not establish an external fair price, and it does not promise that liquidity is available at every moment.

Pricing and oracles covers the details and the trade-offs.

What a market offers

Traders

Swap along a concentrated curve with a known fee stack and a quoted price impact.

Borrowers

Post one asset, borrow the other. No listing committee, and a collateral factor derived from the curve.

Liquidity providers

Deposit both tokens to earn from fees and interest, take losses first in the junior tranche for a larger share, or deposit one token and keep its price exposure.

Leverage traders

Isolated long and short positions up to 10x with take-profit and stop-loss orders.

Market creators

Any token pair, six steps, parameters selected at creation and operator changes announced with the full notice.

Keepers

Liquidation fills, order execution and protection orders are permissionless and paid.

What V2 adds

Omnipair V2, called Dusk, is a new program built around the same idea. The biggest changes from V1:

AreaV1V2 (Dusk)
LP tokenOne omLP tokensrLP (two-sided, senior), jrLP (first-loss junior) and a base and a quote hLP (hedged, single-sided)
CurveConstant productConstant-product tail with optional concentrated bands around a sticky centre
PricingThe pool's own reservesThe market's own reserves, optionally guided toward one oracle feed within fixed bounds
FeesBase swap feeBase fee plus divergence and volatility surcharges, optional launch schedule
RatesTarget-band controller on utilizationTwo bands, junior coverage and utilization: the rate rises when either is out of line
LeverageManual recursive borrowingIsolated positions with market and limit entries, TP/SL and delegated execution
LiquidationAny caller; losses shared by all LPsKeepers' atomic flash fills, an internal fallback past a deeper health boundary, and losses taken by junior capital first
GovernancePool settings fixed at creationMarket operator with an optional manager, seven parameter families and timelocked atomic bundles

The full list is in V2 vs V1. The V1 documentation stays online at docs.omnipair.fi for anyone still using the V1 program.

Where to go next