CEDEX API Changelog
CEDEX API Changelog
Version History · Breaking Changes · Deprecations · Migration Guides · Module-Aware
Versioned record of all changes to the CEDEX REST API and WebSocket API. The CEDEX API serves all three production modules: Equities (Module 1), Real Estate (Module 2), and CORECM — Carbon Ore, Rare Earth, and Critical Minerals (Module 3). Module-aware endpoints, WebSocket channels, and pre-flight failure reasons are tracked in the version history alongside cross-module changes.
This changelog is maintained separately from the protocol-level Changelog (which tracks smart-contract and platform changes). Integrators should subscribe to the CEDEX API status page (status.cedex.market) and monitor this page for upcoming changes.
Table of Contents
Versioning Policy
Current Version
Changelog
Deprecation Policy
Migration Guides
Upcoming Changes
SDK Compatibility Matrix
1. Versioning Policy
Semantic Versioning
The CEDEX API follows semantic versioning (MAJOR.MINOR.PATCH):
MAJOR (v1 → v2)
Breaking changes that require code modifications
Must update integration before deprecation deadline
MINOR (v1.0 → v1.1)
New endpoints, new fields, new features — backward compatible
No action required — existing integrations continue working
PATCH (v1.0.0 → v1.0.1)
Bug fixes, documentation corrections, performance improvements
No action required
Module-Aware Versioning
Module-specific endpoints, fields, and WebSocket channels follow the same versioning policy as cross-module surface. A new module-specific endpoint (for example, a future Module 4 oracle endpoint) is a MINOR change. A breaking change to a module-specific endpoint (for example, restructuring the NAV oracle response) is a MAJOR change. The platform does not maintain separate version trees per module — there is one CEDEX API version that covers all three modules uniformly.
Base URLs
Mainnet
https://api.cedex.market/v1
wss://api.cedex.market/ws/v1
Devnet
https://api.devnet.cedex.market/v1
wss://api.devnet.cedex.market/ws/v1
When a new MAJOR version is released, the old version remains available at its existing URL for the deprecation period (minimum 6 months). Both versions run simultaneously during the transition.
Change Notification
This changelog page
All changes
Published at release
status.cedex.market
Breaking changes, deprecations
30 days before
Developer mailing list
Breaking changes
60 days before
API response headers
Deprecation warnings
At release — X-CEDEX-Deprecation header
2. Current Version
Current version
v1.0.0
Release date
Q3 2026 (mainnet launch)
Status
Active — current
Base URL
https://api.cedex.market/v1
SDK version
@rwatokens/sdk v1.0.x
Module support
Module 1 (Equities), Module 2 (Real Estate), Module 3 (CORECM)
3. Changelog
v1.0.0 — Initial Release (Q3 2026)
Release type: MAJOR — Initial public API release. Status: Current.
The initial CEDEX API release supporting all ST22 Digital Securities trading operations, portfolio management, oracle monitoring, and WebSocket real-time data across all three modules at launch.
REST API — Public Endpoints (No Authentication)
GET
/v1/markets
List all active ST22 trading pairs with 24h stats. Supports ?module= filter.
All modules
GET
/v1/markets/{mint}
Detailed market data for a single ST22 token. Returns module-specific fields.
All modules
GET
/v1/markets/{mint}/orderbook
Current order book depth
All modules
GET
/v1/markets/{mint}/trades
Recent trade history (paginated, default 50, max 200)
All modules
GET
/v1/markets/{mint}/ohlcv
OHLCV candlestick data (1m, 5m, 15m, 1h, 4h, 1d, 1w)
All modules
GET
/v1/oracle/{mint}/custody
Real-time custody attestation (custodied balance, supply, ratio, Ed25519 status)
All modules
GET
/v1/oracle/{mint}/nav
NAV oracle response — appraised NAV, deviation, reappraisal target
Module 2 only
GET
/v1/oracle/{mint}/classification
Classification oracle — USGS / DOE status, federal-action status
Module 3 only
GET
/v1/oracle/ofac/status
OFAC SDN oracle freshness and entry count
All modules
GET
/v1/oracle/aml/{wallet}
AML risk score (cached, public subset)
All modules
GET
/v1/health
System health — oracle status (custody, OFAC, AML, TWAP, EDGAR, NAV, Classification), RPC latency, circuit-breaker state
All modules
REST API — Authenticated Endpoints (Wallet Signature)
POST
/v1/auth/challenge
Request authentication challenge for wallet signature
POST
/v1/auth/verify
Submit signed challenge — returns bearer token (24h TTL); response includes eligibility field
POST
/v1/orders
Place market or limit order (requires Empire verification)
GET
/v1/orders
List orders for the authenticated wallet (filter by status, mint, side)
DELETE
/v1/orders/{orderId}
Cancel an open limit order
GET
/v1/portfolio
Investor portfolio — balances, holding periods (with regime field), unlock dates
POST
/v1/estimate
Pre-flight swap estimate — expected output, price impact, compliance check, module-aware failure reasons
WebSocket API
orderbook
Order book updates (bids/asks)
All modules
trades
Real-time trade stream for a specific ST22 token
All modules
custody
Real-time Empire custody attestation updates per Solana block
All modules
circuit_breaker
Circuit-breaker activation and deactivation events (8 breaker types)
All modules
nav
Real-time NAV oracle updates and deviation tracking
Module 2 only
classification
Routine Classification updates plus federal_action_detected and federal_action_freeze_applied event types
Module 3 only
orders (private)
Real-time updates for the authenticated wallet's orders
All modules
Authentication
Method
Wallet signature (Ed25519)
Flow
POST /auth/challenge → sign with wallet → POST /auth/verify → bearer token
Token TTL
24 hours
Header
Authorization: Bearer <token>
Empire requirement
All authenticated endpoints require Empire Stock Transfer KYC, KYB, AML, OFAC, and KYW verification
Eligibility field
RegD, RegS, RegCF, or comma-separated combination
Pre-Flight Compliance
The pre-flight pipeline at v1.0.0 covers eight steps:
1
Custody verification (CV-01 to CV-06)
All modules
2
OFAC screening (SC-30 to SC-34)
All modules
3
AML risk scoring (IV-09)
All modules
4
KYC and eligibility (IV-07, IV-08)
All modules
5
Holding period (HP-24) — Reg D 6mo / Reg S 12mo / Reg CF 12mo
All modules
6
Price impact (CB-21)
All modules
7
NAV deviation (CB-21 extension)
Module 2 only
8
Classification freshness and federal-action freeze (CV-04, REG-42)
Module 3 only
Pre-Flight Failure Reasons
HOLDING_PERIOD_LOCKED
HP-24
All modules
WALLET_LIMIT_EXCEEDED
PL-16
All modules
PRICE_IMPACT_EXCEEDED
CB-21
All modules
OFAC_MATCH
SC-30 to SC-34
All modules
AML_HIGH_RISK
IV-09
All modules
CUSTODY_DISCREPANCY
CV-01 to CV-06
All modules
NAV_DEVIATION_EXCEEDED
CB-21 (extension)
Module 2
NAV_STALE
CB-21 (extension)
Module 2
CLASSIFICATION_STALE
CV-04 (extension)
Module 3
FEDERAL_ACTION_FROZEN
REG-42
Module 3
Rate Limits
Public (unauthenticated)
60
N/A
2
Standard (authenticated, Empire verified)
120
30
5
Verified (Empire KYC complete)
600
120
10
Institutional (by arrangement)
Custom
Custom
Custom
Error Response Format
All errors return the same envelope:
Response Headers
X-CEDEX-Version
API version serving the response (e.g., 1.0.0)
X-RateLimit-Remaining
Remaining requests in current window
X-RateLimit-Reset
Unix timestamp when rate limit resets
X-CEDEX-Deprecation
Present only if endpoint is deprecated — contains sunset date
Idempotency
POST /v1/orders accepts an idempotency_key field (max 128 characters). Duplicate requests with the same key and same parameters return the original order without creating a duplicate. Same key with different parameters returns 409 IDEMPOTENCY_CONFLICT. Keys expire after 24 hours.
v1.1.0 — Planned (Q4 2026)
Release type: MINOR — Backward-compatible additions. Status: Planned.
GET /v1/markets/{mint}/stats
New endpoint
Extended market statistics — 7d / 30d volume, unique traders, fee revenue. Module-specific breakdowns surfaced on Module 2 (NAV history) and Module 3 (classification refresh history).
GET /v1/governance/history
New endpoint
On-chain governance action history (parameter changes, upgrades)
GET /v1/governance/pending
New endpoint
Currently-timelocked governance proposals
GET /v1/pool/stats
New endpoint
Global Pool TVL, cumulative fees, reserve ratios — aggregate across all modules
GET /v1/staking/summary
New endpoint
Staking pool stats — total staked, current APY, epoch countdown
trades channel — fee_breakdown field
New field
Per-recipient fee breakdown on trade events
portfolio channel — holding_period_pct field
New field
Percentage completion of holding period — works across Reg D, Reg S, and Reg CF regimes
nav channel — appraisal_history snapshot
New message type
Optional historical NAV snapshot on subscribe (Module 2 only)
classification channel — monitored_sources_summary
New field
Roll-up summary of all monitored federal sources for the affected basin asset (Module 3 only)
All v1.0.0 endpoints and fields remain unchanged. No migration required.
v1.2.0 — Planned (Q1 2027)
Release type: MINOR — Backward-compatible additions. Status: Planned.
GET /v1/oracle/{mint}/custody/history
New endpoint
Historical custody attestation records (paginated, all modules)
GET /v1/oracle/{mint}/nav/history
New endpoint
Historical NAV appraisals with deviation tracking (Module 2 only)
GET /v1/oracle/{mint}/classification/history
New endpoint
Historical Classification status changes and federal-action events (Module 3 only)
GET /v1/oracle/aml/{wallet}/tier
New endpoint
AML risk tier (Low / Medium / High) — abstracts the raw score for less-sensitive consumption
POST /v1/orders/batch
New endpoint
Submit up to 10 orders in a single request, with atomic-or-best-effort semantics
alerts WebSocket channel
New channel
Subscribe to circuit-breaker events, oracle staleness warnings, Control 42 freezes, and Module 3 federal-action detections across the entire wallet's holdings
Pagination cursor
Enhancement
All paginated endpoints support cursor-based pagination (in addition to offset)
All v1.0.x and v1.1.x endpoints and fields remain unchanged.
v2.0.0 — Future (TBD)
Release type: MAJOR — Breaking changes. Status: Not scheduled.
Potential breaking changes under consideration for a future v2 release. These are not committed and may change based on integrator feedback.
Authentication migration from wallet signature to OAuth 2.0 + wallet
Institutional integrators prefer OAuth flows for server-to-server
Response envelope standardization
Wrap all responses in { data: ..., meta: ... } envelope
Decimal representation change (number → string)
Prevent floating-point precision loss for large amounts
WebSocket protocol upgrade (JSON → Protobuf option)
Bandwidth reduction for high-frequency institutional feeds
Module-aware namespacing
Optional /v2/equities/... and /v2/real-estate/... and /v2/corecm/... namespaces in addition to mint-keyed endpoints, for integrators who want to scope clients to a single module
When v2.0.0 is scheduled, this section will be replaced with a concrete migration guide and a minimum 6-month deprecation timeline for v1.
4. Deprecation Policy
Timeline
Active
Current version
Full support, bug fixes, new features
Deprecated
6 months minimum
Still operational. X-CEDEX-Deprecation header added. No new features. Bug fixes only.
Sunset
End of deprecation period
Endpoints return 410 Gone. Integrators must have migrated.
Deprecation Signals
When an endpoint or field is deprecated, three signals are emitted:
Individual Endpoint Deprecation
Individual endpoints within a MAJOR version can be deprecated independently. For example, if /v1/markets/{mint}/orderbook is replaced by a more efficient endpoint, the old endpoint enters the deprecation lifecycle while the rest of v1 remains active.
Module-Specific Deprecation
A module-specific endpoint (NAV oracle, Classification oracle) can be deprecated and replaced independently of cross-module endpoints. For example, the Module 2 NAV oracle endpoint structure could evolve to support multi-asset NAV (multiple properties under a single mint) in a future version. The original NAV endpoint would enter deprecation while the cross-module surface remains untouched.
No Silent Deprecation
The platform will never remove an endpoint, change a response format, or alter behavior without advance notice through the channels listed above. If you see X-CEDEX-Deprecation in any response header, check this changelog for migration instructions.
5. Migration Guides
Migrating from Devnet to Mainnet
No code changes required — only configuration:
API base URLs:
Devnet:
https://api.devnet.cedex.market/v1Mainnet:
https://api.cedex.market/v1
Request and response formats are identical across environments. Devnet uses simulated oracle data and test tokens. Module-aware endpoints are available on both environments — the same /v1/oracle/{mint}/nav and /v1/oracle/{mint}/classification endpoints work for devnet test mints with simulated NAV and Classification data.
Migrating Between Modules
The CEDEX API is designed so that integrators do not need to change SDK calls when handling mints from different modules. The same client.cedex.placeOrder(), client.cedex.estimateSwap(), and client.cedex.cancelOrder() methods work for any ST22 mint regardless of module. Module-specific behavior is surfaced through module-specific oracle endpoints (getNAVOracle(), getClassificationOracle()) and module-specific WebSocket channel subscriptions.
The recommended pattern for module-aware applications:
Read the
modulefield onGET /v1/markets/{mint}to determine the mint's module.For Module 2 mints, additionally subscribe to the
navWebSocket channel and surface NAV deviation in the UI.For Module 3 mints, additionally subscribe to the
classificationWebSocket channel and surface federal-action status in the UI.Handle the additional pre-flight failure reasons (
NAV_DEVIATION_EXCEEDED,CLASSIFICATION_STALE,FEDERAL_ACTION_FROZEN) in error-handling code paths.
Future: Migrating from v1 to v2
This section will be populated when v2 is scheduled. It will include:
Complete mapping of v1 endpoints to v2 equivalents.
Request and response format changes with before/after examples.
Authentication migration steps.
SDK upgrade instructions.
Timeline with deprecation and sunset dates.
Module-specific migration steps where applicable.
6. Upcoming Changes
Under Consideration (Not Committed)
These are features and changes being evaluated based on integrator feedback. Nothing in this section is guaranteed to ship.
GraphQL API
Evaluating
Alternative query interface for complex portfolio and market data queries; particularly useful for module-aware UIs that need to compose data across multiple oracles
Webhook notifications
Evaluating
Server-to-server push notifications for trade fills, holding-period unlock, circuit-breaker events, NAV-deviation triggers (Module 2), and federal-action events (Module 3)
FIX protocol gateway
Early research
FIX 4.4 / 5.0 interface for institutional trading desks
Historical data API
Planned (v1.2)
Paginated historical trades, OHLCV, custody attestations, NAV appraisals (Module 2), and classification history (Module 3)
Multi-mint batch operations
Planned (v1.2)
Batch order submission and portfolio queries across multiple ST22 tokens regardless of module
Module 4 onboarding hooks
Future research
Generic oracle-extension framework for future asset classes beyond Equities, Real Estate, and CORECM
How to Request Features
Submit feature requests through the platform's developer GitHub issue tracker or via developers@rwatokens.net. Include your use case, expected request/response format, and volume expectations.
7. SDK Compatibility Matrix
@rwatokens/sdk 1.0.x
v1.0.0
20 LTS
All three modules
Current — active support
@rwatokens/sdk 1.1.x
v1.0.0 + v1.1.0
20 LTS, 22 LTS
All three modules
Planned (Q4 2026)
@rwatokens/sdk 1.2.x
v1.0.0 + v1.1.0 + v1.2.0
20 LTS, 22 LTS
All three modules
Planned (Q1 2027)
@rwatokens/sdk 2.0.x
v2.0.0
TBD
All three modules
Future (when v2 API ships)
SDK Update Policy
Patch (1.0.0 → 1.0.1)
Bug fixes only
Recommended but not required
Minor (1.0.x → 1.1.0)
New methods added
Not required — existing code works
Major (1.x → 2.0)
Breaking changes
Required — update before v1 sunset
Checking Your SDK Version
Checking the API Version at Runtime
Module-Aware SDK Usage
The SDK exposes module-specific helpers without requiring integrators to instantiate per-module clients:
Related Documentation
CEDEX API Reference — Complete endpoint documentation with request/response schemas, code examples, and module-aware API surface.
SDK Reference —
RwaTokensClientmethods, error handling, WebSocket patterns.Changelog — Protocol-level version history (smart contracts, platform changes).
Network Configuration — RPC endpoints, program IDs, environment variables, oracle PDAs.
Smart Contract Reference — On-chain program documentation (Transfer Hook, AMM, Oracle Aggregator, Liquidity Pool, Governance).
Oracle Integration Guide — Custody, OFAC, AML, TWAP, EDGAR, NAV, and Classification relay architecture.
RWA Tokens · CEDEX API Changelog · v1.0.0 · Q3 2026
Last updated
Was this helpful?