Skip to main content

TypeScript Client

TL;DRA reference client that ties the pieces together: get a bearer token, read markets and server time, use the SDK’s order builders to assemble a signed order from a deposited note, submit it, and subscribe to the order and fill streams. The Node client first creates one quote-verified RA-TLS transport and injects its HTTP and WebSocket adapters everywhere. The SDK owns the cryptography (note commitments, the input proof, viewing-key derivation, and canonical signing) so your code works in economic terms.

What the SDK does for you

The hard part of a Darknyx order is its cryptographic backing: the collateral-note commitment, the zero-knowledge input proof, the owner-commitment opening, the signed viewing key, and the current boot session (see Place Order). The SDK derives all of it from your seed and a spendable note, and signs the canonical body with your trading key. You supply the intent (side, amount, price, time-in-force) and get back a ready-to-send order. The SDK also ships:
  • Order builders: presets for market, all-or-none, and good-til-time orders over the native fields. They include the viewing_pubkey for on-chain trade/change recovery by default, so exact and partial output notes stay recoverable without extra work.
  • Stream clients: per-account order-lifecycle and fill subscriptions, with the fill-memo verification built in.
  • Recovery helpers: generate and securely store a CSPRNG master seed, export or import its authenticated versioned backup with exportEncryptedMasterSeed / importEncryptedMasterSeed, recover fill outputs (recoverFillFromChain), or rebuild deposits, fills, continuations, and merges from seed + chain (recoverNotesFromChain). Wallet-message signatures are not used as spend authority.
  • System helpers: server time (for slot-based expiry) and the degraded-mode status.
  • Node transport: createVerifiedTransport binds the certificate on the live HTTP/WebSocket connection to a fresh enclave quote, approved compose hash, boot session, and finalized signer-set pin.

Client implementation

Building an order with the SDK builders

The builders set the execution-policy fields (type, price limit, fill size, expiry) for a common intent. You merge a policy with the collateral the SDK derives from a deposited note.
Already hold a proof?If you already have a VALID_INPUT proof (e.g. relayed from elsewhere), skip the prover and call buildOrder({ …, validInput: { proofBytes, merkleRoot } }) directly. proveAndBuildOrder is just the fetch-prove-build convenience on top.

Streaming order and fill events

Submitting over the trading socket

For a high-frequency client, submit orders over the shared /v1/stream session instead of REST, using one warm connection plus cancel-on-disconnect. The TradingClient correlates each reply to its request and resolves a promise per call:

Usage

One verified transport, everywhereEvery helper that can reach the venue requires an injected fetchImpl, and every stream constructor accepts the verified webSocketFactory. Always pass the pair from the same createVerifiedTransport result. Falling back to global fetch, a stock WebSocket, or an accept-any-certificate switch bypasses the property even if another call successfully verified an attestation quote. The reference daemon is the complete pin-loading and DCAP-verifier integration.