Skip to main content

Changelog

Notable changes to the Rocky Perpetual Contracts API and the Spot API. Newest first.

2026-09-24​

  • Fees on the wallet-funded spot segment: fills that settle on-chain are no longer zero-fee. The wallet-funded side now pays the standard spot fee (4 bps maker, 10 bps taker) in the asset it receives, reported in myTrades commission and withheld on chain from the leg Rocky's custody party sends. Fills where both sides are wallet-funded remain uncharged. See Fees.

2026-09-23​

  • RFQ Swap with Liquidity Providers — specification published (LP Protocol v1, draft): a second way to provide liquidity next to order-book market making. Traders request quotes, Rocky fans out to registered LPs, both sides lock their legs as Token Standard allocations with Rocky's operator party as executor, and one Allocation_ExecuteTransfer transaction settles all legs atomically. The section defines the LP Service API an LP hosts (/health, /rfq/quotes, /rfq/trades/{swapId}/accept-and-allocate, /result, /cancel; Ed25519-signed requests from Rocky), the Rocky endpoints for LPs (/v1/lp/*) and for wallet providers (/v1/swaps/rfq/*, prepare/execute or wallet-submitted allocations), the status machine, fees and timing, and settlement, failure handling and onboarding. Implementation is in progress; the contract is frozen for v1 unless a change is announced here.

2026-09-18​

  • Epoch commitments (ADR-005): every order event and every fill on the venue — house accounts included — is now written to an append-only journal in the same database transaction as the event and committed to Canton once per 60 s epoch as a RockyEpochCommitment contract (Merkle root over the journal plus the epoch's fill records; prev_root chain; never skipped). New public endpoints GET /v1/chain/status, /v1/chain/epochs, /v1/chain/epochs/{id} and /v1/chain/proof?seq=|ref_id= return inclusion proofs anyone can verify against the on-chain root. See Epoch Commitments.
  • Traffic transparency: GET /v1/traffic publishes the venue's measured Canton traffic per budget lane against the free base-rate allowance, and GET /v1/traffic/mm the one-word state Rocky's own market-making fleet follows; house fill volume is now budgeted (about 20,000 fills/day) rather than unbounded.
  • Net settlement: fills between the same two parties are batched per counterparty pair and settled as one atomic multi-leg DvP with per-asset net amounts (60 s window, adaptive up to 15 min while exposure is small; immediate at 500 fills or large exposure). All fills of a batch share one cantonUpdateId; a batch that nets to zero is confirmed without a ledger transaction. See On-chain Settlement.
  • Settlement path: the DvP settler now settles as two direct Token Standard transfers in one atomic transaction (rocky-clob-v8 0.6.0; 14 KB per DvP measured on mainnet, down from 32 KB), falling back to allocate-and-execute when a receiver lacks a direct preapproval; it picks the fewest input holdings per leg, runs a small pool of concurrent workers (SPOT_CHAIN_WORKERS, default 2) that never spend the same holding, and polls every 2 s in production.
  • Markets: ACC-USDCB delisted (open orders cancelled and refunded; history stays queryable). Active spot markets: CBTC-USX, CBTC-USDCB, CBTC-USDCX, CETH-USDCB, CETH-CBTC.

2026-09-02​

  • Spot WebSocket streams (Phase C): Binance-style market-data streams at wss://api.rocky.exchange/ws/<stream> and /stream?streams=… — <symbol>@depth5|depth10|depth20 (250 ms snapshots), <symbol>@trade, <symbol>@kline_1m, <symbol>@ticker (1 s). Stream names are lowercase and keep the symbol hyphen (cbtc-usdcb@trade). Governance: 32 streams per connection, 16 connections per IP (RATE_LIMIT_WS_CONNS_PER_IP, HTTP 429 at the upgrade), 20 s server ping, 60 s pong timeout, close code 1008 with a readable reason for bad stream lists. No subscribe/unsubscribe protocol, no user-data streams, no diff-depth. See WebSocket Streams, Partial Book Depth, Trade Streams, Kline and Ticker, Diff. Depth (not yet implemented).
  • Edge: nginx now proxies /ws/ and /stream with WebSocket upgrade headers and a 300 s read timeout; X-Real-IP is forwarded so the per-IP connection cap keys on the real client.
  • Docs: New Spot API section — overview, Basic Information (HMAC-SHA256 and Ed25519 signing with reference vectors, rate-limit tiers and weights, error codes, consolidated Binance differences), every /api/v3 endpoint, On-chain Settlement (DvP model, status machine, Canton verification by updateId, zero fees, minNotional, STP), Institutional Onboarding and the Integration Pack Template.

2026-08-31​

  • On-chain spot settlement (Phase A): every spot fill between customer accounts is now delivered as a two-leg atomic DvP on Canton by the spot-chain-settler worker (serial FIFO, retry with backoff, terminal failed/skipped audit rows), activated per venue by a settlement watermark. Accounts bound to a Canton party that complete MemberAuth become wallet-funded: ledger.spot_balances is maintained as a mirror of the wallet (30 s reconciliation with clamp, order cancellation, and freeze on shortfall); internal funding→spot transfers and custody withdrawals are disabled for that segment; the on-chain segment settles at zero fees; a per-symbol minNotional (USD-quoted markets: 10) is enforced at order entry with -1013; new gateway gates return -2010 Account is frozen… and -2012 Complete wallet enrollment (MemberAuth) before trading. Self-trade prevention (same-account resting orders are skipped by the matcher) is pinned by regression tests and disclosed. See On-chain Settlement.
  • Spot REST additions (Phase B): GET /api/v3/exchangeInfo (symbols, PRICE_FILTER / LOT_SIZE / NOTIONAL filters, enforced rateLimits), GET /api/v3/ping, GET /api/v3/time. GET /api/v3/myTrades gained settlementStatus (pending|processing|retry|confirmed|failed|skipped|internal) and cantonUpdateId. See Exchange Information, Account Trade List.
  • Rate limiting (Phase B): Binance-shaped fixed-window limiter on all /api/v3/* and /fapi/* routes — per-key request weight and 10 s / 1 m order counts by tier (standard 1200/50/200, ext-mm 2400/100/600, house 6000/200/1200), per-IP public weight 6000/min and pre-auth signed brake 24000/min, response headers X-MBX-USED-WEIGHT-1M, X-MBX-ORDER-COUNT-10S, X-MBX-ORDER-COUNT-1M, and 429 {"code":-1003} on rejection. No 418 escalation and no Retry-After. See Rate limits.
  • API keys (Phase B): new ED25519 key type — Rocky stores only the base64 public key and verifies a base64 Ed25519 signature over the same canonical payload as HMAC; mint_api_key --ed25519 --pubkey <b64>. rate_tier column on auth.api_keys (standard default; ext-mm for external market makers; house for Rocky's own fleet, which must be set explicitly before deploying the limiter). See Authentication.
  • FAPI: the perpetuals surface shares the same limiter, headers, error codes, and key types; existing HMAC keys are unaffected.

2026-07-01​

  • Backend: Multi-leverage support shipped — POST /fapi/v1/leverage implemented (per-user, per-symbol preference, 1–100x), POST /v1/orders's leverage field is now genuinely enforced up to 100x instead of silently capped to a system-wide 10x, and GET /fapi/v2/positionRisk / GET /v1/positions/* report the real per-position leverage. Margin math (ledger.orders_open.leverage, ledger.positions.leverage) now uses each order's actual chosen leverage for opens/adds/flips, and the position's own existing leverage (not a closing order's) for reduces/closes — see Change Initial Leverage, New Order, Place Order (Web v1).
  • Backend: Confirmed the market list was already BTC-PERP/ETH-PERP/CC-PERP only — no other symbols existed in ledger.markets, symbol_map, matching-engine, or oracle-poller.
  • Backend: Points and Referral accrual pipelines shipped (services/api-gateway/src/accrual.rs) — Trading Points and referral commissions are now computed from real fills (ledger.trades) every 5s, per the documented tier tables. GET /v1/referral/dashboard's total_referred_volume/active_referrals/pending_earnings/tier and POST /v1/referral/claim now reflect real data instead of hardcoded zeros. PnL/Holding/Staking Points and the season distribution engine remain not implemented — see Points Overview and Referral Overview for exact status.
  • Backend: ledger.trades gained an is_maker column (needed by the accrual pipeline to apply the correct maker/taker rate).
  • Backend: GET /fapi/v1/openInterest implemented (aggregates ledger.positions); see Open Interest.
  • Bot: Fixed a production incident where rocky-bot's taker loop was running ~60x too frequently with 10–200x oversized order quantities (a config.py default silently overrode TakerLoop's own correct defaults), overloading the matching-engine's NATS subscription and leaving BTC-PERP's orderbook desynced from the database for 6+ hours with zero fills. Also fixed flatten-positions.sh/funnel-auto-reset.sh being committed non-executable, which silently broke the periodic house-account inventory reset in production.
  • Docs: User Account API and CC Deposit Flow marked as describing a superseded mtc-exchange-era architecture (email/password auth, a BFF that no longer exists); the actual current wallet-based auth and deposit endpoints are documented alongside. MTC Mining Reward marked not implemented, with rationale. Bot docs (quantities, risk caps, symbol count) reconciled with the bot's actual, deliberately-scaled-up configuration.

2026-05-26​

  • Docs: Restructured the API reference to mirror the industry-standard USD-margined perpetual futures taxonomy. Every endpoint now has a page; gaps are marked Not yet implemented.
  • Backend: LEVERAGE_V1=10 constant landed in apply.rs, closing a long-running margin-leak class of bugs.

2026-05-25​

  • FAPI: Initial release. HMAC-SHA256 signing, X-MBX-APIKEY header, recvWindow up to 60 s. Order CRUD + openOrders + /fapi/v2/balance + /fapi/v2/positionRisk.
  • Market data: GET /v1/markets/{symbol}/{ticker,orderbook,recent-trades,candles,funding-rate} + GET /fapi/v1/{exchangeInfo,ticker/price}.

2026-05-22​

  • Web v1: Trade History endpoints (/v1/{positions,orders,trades,fees,funding}/me).
  • Web v1: POST /v1/orders, DELETE /v1/orders/{order_id} for browser-side order placement.

2026-05-19​

  • Web v1: CC withdrawal flow (POST /v1/withdrawals, GET /v1/withdrawals/{wid}).
  • Dev tools: POST /v1/deposits/seed, POST /v1/funding/tick (devnet-only).