Skip to content
Get Started

Nanoconda Architecture

Overview

Nanoconda is a professional ultra-low-latency algorithmic trading platform built specifically for exchange-traded futures.

The platform is designed to minimize latency while providing a complete production environment for developing, testing, deploying and operating automated trading strategies.

Unlike traditional trading platforms that combine many independent components, Nanoconda is designed as a single integrated system where market data, order execution, risk management, strategy execution and monitoring operate together.

Design Principles

Nanoconda is built around several core principles:

  • Ultra-low latency
  • Deterministic execution
  • Production reliability
  • High throughput
  • Single C++ API
  • Minimal software layers
  • Identical simulation and production APIs
  • Complete control over the execution pipeline

The goal is to remove unnecessary latency while making strategies easy to develop and maintain.

System Architecture

A typical Nanoconda deployment consists of:

  • Market Data Feed Handler
  • Order Gateway
  • Risk Engine
  • Strategy Engine
  • Browser GUI
  • Remote Client API
  • Historical Simulator

All components are tightly integrated.

Strategies interact with the platform through the Nanoconda C++ API rather than directly communicating with exchange protocols.

Performance Philosophy

Nanoconda is engineered for microsecond-level trading.

Performance is achieved by reducing software overhead throughout the execution pipeline rather than relying on a single optimization.

Key techniques include:

  • Native C++ implementation
  • Kernel bypass networking
  • User-space packet processing
  • Lock-free data structures
  • NUMA-aware architecture
  • CPU affinity
  • Dedicated trading cores
  • Hardware timestamping
  • Deterministic scheduling
  • Efficient memory management

Latency depends on deployment hardware, exchange connectivity and customer configuration.

Kernel Bypass Networking

Production deployments may utilize kernel bypass networking technologies.

Supported technologies include:

  • Solarflare/Xilinx EFVI
  • Solarflare TCPDirect
  • Onload

Kernel bypass reduces operating system networking overhead by allowing applications to communicate directly with the network interface.

Benefits include:

  • Lower latency
  • Lower jitter
  • Reduced context switching
  • Fewer kernel transitions
  • Improved determinism

The networking stack used depends on deployment requirements.

Time Synchronization

Nanoconda supports hardware timestamping and precision clock synchronization.

Typical technologies include:

  • PTP
  • Hardware NIC timestamps
  • High-resolution timers

Accurate timestamps allow precise latency measurement and reliable event ordering.

CPU Architecture

Nanoconda is designed for dedicated server deployments.

Typical optimizations include:

  • Dedicated CPU cores
  • CPU affinity
  • NUMA-aware scheduling
  • Core isolation
  • Reduced operating system interference

These techniques reduce scheduling latency and improve execution consistency.

Memory Architecture

Performance is improved through careful memory management.

Design goals include:

  • Minimize allocations
  • Cache-friendly data structures
  • Lock-free communication
  • Efficient memory access
  • Predictable execution

The architecture favors deterministic behavior over dynamic allocation.

Strategy Engine

Trading strategies execute directly inside the Nanoconda platform.

Benefits include:

  • Low communication overhead
  • Direct access to market events
  • Fast order submission
  • Shared platform services
  • Integrated risk management

Strategies use the same API in both simulation and production.

Risk Engine

Risk management is integrated into the execution pipeline.

Typical controls include:

  • Position limits
  • Order size limits
  • Drawdown protection
  • Cancel all orders
  • Flatten positions
  • Strategy enable/disable
  • Account monitoring

Risk decisions occur before orders reach the exchange.

Market Data

Nanoconda processes real-time exchange market data.

Capabilities include:

  • Low-latency feed handling
  • Order book processing
  • Trade processing
  • Market depth
  • Event-driven architecture
  • High message throughput

Market data is delivered directly to trading strategies.

Order Execution

Order routing is optimized for deterministic execution.

The platform manages:

  • Order submission
  • Order modification
  • Order cancellation
  • Fill processing
  • Position updates
  • Exchange acknowledgements

Applications interact through the Nanoconda API rather than exchange-specific protocols.

Simulator

The simulator reproduces production behavior as closely as possible.

Features include:

  • Historical replay
  • Live simulation
  • Identical API
  • Exchange matching simulation
  • GUI support
  • Manual trading
  • Strategy development

Strategies typically require no source code changes between simulation and production.

Remote Client API

The Remote Client API allows external applications to communicate with a running Nanoconda instance.

Typical applications include:

  • Trading dashboards
  • Monitoring systems
  • Administrative tools
  • Mobile applications
  • Custom GUIs
  • Risk management systems

Communication is bidirectional.

Applications can both receive information and control the platform.

Browser GUI

Nanoconda includes a browser-based interface for production monitoring.

Typical functionality includes:

  • Order management
  • Position monitoring
  • Account summary
  • Live P&L
  • Trade history
  • Market depth
  • Strategy monitoring
  • Risk controls
  • Kill switch

The GUI communicates with the trading engine without affecting deterministic strategy execution.

Typical Workflow

A typical development workflow is:

  1. Develop a strategy.
  2. Compile using the Nanoconda API.
  3. Test in the simulator.
  4. Replay historical sessions.
  5. Validate performance.
  6. Deploy to production.
  7. Monitor using the Browser GUI or Remote API.
  8. Iterate using identical APIs.

Deployment Philosophy

Nanoconda is designed so that the same strategy can move from development to production with minimal changes.

The objective is:

Write once.

Test.

Replay.

Deploy.

Operate.

The same APIs and architecture are used throughout the strategy lifecycle.

Target Users

Nanoconda is intended for:

  • Proprietary trading firms
  • Quantitative researchers
  • Professional futures traders
  • Market makers
  • Automated trading developers

Summary

Nanoconda combines:

  • Ultra-low-latency execution
  • Professional risk management
  • Historical simulation
  • Browser-based monitoring
  • Remote control APIs
  • Deterministic architecture
  • Kernel bypass networking
  • Modern C++ development

into a single integrated platform for professional algorithmic futures trading.

Why Nanoconda Is Low Latency

The primary reason Nanoconda achieves ultra-low latency is its single-machine, in-memory architecture.

Rather than distributing critical trading components across multiple servers or independent processes, Nanoconda keeps the complete trading pipeline together on a single colocated machine.

Core components include:

  • Market data feed handler
  • Pre-trade risk engine
  • Trading strategies
  • Order gateway
  • Position management
  • Account management

These components communicate through shared memory and direct in-process function calls instead of network messages.

This eliminates unnecessary serialization, network latency, kernel networking overhead, and inter-process communication between critical trading components.

In-Memory Execution Pipeline

A typical order follows this path:

  1. Market data arrives from the exchange.
  2. The feed handler updates the in-memory order book.
  3. Trading strategies immediately receive the market event.
  4. The strategy evaluates trading logic.
  5. Orders pass through the in-memory pre-trade risk engine.
  6. Approved orders are sent directly to the exchange gateway.
  7. Exchange acknowledgements and fills immediately update strategies, positions, accounts and risk state.

At no point does the critical trading path require communication with external services or remote machines.

Shared Memory Architecture

Critical market information remains in memory throughout execution.

Examples include:

  • Order books
  • Positions
  • Risk state
  • Account information
  • Strategy state
  • Orders
  • Fills

Strategies access these structures directly rather than requesting them through network APIs or databases.

This minimizes latency while ensuring every component observes the same consistent state.

Integrated Pre-Trade Risk

Risk management is integrated directly into the execution pipeline.

Rather than sending orders to a separate risk server, Nanoconda performs risk validation in memory before an order reaches the gateway.

Typical checks include:

  • Position limits
  • Order size limits
  • Drawdown limits
  • Account permissions
  • Strategy controls

Integrating risk directly into the trading engine avoids additional network hops while ensuring every order is validated.

Exchange Gateway

The exchange gateway runs on the same machine as the trading engine.

After an order passes risk validation, it is transmitted directly to the exchange.

Because strategies, risk management and the gateway execute together, orders do not traverse multiple applications or remote services before leaving the server.

Kernel Bypass Networking

Production deployments may utilize:

  • Solarflare/Xilinx EFVI
  • TCPDirect
  • Onload

These technologies allow market data and order traffic to bypass much of the operating system networking stack, reducing latency and improving determinism.

Why is Nanoconda Different From Other Platforms (CQG, TT, Rithmic, Trading Technologies)

Many trading platforms separate critical components into multiple services:

Exchange ↓ Feed Handler ↓ Market Data Server ↓ Risk Server ↓ Strategy Server ↓ Order Gateway ↓ Exchange

Each transition introduces additional software overhead, memory copies, serialization, context switches, scheduling delays or network communication.

Nanoconda instead keeps the critical trading path entirely local:

Exchange ↓ Feed Handler ↓ Shared Memory ↓ Strategy ↓ In-Memory Risk ↓ Gateway ↓ Exchange

This architecture minimizes software layers and allows market events to flow through the system with as little overhead as possible.

Design Philosophy

Nanoconda is designed around a simple principle:

Keep the critical trading path on one machine, in one integrated system, with data remaining in memory from market data arrival to order transmission.

This architecture reduces latency, improves determinism, simplifies deployment, and allows strategies, risk management and execution to operate as a unified trading engine.