Skip to main content

Programmatic Access

TL;DRDarknyx exposes a REST + WebSocket API from the confidential-VM deployment. Authentication is two layers: an account bearer token (who is allowed to talk to the venue) plus a per-order trading-key signature (who cryptographically owns the order). Market and health reads are public; private state and order management are authenticated. The Node SDK and daemon first verify the enclave’s boot-scoped RA-TLS certificate on the connection they will use; only then do they disclose credentials or order intent.

The authentication model

Two independent layers gate the API. They answer different questions and you need both to trade. The separation is deliberate. One account may operate many trading keys (sub- portfolios, a market-maker fleet), and the trading key, not the account, is the cryptographic identity that authorizes settlement. The bearer token only enables operational controls; it cannot, by itself, move or cancel another key’s orders. See Authentication for the full credential model and Place Order for how the order signature is constructed.

Available APIs

REST is simplest to start with. A long-running trading client should use one warm, in-band-authenticated /v1/stream connection for order operations and subscribe to lifecycle and fill events. Sequence numbers let it detect gaps and reconcile after reconnecting.

Endpoint map

REST

WebSocket

Open /v1/stream without query credentials and authenticate with an op: login frame within 10 seconds. The SDK multiplexes all channels and order operations on that session, refreshes tokens in-band, and reconnects/resubscribes when the connection drops.

Quick start

The verifier dependency and pin-loading setup is deployment-specific; the reference daemon is the complete integration example. Raw curl is useful for public diagnostics only after an operator has independently verified the endpoint. Do not use curl -k or disable Node TLS verification for credentials or orders: accepting an arbitrary self-signed certificate removes the RA-TLS guarantee.
Use the SDKA raw place-order body is large: it includes a note commitment, a 256-byte zero-knowledge input proof, the note opening needed for intake validation, a contributory viewing key, and the current boot session, all of which the TypeScript SDK signs for you from your keys and a deposited note. Hand-building the body is possible (the wire contract is documented), but the SDK is the intended path. See SDK → TypeScript Client.

Rate limits

Credential verification and authenticated order management have separate, per-account limits. Cache bearer tokens for their lifetime, back off on 429 (order-operation responses include Retry-After; authentication errors include an approximate delay in the message), and prefer the shared /v1/stream session for high-frequency order management. Authentication can also return a short-lived 503 when expensive credential verification is at capacity. See System Status for how the venue signals degradation.