Cowrie Research

omnipair

3 min read

Omnipair

  • Name: Omnipair
  • URL: https://docs.omnipair.fi/
  • Category: oracleless margin protocol / AMM-coupled lending / isolated-pool leverage
  • Tags: solana-ecosystem
  • Summary: Omnipair is an AMM-native money market, not another Solana margin app. Its GAMM collapses spot swaps, lending, borrowing, leverage, and liquidation into the same isolated two-token pool. Credit policy therefore sits inside pool math — pessimistic double-EMA pricing plus impact-aware collateral factors — instead of an oracle committee and a separate risk desk.
  • What it does:
    • Runs isolated two-token pools on Solana that support spot swaps, borrowing, and recursive leverage inside the same pool
    • Uses a Generalized Automated Market Maker (GAMM) with virtual reserves, cash reserves, and debt accounting tied together by explicit solvency invariants
    • Prices lending risk with a pessimistic double-EMA system instead of external oracle feeds
    • Computes dynamic borrowing limits from simulated liquidation impact on the AMM curve, with separate borrow and liquidation collateral factors
    • Handles liquidations through debt write-offs and collateral seizure rules rather than auction-based external liquidator markets alone
    • Routes protocol-fee surplus into a futarchy-governed authority while the current upgrade/admin path remains under a Squads multisig
    • Positions isolated pools as the way to support long-tail assets without letting one market’s insolvency contaminate others
  • Key claims:
    • Omnipair’s docs describe the protocol as permissionless, oracle-less, and isolated-collateral, with a single GAMM pool unifying swaps and margin borrowing instead of splitting spot and lending across separate venues.
    • The technical overview defines three reserve layers — virtual reserve, cash reserve, and debt — and ties them together with the invariant R_virtual = R_cash + R_debt, which makes the pool’s credit system analytically inseparable from its AMM state.
    • The protocol uses a double-EMA system with both symmetric and directional EMA components, then values collateral at the more conservative of the two; this is important because Omnipair is explicitly trying to make borrowing power depend on pessimistic internal pricing rather than on a separate oracle committee.
    • The impact-aware collateral-factor docs say borrowing limits are derived by simulating liquidation through the AMM curve itself, so larger positions face tighter effective leverage because liquidation slippage is priced into credit capacity ex ante.
    • The liquidation docs emphasize that Omnipair values collateral by reconstructing virtual reserves at pessimistic prices and using constant-product swap math for recovery estimates, which is more analytically useful than filing it as a generic oracleless lending project.
    • Omnipair’s system keeps separate borrow-CF and liquidation-CF values with a built-in 5% buffer, plus applied_min_cf_bps protection for existing borrowers, exposing a distinct policy surface around how much pool conditions can tighten after a position is opened.
    • The security and addresses pages show that the protocol is currently still upgradeable via a Squads multisig with no timelock, while a futarchy authority controls fee-routing and emergency global_reduce_only; that means the real governance/control surface today is still split between aspirational MetaDAO-style futarchy and present multisig upgrade power.
    • The fee-surplus and governance docs make clear that Omnipair is not only a lending primitive but also a revenue-routing system: swap and interest fees accumulate as surplus and are directed among treasury, buybacks, and team recipients through the futarchy authority.

Internal linkages

Graph View

Backlinks