Live mode runs the same rig as paper mode — same symbols, same dashboard, same MCP bridge, same audit trail — but replaces the simulated fill engine withDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/theonetrade/ai-trading-mcp/llms.txt
Use this file to discover all available pages before exploring further.
modules/live.module.ts: a Binance spot broker adapter that places real limit and market orders, wraps every position in an OCO bracket, and recovers safely from restarts, network hiccups, and exchange edge cases.
Prerequisites
- Paper trading working end-to-end (feed visible, positions open and close correctly)
- Binance account with spot trading enabled
- Binance API key and secret with Spot & Margin Trading permission — no withdrawal permission required or recommended
Starting Live Trading
Export your Binance API keys
Set the keys in your shell before starting the process. They are read at startup and never written to disk by the rig itself.
Launch the trading process in live mode
--live flag causes the process to load modules/live.module.ts instead of modules/paper.module.ts. Everything else starts identically: one Live.background() per whitelisted symbol, persistence wired, and the same config/setup.config.ts calling serve().Verify the dashboard and bridge
Open the dashboard at
http://localhost:60050 and confirm symbols appear with live prices. The MCP HTTP bridge is on 127.0.0.1:60051 — the same address as paper mode. No configuration change is needed in mcp.servers.json.What Changes in Live Mode
Module swap
The only structural difference between--paper and --live is which exchange module the process loads:
| Flag | Module loaded | Order execution |
|---|---|---|
--paper | modules/paper.module.ts | Simulated fills in the engine |
--live | modules/live.module.ts | Real Binance spot orders via ccxt |
modules/paper.module.ts registers a ccxt Binance exchange for market data only — getCandles and getOrderBook — with no broker adapter. modules/live.module.ts adds the full broker implementation on top of the same data feeds.
OCO brackets
Every open position is protected by a single OCO (one-cancels-other) order: a limit take-profit and a stop-limit stop-loss placed as one atomic bracket. This sidesteps the classic Binance failure mode where two independent sell orders compete for the same frozen coins — only one OCO is allowed per position, so the second order can never die withInsufficientFunds.
Guaranteed entry
The adapter uses a limit order followed by a polling loop (up to 10 × 10 s). If the limit has not fully filled by the end of the poll window, it cancels the remainder and tops up with a market order. The entry never lingers on the book indefinitely.Idempotent recovery by clientOrderId
Every entry order is placed with clientOrderId = signalId. On any revalidation or restart the adapter checks for an existing order under that ID before placing a new one — if a filled entry is found and an OCO bracket is already in place, it returns without buying again. This prevents position doubling across restarts.
Error classification
ccxt.NetworkError maps to OrderTransientError (bounded retry). ccxt.ExchangeError maps to OrderRejectedError (permanent — surfaced to the engine and then to the agent as an isError tool result). Network hiccups and exchange verdicts are never treated the same way.