OriginDOCS

Pricing & Funding

Origin operates two distinct price pipelines for two distinct purposes. Index price is sourced from Pyth and is used for funding rate calculation and PnL accounting. Mark price is constructed from a robust three-source median (with one input being a CEX-direct median) and is used for liquidation triggers and margin ratio. Keeping these pipelines separate means that the source used for solvency decisions is independent from the source used for funding, which limits the blast radius of any single data-source failure.

Index Price (Pyth)

Source

Index price is provided by Pyth Network. Pyth supplies high-frequency, first-party price data sourced from major trading firms and exchanges, with confidence intervals and cryptographic attestations.

Use

Index price drives:

  • The funding rate calculation (Section 8.4).
  • Reference values reported in account state.
  • Conversion of non-USD collateral to USD for margining (where Pyth provides the FX feed).

Feed Binding

Each market binds to a specific Pyth feed identifier at listing. The feed binding is recorded in the on-chain Asset Registry and can only be changed via governance.

Mark Price (Three-Source Median)

Formula

Mark price is the median of three independent price estimates, each robust to a different failure mode:

mark_price = median( impact_price, cex_median, ema_orderbook )

Where:

InputDefinition
impact_priceAverage execution price of a hypothetical fixed-size market order on Origin's own order book, computed for both bid and ask sides and averaged.
cex_medianMedian of recent prices for the underlying instrument across a configured set of major external venues, polled directly by Origin's Oracle Ingestion service.
ema_orderbookExponentially weighted moving average of Origin's order book mid price over a short rolling window (default 10 seconds).

Sources of cex_median

The CEX price set is configured per market and is independent of the Pyth feed used for index. For crypto perps, the set is the major centralized spot or perp venues for the underlying. For equity and commodity perps, the equivalent reference venues are used. The configured set is published per market and updated only through governance.

This separation matters: even if Pyth experiences degradation or compromise, the mark price (which gates liquidations) does not depend on it.

Why a Three-Source Median

Each input alone has a known weakness:

  • impact_price can be moved by a determined trader willing to take losses on Origin.
  • cex_median can lag during fast moves or fail to reflect Origin-specific liquidity.
  • ema_orderbook is exposed to spoofing or thin-book conditions.

The median of all three is robust to any single source being attacked or stale: an attacker would need to move at least two of the three simultaneously, which is materially harder.

Use of Mark Price

Mark price (not last-trade price) is used to calculate:

  • Unrealized PnL.
  • Margin ratio and account health state.
  • Liquidation triggers.
  • Conditional order trigger conditions (SL/TP/Stop).

Using mark price prevents wick-based liquidations and triggers caused by transient illiquidity or single-print spikes.

Oracle Heartbeat & Staleness

Heartbeat

The Risk Engine expects fresh price updates at minimum every 5 seconds per market. Both pipelines (Pyth index and CEX-median for mark) carry independent heartbeats.

Stale-Feed Behavior

When a feed is flagged stale:

Pipeline StaleSystem Response
Index (Pyth)Halt funding rate updates for affected market.
One of three mark inputsMark price falls back to the median of the remaining two valid sources.
Two of three mark inputsMarket enters per-market HALTED.
Both pipelinesMarket enters per-market HALTED.

In HALTED state, existing positions continue to mark against the last valid mark price but cannot be liquidated. This prevents liquidations driven by missing data rather than genuine market moves.

Feed Recovery

When a feed resumes, the engine resumes mark and index updates and clears any backlog of margin evaluations before re-enabling trading and liquidations. There is a brief grace period (default 30 seconds) during which margin breaches are flagged but not liquidated, giving users time to react to post-recovery prices.

FX Oracle for Virtual Markets

Virtual cross-currency markets (Section 3.4) require a separate FX price pipeline for each supported stablecoin pair (e.g., USD/KRW, USD/EUR, USD/JPY). This pipeline is distinct from the asset-level Pyth and CEX sources described above.

Primary source: StableFX $1M RFQ. The FX oracle mark price is anchored to the $1M-notional executable RFQ quote sourced from StableFX. Circle describes StableFX as an Arc-based stablecoin FX engine that combines off-chain RFQ execution with on-chain settlement, receiving competitive quotes from multiple liquidity providers. The $1M RFQ level is used as the primary mark input because it reflects real executable liquidity at an institutionally meaningful size, rather than a theoretical midpoint that may not be achievable. Size buckets are cached:

USD/KRW ask curve (StableFX RFQ):
  $100K:  1,382
  $1M:    1,385   ← primary mark input
  $5M:    1,390
  $10M:   1,396

Blended oracle formula. The published FX oracle mark is not a raw RFQ quote in isolation. It is a weighted blend designed to be robust to RFQ sparseness and LP-level manipulation:

fx_oracle_mark = weighted_blend(
  StableFX $1M RFQ mid,          # primary: executable, size-aware
  backup FX oracle feed,          # secondary: ensures continuous coverage
  internal StableFX fill prices,  # reinforces with actual settled rates
  5-minute TWAP                   # smoothing: prevents spike manipulation
)

The $1M RFQ is the dominant weight under normal conditions. If StableFX quotes become unavailable, the oracle falls back to the blended backup with widened haircuts (Section 4.3.5).

Conversion pricing. When actual currency conversion is needed (user withdrawal, liquidation collateral seizure, treasury rebalancing), the protocol does not use the oracle mark. Instead, it requests a live executable RFQ at the actual notional size of the conversion. The oracle mark is for continuous valuation; the live RFQ is for actual settlement. The distinction matters: a $50M liquidation is priced with a $50M RFQ, not with the $1M mark rate.

FX Stablecoin Basis Tracking

There is a meaningful difference between the theoretical fiat FX rate (e.g., USD/KRW on TradFi markets) and the actual stablecoin FX rate (KRW1/USDC on-chain). The protocol tracks this basis explicitly:

stablecoin_fx_basis = stablecoin_fx_rate - reference_fiat_fx_rate

If KRW1 trades at a discount to fiat KRW (a negative basis), collateral value must reflect the KRW1 on-chain rate, not the theoretical fiat rate. The protocol does not value KRW1 as if it were perfectly redeemable at the fiat FX rate unless that rate is executable.

When the stablecoin basis widens beyond a configurable threshold, the collateral haircut for that asset is tightened automatically and the dynamic haircut formula (Section 4.3.7) applies the issuer penalty component.

FX Circuit Breakers

Virtual market trading for a given currency pair is automatically suspended under the following conditions:

TriggerAction
StableFX RFQ unavailable for a currency pairDisable new virtual orders for that currency; switch to reduce-only
Backup oracle deviates from $1M RFQ by > thresholdPause virtual market; increase collateral haircut; alert operator
FX bid/ask spread widens beyond circuit_breaker_spread_bps (default 100 bps)Pause virtual order entry; allow canonical USD trading
FX moves > configured bps in configured windowPer-market HALTED for affected virtual pairs
Settlement failure rate for an LP exceeds thresholdRemove LP from oracle weighting; reduce quote TTL
Stablecoin depeg detected (basis > threshold)Reduce collateral factor dynamically; disable new deposits in that asset; force reduce-only for affected accounts

Circuit breaker events are logged on-chain and announced via the system-state WebSocket channel. Canonical USD market trading is unaffected by FX circuit breakers; only the virtual overlays are suspended.

Purpose

The funding rate is the periodic payment exchanged between long and short positions in a perpetual contract. Its purpose is to anchor the contract's mark price to the underlying index price. When perps trade above index, longs pay shorts; when perps trade below, shorts pay longs. There is no protocol skim. Funding is a closed system between traders.

Interval

Funding settles every 1 hour. At each funding interval, the funding payment is calculated from the prevailing funding rate and applied to every open position pro-rata to position size.

Formula

Origin uses the standard premium-plus-interest construction:

funding_rate = premium_index + clamp( interest_rate - premium_index, -0.05%, +0.05% )

Where:

premium_index = TWA( (mark_price - index_price) / index_price )       over the funding interval
interest_rate = small positive constant reflecting cost-of-carry      (default 0.01% per interval)

Cap

The funding rate is hard-capped per interval at ±4.00%. The cap is sized to allow funding to forcefully drive perps toward index during sustained dislocations while still bounding the worst-case payment any single position can incur in one settlement.

Settlement

At each interval, funding is calculated on each account's net position, debited from one side, and credited to the other, with all bookkeeping settled on-chain in the Margin Vault as part of the next batch. The funding payment flows directly to realized PnL and collateral (Section 6.4.1).

Worked Example

Suppose during a 1-hour interval:

  • Time-weighted average premium: +0.30%
  • Interest rate component: +0.01%
  • An account holds long 10 BTC-PERP at mark price $80,000 (notional $800,000).
premium_index   = +0.30%
interest_term   = clamp( 0.01% - 0.30%, -0.05%, +0.05% )
                = -0.05%       (clamped to lower bound)

funding_rate    = 0.30% + (-0.05%)
                = 0.25%

funding_payment = signed_size × mark_price × funding_rate
                = +10 × 80,000 × 0.0025
                = +2,000        (paid by long; received pro-rata by shorts)

The long account's realized_pnl_lifetime decreases by 2,000 and funding_paid_lifetime decreases by 2,000. Collateral balance decreases by 2,000.

If the same conditions persisted such that the raw rate exceeded 4.00%, it would be capped at exactly 4.00% for that interval.