ai-trading-web

AI Multi-Agent Cryptocurrency Futures Platform is a production-oriented cryptocurrency futures research and execution system for Binance USD-M Futures and OKX perpetual swaps. It is structured as a pnpm workspace with a Next.js web application and a Node.js API, backed by PostgreSQL via Prisma, Redis and BullMQ, and shipped with a Docker Compose setup. The stated core principle is that AI is advisory only: agents cannot call an exchange adapter directly, and automated orders must flow through the Decision/Judge pipeline and a deterministic Risk Engine before the Trading Engine may execute them. Security and accounts. Multi-user authentication, Redis-backed sessions, CSRF protection, TOTP two-factor authentication, audit logs, Argon2id password hashing and AES-256-GCM encrypted provider credentials. Password reset is configured through one email transport (SMTP, or a webhook URL plus secret); reset links expire after 15 minutes, are single-use, are never stored or logged in plaintext, and a successful password change revokes every existing session for the account. Exchange integrations. Binance Futures and OKX adapters cover public market data, private account state, positions, open orders, order history, order placement, cancellation, and protective-order amendment where the exchange supports it. Market and external data. Realtime market streams, normalized candles, indicators, gap detection, backfill, Redis snapshots and a Socket.IO namespace at /market. A separate ingestion layer handles news, exchange announcements, incidents, sentiment, Reddit and a macro calendar, with ingestion queues, deduplication and importance scoring, published through /external-data realtime events. AI infrastructure. A provider-independent AI layer with bounded tool calling, agent lifecycle management, a Decision Agent, Judge controls, BullMQ pipeline scheduling, replay, cancellation, health reporting and metrics. Risk, portfolio and research. Deterministic risk assessment, portfolio exposure controls, strategy allocation and rebalancing, performance and reflection loops, shadow/canary self-learning, backtesting, validation, benchmarking, simulation, factor discovery and quantitative recommendations. Execution. Exchange-backed DEMO/LIVE trading with a kill switch, idempotent client order IDs, state synchronization, TP/SL protection and a Position Manager, surfaced through a /live-trading realtime dashboard namespace. Adaptive TP/SL and Position Manager. Rather than always deriving take-profit and stop-loss levels from environment percentages, the deterministic Trade Plan Engine uses ATR, support/resistance, EMA20/EMA50, ADX, efficiency ratio, breakout state, market structure, fees and configured risk/reward requirements to classify conditions as TREND_UP, TREND_DOWN, RANGING, BREAKOUT or HIGH_VOLATILITY, and produces the matching plan type: trend pullback, range-boundary entry and target, breakout/retest, or volatility-controlled. The engine rejects poor entry location, structurally excessive stops, and targets whose net reward/risk is below policy; settings such as STOP_LOSS_PCT and RISK_REWARD_RATIO remain policy defaults and a fallback when ATR and structure data are unavailable. After entry, the Position Manager synchronizes exchange state and can move the stop to break-even plus a fee buffer, trail by ATR after sufficient favorable movement, take one partial profit at 1R, keep stagnant positions open until an explicit protective, manual, exchange or strategy-authorized close occurs, amend or cancel/recreate protective orders through the adapter, and clean orphan protection after the position closes. LIVE_POSITION_SYNC_INTERVAL_MS defaults to 30 seconds; exchange order-history imports and the Live Trading dashboard are capped at the 20 most recent orders, while positions and safety/protection checks are not truncated. Safety gates. TRADING_MODE=DEMO is the safe default. Before execution the system checks GLOBAL_TRADING_ENABLED, LIVE_TRADING_ENABLED, verified connection state, production connection permission, recent authentication, risk approval TTL, exposure limits, leverage limits, cooldown and kill-switch state. LIVE mode requires LIVE_TRADING_ENABLED=true, and production exchange connections remain disabled unless explicitly enabled. The README advises using dedicated demo/testnet credentials while validating behavior and never using withdrawal-capable API keys. Setup and operations. Requirements are Node.js 22.13 or newer (required by pnpm 11), pnpm 11 or newer, and Docker Desktop with Docker Compose. Local setup copies .env.example into the root, apps/api and apps/web locations, installs dependencies, starts Postgres, Redis and Adminer via Compose, generates the Prisma client, applies migrations and runs the dev servers; the full stack can also be started with docker compose up -d --build. Documented services include the web app on port 3000, the API on 3001 with /api, /docs and /api/health, and Adminer on 8080. Scripts cover dev, build, lint, strict TypeScript typechecking, Vitest unit suites, API integration tests, end-to-end tests, formatting checks, and Prisma generate, migrate and studio. Additional documentation is referenced in ARCHITECTURE.md, API_CONTRACT.md, DATABASE.md, DIRECTORY_STRUCTURE.md, ROADMAP.md, PROJECT_CONTEXT.md, DEFINITION_OF_DONE.md and PROJECT_RULES.md. Known boundaries stated by the project. Paper/shadow records exist and support evaluation and self-learning, but there is no standalone paper-trading execution API comparable to Live Trading. Backtests, demo runs and model confidence do not guarantee production profitability, and promotion requires adequate samples and drawdown review. Code updates do not affect running containers until API and web services are rebuilt or restarted.