1. System Overview

DOCS SYNCED WITH THE DEPLOYED COCKPIT VERSION

ElquoAI is a professional-grade quantitative execution engine and risk-controlled cockpit for cryptocurrency futures markets. The core mission, in priority order: capital preservation first, market-flow continuation second, opportunistic trend capitalization third.

The engine scans markets on a schedule, grades candidate setups with large language models, audits every candidate against a mathematical risk policy, and — only on the plans where you enable it — executes on your own exchange account through restricted API keys. Users retain full self-custodial control over exchange permissions at all times.

What ElquoAI is not

• Not a broker or custodian. Your funds never move to ElquoAI. All positions live on your exchange account, under your keys.
• Not financial advice. Signals and setups are generated for informational purposes; execution is voluntary and user-configured.
• Not a "always in the market" bot. The most common verdict on a choppy day is NO_TRADE — the engine is built to refuse risk, not to manufacture it.

2. Core Architecture

PROCESS MODEL · DATA STORES · FAILURE ISOLATION

ElquoAI runs as a decoupled multi-process suite so that web traffic, scanning, execution auditing, and price monitoring cannot degrade each other. A web request spike never delays a stop-loss check; a scanner outage never takes the dashboard down.

Processes and their jobs

Failure isolation

Auxiliary fetchers (news, macro calendar, Telegram feed) are wrapped in their own error boundaries: a failing news source can degrade news context, but it can never interrupt scanning or touch execution. The trading core is deliberately isolated from every enrichment path.

3. Execution Pipeline

SCHEDULING · GRADING · POLICY · VERDICTS

Every scan runs the same multi-stage pipeline. Nothing skips stages, and a failure at any stage degrades to a safe verdict — never to an unaudited trade.

3.1 Scheduling

Scans start from your plan's schedule: fixed daily queues on Essential, adaptive volatility-following schedules on Dynamic and above. Each plan has a hard daily scan allowance (5 / 8 / 14 / 24 across the paid tiers). The scheduler also respects news block windows: scans are automatically shifted away from high-impact macro prints (CPI, FOMC) instead of grading into chaos.

3.2 Market flow scan

The worker pulls candle histories and order-book state from the market-data feed, checks volatility and volume trends, and short-lists assets worth grading this cycle.

3.3 AI grading

A combined scout-and-validator prompt runs as a single LLM call: the scout side forms a trading thesis with a concrete bracket (entry, stop-loss, take-profit targets), the validator side audits that thesis against the same market data. The primary route is a frontier Anthropic Claude model with automatic fallback to secondary providers if the primary is unavailable. If the model output cannot be parsed, the scan is graded SYSTEM_ERROR — it is never silently retried into a trade.

3.4 Policy check

The risk engine (decision_policy.py) audits every candidate: duplicate exposure block, margin feasibility, fee-adjusted risk/reward threshold, daily drawdown headroom. A candidate that fails any check is refused regardless of how confident the model was.

3.5 Verdicts

4. Capital & Risk Model

SIZING · R:R CONSTRAINT · CIRCUIT BREAKERS

Risk rules are centralized in decision_policy.py and applied before any execution path is reached. They are mathematical constraints, not model suggestions — the LLM cannot override them.

4.1 Dynamic margin sizing

The maximum margin for a single position derives from account equity, your configured risk factor, and exchange leverage bounds:

4.2 Net risk/reward constraint

A candidate is invalid unless its reward-to-risk ratio — after estimated maker/taker fees — clears the minimum threshold:

4.3 Worked example

Example calculation with a $10,000 account, 1.5% risk per trade:

The dollar loss at the stop is fixed by construction — a wider stop means a smaller position, never a bigger loss.

4.4 Hard circuit breakers

5. Your Money & Your Keys

CUSTODY · KEY SECURITY · FAILURE MODES

This section answers the question an experienced trader should ask before connecting anything: what exactly happens with my money?

5.1 Custody model

Your funds never leave your exchange account. ElquoAI holds no balances, processes no deposits, and has no withdrawal path. The engine interacts with your account exclusively through exchange API keys that you create, you restrict, and you can revoke at any second from your exchange dashboard.

5.2 API key security

• Keys are encrypted at rest with AES-GCM (authenticated encryption; a unique nonce per secret) and stored in that encrypted form only.
• Decryption happens inside the execution process at the moment an order or telemetry call is made — keys are not held decrypted in long-lived state.
• A background API auditor continuously re-checks key permissions. If withdrawal rights or unverified permissions ever appear on a connected key, the key is de-authorized for execution instantly.

5.3 The execution path of one trade

1. A graded candidate passes every policy gate (sections 3-4).
2. On Pro, the bracket waits at an approval checkpoint — nothing is sent until you explicitly approve. On Apex autopilot, execution proceeds within your configured bounds.
3. The entry order is placed on your exchange account under your key.
4. Protective orders rest on the exchange itself: the stop-loss is a real STOP_MARKET order and each take-profit a real TAKE_PROFIT_MARKET order on Binance — not just software levels inside ElquoAI.
5. The Go WebSocket monitor tracks the position tick-by-tick as a second layer of enforcement and telemetry.

5.4 Failure modes, honestly

5.5 What ElquoAI cannot do

• Withdraw, transfer, or move funds in any direction — ever.
• Trade outside the futures permissions you granted the key.
• Exceed the drawdown, margin, and exposure limits you configured.

6. Exchange Setup Guide

KEY CREATION · PERMISSIONS · AUDITOR

Connecting an exchange takes five steps and roughly five minutes:

1. In your exchange account dashboard, create a new API key dedicated to ElquoAI — never reuse a key another service already holds.
2. Set the permission profile exactly as below — reading plus futures trading, nothing else.
3. If your exchange supports it, restrict the key to IP access listsfor defense in depth.
4. Paste the key and secret into the cockpit's exchange settings. They are AES-GCM encrypted before they are stored (section 5.2).
5. The API auditor validates the key's permission profile before execution is enabled — and keeps re-checking it for as long as the key is connected.

Required permission profile

7. Backtesting Suite

SANDBOX · PAPER · REPLAY

Three simulation layers exist so that a strategy configuration can be evaluated without risking capital, each one closer to live conditions:

Replay results are labeled as simulations everywhere they appear — simulated performance never mixes with live performance statistics.

8. Concrete Setup Examples

GRADED CANDIDATE · NO_TRADE · FIELD REFERENCE

A graded trade candidate produced by the scout and approved by the validator looks like this:

{
  "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."
}

And a refusal — the verdict you will see most on ranging days:

{
  "verdict": "NO_TRADE",
  "reason": "Range-bound structure; no continuation setup meets the net R:R threshold.",
  "rerun_after_minutes": 0
}

Field reference

9. FAQ & Troubleshooting

OPERATIONS · GRADING · ACCESS

SYSTEM_ERROR is graded when exchange APIs time out, WebSocket feeds drop, or a model payload cannot be parsed. It is excluded from performance statistics by design — a technical failure is never counted as a missed or losing setup.

Because the engine refused risk. Sideways structure, news block windows, or failed R:R thresholds all produce NO_TRADE verdicts, and a refusal never reruns itself. On genuinely poor days, zero trades is the correct output.

Per day: 5 on Essential, 8 on Dynamic, 14 on Pro, 24 on Apex — with 4 / 8 / 20 / 50 assets scanned concurrently. The full gate-by-gate breakdown is on the pricing page's capability matrix.

The primary route is a frontier Anthropic Claude model running the combined scout-and-validator analysis in a single call, with automatic fallback to secondary providers (OpenAI, Google) if the primary route is unavailable. Fallbacks follow the same output contract and the same policy audit.

Live Binance futures market data (prices, candles, order-book depth) via a dedicated market-data feed service — the same feed that powers the public order book on the landing page.

No. There is no withdrawal code path, keys are required to have withdrawals disabled, and the API auditor de-authorizes any key where withdrawal permissions appear. See section 5.

Stop-loss and take-profit orders rest on the exchange itself as real orders, so open positions keep their protection through an ElquoAI outage. No new positions are opened while the engine is down.

At docs.elquoai.com (also reachable at elquoai.com/docs), always in sync with the deployed cockpit version.