> For the complete documentation index, see [llms.txt](https://docs.imperial.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.imperial.space/pairs-markets.md). # Pairs Markets ### What is a pairs market? A pairs market lets you trade the **relationship between two assets** instead of either asset outright. SOL/BTC is the first one: long means "SOL outperforms BTC," short means "BTC outperforms SOL." You have no net exposure to the overall market going up or down — if SOL and BTC both pump 10%, a SOL/BTC position is roughly flat. It trades like any other perp on Imperial: one position, one price, USDC collateral, leverage, TP/SL, funding, liquidations. Under the hood there is no spot pair being traded anywhere — the price is a **synthetic index** composed from the two assets' USD oracle prices, and your counterparty is the pairs liquidity pool. ### Beta Weighting The obvious way to build SOL/BTC is the raw price ratio (what TradingView shows for SOLBTC). We don't use that, on purpose. **The problem with the raw ratio:** SOL is much more volatile than BTC (roughly 79% vs 46% annualized). A 1:1 ratio is dominated by whatever SOL does — it's mostly just a leveraged SOL bet with extra steps, not a bet on relative performance. **What we do instead — beta weighting:** we scale each leg so both contribute proportionally to their volatility. From two years of daily data, SOL's beta to BTC is \~1.40 — so the index is built as if every $1 of SOL exposure is hedged with $1.40 of BTC. Normalized, that's: * **SOL weight: 41.7%** * **BTC weight: 58.3%** This makes the index genuinely market-neutral: its residual correlation to BTC is \~zero (the naive 1:1 ratio still carries about +0.19 BTC beta). The result is an index that isolates "is SOL winning or losing vs BTC" — about a third as volatile as BTC itself (\~0.7–0.9% daily moves). **The formula.** The index is geometric (built from log returns), so it moves symmetrically and can never go negative: ``` index = anchor × exp(0.417 × ln(SOL / SOL_anchor) − 0.583 × ln(BTC / BTC_anchor)) ``` The anchors are the leg prices captured when the market was listed; the index started at an arbitrary reference value and compounds relative performance from there. **So versus TradingView SOLBTC:** 1. **Different weights.** TV's ratio is effectively 1:1 in log terms; ours is 0.417 / 0.583. Direction usually agrees, magnitude doesn't — our index moves less when SOL moves and more when BTC moves. 2. **Different level.** The index value is anchored to a reference at listing, not to the raw SOL-per-BTC ratio, so the absolute number is different. Only returns are comparable. 3. If you overlay `SOL − 1.4×BTC` style beta-weighted spreads on TV you'll get close; the raw SOLBTC symbol will not match and isn't supposed to. The chart on Imperial shows the index plus optional raw SOL/USD and BTC/USD leg overlays (rebased to 100) so you can see which leg is driving a move. ### Where prices come from * Both legs price off **Pyth oracle feeds** (SOL/USD and BTC/USD) — never any exchange's orderbook mid. * If either leg's oracle is stale, the market treats the whole index as stale and halts pricing rather than quoting off one live leg. ### Fill price: skew impact instead of spread There is no orderbook, so instead of a bid/ask spread the execution price carries a **skew impact premium** (the Synthetix v2 model). The book's *skew* is total long OI minus total short OI. Your fill is: ``` fill = index × (1 + (skew_before + skew_after) / (2 × impact_scale)) ``` clamped to a max impact *(current: ±30 bps on SOL/BTC)*. What this means in practice: * **Trades that increase the imbalance pay a premium; trades that reduce it get a discount.** If the book is long-heavy, new longs buy above index and new shorts sell above index (they're paid for balancing). * Because the premium is averaged over the skew your trade traverses, the mechanism is **path-independent** — an instant open-and-close round trip fills at the same price both ways and costs only the flat fees. There is no rebate pot to farm. * The premium/discount goes to the liquidity pool, compensating it for warehousing the imbalance. Opens, closes, **and liquidations** all price at the fill, not the raw index — your liquidation health is computed against the price you could actually exit at. ### Funding Funding is proportional to skew: the heavy side pays the light side continuously. ``` rate per day = k × net_skew / skew_scale (clamped at a max) ``` Positive skew (long-heavy) means longs pay, shorts receive; funding accrues per second against your notional and settles when you close (it's included live in your PnL and liquidation health). A balanced book pays nothing. On the portion of skew that no trader balances, the pool itself collects the funding — it's paid to warehouse the residual risk. ### PnL Positions are fixed-notional. For a long: ``` pnl = notional × (index_now − entry_fill) / entry_fill ``` (mirror-image for shorts). Example: $1,000 long SOL/BTC; SOL +2%, BTC +1% → index moves ≈ 0.417×2% − 0.583×1% = **+0.25%** → **+$2.50**. Note that your PnL is measured from your **entry fill** (which includes any skew impact), not the raw index at the moment you clicked. #### Per-position basket locking Your position locks its exact basket (the SOL/BTC weights and leg anchor prices) at open. If we ever re-estimate beta and reweight the market index, existing positions are untouched — they keep tracking the basket they actually bought, and the new weights apply only to positions opened afterward. Adding to a position blends the tranches (notional-weighted entry, delta-preserving weights).