WAMCOS — математика и логика торговли

Документ для оператора и аналитика: как система принимает решения и считает уровни. Без инфраструктуры, API и листингов кода. Полная архитектура — в canvas.md.

1. Роль системы

Автоматическая торговля бессрочными SWAP на OKX (в т.ч. demo). Источники сигналов — RSS (вкладка «Новости»), Telegram MTProto (live-каналы) и RSSHub (локальный контейнер, username каналов в TG Sentinel, без MTProto). Языковая модель даёт только тональность; цены входа, стопа и объёма считаются детерминированно.

Направление сделки (после всех фильтров): Score ≥ 0 → лонг (Buy); Score < 0 → шорт (Sell).

1.1. Режимы инициации сделок

Переключатель в админке: execution.trading_strategy_mode (default event_driven).

В режиме trend_validation новости по-прежнему собираются и анализируются LLM в news_cache, но после AI не вызываются Risk Gate / MarketAnalyzer / ордер по новости. Торговля — только цикл MARKET_TRIGGER (см. § 2.2).

1.2. Ручная торговля (оператор)

Два независимых слоя на вкладке Admin «Ручная торговля»:

Оператор задаёт пару, side, тип ордера (Market / Limit / PostOnly), объём USD, плечо, режим маржи (cross/isolated), стоп (% или дефолт пары). Расчёт контрактов и стопа — те же формулы, что в § 5 и § 6; для Market базовая цена — last (тикер), для Limit/PostOnly — введённая limit_price.

2. Конвейер решения

2.1. Event-Driven Core (по умолчанию)

flowchart TD
    N[Новость RSS или TG] --> K{Ключевые слова?}
    K -->|нет| Skip[Пропуск]
    K -->|да| H[Дедуп по hash]
    H --> AI[LLM: score, confidence]
    AI --> G[Risk Gate 1–8]
    G -->|отказ| Skip
    G --> M[MarketAnalyzer 9–11]
    M -->|вето| Skip
    M --> E[Расчёт входа и объёма]
    E --> O[Лимит на бирже + SL]
    O --> Gd[Guardian: fill / TTL / kill-switch]

Одна новость может дать сигнал на несколько пар из списка execution.pairs[] (у каждой свои keywords и параметры). Вход по паре (hash новости, symbol) — не более одного раза (news_trade_dispatches + pending в одной транзакции до PlaceOrder).

2.2. Trend-Validation Smart

flowchart TD
    T[Каждые N мин] --> S[Снапшот пары]
    S --> TR{RSI и channel_pos?}
    TR -->|нет| Log[Лог опроса + rsi/ch]
    TR -->|long/short| NW[Новости за окно H ч]
    NW --> V{AI veto JSON}
    V -->|veto| Skip[Пропуск]
    V -->|ok| I[Infra Risk 1–2,5–7]
    I -->|ok| E[ExecuteSignal mkt:]
    E --> Gd[Guardian как обычно]

Параметры: market_trigger_poll_interval_min (5), пороги RSI/канала — в execution.*. Формулы RSI/канала — общий пакет internal/pkg/math (тот же расчёт, что у MarketAnalyzer).

3. Risk Gate — проверки 1–8

Все условия обязательны по порядку. При нарушении любого — ордер не выставляется.

Дополнительно перед ордером: preflight доступной USDT-маржи. Для SWAP код оценивает initial margin как notional / risk.swap_leverage × (1 + margin_buffer_pct%) (default leverage 10, buffer 5%), а не требует весь notional. Перед PlaceOrder для SWAP вызывается OKX POST /account/set-leverage (risk.swap_leverage, cross); при ошибке API — fail-closed (ордер не выставляется).

4. MarketAnalyzer — проверки 9–11

Выполняется после Risk Gate. Может запретить сделку или уменьшить/увеличить объём (VolumeMultiplier ∈ [0.5 … 1.25]).

4.1. Свежесть данных (шаг 9)

Снапшот рынка не старше 10 минут. Иначе — отказ stale_market_data.

Данные обновляются фоном каждые 5 мин (свечи 4H и 15M с биржи).

4.2. Индикаторы в снапшоте

EMA 200

• Первое значение: SMA первых 200 цен закрытия.
• Коэффициент сглаживания: \(k = \dfrac{2}{200+1}\).
• Рекуррентно: \(\text{EMA}_t = \text{Close}_t \cdot k + \text{EMA}_{t-1} \cdot (1-k)\).
• BULLISH, если последний close > EMA200; иначе BEARISH.

Регрессионный канал (100 свечей)

Линейная регрессия \(y = a x + b\), где \(x = 1..100\), \(y_i\) — close.

\[ a = \frac{N\sum xy - \sum x \sum y}{N\sum x^2 - (\sum x)^2}, \quad b = \frac{\sum y - a\sum x}{N} \]

Стандартное отклонение остатков \(\sigma\). На текущей свече (\(x = N\)):

\[ \text{Base} = aN + b,\quad \text{ChannelHigh} = \text{Base} + 2\sigma,\quad \text{ChannelLow} = \text{Base} - 2\sigma \]

\[ \text{ChannelPos} = \mathrm{clamp}\left(\frac{\text{Price} - \text{ChannelLow}}{\text{ChannelHigh} - \text{ChannelLow}},\, 0,\, 1\right) \]

Направленный Фибоначчи

За 100 свечей: SwingHigh = max(high), SwingLow = min(low), Range = SwingHigh − SwingLow.

RSI 14 (Уайлдер)

\(\Delta_t = Close_t - Close_{t-1}\). За первые 14 изменений — средние gain и loss. Далее:

\[ \overline{Gain}_t = \frac{13 \cdot \overline{Gain}_{t-1} + gain_t}{14}, \quad \overline{Loss}_t = \frac{13 \cdot \overline{Loss}_{t-1} + loss_t}{14} \]

\[ RS = \frac{\overline{Gain}}{\overline{Loss}}, \quad RSI = 100 - \frac{100}{1 + RS} \]

Если \(\overline{Loss} = 0\) → RSI = 100.

4.3. Тренд пары и поводыри (шаг 10)

4.4. Матрица объёма RSI × канал (шаг 11)

Для лонга — таблица ниже. Для шорта перед таблицей: \(RSI' = 100 - RSI\), \(Pos' = 1 - ChannelPos\).

Итог: сначала применяются BTC/ETH-правила, затем BTC-множитель умножается на min(доли по RSI, доли по каналу) и результат clamp'ится в диапазон 0.5 … 1.25. Достаточно одного фактора зоны D для полного вето. Пример: bearish BTC + bearish альт + Sell даёт базово 1.25; если RSI/канал дают 0.75, итоговый множитель будет 0.9375, а не 0.75.

5. Расчёт цены входа и стопа

От текущей рыночной цены \(P_{mkt}\) (тикер в момент сигнала). Параметры — на пару: entry_offset_pct, stop_loss_pct, trailing_pct.

Обозначения: \(o = entry\_offset\_pct / 100\), \(s = stop\_loss\_pct / 100\).

Лонг (Buy)

\[ P_{entry} = P_{mkt} \cdot (1 - o) \] \[ P_{stop} = P_{entry} \cdot (1 - s) \]

Шорт (Sell)

\[ P_{entry} = P_{mkt} \cdot (1 + o) \] \[ P_{stop} = P_{entry} \cdot (1 + s) \]

Пример (лонг)

\(P_{mkt} = 5.40\), offset 0.1%, stop 1.5%:

Пересчёт стопа после fill (Guardian)

Лимитный вход может исполниться по цене, отличной от \(P_{entry}\) в момент сигнала. Чтобы сохранить заданный stop_loss_pct, Guardian пересчитывает стоп от фактического AvgPx:

\[ s\% = \frac{|P_{stop,plan} - P_{entry,plan}|}{P_{entry,plan}} \times 100,\quad P_{stop,fill} = P_{fill} \times (1 \mp s/100) \]

(минус для Buy, плюс для Sell). В БД (positions.stop_price) записывается \(P_{stop,fill}\). Если SL уже привязан к ордеру (algo_ord_id), Guardian вызывает OKX amend-algos с newSlTriggerPx (и newSz при partial fill).

6. Расчёт размера позиции

1. Базовый бюджет: max_position_usd по паре (или глобальный fallback) — целевой notional, не жёсткий потолок (§ 12).
2. Event-driven: умножить на VolumeMultiplier из MarketAnalyzer (диапазон 0.5–1.25; усиление шорта ×1.25 только при BTC BEARISH и тренде альта BEARISH). Trend-Validation: база 1.0, только BTC-поводырь (×0.5 long при BTC BEARISH), без матрицы RSI×канал.
3. Для SWAP: qtyUSD / price / ctVal, округление по lotSz.
4. Если ниже minSz биржи — минимально допустимый размер (фактический notional может превысить бюджет; лог min_sz_upscale).
5. Preflight баланса: оценка IM ≈ notional / swap_leverage × (1 + margin_buffer_pct%), не весь notional; затем синхронизация плеча на бирже (SetSwapLeverage) — fail-closed при ошибке.

\[ Budget_{final} = max\_position\_usd \times VolumeMultiplier \]

7. Исполнение и жизненный цикл ордера

7.1. Открытие

1. Лимитный ордер на \(P_{entry}\).
2. К ордеру привязывается стоп-лосс на бирже (algo) на весь объём входа.
3. При trailing_pct > 0 трейлинг выставляется после исполнения лимитки (отдельный algo), не вторым attach при входе; trailing_algo_id сохраняется в positions.meta.
4. В учёте: сначала pending order; строка позиции — только после fill (или после сценария partial TTL). stop_price в позиции — после пересчёта от fill; algo_ord_id / trailing_algo_id — в meta для точного PnL.
5. Event-driven (content_hash новости): в одной транзакции — news_trade_dispatches claim + pending (без okx_order_id); при дубликате claim ордер не отправляется. После PlaceOrder — UpdatePendingOrderOKXID. Trend-Validation: hash mkt:…, отдельный guard в execution (не смешивается с news hash).

Новый вход по той же паре ограничен max_positions_per_symbol: при default 1 наличие pending или open блокирует повторный вход; если лимит поднять выше 1, код допускает несколько одновременных слотов по symbol.

7.2. TTL лимитки — 15 минут

7.3. Выход

7.4. Ручное открытие (Manual Open)

flowchart TD
    OP[Оператор: LONG/SHORT] --> KS{Kill-switch?}
    KS -->|да| Block[Отказ]
    KS -->|нет| Bal{Достаточно USDT IM?}
    Bal -->|нет| Block
    Bal -->|да| Lev[SetSwapLeverage + tdMode]
    Lev --> Calc[Контракты + SL от entry]
    Calc --> PO[PlaceOrder + attach SL]
    PO --> DB[InsertPendingOrder meta.source=manual]
    DB --> Gd[Guardian: как автоматический вход]

Стоп: custom_stop_pct; если 0 — stop_loss_pct пары. Формулы § 5 от выбранной entry-цены. SL на бирже — sl_trigger_px_type (mark / last / index).

После успеха ордер виден на вкладке Ордеры с бейджем «Ручная» (orders.meta.source = manual). Guardian: TTL 15 мин, partial fill, пересчёт SL от fill — как в § 7.2 и § 5.

UI (Quick Trade PRO): график Lightweight Charts 4.2.2, TF 15m/1H/4H/1D, линии Entry/SL на графике при изменении параметров; live estimate контрактов/маржи через manual-estimate; кнопка «Спросить у ИИ» и drawer с анализом — § 7.5. Post-Only отключён при Market; Reduce-Only — предупреждение и readonly объёма.

Ограничение: принудительная смена set-position-mode на бирже не выполняется — только проверка текущего режима аккаунта (RequireSwapAccountMode).

7.5. Ask AI Vision (советник)

Итерация 5.6 (Vision hybrid datapack): при клике Core собирает Market Snapshot Bundle и отправляет его в LLM вместе с опциональным скриншотом. Подробности API, OKX endpoints и промпты — canvas.md §4.2.2.

flowchart TD
    Q[Спросить у ИИ] --> M{include_image?}
    M -->|да| PNG[Скрин #manual_chart_wrap или chart.takeScreenshot]
    M -->|нет| TXT[Только текстовый дата-пакет]
    PNG --> API[POST manual-analyze-vision]
    TXT --> API
    API --> BUNDLE[Core: параллельно OKX свечи 15m/1H + funding/OI/books/LSR]
    BUNDLE --> IND[ATR/ATR% MACD RSI compression + macro 4H EMA distance]
    IND --> LLM[Vision LLM: primary → fallback]
    LLM --> AUDIT[ai_audit_logs + async PNG audit_id.png]
    AUDIT --> DR[Drawer: analysis RU + recommendation]
    DR --> AP{trade_recommended?}
    AP -->|да| FILL[Применить → поля mt_* + линии + estimate]
    AP -->|нет| READ[Только чтение анализа]
    FILL --> OP[Оператор сам жмёт LONG/SHORT → § 7.4]

Роль: пассивный советник. ИИ не выставляет ордер; после «Применить рекомендации» оператор вручную подтверждает сделку.

Что уходит в LLM (текст + опционально PNG):

При недоступности деривативов/стакана в промпт подставляется N/A — запрос не падает. Если 4H-снапшот устарел — префикс [STALE 4H MACRO DATA] в user prompt.

Не отправляется: открытые позиции; base64 скрина в БД (только файл на диске).

Справочник параметров дата-пакета (для трейдера)

Всё ниже попадает в user prompt (текст к модели), кроме system prompt (отдельный блок инструкций на EN) и скриншота (опционально, визуальный слой). Технические детали кода — canvas.md §4.2.2, таблица «Полный каталог входа LLM».

Визуальный слой

Черновик сделки (из формы Quick Trade)

OHLC (текстовые массивы свечей)

Моментум и волатильность (15m)

Range compression (15m)

Макро-структура (4H, снапшот MarketAnalyzer)

Если снапшот 4H недоступен — в начале промпта [STALE 4H MACRO DATA], макро-поля N/A.

Деривативы (OKX, публичные)

Стакан (top-5 уровней)

Что модель возвращает (не вход, а выход)

Ответ Core (JSON):

Применение в UI: перенос в поля mt_*, линии Entry/SL, manual-estimate. Кулдаун кнопки — 30 с.

Настройки: ИИ → Подключение (ai_connection: серверы, primary/fallback), ИИ → AI Vision (ai_vision: enabled, vision_model_id, system/user prompt). Полный список плейсхолдеров user prompt — справочник выше и canvas.md §4.2.2 (таблица по коду).

Просмотр последнего запроса: Admin → Журналы → Логи анализа новостей → Purpose vision → клик по строке → User prompt (весь дата-пакет) / Raw response (ответ модели). Скриншот: storage/ai_vision_screenshots/{audit_id}.png.

8. Kill-switch и возобновление

При kill-switch:

• Снять лимитки по всем instId из execution.pairs[] + символы open/pending в БД.
• Закрыть каждую open позицию рыночным reduce-only.
• trading_enabled = false, kill_switch = true.

Guardian при активном kill-switch: не открывает позицию из pending; live — cancel; при fill/partial — немедленный market close, позиция в БД не создаётся.

/resume: снимает kill-switch, снова разрешает торговлю; не переоткрывает позиции.

9. Симулятор (Dry-Run)

Тот же конвейер AI → Gate → Analyzer → расчёт уровней, без ордера на бирже.

Golden cases — эталонные сценарии для регрессии (вето RSI, вход TRX/BTC, отказы gate/analyzer).

10. Настраиваемые параметры (сводка)

11. Функциональные возможности (статус)

12. Известные ограничения и риски

Сводка аудита логики (2026-05); детали инфраструктуры — в canvas.md §4.7.

Рекомендации для live: golden-сценарии minSz выше бюджета, BTC bearish short ×1.25 с урезанием матрицей, partial fill + amend SL, stale на границе 10 мин; для Trend-Validation — отдельные кейсы в симуляторе.