This file explains connection recovery, read-only verification, unknown-write reconciliation, and diagnostic evidence. Timing windows and operational thresholds belong to the application and must be configured explicitly.
TL;DR
- Authenticate and re-subscribe on every new connection.
- Resting orders survive normal disconnection in observed behavior.
- A disconnected in-flight placement is unknown, never automatically replayed.
- Serialize reads and discard timed-out connections before reusing a response kind.
- Public smoke uses no credentials or writes. An authenticated micro-cycle is a separate authorized action.
1. Startup and reconnection
Read metadata and validate the configured deployment. Authenticate the trade socket, then await order/fill subscriptions. Confirm account selection through independent reads where available, recognizing REST order-count lag. Optional binding probes are experimental: primary-account observations do not prove subaccount scope.
The server sent ping control frames on an idle connection around every ten seconds on 2026-10-01. Client heartbeat frequency, timeout, reconnect delay, and maximum backoff are application choices. A ping-capable injected socket is needed if liveness relies on ping/pong control frames.
Both clean and abrupt disconnects left resting orders alive in observations on 2026-10-01. Re-read complete orders after reconnect; do not replace the book based on socket state. cancel_on_disconnect is a separate account-wide behavior that must not be enabled by ordinary recovery.
2. Unknown writes and restarts
A send before a socket drop can fill without its originating session seeing the reply. Preserve intent and correlation data before sending. On recovery, resolve through order events, complete open orders, and exact-ID history; history may lag substantially. Do not treat a miss as rejection.
Pending memory is instance scoped. Application restart requires reconciliation of unresolved work and current complete state. A local time window cannot reset exchange state or prove no execution. The experimental ledger is an optional additional signal, with known safety/liveness limitations in orders.md §6.
3. Authentication diagnostics
Distinguish invalid signature, unknown credentials, permission failure, KYC/terms prerequisites, CDN rejection, clock error, and network failure. A fresh nonce/timestamp may address a transient signature failure, but persistent credential errors must stop a blind reconnect loop.
Keep credentials out of source, URLs in logs, diagnostics, and fixture data. Mask signatures, public-key query parameters, and secret values explicitly. Read-only transport guards refuse write frames and methods; authenticated reads still depend on the caller's key permissions.
4. Verification workflow
The public smoke checks reference data and validated public market data. The synthetic exchange controls ACK/read delay, dropped placement replies, rejection after ACK, injected frames, and disconnects. Its controls model adverse behavior; its timings are not measurements of QFEX.
When a user authorizes live trading validation, use a dedicated account and the venue's minimum quantity. Verify placement acknowledgement, complete open-order appearance, exact-ID cancellation, fill reconciliation, and fresh position state. If testing reduce-only or leverage, record the necessary before/after evidence. Each probe needs its own cleanup and stopping conditions.
No public knowledge file should contain the wallet, account ID, trade ID, exact experiment order ID, position amount, or request-specific transaction record. A new venue fact is recorded with a date and its proof class, without identifying the tested account.
5. Investigating a discrepancy
Start with raw venue responses: metadata, socket lifecycle and correlated frames, complete order pages, signed position rows, terminal history, and HTTP status/cache headers. Check exact client-ID case, original sent size, remaining size, and trade deduplication. Then classify the outcome as local refusal, exchange rejection, accepted, or unknown.
Never diagnose account binding solely from a temporary REST/socket order-count mismatch. Never diagnose a fill from an alert string or a single stale position read. New observations must explicitly supersede conflicting older claims.
Pitfalls
| What breaks | Why | Correct approach |
|---|---|---|
| Reconnect duplicates the book | Resting orders survived | Read first, reconcile |
| A late query reply answers a new query | Reused response kind after timeout | Replace the socket |
| An automatic test places real orders | Authenticated probe was treated as smoke | Keep public smoke read-only |
| Fake timings are published as facts | Hostile model mistaken for measurement | Label test model explicitly |
Open questions / not verified
- Authenticated UAT provisioning, subaccount scope, heartbeat-channel semantics, and emergency restriction signals.
- The precise maximum lag of order/history/position replicas.
- Binding probes and the optional ledger remain experimental.
Sources
Authenticate; Cancel on disconnect; Errors; Prohibited jurisdictions. Session and disconnect observations: 2026-10-01. Eligibility rules change; consult the current official page before onboarding. No circumvention workflow is provided.
© markpaper authors. Licensed under CC BY 4.0: when publishing or adapting this material, credit “markpaper — QFEX knowledge base” and link to the original and the license.