What this page answers
Use this page when you need the fastest factual answer to:- which DerivaDEX market surfaces are publicly documented right now
- which market and account constraints affect trading correctness first
- whether a workflow belongs to the public REST/realtime families or to a restricted/product-specific surface
Use this page before
| Before you… | Check this page because… |
|---|---|
| assume a symbol or product is supported everywhere | deployment and docs scope can differ from repo-backed baselines |
| design a strategy or client around one limit assumption | several public constraint families apply before matching or settlement |
| assume an HTTP or WebSocket surface is public | visibility is family-specific and not every adjacent artifact is a public contract |
Constraint map
| Need | Canonical route |
|---|---|
| Supported perpetual products, tick sizes, and minimum order sizes | Product and Trading Specifications |
| Margin thresholds, liquidation trigger math, and solvency rules | Margin Requirements |
| Funding behavior and mark-price inputs | Funding Rate Logic, Price Feeds and Mark Price Inputs |
| Request-rate tiers, DDX thresholds, and collateral tranches | Rate Limits and Access Tiers |
| Public versus restricted API-family visibility | API Reference, Operator & Restricted APIs, Copy Trading APIs |
Current public baseline
| Surface | Current public baseline |
|---|---|
| Product model | Perpetual swaps on a central-limit-order-book market |
| Public repo-backed symbols | ETHP, BTCP, SPCXP; test-only market specs may also exist in repo-backed development surfaces |
| Core trade constraints | Tick size, minimum order size, max order notional, price-deviation checks, and strategy-level open-order caps |
| Margin model | Cross-margin at strategy level with liquidation and ADL safeguards |
| API visibility | Public REST and realtime families are the primary public integration paths; restricted or product-specific families remain boundary-scoped |
Source precedence
| Source class | Public reading |
|---|---|
| operator core market/spec constants | production-style baseline for the current published market and constraint contract |
| current public reference pages | canonical public explanation of those baseline values and caveats |
| dev-utils and test scaffolding constants | development context only unless a public page explicitly promotes them into the baseline |
First questions to settle
| Question | Public answer path |
|---|---|
| is the market family in scope at all | Product and Trading Specifications |
| can the order be accepted before matching | Product and Trading Specifications plus Trading Safeties and Guards |
| can the position remain solvent | Margin Requirements |
| which price and cadence matter for execution and carry | Funding Rate Logic and Price Feeds and Mark Price Inputs |
| does the workflow belong to a public integration family | API Reference |
Constraint families that matter first
| Constraint family | What it governs first | Public answer today |
|---|---|---|
| Product availability | Whether a symbol and product model are even in scope | Public docs currently describe perpetual-swap products and point to repo-backed market-spec baselines rather than promising a timeless deployed symbol list |
| Order-shape validity | Whether a request can be accepted before matching | Tick size, minimum order size, order-type compatibility, notional caps, and open-order caps are first-class public constraints |
| Solvency and liquidation | Whether a position can stay open safely | Public docs expose cross-margin, liquidation trigger framing, ADL, and solvency safeguards through the reference layer |
| Pricing and funding | Which prices and cadence drive execution and carry | Public docs expose mark-price inputs, funding logic, and checkpoint/settlement posture at launch-reference level |
| API access posture | Which integration surface is intentionally public | Public REST and realtime are the active public integration families; operator and copy-trading remain visibility-bounded summary surfaces |
Public visibility matrix
| Surface | Public docs posture | What not to assume |
|---|---|---|
| Trading UI and public market data | Publicly documented | Do not assume every deployment exposes every market or operational mode identically |
| Public REST | Public family with generated reference plus authored support pages | Do not assume all private or operator-like workflows belong here just because they use HTTP |
| Public realtime | Public family with AsyncAPI-backed channel reference and authored support pages | Do not assume old token-auth narratives override the current published contract |
| Operator and compliance-oriented APIs | Boundary-summary only in public docs | Do not assume a public generated contract exists for every restricted surface |
| Copy-trading APIs | Product-specific boundary-summary only in public docs | Do not assume copy-trading contracts are interchangeable with the core exchange API |
Feature-gated and non-baseline families
Feature-gated or development-oriented product families can exist in repo sources without being part of the current public baseline. Treat the published baseline here as “currently public and in scope,” not as a timeless statement about every possible future or gated product family.Deployment rule
Treat the table above as the current public baseline, not a guarantee that every deployment exposes the same live products, quotas, or restricted-surface posture. Check the linked reference pages before assuming one market, address, or access model is universal.Reading order
If you are checking platform relevance or trading constraints, read in this order:- Product and Trading Specifications
- Margin Requirements
- Trading Safeties and Guards
- API Reference if your workflow is programmatic