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_pubkeyfor 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:
createVerifiedTransportbinds 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.