O APEX PREDATOR V7 é um sniper de liquidação em OKX SWAP que opera scalps de alta intensidade em cima de choques de Open Interest, rejeição de pavio e contexto de funding, com execução em Rust (Tokio) e orquestração/auditoria em Python.
Ele não é um bot de “trend following” lento: ele tenta capturar o snap‑back logo após uma mini cascata de liquidação, entrando com precisão no pavio e saindo rápido via hard stop, time stop e trailing scalper.
Arquitetura Você tem três componentes principais:
rust_core/src/main.rs: motor de execução, leitura de WebSocket da OKX (OI, funding, candles), cálculo de sinal e envio/fechamento de ordens.
python_brain/main_orchestrator.py: “Maestro” que escolhe os alvos na OKX, segura o servidor IPC, recebe relatórios de trades, grava CSV e calcula estatísticas em tempo real.
python_brain/dashboard.py: painel Streamlit que consome o CSV de trades e mostra curva de PnL, win rate e log de operações ao vivo.
Comunicação Rust ↔ Python é via TCP local (127.0.0.1:9001), com mensagens JSON SET_TARGETS, TRADE_OPENED e TRADE_CLOSED.
Lógica de alvo e dados de mercado O Maestro faz:
Puxa market/tickers?instType=SWAP na OKX, filtra só *-USDT-SWAP com volume 24h (volCcy24h) acima de 10M USD.
Garante que majors estejam sempre dentro: BTC, ETH, SOL, XRP, BNB.
Monta um top 10 por volume, manda isso pro Rust como {"action":"SET_TARGETS","symbols":[...]}.
A cada 1h, reavalia o ranking e, se mudar, reenvia novos alvos.
O motor Rust:
Usa REST pra pegar tickSz e ctVal de cada instId e montar ordens com preço e tamanho corretos.
Abre dois WebSockets:
public: open-interest e funding-rate para cada alvo.
business: candle1m para cada alvo.
Candles 1m alimentam:
last_close
upper_wick_ratio e lower_wick_ratio (pavio em % do candle)
last_candle_ts (timestamp)
OI + funding alimentam:
current_oi, highest_oi (pico em janela de 5 min), drop_pct relativo a esse pico.
oi_panic_score: velocidade recente do OI com decaimento exponencial.
current_funding em %.
Setup de entrada A função evaluate_signal recebe o estado da moeda (CoinState) e o current_time e devolve TradeSignal::Short, Long ou None.
Filtros:
Só opera se tiver last_close, highest_oi e last_candle_ts.
Respeita cooldown por símbolo (COOLDOWN_SEC, hoje 120s).
Exige que o drop de OI seja muito recente: current_time - highest_oi_ts <= 15s.
Exige drop_pct mínimo: drop_pct >= OI_DROP_ALARM_PCT (1.5% padrão).
oi_panic_score precisa passar de um threshold dinâmico baseado em highest_oi e OI_DROP_ALARM_PCT.
Candle precisa ser “vivo”: idade do candle <= 10s.
Funding entra como bias, não gate: funding positivo fortalece short, negativo fortalece long; neutro não bloqueia.
Scoring:
short_score = drop_pct * 0.5 + upper_wick_ratio * 0.3 + funding_bias_short * 20 (se pavio de topo > MIN_WICK_RATIO).
long_score = drop_pct * 0.5 + lower_wick_ratio * 0.3 + funding_bias_long * 20 (se pavio de fundo > MIN_WICK_RATIO).
Só dispara se o maior dos dois scores ≥ min_score (10.0).
Se o sinal for Short ou Long, o sniper:
Calcula notional = saldo_usdt * RISK_PER_TRADE_PCT (1% hoje).
Converte isso em contratos usando ct_val e preço: sz = floor(notional / (price * ct_val)), mínimo 1.
Envia POST‑only maker com ordType="post_only" na OKX via REST.
Só ativa position_active depois de confirmação (code == "0").
Dispara um TRADE_OPENED pro Maestro com todo o contexto: oi_drop_pct, oi_panic_score, wick, funding, tamanho, lado, entry_price, timestamp.
Gestão de posição e saídas Enquanto position_active = true, cada tick de OI/trade chama evaluate_exit:
Calcula PnL em % com base em entry_price e last_close (short ou long).
Atualiza max_favorable_pnl.
Regras de saída:
Stop Loss hard: PnL ≤ −STOP_LOSS_PCT (1.5% hoje) → StopLoss.
ScalperTrail: se max_favorable_pnl ≥ trail_trigger (1.5%) e PnL devolveu mais que trail_gap (0.8%), sai (ScalperTrail).
Take Profit nominal: se PnL ≥ TAKE_PROFIT_PCT (2.5%) e trailing não acionou, sai (TakeProfit).
Time stop: se duration > TIME_STOP_SEC (90s), fecha:
Se PnL > 0 → TimeStopProfit.
Senão → TimeStopLoss.
Quando decide sair:
Loga 🛡️ [SAÍDA] symbol | reason | PnL | Duração.
Manda ordem market na OKX para fechar a posição (lado oposto, mesmo posSide).
Envia TRADE_CLOSED pro Maestro com: symbol, side, entry_price, exit_price (last_close), pnl_pct, duration_sec, exit_reason, timestamp.
Reseta estado da posição (position_active=false, size=0, etc.) e aplica cooldown (last_shot_ts = now).
Auditoria e estatísticas Python Maestro faz:
inicializar_csv() cria dois arquivos:
auditoria_scalper.csv (trades fechados).
auditoria_entradas_scalper.csv (contexto de entrada).
gravar_trade_csv() recebe TRADE_CLOSED e loga:
timestamp, symbol, side, entry_price, exit_price, pnl_pct, duration_sec, exit_reason.
gravar_entrada_csv() recebe TRADE_OPENED e loga:
timestamp, symbol, side, entry_price, position_sz, oi_drop_pct, oi_panic_score, upper/lower_wick_ratio, funding_pct.
MaestroState mantém estatísticas em memória:
total_trades, winning_trades, total_pnl.
por símbolo (wins, losses, pnl).
por motivo de saída (STOP_LOSS, TAKE_PROFIT, etc.).
print_stats() mostra:
Win rate com contagem W/L.
PnL total e médio.
Distribuição de motivos.
Alerta se win rate < 40% depois de 20 trades.
Dashboard O dashboard.py:
Lê auditoria_scalper.csv.
Se vazio, mostra mensagem de “Sniper na espreita”.
Caso tenha dados:
KPIs: total trades, win rate, PnL acumulado, PnL médio.
Curva de capital: pnl_pct.cumsum() em gráfico de linha.
Gráfico de barras de exit_reason.
Tabela de auditoria invertida (últimos trades em cima) com PnL colorido (verde/vermelho).
Atualiza automaticamente a cada 10s com st.rerun().
Diferenciais reais desse bot Motor em Rust + Tokio: latência baixa, WS estável, reconexão automática, heartbeat ativo.
Setup centrado em OI: não é só price action; ele usa flush de OI e velocidade de mudança (panic score) para diferenciar ruido de liquidação real.
Wick + funding como filtros de contexto: evita tomar trade em candle morto ou contra funding extremo; wick garante entrada no extremo da barra.
Gestão de risco explícita: risco por trade em % do saldo, stop loss curto, trailing scalper e time stop agressivo.
Auditoria full: tudo em CSV, com contexto de entrada + resultado da saída, permitindo backtest offline e tuning quantitativo de thresholds.
Arquitetura separada: Python cuida de orquestração, estatística e dashboards; Rust só pensa em latência e execução.