01 // System Overview
Welcome to the ElquoAI Autopilot documentation. ElquoAI is a professional-grade quantitative execution engine and risk-controlled cockpit designed for cryptocurrency futures markets. The core mission is capital preservation first, market-flow continuation second, and opportunistic trend capitalization third.
The system relies on a fully quantitative architecture to scan markets, identify high-probability setups, and manage active trade exposure using strict risk limits. Users retain full self-custodial control over exchange permissions, enabling write access only for designated futures trading operations.
02 // Core Architecture
ElquoAI runs as a decoupled multi-process suite to isolate web UI, scanner daemons, API auditors, and order tracking databases. This ensures that web traffic peaks never degrade scanner frequency or delay execution loops.
The system relies on three vital daemons:
- daemon.py: The main coordinator. It polls user schedules, manages cooldown periods, and starts isolated scans for active SaaS accounts.
- paper_monitor.py: A dedicated process evaluating candidate bracket criteria and tracking synthetic paper performance to test risk settings.
- main.go (Go WebSocket Monitor): Built in Go for maximum concurrency. It listens directly to the Binance pricing feed via WebSockets, matches values against active open trades in the SQLite database, and enforces stop-loss and limit targets.
03 // Execution Pipeline
Every scan undergoes a multi-stage validation pipeline to filter noise and verify structural setups:
The worker pulls candle histories, checks volatility, evaluates volume trends, and filters active assets for grading.
The Scout model forms a trading thesis and setup bracket, which is subsequently parsed and audited by the Validator model.
The risk engine verifies duplicate exposure limits, checks margin feasibility, and checks daily drawdown thresholds.
04 // Capital & Risk Model
Risk guidelines are centralized inside decision_policy.py. We enforce capital allocation guidelines using mathematical constraints to prevent account over-leverage or chasing positions:
Calculates the maximum margin allowed for a single position based on account equity, user-configured max risk factor, and exchange leverage bounds:
A candidate setup is instantly invalid unless the net reward-to-risk ratio (after accounting for estimated maker/taker fees) meets the minimum threshold:
- Max Daily Drawdown: Stops execution if daily realized/unrealized loss exceeds your configured daily cap.
- News Block Window: Halts trading 15 minutes before and after high-impact events.
- Duplicate Symbol Block: Blocks duplicate active exposure in the same direction to avoid concentration risk.
05 // Exchange Setup Guide
To connect your exchange API, generate API keys inside your account dashboard. For maximum security, you should strictly enforce restricted API key capabilities:
The system runs a background API Auditor that continuously monitors keys. If spot withdrawals or unverified permissions are enabled on your API keys, the system de-authorizes execution keys instantly.
06 // Replay Backtesting Suite
The Replay Backtester (available in Pro and Apex tiers) replicates execution step-by-step using historical order book data. This allows quants to stress-test prompt structures, continuation rulesets, and risk levels:
• Sandbox Mode: Preview telemetry layout panels with simulated data streams. No real-time scans are submitted to exchanges.
• Paper Trading Mode: Evaluates setups in real-time using live WebSocket order book streams, but executes virtual trades to track net returns after simulated fees.
07 // Concrete Setup Examples
Here is a concrete example of a graded trade candidate generated by the Scout and approved by the Validator for BTC/USDT Futures:
{
"symbol": "BTCUSDT",
"direction": "LONG",
"entry": 59250.00,
"stop_loss": 58600.00,
"take_profit": 61200.00,
"risk_pct": 1.5,
"leverage": 10,
"net_rr_ratio": 3.0,
"setup_thesis": "Trend continuation breakout above key resistance with strong volume confirmation."
}
08 // FAQ & Troubleshooting
SYSTEM_ERROR is graded when exchange APIs time out, WebSocket feeds drop, or JSON payload formats are corrupt. It is never counted as a missed trading setup to preserve integrity.
Configure a CNAME record with Host docs pointing directly to your Fly.io app target (crypto-auto-worker-felix.fly.dev). This serves the documentation website natively on the same cluster interface.