Overview
TL;DRDarknyx is a privacy-preserving spot darkpool on Solana. Hidden orders match
inside an attested Intel TDX Confidential VM (a “CVM”); custody and proven value
movement remain on-chain. Solana sees deposits, withdrawals, commitments, and
proofs, but never the order book or a settled trade’s plaintext price and size.
What Darknyx is
Darknyx is a dark pool: an order book where resting orders are not public. Side, size, and limit price never appear in a Solana transaction, a log, or an account. On the supported programmatic path they travel over an attestation-bound TLS connection that terminates inside the hardware-isolated matching engine, whose exact compiled code and boot-scoped certificate are remotely verifiable. The dstack gateway passes that TLS stream through without learning the plaintext. See Transport & Attestation for the complete verification boundary. Unlike an off-chain matching desk, Darknyx does not give one ordinary operator both custody and readable order flow:- Custody is on-chain. Funds sit in a Solana program. Withdrawals, merges, and matched transfers must satisfy the corresponding proof and replay guards.
- Matching is in an attested enclave. The operator runs the machine but cannot read enclave memory, and the enclave’s signing keys are bound to one specific measured image. Swap the code and the keys no longer derive, and clients detect it at attestation time.
What “private” means here
Darknyx enforces three distinct privacy properties, each by a separate mechanism.
Deposits reveal the funding signer, mint, and gross amount; withdrawals reveal
the destination, mint, and amount. VALID_DEPOSIT prevents the funding transaction
from publishing the wallet-wide note owner, so that public boundary does not by
itself label the rest of the wallet’s notes.
The three layers
Darknyx is three layers that compose into one trust chain.- Custody (Solana). A single program owns custody: the incremental Merkle tree of note commitments, the shared consumed-note set that prevents double-spends, the Groth16 verifier, and the atomic batched-settlement path.
- Matching (the CVM). The engine accepts orders over an authenticated HTTPS/WebSocket surface, enforces limits and an oracle circuit-breaker policy, routes each signed symbol to an isolated market book, clears crossing orders at one price per market batch, proves the resulting value movement, and submits settlement to Solana. Several pairs can share one endpoint and one attestation session, but their books and proof batches never mix. Your order never becomes a Solana transaction; the enclave settles the result.
- Client (the SDK). Your software builds the collateral note, generates the zero-knowledge input proof, signs the order with your trading key, and (if you want the full guarantee) verifies the running enclave against an expected measurement before trusting it.
Spot, not perps
Darknyx is a spot venue. There are no positions, no leverage, no funding, and no liquidations. Every order is fully collateralized up front by a note you already deposited, and a trade is an atomic swap of value between two notes. If you have traded a perps dark pool before, the concepts that carry over are order types, time-in-force, and execution attributes; the concepts that do not (positions, margin, funding) simply are not part of the model.Who it is for
- Traders who do not want their resting orders read by the venue or the chain.
- Market makers and systematic desks that want programmatic order management (REST and WebSocket) with order intent kept private.
- Integrators building privacy-preserving trading flows who need custody to stay on-chain and verifiable.
Next steps
- Why Darknyx: the product thesis, exact trust boundary, and tradeoffs.
- Programmatic Access: the API surface, the auth model, and a quick start.
- Base URLs: where the endpoints live and the common response conventions.
- Trade Flow: the end-to-end lifecycle of an order, from submission to on-chain settlement.
- Multi-Market Venue: how several isolated books share one attested endpoint.