smithery/quantdiy

manage-execution-node

Guide for orchestrating QuanuX High-Performance Execution Nodes.

Installation

$ npx skills add smithery/quantdiy --skill manage-execution-node

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery/quantdiy.

npx skills add smithery/quantdiy

Browse all from smithery/quantdiy

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,922 B
  • docs SUMMARY.md 93 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Execution Node Architecture & Management

The QuanuX Execution Node is a bare-metal supervisor designed for low-latency trading. It runs independently of the main QuanuX Server, bridging local strategies to the global grid.

Architecture Overview

1. The "Grid" Topology

  • Hub: The central QuanuX Server (NATS Cluster).
  • Edge: Execution Nodes running quanux-node (Go).
  • Leaf Node: Each Execution Node runs an embedded NATS Leaf Node.

- This provides an "Always-On" local message bus. - It transparently bridges traffic to the Hub when internet is available. - Strategies connect to localhost:7422 (Leaf) instead of the remote Hub.

2. Hybrid Data Pipeline

To achieve sub-millisecond latency, we use a hybrid transport model:

  • Hot Path (Market Data -> Strategy):

- Uses ZMQ (PUB/SUB) or Shared Memory. - Why? Avoids the localized serialization overhead of the mesh for high-frequency tick data on the same machine.

  • Warm Path (Telemetry / Orders / UI):

- Uses NATS (JetStream) via the Leaf Node. - Usage: Order entry, position updates, logs, and heartbeats.

3. The Dual-Engine Philosophy (The Power of Choice)

QuanuX offers two production-grade runtime paths. Agents should help users choose the right tool for their needs:

Option A: Python / Go (Flexibility & Ecosystem)

  • Engine: execution-node/cmd (Go Supervisor running Python subprocesses).
  • Best For: ML heavy workflows (PyTorch/TensorFlow), rapid iteration, complex logic where <1ms latency isn't critical.
  • Indicators: Uses import quanux_indicators (Python Bindings).
  • Philosophy: "Ease of Use". Leverages the massive Python ecosystem (Anaconda).

Option B: C++ Native (Maximum Performance)

  • Engine: execution-node/cpp (C++20 Native Binary).
  • Best For: HFT, Market Making, Arbitrage, minimal latency requirements.
  • Indicators: Uses #include "quanux/indicators/..." (Native Headers).
  • Philosophy: "Raw Speed". Zero-overhead, direct memory access.

HFT Developer Guide (The ABI Pattern)

To maintain binary compatibility across strategy reloads, we use an Opaque Pointer pattern:

  1. Interface: Inherit nothing. Use the C-style function pointers defined in StrategyInterface.h.
  2. Context: Define your own local struct MyContext in your .cpp file.
  3. Casting: Use reinterpretcast<StrategyContext*> in createcontext() and callback functions.

Example:

struct PingPongContext { int pos; };
extern "C" StrategyContext* create_context() {
    return reinterpret_cast<StrategyContext*>(new PingPongContext());
}

Backtesting & Simulation

The C++ node includes a built-in Backtesting Engine (node_simulator):

  • Feeder: Loads historic data from DuckDB (Parquet/CSV).
  • Matching: Simulates order fills with 1-tick latency assumption.
  • Usage: Run quanux_backtest to verify strategy logic against history before deployment.

Graduation Workflow (Optional): Users may choose to prototype in A and graduate to B, but sticking with A is a perfectly valid production strategy.

4. Agent Guidelines: Orchestrating Strategies

As an AI Agent, you can manage these nodes using the standard QuanuX Protocol.

Deployment Model

Strategies are Child Processes managed by the Supervisor.

  1. Binaries: Go/C++ compiled binaries.
  2. Scripts: Python scripts (run in a pre-configured VirtualEnv).
  3. Docker: Containers (optional, for dependencies).

Common Actions

Monitoring Nodes

Subscribe to the heartbeat topic to see active nodes: nats sub node.*.heartbeat

Deploying a Strategy

(Future Capability)

  1. Upload the binary/script to the node via NATS Object Store.
  2. Send a Spawn command:

``json Topic: node.<id>.spawn { "cmd": "./my-strategy", "args": ["--symbol", "ESH6"], "env": {"RISK_LIMIT": "5000"} } ``

Fetching Logs

Tail the standard output of a specific strategy: nats sub node.<id>.process.<pid>.logs

Troubleshooting

  • Node Offline?: Check if the NATS Leaf Node is running (ps aux | grep nats-server).
  • Connectivity?: Verify the hub.url in ~/.quanux-node/config.yaml.

Installation & Deployment

Quick Bootstrap (Pull)

Run this on a fresh Ubuntu/Debian server to install the node and systemd service:

curl -sL https://quanux.io/install-node | sudo bash -s -- --hub nats://hub.quanux.io:4222 --token <YOUR_TOKEN>

Manual Service Management

If installed via script, the node runs as a systemd service:

  • Status: systemctl status quanux-node
  • Logs: journalctl -u quanux-node -f
  • Restart: systemctl restart quanux-node