Skip to main content

​
General

Omnipair is a decentralized protocol for spot trading, borrowing, and leverage built around isolated, pair-specific money markets. Each market operates independently and supports swaps, collateralized borrowing, leveraged positions, and liquidity provision within a single pool.Unlike traditional AMMs or lending protocols, Omnipair does not rely on governance whitelists or external price oracles. Any SPL token pair with liquidity can form its own market, with risk and pricing determined by that market’s dynamics.
Traditional AMMs are designed for token swaps and do not support borrowing or leverage. Lending protocols, on the other hand, typically allow users to supply assets into shared pools that support borrowing across the entire system, often restricted to a curated list of assets. Omnipair combines these models into a single structure.Each market is isolated to a specific token pair and supports swaps, borrowing, leverage, and liquidity provision within the same pool. This design allows long-tail and emerging assets to form money markets organically, while maximizing capital efficiency in every pool. 
Yes. Omnipair is a non-custodial protocol, meaning users always retain control over their assets. To interact with Omnipair, you must connect a Solana-compatible wallet such as Phantom or Solflare. The wallet is used to sign transactions, manage assets, and interact with markets directly on-chain.
Omnipair is currently deployed on Solana, and is designed to leverage Solana’s high throughput and low transaction fees. 
Yes. Market creation is fully permissionless. Any user can deploy a market for any SPL token pair by supplying initial liquidity and selecting market parameters at deployment.There is no approval process, governance vote, or asset whitelist required. Once deployed, the market is immediately available for anyone to trade, provide liquidity, borrow, or open leveraged positions.
Users can interact with Omnipair through a user-friendly web interface or directly with its on-chain programs on Solana. This openness also enables developers to build integrations, third-party apps and services that compose on top of Omnipair’s architecture.To interact with Omnipair through the interface, simply connect a Solana-compatible wallet and select a market. From there, you can swap assets, provide liquidity, borrow against collateral, or create leveraged positions within that market. Assets supplied to a pool earn fees and interest based on market activity, and supplied collateral can be used to access borrowing and leverage within the same isolated pool.
Interacting with the Omnipair Protocol requires transactions on Solana. These transactions may incur gas fees, which are non-refundable network transaction fees determined by the network status and transaction complexity.

​
Liquidity Provisioning

Providing liquidity on Omnipair means depositing assets into a specific market’s pool so they can be used for swaps, borrowing, and leveraged positions within that market.Unlike traditional AMMs where liquidity is only used for trading, Omnipair liquidity is shared across multiple market functions. This allows the same capital to generate fees from swaps and interest from borrowing, all within a single isolated pool.
To join an existing pool, users select a market and deposit both assets according to the pool’s current ratio. Once deposited, users receive omLP tokens representing their proportional ownership of the pool.omLP tokens track the user’s share of the pool and accrue value as the market generates fees and interest over time. 
Liquidity providers earn yield from two primary sources within each market: swap fees paid by traders who execute swaps in the market, and interest paid by borrowers who use liquidity from the same pool to open borrowing or leverage positions, resulting in multi-source yield accrual through one position. Users receive omLP tokens representing their proportional ownership of the pool. Because Omnipair markets are isolated, the exact yield varies by pool and reflects the specific trading volume, borrowing demand, and utilization of that market over time.
An LP position represents a proportional claim on the assets held within a specific pool. Over time, both the value and composition of the position can change as the market evolves.LP performance is influenced by trading activity and accumulated swap fees, interest paid by borrowers, changes in relative asset prices, and overall market utilization. Since all activity occurs within an isolated market, LP outcomes are directly tied to that market’s dynamics rather than protocol-wide conditions.
Liquidity providers can withdraw their position by burning their LP tokens, which returns their proportional share of the pool’s underlying assets. Withdrawals can be performed in a single transaction through the Omnipair app interface and may be done partially or in full, depending on the amount the user chooses to remove.Withdrawals are subject to current market utilization. If a significant portion of the pool’s liquidity is actively borrowed, some assets may be temporarily unavailable until borrowers repay or positions are liquidated, at which point liquidity becomes available again.
Impermanent loss occurs when the relative prices of assets in a pool change compared to when liquidity was deposited, resulting in a different asset composition than simply holding the assets outside the pool. This can lead to a lower value upon withdrawal than holding the tokens individually.On Omnipair, multi-source yield within the same market may offset impermanent loss over time. However, impermanent loss remains an important consideration for liquidity providers, particularly in volatile or low-liquidity markets.

​
Swaps

Users can swap tokens by selecting the asset they want to swap from and then choosing an available paired asset that has an active market on Omnipair. Swaps can be executed through Omnipair’s user interface or by interacting directly with the protocol’s smart contracts.Once a market is selected, users enter an amount and confirm the transaction through their wallet. Before confirming, users are shown the expected output amount, price impact, and any applicable fees, allowing them to review execution conditions prior to submission.
Omnipair’s GAMM model uses constant-product AMM pricing (the x·y = k invariant) based on on-chain liquidity, meaning swaps are executed directly against the liquidity in the selected market using AMM pricing, similar to traditional AMMs.The key difference is that each Omnipair market is isolated and may vary in risk parameters and utilization levels, which can influence available liquidity and price impact without changing the underlying pricing formula.
Price impact represents how much a swap changes the market price due to the size of the trade relative to available liquidity.Larger trades or trades in markets with lower liquidity generally result in higher price impact. This is a natural consequence of trading against a finite liquidity pool and is displayed to users before execution.
Long-tail and newly issued assets often have lower liquidity and higher volatility than more established tokens. As a result, swaps involving these assets may experience higher price impact and more noticeable price movement.Because Omnipair markets are isolated, these dynamics are contained within the specific market and do not affect other markets on the protocol.
Swap prices on Omnipair are not directly affected by borrowing or leverage activity. Swaps are priced using the pool’s actual reserves under the constant-product AMM model. Borrowing and leverage operate through virtual reserves, which track debt and risk exposure without affecting the reserves used for swap pricing.Because of this separation, opening borrow or leveraged positions does not distort swap prices or cause artificial price movements. However, high borrowing utilization can reduce available liquidity in the pool, which may increase price impact for large swaps.

​
Borrowing

Borrowing on Omnipair takes place within the same pair-specific market where swapping occurs. Users can access assets by depositing collateral into a pool and borrowing the paired asset, either through Omnipair’s user interface or by interacting directly with the protocol’s smart contracts.When a user supplies collateral, it remains locked within the selected market while the borrowed asset is transferred to the user’s wallet. The borrowed position accrues interest over time until it is repaid.
The amount a user can borrow on Omnipair is determined by the value of their deposited collateral, the Collateral Factor (CF) of the market, and the price used to evaluate that collateral. Each market defines a maximum Collateral Factor, which caps how much value can be borrowed relative to the collateral supplied.To evaluate collateral safely, borrowing capacity is calculated using time-weighted EMA prices derived from the pool’s own liquidity. This smoothing mechanism reduces the impact of short-term price spikes or manipulation, ensuring that borrowing power adjusts gradually rather than instantly.
In most cases, yes. Omnipair allows borrowing against any SPL token, provided it has an active, sufficiently liquid market. Token-2022 tokens are not yet supported. Unlike traditional lending protocols that rely on protocol-wide whitelists, Omnipair’s markets are pair-specific and isolated. Whether an asset can be efficiently used as collateral depends entirely on the liquidity, configuration, and risk parameters of its individual market rather than approval at the protocol level.
Interest rates on Omnipair are market-driven and adjust dynamically based on utilization within each isolated pool.As borrowing demand increases and a larger portion of available liquidity is utilized, interest rates rise to reflect increased capital scarcity. When utilization decreases, rates fall accordingly. This ensures that borrowing costs respond in real time to supply and demand within the market.
Borrowed positions can be repaid either directly through the Omnipair app interface or by interacting with the protocol smart contracts directly.Within the app, navigate to the Borrowed Positions tab, select the position you would like to repay, and click Repay. You can choose to repay part of the borrowed amount or close the position entirely, depending on your preference.

​
Leveraging

Leveraged positions on Omnipair are created through a process often referred to as recursive borrowing. A user deposits an asset as collateral, borrows the paired asset from the same market, and then swaps the borrowed asset back into the original asset.This process can be repeated to increase exposure, as long as the position remains within the market’s borrowing limits. Rather than relying on external margin systems or order books, leverage is achieved directly inside the market through borrowing and swapping using the pool’s existing liquidity.
Leverage on Omnipair is constrained by market-specific parameters that determine how much risk a pool can safely support. The primary constraint is the Collateral Factor (CF), which sets the maximum value that can be borrowed relative to deposited collateral.Leverage is further limited by liquidity depth, market utilization, and EMA-smoothed pricing, which influence borrowing capacity and liquidation thresholds. Together, these factors ensure that leverage scales naturally with liquidity and risk conditions within each isolated market.
Smaller or less liquid markets tend to experience larger price movements and tighter liquidity conditions, which can make leveraged positions more sensitive to market changes.Because leverage on Omnipair is fully market-driven, users should expect lower leverage limits and more sensitive liquidation thresholds in markets with limited liquidity or higher volatility. Positions in smaller markets may require more frequent monitoring and a greater margin for price fluctuations.
A dedicated leverage trading interface for Omnipair is currently in active development. The goal is to provide users with a streamlined, intuitive experience for opening and managing leveraged positions without manually executing recursive steps.In the meantime, leverage can be achieved through borrowing and swapping within the same market using the existing interface. Updates on the leverage UI and related features will be shared through Omnipair’s official documentation and community channels as development progresses.

​
Liquidations

When a borrower crosses the liquidation threshold (collateral value < debt value based on EMA pricing), their debt is immediately removed from the debt accounting pool. This requires no external liquidator.Once the debt is written off, the borrower’s collateral ownership transfers to the pool. Rather than selling collateral into the market, the protocol absorbs it directly, preventing external price shocks and manipulation. This internal liquidation logic is oracle-less and leverages EMA pricing to smooth volatility and reduce manipulation risk.
Traditional lending protocols liquidate by selling seized collateral into the market, which can cause price impact, slippage, and cascading liquidations during volatility. Omnipair avoids this by absorbing the collateral into pool reserves after writing off the borrower’s debt, eliminating reliance on third-party liquidators and minimizing disruption to the pool’s liquidity and price. Without external collateral sales, the pool remains solvent without triggering price cascades, helping maintain smoother market conditions and reducing flash-crash risks inherent in auction-based systems.
When a borrower is liquidated through debt write-off, the borrower’s collateral is absorbed into the pool’s reserves. Any resulting changes in reserves are shared proportionally among LPs within that isolated market.Because liquidations do not rely on external auctions or third-party liquidators, risk remains contained within the market and cannot impact other pools or the protocol as a whole.
To avoid liquidation on Omnipair, users should keep their borrowing positions sufficiently collateralized relative to the market’s Collateral Factor and EMA-based pricing.Because borrowing capacity is evaluated using time-weighted EMA prices, collateral requirements adjust gradually rather than reacting to short-term price spikes. Maintaining a buffer by borrowing below maximum limits, adding collateral, or repaying debt partially as market conditions change can help reduce liquidation risk.

​
Customizable Pools

To deploy a new pool on Omnipair, a user selects a token pair, configures the market’s risk parameters, and supplies initial liquidity for both assets. Pools can be created through the Deploy Pool interface in the Omnipair app or by interacting directly with the protocol’s smart contracts.Once deployed, the pool becomes an active market immediately and can be used by anyone for swaps, borrowing, leverage, and liquidity provision.
Risk presets are predefined configurations that bundle key market parameters into a single choice. Each preset sets a maximum Collateral Factor (CF), an implied maximum leverage, and an EMA half-life, allowing users to quickly tune the balance between capital efficiency and risk resilience.Conservative presets prioritize stability with lower CF and longer EMA smoothing, Balanced presets offer a middle ground suitable for most markets, and Aggressive presets enable higher leverage and faster price responsiveness with increased sensitivity to volatility. Presets provide sensible defaults while avoiding the need for complex manual configuration.
Advanced customization allows pool creators to manually tune all risk parameters instead of using presets. This includes configuring values such as the Collateral Factor, EMA half-life, and other parameters that influence borrowing capacity, price responsiveness, and leverage limits. Advanced mode is intended for users who understand the trade-offs between capital efficiency and market stability.
No. Pool parameters are fixed at the time of deployment and cannot be changed afterward. This immutability ensures that all participants interact with a market under known and predictable rules.

​
Risks & Security

Using Omnipair involves several types of risk that vary by market:
  • Market volatility: Asset prices can change rapidly, affecting collateral value and borrowing capacity
  • Liquidation risk: Borrowed positions may be liquidated if collateral falls below required thresholds
  • Impermanent loss: Liquidity providers may experience divergence between pooled assets compared to holding
  • Utilization risk: High borrowing demand can temporarily reduce available liquidity for withdrawals or swaps
  • Long-tail asset risk: Newly issued or low-liquidity tokens may experience sharper price movements and lower stability
Because markets are isolated, these risks are confined to the specific pool in which a user participates.
Omnipair incorporates several structural safeguards to reduce systemic risk:
  • Isolated markets ensure that risk is contained within individual token pairs
  • EMA-based pricing smooths price inputs for lending and liquidation logic, reducing susceptibility to short-term manipulation
  • Collateral Factor ceilings cap borrowing and leverage at the market level
  • Utilization-aware dynamics naturally limit borrowing when liquidity becomes scarce
  • On-chain enforcement ensures that constraints, liquidations, and debt resolution occur deterministically according to market rules
These mechanisms allow Omnipair to remain permissionless while maintaining disciplined risk boundaries.

​
Governance

OMFG (Omnipair Futarchy Governance token) is the governance token of Omnipair. It empowers token holders to regulate the protocol’s high-level behavior without interfering with immutable smart contracts. OMFG holders are part of a two-layer governance model that balances market-driven decision-making with regulatory oversight while keeping markets permissionless and autonomous.
Omnipair uses a layered governance model that separates market-driven behavior from protocol-level oversight. Higher-level protocol decisions are handled through futarchy-based governance on MetaDAO, where prediction markets are used to signal which proposals are expected to lead to better outcomes. Futarchy proposals are open to anyone and rely on market participation rather than token voting alone.In parallel, certain regulatory decisions and protocol authorities are reserved for OMFG holders through vote-based governance, providing oversight without interfering with deployed markets.Learn more: Omnipair on MetaDAO
Futarchy is a governance mechanism where prediction markets decide policy outcomes. Instead of traditional voting, participants buy and sell conditional outcomes, and the market selects the policy expected to perform best. In Omnipair, futarchy proposals are open to anyone and often relate to measurable metrics such as protocol revenue or adoption. The winning outcome is executed on-chain when the market signals its preference.
Vote-based governance is reserved for OMFG holders and serves as a regulatory authority rather than a day-to-day decision maker. This layer can adjust protocol-level parameters such as fees and governance mechanics (e.g., timelock durations, proposal costs, bond sizes), and it provides guardrails against malicious or reckless actions by market participants or pool creators.
Omnipair splits governance responsibilities to balance decentralized decision efficiency with long-term safety. Futarchy allows proposals to be evaluated by market prediction, which can capture collective insight and economic incentives. Vote-based governance gives OMFG holders a regulatory role, overseeing systematic risk and setting protocol-wide constraints without micromanaging individual markets.
No. Participation in governance, including futarchy proposals and OMFG voting, is entirely optional. Users can interact with Omnipair without engaging in governance at all. Governance exists to guide the protocol’s long-term evolution and regulatory boundaries, but using Omnipair’s markets, swapping, borrowing, or providing liquidity does not require participation in any proposal or vote.

​
Developers

​
Troubleshooting

Transactions may fail for several reasons, including insufficient SOL for network fees, slippage limits being exceeded, or rapid changes in market conditions between transaction submission and confirmation. Reviewing error messages and adjusting parameters such as slippage tolerance can often resolve the issue.
Borrow capacity depends on multiple factors, including the Collateral Factor of the market, current asset prices, market utilization, and available liquidity. If utilization is high or prices have moved recently, borrowing limits may be lower than anticipated.
When a large portion of liquidity in a market is currently borrowed, some assets may be temporarily unavailable for withdrawal. Liquidity becomes available again as borrowers repay or positions are liquidated according to market rules.
High price impact usually indicates that the trade size is large relative to available liquidity in the selected market. This is more common in smaller or newly created markets and is displayed before confirming a transaction.