Integration Pack Template
Status: Implemented. This is the template Rocky fills in for each institutional participant. Bracketed values are completed by Rocky operations for your firm; everything else applies as written.
1. Environments
| Sandbox | Production | |
|---|---|---|
| REST base URL | https://[sandbox-api-host] | https://api.rocky.exchange |
| WebSocket base URL | wss://[sandbox-api-host] | wss://api.rocky.exchange |
| Canton network | test network ([sandbox synchronizer id]) | Canton mainnet |
Explorer for cantonUpdateId | [sandbox scan URL] | [production scan URL] |
| Rocky custody party (counterparty for fills against house liquidity) | [sandbox custody party] | [production custody party] |
| Your bound party | [your sandbox party] | [your production party] |
| Your API key id | [sandbox key] | [production key] |
| Key type | ED25519 (default) / HMAC | ED25519 (default) / HMAC |
| Rate tier | ext-mm | ext-mm |
| Registered egress IPs (monitoring only; not exempt from IP buckets) | [list] | [list] |
Paths are identical in both environments: /api/v3/* for REST, /ws/<stream> and /stream?streams=… for WebSocket. See Basic Information and WebSocket Streams.
Request conventions that differ from Binance and matter on day one: all parameters — for GET, POST, and DELETE — go in the query string with signature last; symbols are CBTC-USDCB style; stream names keep the hyphen (cbtc-usdcb@trade); orderId and trade id are UUID strings. Full list: Differences from Binance.
2. Key registration
- Generate an Ed25519 keypair (see Institutional Onboarding §3).
- Send the base64 public key to
[secure channel]. - Read the SHA-256 fingerprint of the public key back to Rocky over
[second channel]; Rocky reads it back to you. - Rocky registers the key and replies with the API key id and the environment it is valid in. Sandbox and production keys are distinct.
- Validate with the reference vector, then with a signed
GET /api/v3/account.
Rotation and revocation: request via [secure channel]; revocation is immediate, rotation is scheduled to a time you name. Never send a private key or seed to Rocky; Rocky will never ask for one.
3. Rate limits for your tier
| Bucket | ext-mm ceiling | Header |
|---|---|---|
| Request weight | 2400 / minute | X-MBX-USED-WEIGHT-1M |
| Orders | 100 / 10 seconds | X-MBX-ORDER-COUNT-10S |
| Orders | 600 / minute | X-MBX-ORDER-COUNT-1M |
| Public market data (per IP) | 6000 weight / minute | X-MBX-USED-WEIGHT-1M |
| Signed pre-auth brake (per IP) | 24000 weight / minute | — |
| WebSocket connections (per IP) | 16 concurrent | — |
Weights: exchangeInfo / allOrders / myTrades = 10; depth / klines / trades / ticker/24hr = 5; everything else = 1. Cancels are not counted as orders. Over the limit: 429 {"code":-1003}; there is no 418 and no Retry-After — back off to the next fixed window. Details: Rate limits. Higher ceilings can be agreed if your measured usage requires it.
4. Support and incident reporting
| Integration support channel | [shared channel / mailbox] |
| Incident escalation (24×7 for settlement and trading outages) | [phone / pager address] |
| Rocky operations contact | [name, role] |
| Your technical contact(s) | [name, role] |
| Your commercial contact | [name, role] |
Incident report format — send one message per incident to the support channel with these fields; it lets Rocky correlate against gateway and settlement logs immediately:
Subject: [SEV1|SEV2|SEV3] <one-line summary>
Environment: sandbox | production
Detected at: <UTC timestamp>
API key id: <id> (never the secret or seed)
Party: <party id>
Endpoint/stream: <e.g. POST /api/v3/order, cbtc-usdcb@depth5>
Symbols: <list>
Symptom: <HTTP status + {code,msg} body, close code + reason, or observed behaviour>
Identifiers: <orderId(s), trade id(s), cantonUpdateId(s)>
Sample request: <method, path, query with signature redacted>
Frequency: <once | intermittent (rate) | continuous since <time>>
Impact: <e.g. cannot cancel quotes; fills stuck pending > 10 min>
Your actions: <what you have already tried>
Severity guide: SEV1 — cannot cancel or place orders, or settlements failed/stuck beyond 10 minutes with open exposure; SEV2 — degraded (elevated latency, intermittent 429/500, stream gaps); SEV3 — questions, documentation, non-urgent discrepancies.
For a settlement discrepancy, always include the cantonUpdateId and the trade id; Rocky reconciles from the ledger, not from the API response.
5. Service level and maintenance
- Availability is provided on a best-effort basis; there is no contractual uptime guarantee for the sandbox or production API at this stage. Rocky operates monitoring on settlement failures, mirror drift, and stuck settlements, and responds to SEV1 incidents around the clock.
- Planned maintenance (gateway, matching engine, or settlement deployments) is announced on
[maintenance notice channel]at least[notice period]in advance, with the expected impact (for example "WebSocket reconnects", "order entry paused for N minutes"). Cancel-only periods are announced the same way. - Unplanned incidents and their resolution are posted on the same channel; a post-incident summary follows for SEV1.
- Settlement is asynchronous and optimistic; the applicable risk disclosure is in On-chain Settlement. Credit terms governing exposure between fill and delivery are in the separately signed agreement.
6. Reference
- Spot API Overview
- Basic Information — signing, rate limits, error codes, Binance differences
- On-chain Settlement — verifying
cantonUpdateId - Institutional Onboarding — party binding, MemberAuth, preapproval, go-live checklist