Gráfico em tempo real
Controle do bot
POC local — Spot Grid · MOCK / Testnet
POC educacional/técnica. Não é recomendação financeira.
Controle do bot
| Símbolo | Origem | Status | Preço MOCK | Criado em | Ações |
|---|---|---|---|---|---|
| Carregando… | |||||
| Símbolo | Entrada | Qtd bruta | Qtd vendável | Notional vendável | Resíduo | Inventário | P&L n/ realizado | Aberta em | Estratégia | Ações |
|---|---|---|---|---|---|---|---|---|---|---|
| Sem operações abertas | ||||||||||
| Símbolo | Entrada | Saída | Qtd | P&L USDT | P&L % | Aberta | Fechada |
|---|---|---|---|---|---|---|---|
| Sem operações fechadas | |||||||
| Símbolo | Side | Tipo | Status | Preço | Qtd | Notional | Motivo | Data |
|---|---|---|---|---|---|---|---|---|
| Sem ordens | ||||||||
—
Sem trades fechados no período para desenhar a curva.
| Início | Duração | Amostras | Diagnóstico |
|---|---|---|---|
| Sem incidentes na janela | |||
Operação: —
Esta ação remove somente o registro da operação no banco. Nenhum ativo será vendido e nenhuma ordem será cancelada. O histórico de ordens e o motivo permanecem para auditoria.
O bot vai operar na API oficial da Binance com fundos reais da sua conta. Confira o resumo:
Ordens LIMIT reais serão criadas e taxas reais (~0,1%/lado) serão cobradas. Perdas são reais. Este projeto é uma POC educacional — não é recomendação financeira.
Onde o bot opera. MOCK: tudo simulado localmente — nenhuma ordem vai para a Binance; fills acontecem quando o preço cruza o limite, aplicando a taxa e o slippage MOCK. BINANCE_TESTNET: ordens LIMIT reais na Spot Testnet (saldo fictício, chaves no .env) — ambiente de homologação. BINANCE_MAINNET: ordens reais com dinheiro real na API oficial; exige ALLOW_MAINNET_TRADING=true no .env, confirmação "OPERAR REAL" a cada início e respeita o teto de capital da fase de validação (100 USDT).
Exemplo: comece em MOCK para conhecer a estratégia; valide em BINANCE_TESTNET contra filtros reais; só então use BINANCE_MAINNET com capital pequeno.
Pares negociados em paralelo, sob uma única execução (portfolio). A lista vem do cadastro dinâmico da aba Símbolos (só pares ativos aparecem aqui), sem duplicata e sem limite fixo — mas atenção: quanto mais símbolos, menor a fatia de capital de cada um; a validação alerta quando a fatia por ordem se aproxima do notional mínimo (~5 USDT). Cada símbolo marcado ganha seu próprio bloco de parâmetros de grade/risco abaixo. O capital da carteira é dividido igualmente entre os símbolos selecionados no início do run (sobra de arredondamento fica com o 1º); a perda máxima diária é global (soma de todos os símbolos) e start/stop/pausa são sempre para o portfolio inteiro — não há controle por símbolo.
Exemplo: capital 1000 USDT com BTCUSDT + ETHUSDT marcados → cada engine recebe 500 USDT; se o P&L consolidado do dia atingir a perda máxima diária, os dois param juntos.
Semente da carteira persistente do modo. É usado apenas no primeiro início de cada modo (e no botão “Zerar saldo”); os próximos runs partem do saldo acumulado, que evolui com o P&L de cada trade. Os limites de risco do run são calculados sobre o saldo no momento do start.
Exemplo: 1000. Se o bot lucrar 25 USDT, o próximo run inicia com 1025.
Largura da grade, simétrica em torno do último preço no momento do start (não é fixa: cada start recalcula). O bot compra nos níveis abaixo do preço e vende um nível acima de cada compra. Máximo 20%.
Exemplo: preço 64.000 com ±2% → faixa 62.720 a 65.280.
Quantidade de níveis igualmente espaçados dentro da faixa (mínimo 2). O passo entre níveis é (topo − piso) ÷ (níveis − 1). Mais níveis = passo menor = trades mais frequentes e menores — atenção ao alerta de viabilidade: o passo deve cobrir pelo menos 3× o custo de ida e volta em taxas.
Exemplo: faixa ±2% com 6 níveis → passo ≈ 0,8% do preço. Com fee 0,1%/lado (round-trip 0,2%), está acima do mínimo recomendado de 0,6%.
Quanto investir em cada nível de compra. Vazio = automático: o orçamento de exposição disponível é dividido igualmente pelos níveis de compra. Preenchido, vale o menor entre o seu valor e o teto automático — nunca ultrapassa a exposição máxima.
Exemplo: exposição máx. de 500 USDT com 4 níveis de compra → automático ≈ 125 por nível; se você digitar 200, o bot usa 125 mesmo assim.
Limita a perda potencial de cada trade, não o valor investido. A perda potencial é estimada como a queda da entrada até a borda inferior da grade. Se a ordem planejada excede o limite, o tamanho é reduzido automaticamente (ORDER_SIZED_DOWN). Obrigatório para iniciar o bot.
Exemplo: 1% com capital 1000 → nenhuma operação pode arriscar mais que 10 USDT de perda potencial.
Trava de segurança sobre o capital do início do run. Ao atingir a perda realizada do dia (ou o drawdown de equity, incluindo posições abertas), o bot para sozinho: cancela ordens, liquida posições com ordens LIMIT e encerra o run. Obrigatório para iniciar.
Exemplo: 3% com capital 1000 → ao acumular −30 USDT no dia, o bot para automaticamente.
Teto de ordens simultâneas ativas (status NEW) do run. Ordem que ultrapasse o teto é rejeitada pelo risco, com o motivo registrado.
Exemplo: 12 — folga suficiente para uma grade de 6 níveis (BUYs + SELLs recicladas).
Teto de capital comprometido no símbolo: posições abertas + ordens BUY ativas, em % do capital do início do run. O dimensionamento automático por nível já respeita este teto (sizing e risco usam a mesma base).
Exemplo: 50% com capital 1000 → o bot nunca compromete mais que 500 USDT ao mesmo tempo.
Fee simulada por lado aplicada nos fills do modo MOCK, descontada do P&L de cada trade. Só afeta o MOCK.
Exemplo: 0.1 = 0,1% por ordem (padrão spot da Binance mainnet). Compra de 170 USDT paga ~0,17 de fee simulada.
Piora simulada no preço executado dos fills MOCK (compra sai um pouco mais cara, venda um pouco mais barata). Aproxima o resultado simulado da realidade. Só afeta o MOCK.
Exemplo: 0.02 → compra com limite 63.000 executa a ~63.012,60.
Não altera a execução — alimenta o alerta de viabilidade da grade. No testnet a fee real é 0 e qualquer grade “parece lucrativa”; este campo estima a fee da mainnet para avisar quando o passo da grade não cobre 3× o custo de ida e volta (aviso no Validar e no start, sem bloquear).
Exemplo: 0.1 → round-trip 0,2% → passo recomendado ≥ 0,6%. Com BNB (0,075%/lado), use 0.075.
Intervalo mínimo entre recentralizações da grade após rompimento confirmado (para cima ou para baixo). Evita que o bot persiga oscilações em mercado serrilhado, recentrando repetidamente. 0 desativa o cooldown.
Exemplo: 15 → depois de recentrar, o bot espera ao menos 15 min antes de recentrar de novo (decisão RECENTER_COOLDOWN no log).
Se o preço romper o piso da grade e ficar lá por mais de X horas com posições abertas, o bot cancela as vendas de alvo e liquida as posições com LIMIT no preço atual — realizando a perda — para liberar o capital e recentralizar a grade mais abaixo assim que ficar flat. 0 desliga (comportamento conservador: segurar até os alvos ou até o limite de perda diária). A perda realizada conta no limite diário.
Exemplo: 2 → no episódio da madrugada de 08/07 (rompimento às 04:50), o bot teria liquidado ~06:50 com perda de ~3 USDT e recentralizado, em vez de passar 4+ horas parado (decisão BELOW_RANGE_EXIT_STARTED no log).
Garante que as ordens de grade paguem sempre fee de maker na mainnet. Ligado, BUYs e SELLs da grade são enviadas como LIMIT_MAKER: se a ordem executaria na hora contra o book (fill como taker), a exchange a rejeita e o bot a reprecifica automaticamente 1 tick para dentro do preço atual (decisão POST_ONLY_REQUOTED, até 3 tentativas; persistindo, POST_ONLY_REJECTED e o nível volta no próximo ciclo). A saída de risco/liquidação nunca usa post-only — cruzar o book ali é intencional. Desligado (default), comportamento clássico: LIMIT comum com aviso TAKER_FILL_EXPECTED quando cruza. No MOCK a rejeição é simulada contra o último preço.
Exemplo: na análise de 10/07, 3 de 16 fills foram taker previstos; na mainnet cada um pagaria 0,1% de taker. Com post-only, viram re-quotes 1 tick dentro do book, mantendo a fee de maker.
Monitor embutido na API que sonda 3 camadas a cada ciclo (default 10s): gateway local (Wi-Fi/aparelho), DNS e TCP 443 na Binance. Cada incidente ganha um diagnóstico de onde a conexão morreu; o "maior gap entre amostras" revela suspensão do próprio processo/aparelho (deep sleep). As amostras ficam em arquivos locais diários com retenção configurável via NETMON_RETENTION_HOURS no .env (default 48h) — limpeza automática no boot e na virada de dia, teto de disco de ~3,5 MB. Outros parâmetros: NETMON_ENABLED, NETMON_INTERVAL_SECONDS, NETMON_TARGET_HOST. Somente leitura de rede: não usa API key nem interfere nas ordens.
Exemplo: incidente com diagnóstico "Wi-Fi/aparelho" nos minutos x4/x9 confirma power-save do Android; "Rota externa/Binance" com gateway ok isenta o aparelho.