QuantDinger

QuantDinger Open-source AI Trading OS Turn trading ideas into Python strategies, backtests, paper trading, live execution, and monitoring — all in one self-hosted stack. QuantDinger is a product of Open Byte Inc. AI research → Strategy code → Backtest → Paper/Live execution → Monitoring

<strong>English</strong>
·
<strong>简体中文</strong>
·
<strong>API</strong>
·
<strong>AI Agents & MCP</strong>



<strong>Live App</strong>
·
<strong>Website</strong>
·
<strong>Video Demo</strong>
·
<strong>Official Support Email</strong>

SUPPORTED BY

    

  
    
    
  

Want to contribute? Explore the public roadmap or claim a scoped task from Ready for contributors.

QuantDinger can submit real orders when live trading is explicitly enabled. Start with paper trading, use restricted API keys, and review the risk and compliance requirements for your jurisdiction. This project does not provide investment advice.

Watch QuantDinger in action

What QuantDinger is

QuantDinger is an open-source AI Trading OS for independent traders, Python strategy authors, and small teams. Its local-first, self-hosted design keeps market data, strategy code, broker credentials, and deployment under the operator's control.

The project combines:

• multi-provider AI market research and analysis;
• Python indicators and Strategy API V2 development;
• server-side backtesting and experiment workflows;
• paper and live execution across crypto exchanges and traditional brokers;
• web, mobile H5, human API, Agent Gateway, and MCP access;
• PostgreSQL-backed state, durable workers, audit logs, and optional monitoring.

It is not a black-box signal service. Strategy code, risk settings, credentials, and deployment remain under the operator's control.

Strategy evolution and signal-only virtual accounts

• Strategy evolution searches declared tunable parameters with random, grid, or TPE optimization, using bar-count walk-forward validation and a final blind holdout. Jobs run asynchronously with per-strategy history, automatic pruning, composite scoring, PBO, Deflated Sharpe, block-bootstrap Monte Carlo, and transaction-cost stress tests. Results compare parameter robustness; they do not forecast future returns.
• Signal-only virtual accounts turn notification-mode signals into internal virtual orders, fills, positions, trade records, PnL, and an equity curve. They never connect to a broker or submit live orders. Each fill uses a fixed 0.05% commission on executed notional and 0.05% adverse slippage; leverage is not charged a second time in the commission calculation.

What changed in v5

The v5 backend is organized around explicit runtime and operational boundaries:

• the HTTP API no longer owns long-running trading or scheduler loops;
• trading, scheduling, Celery jobs, and migrations run as separate processes;
• Celery handles finite, retryable work while long-lived strategy runtimes stay in the trading worker;
• cache Redis and durable job Redis use separate instances and eviction policies;
• high-risk API contracts are represented in OpenAPI and protected by tests;
• JSON logs, request IDs, Prometheus metrics, dashboards, and alert rules are available through an optional observability overlay;
• the production overlay runs backend processes as a non-root user with a read-only root filesystem, dropped capabilities, and resource limits;
• CI checks syntax, lint, tests, release gates, Compose files, dependencies, source security, secrets, API compatibility, version drift, and text encoding.

The source version is declared in VERSION. Git release tags use the same semantic version with a leading v, for example v5.0.1.

Architecture

The editable source is architecture-v5.svg; the Mermaid topology below is the detailed runtime source of truth.

The static diagram above is the product-level view. The runtime topology below is the current source of truth for container ownership and event/data flow.

flowchart TB
    C["Web / Mobile / API / MCP clients"]
    FE["Nginx frontend services"]
    API["Flask + Gunicorn API"]
    PG[("PostgreSQL")]
    CACHE[("Redis cache")]
    JOBS[("Redis jobs")]
    KAFKA[("Kafka event backbone")]
    TW["Trading workers\ncontrol, realtime, execution, grid actors"]
    DISPATCH["Strategy dispatcher workers"]
    EVAL["Strategy evaluator workers\nhot bar runtimes"]
    AUDIT["Kafka audit worker"]
    SW["Scheduler worker"]
    CW["Celery worker"]
    BEAT["Celery beat"]
    PROM["Prometheus"]
    GRAF["Grafana"]
    ALERT["Alertmanager"]

    C --> FE --> API
    API --> PG
    API --> CACHE
    API -->|"durable commands"| PG
    TW -->|"leases, order intents, fills, grid actor state"| PG
    TW -->|"closed bars and lifecycle events"| KAFKA
    KAFKA --> DISPATCH --> KAFKA
    KAFKA --> EVAL
    EVAL -->|"inbox, leases, checkpoints, order intents"| PG
    KAFKA --> AUDIT --> PG
    PG -->|"owned pending orders"| TW
    SW -->|"schedules, monitoring, heartbeats"| PG
    API -->|"finite async jobs"| JOBS
    BEAT --> JOBS --> CW
    CW --> PG
    API -. metrics .-> PROM
    PG -. exporter .-> PROM
    CACHE -. exporter .-> PROM
    JOBS -. exporter .-> PROM
    PROM --> GRAF
    PROM --> ALERT

One backend image is reused by several containers with different commands:

Process	Responsibility
migration	Applies the database schema and exits before application services start.
kafka-init	Creates the versioned runtime topics and exits before event consumers start.