Engineering principles
Digital asset markets do not close. There is no overnight window in which to deploy, reconcile or recover. Every component of the platform must be designed for change without downtime, and for failure without loss of integrity. NPX organizes its engineering work around four principles:
- Deterministic core. Order handling and matching logic should produce consistent, auditable results under identical inputs.
- Observable systems. Latency, queue depth, error rates, liquidity and risk signals are measured continuously rather than discovered after an incident.
- Controlled change. Deployments are staged, reversible and monitored; model or parameter changes are versioned.
- Graceful degradation. Under stress, the system should protect integrity first and throughput second, with clear communication to users.
Order matching and execution
The matching engine is the core of a trading venue. It receives orders, maintains price-time priority according to published rules, executes compatible orders and emits trade events. NPX is optimizing the engine for consistent latency, predictable behavior under high concurrency and clear auditability of every state transition.
Speed alone is not the objective. A matching engine that is fast in normal conditions but unpredictable during a volatility spike creates a worse experience than a slightly slower engine with stable behavior. NPX measures performance across percentiles, not only averages, and tests the system against synthetic load scenarios that resemble real market stress.
Market data pipeline
Market data moves through several stages: ingestion from liquidity sources, normalization, validation, aggregation and distribution. Each stage introduces potential latency or error. NPX designs the pipeline so that timestamps are preserved, anomalies are flagged and consumers can distinguish between delayed, indicative and final data.
For professional and institutional users, data quality is a trading input. Inconsistent symbol definitions, missing intervals or unclear timestamps can invalidate a strategy. The platform documents data definitions and maintains change logs so that consumers can adapt deliberately rather than discover changes through unexpected results.
API access
NPX is developing API access for professional and institutional clients. The design priorities are stable interfaces, explicit rate limits, scoped permissions and predictable error semantics. API keys are treated as sensitive credentials, with support for restriction by operation, IP range and account scope.
GET /api/v1/markets/BTC-USDT/depth?limit=50
Authorization: Bearer <scoped-key>
{
"symbol": "BTC-USDT",
"timestamp": "2026-10-18T12:00:00.000Z",
"bids": [["68420.50", "0.482"], ...],
"asks": [["68421.00", "1.104"], ...]
}Illustrative endpoint format only. Interfaces, parameters and availability are subject to development and eligibility review.
Resilience and capacity
Continuous markets require continuous availability. NPX designs for redundancy across compute, storage, networking and data feeds, with failover procedures that are tested rather than assumed. Capacity planning accounts for peak concurrency, market data bursts and the operational load created by risk reviews and withdrawals during stress.
Incident response is part of the architecture. The platform maintains runbooks for common failure modes, defined communication paths for users and a post-incident review process that identifies root causes rather than stopping at symptoms. Transparency after an incident is as important as performance before one.
| Layer | Design objective | Operational measure |
|---|---|---|
| Matching core | Deterministic, auditable execution | Latency percentiles, queue depth, rule conformance |
| Market data | Freshness and consistent definitions | End-to-end delay, gap detection, schema versioning |
| Account systems | Integrity of balances and permissions | Reconciliation, access review, change audit |
| Risk controls | Timely detection and intervention | Alert precision, review latency, case outcomes |
| Infrastructure | Availability and recoverability | Uptime, failover drills, recovery time objectives |
A deliberate roadmap
NPX plans to explore data analysis, automated risk controls and abnormal-behavior detection as the platform matures. These are development directions, not claims of deployed capability. The company’s stated position is that technical concepts are no substitute for proven performance: any technology must be measured by whether it makes trading more stable, risk identification more timely and operations more efficient.
Related
See the security model for account and asset protections, or the compliance framework for how technology supports regulatory obligations. Market-level details are on the markets page.