Privacy and attestation

What Darknyx hides, what remains public, and how clients verify the confidential matcher and its complete on-chain signer set.

Privacy & Attestation

TL;DR

On the programmatic path, Darknyx keeps order intent inside the measured matcher and balances inside on-chain commitments. The engine terminates TLS with a boot-random key inside its confidential VM; the deployment gateway passes that encrypted stream through. The SDK and daemon verify that live certificate, hardware quote, image measurement, boot session, and complete on-chain settlement-signer set before sending credentials or orders.

Who can see your orders?

Venue type	Who sees your orders	Risk
Centralized exchange	The operator	Can front-run, trade against you, or leak data.
On-chain order book	The sequencer / validators, and anyone indexing the chain	Reorder, censor, sandwich (MEV); the leak is permanent and public.
Off-chain dark desk	The operator	Custody and order intent both exposed to one party.
Darknyx programmatic path	The measured matcher inside protected VM memory	The host and chain do not receive plaintext orders. The client verifies that the certificate on its connection belongs to the approved matcher boot.

The difference from “encrypted on-chain orders” is that on Darknyx your order is never a transaction at all (see Trade Flow). What lands on Solana is the settled result, with a zero-knowledge proof, never the order.

The three privacy properties

Property	What is hidden	Mechanism
Order privacy	Side, size, limit price	On the supported programmatic path, order intent crosses enclave-terminated RA-TLS and stays inside matcher memory; it never appears in a tx, log, or account.
Trader privacy	The link from an order or settled note to your wallet	Orders use a trading key. Deposit and withdrawal transfers remain visible, but do not publish the shielded note owner.
Position privacy	What you hold	Balances are on-chain note commitments (Poseidon hashes) that seal owner, value, and token until you spend them.
Amount privacy	The size and price of a settled trade	Settlement publishes only note commitments and a zero-knowledge proof of conservation; the traded amounts and the clearing price never appear on-chain.

Deposits reveal the signer, mint, and gross amount. Withdrawals reveal the destination, mint, and amount. Network timing and aggregate activity are also observable. The privacy claim covers the book, note ownership, and settled trade plaintext; it is not a claim that all protocol activity is invisible.

How note lineage stays private

A note commitment is public only when the note is created as a Merkle leaf. Later locking and consumption publish a different handle—the note-use tag—whose derivation also needs the note’s private inner hash. That prevents an observer from following a note through deposit, trade, merge, and withdrawal by matching one repeated identifier.

The same rule extends to newly created notes. Trade and change outputs inherit private entropy from the consumed note, merge outputs combine private input inners, and protocol fee outputs incorporate a protocol-held epoch secret whose binding and epoch are governed on-chain. As a result, descendant relationships are not reconstructible from public commitments and other chain data. The user’s seed plus finalized chain data still recovers user-owned notes; the protocol separately retains the historical epoch keys needed to recover protocol-owned fee notes.

This is an unlinkability guarantee about cryptographic identifiers. Public deposit and withdrawal amounts, recipients, and transaction timing can still provide statistical clues, especially when values are distinctive.

Privacy is a guarantee, not a promise

The point of attestation is that a client can check which code receives its order. Confidentiality comes from hardware isolation of a measured image; settlement integrity comes from a narrower proof the chain verifies. Neither substitutes for the other.

Verifying the engine

Verification is a client-side step (the SDK ships a helper). In order, you confirm:

 1. Transport belongs to a live enclave boot?
        A fresh quote binds the certificate on the actual connection.
                          │  yes
                          ▼
 2. Hardware attestation and code valid?
        TDX quote signature checks out; platform TCB is current;
        quote event log commits to the compose_hash YOU expect.
                          │  yes
                          ▼
 3. Same boot and settlement authority end-to-end?
        transport quote binds the boot session and ordered full signer set;
        that set == finalized VaultConfig.tee_pubkeys on Solana.
                          │  all three hold
                          ▼
                 trust the channel with order intent

• Step 1 observes the self-signed certificate on the connection that will carry the request and verifies a fresh transport quote binding its SPKI. A probe to a different socket is not a substitute. After bootstrap, the connector accepts a replacement only when it presents the same quote-bound, boot-random SPKI; a mismatch is destroyed before request bytes can leave.
• Step 2 performs DCAP verification, rejects malformed or ambiguous event logs, requires exactly one runtime-typed compose event, derives the trusted compose hash from the DCAP-verified RTMR3 log, and compares it with a release measurement obtained independently. /info and /transparency are useful displays, not the root of trust.
• Step 3 checks the boot session and every shard signer, in order. The transport quote commits to both; tee_pubkey is simply the first signer exposed for convenience. The client compares the complete set with a finalized on-chain VaultConfig read.

The SDK verifies the transport evidence and returns the quote-bound identity; the client still supplies the independently approved compose hash and compares the full returned signer set with finalized on-chain configuration. The reference daemon performs these checks automatically and pauses new trading when its evidence becomes stale or mismatched. A reconnect may reuse only the same verified boot identity; a genuine engine restart produces a new certificate and boot session that must be attested again before private traffic resumes.

TLS alone is not verification

Connecting over ordinary TLS gives you a private channel to some machine. Darknyx clients instead bind the certificate on the connection they use to a fresh enclave quote and an independently approved measurement. Disabling certificate checks or verifying a separate probe connection defeats that guarantee.

What attestation does not cover

• Your own keys. Custody of your trading and spending keys is yours; losing them is on you, not the protocol.
• Liveness and censorship. Attestation does not force the operator to keep the venue running, include a particular order, or provide timely service.
• Matching fairness beyond the measured code. Limit prices, FIFO, execution attributes, and oracle circuit-breaker policy are enforced by the attested matcher, not re-proven by the settlement circuit.
• Your client’s correctness. Attestation verifies the server. That you submitted the order you intended is your client’s responsibility.