Skip to main content
Each market is one contract with its own specification: what it tracks, how prices and sizes are quantized, what leverage it permits, and how its risk parameters scale with position size. Every parameter is on-chain and readable. Nothing about a market’s behavior lives in a configuration file somewhere — the values the engine applies are the values you can query.

The contract specification

Two specifications worth checking before trading a market you have not traded before: the leverage tier table, because it determines your liquidation distance as the position grows, and the funding interval and caps, because they determine the cost of holding.

Asset classes

The kernel does not distinguish underlyings. A perpetual on a crypto asset, a tokenized equity, an index, or a commodity is the same object to the matching, margin, funding, and liquidation pipeline. The only requirement is a defined index source and a listed specification. That makes the asset surface a listing question rather than an architecture question:
  • Crypto perpetuals. USDC-margined contracts on majors, mid-caps, and long-tail assets, plus pre-market contracts for newly launched tokens.
  • Perpetuals on tokenized real-world assets. Contracts referencing tokenized equities, indices, and commodities. Same execution model; they differ in index composition, trading-calendar behavior, and risk parameters.
RWA perpetuals introduce two mechanics crypto perpetuals do not have: reference venues that close, and index sources whose update cadence differs from block cadence. Gap handling, funding treatment across closed sessions, and index continuity are part of each contract specification and are documented per listing.

Pre-market contracts

A pre-market contract trades an asset before it has a liquid spot market — a token before listing, or an equity before its offering. These carry materially different risk. The index price has fewer sources and thinner ones, which means it is easier to move and more prone to gapping. Specifications reflect that: lower leverage, wider funding caps, and tighter position limits than an established market.

Reading market data

Everything above is queryable. The list of markets, each specification, and current state — order book depth, mark and index prices, funding rates, and open interest — are available over REST and WebSocket. See Developers. Two habits worth building into any integration: Read specifications rather than hard-coding them. Tick sizes, leverage tiers, and funding caps change, and a client holding a stale copy will submit orders the network rejects — or size positions against limits that no longer apply. Handle new markets appearing. Listings are protocol operations. A client that enumerates markets at startup and never again will silently miss everything listed after.

Listings and changes

Listing a market, delisting one, and changing risk parameters are system operations executed in the protocol under governance, at the top of block priority. Because they are on-chain, a parameter change is observable at a specific block rather than announced and applied opaquely. Announcements and notice periods for changes that affect open positions are published under Programs.

Where to go next

Precision

Tick size, lot size, and the rounding rules behind them.

Leverage

How tier tables set maximum leverage and maintenance margin.

Index price

How a market’s index is built from its sources.

Position limits

Per-market concentration caps.