Trader IDONEO.Dev Panel admin

Scalping Binance

Este artículo es el manual de lógica del bot (entradas, DCA, límites de cuenta, tamaño de orden y datos persistidos). La automatización es por reglas técnicas sobre velas de Binance: no usa IA ni LLM. Es independiente del job bot:run-signals (señales con order blocks + IA en Cómo funciona el bot).

Qué hace

  • Entradas (scalping:binance-run, cada minuto si aplica): recorre un universo de símbolos, comprueba filtros de activación, y solo si en la última vela cerrada del timeframe bajo (LTF) hay un touch de order block coherente con el lado (long/short), puede abrir con MARKET y colocar SL/TP según tu configuración (apalancamiento, notional, TP fijo o trailing, etc.). Opcionalmente exige un sesgo de fair value gap en timeframe alto (HTF FVG) alineado con el touch.
  • DCA (scalping:binance-dca, cada minuto si aplica): recorre posiciones abiertas en Binance que el sistema considera gestionadas por este flujo (según ciclo de eventos en la app) y, si cumples presupuesto y reglas, añade tamaño con órdenes MARKET en Binance. Si el destino de entradas es Finandy webhook, el DCA no ejecuta por API (solo Binance).
  • Cierre fuera de ventana (scalping:binance-outside-window-close, cada minuto si aplica): cuando hay ventanas horarias definidas y el reloj está fuera de ellas, puede cerrar con MARKET las piernas en beneficio que superen un mínimo de movimiento de precio a favor desde la entrada media (no ROI sobre margen). Detalle en Cierre fuera de ventana.

Cuándo corren los cron

Los comandos de scalping están programados cada minuto con withoutOverlapping, pero solo si:

  • SCALPING_BINANCE_MASTER_ENABLED no desactiva el sistema (por defecto true).
  • Hay al menos un usuario con scalping activo (panel) o usuario de fallback por entorno, según la lógica de la app.
  • Para el job de DCA hace falta un presupuesto DCA por usuario: max_dca_usdt > 0 y/o SCALPING_BINANCE_MAX_DCA_PCT_OF_CAPITAL (o override en JSON del executor); si ambos, se usa el mínimo del techo en USDT y del techo porcentual sobre el capital.
  • El job de cierre fuera de ventana usa el mismo interruptor global y usuarios activos que el run de entradas; no exige presupuesto DCA. Condiciones lógicas adicionales: ver sección.

Cierre fuera de ventana (off-hours)

Proceso separado del run de entradas y del DCA. Sirve para reducir exposición cuando no operás entradas nuevas según tu ventana horaria, cerrando en mercado las piernas que ya van ganando lo suficiente en términos de precio.

  • Ventanas obligatorias: si SCALPING_BINANCE_TRADING_WINDOWS_JSON está vacío (o equivalente en panel), el sistema considera operación 24/7 y no existe “fuera de ventana” → este job no hace nada. Primero definí al menos una franja en SCALPING_BINANCE_TIMEZONE.
  • Interruptor: por defecto está activo (SCALPING_BINANCE_CLOSE_PROFITABLE_OUTSIDE_WINDOW=true). Puedes desactivarlo con =false o con el mismo campo en el JSON del executor (close_profitable_outside_window_enabled), según fusiones panel/env.
  • Cuándo corre: solo cuando el reloj (timezone + días hábiles si los usas) está fuera de las ventanas configuradas. Dentro de la ventana, no intenta estos cierres.
  • Qué cierra: posiciones USDT‑M con notional ≥ mínimo de posición; PnL no realizado > 0 y movimiento favorable desde el precio medio de entrada ≥ umbral. El umbral es % de precio respecto al entry (long: (mark − entry) / entry; short: (entry − mark) / entry), no el ROI sobre la garantía. Por defecto en config: 0,1 (= 0,1 %). Variable: SCALPING_BINANCE_OUTSIDE_WINDOW_CLOSE_MIN_PROFIT_PCT.
  • Solo piernas gestionadas (por defecto): si SCALPING_BINANCE_OUTSIDE_WINDOW_CLOSE_MANAGED_ONLY=true, solo aplica a posiciones con el mismo criterio de “ciclo abierto” que el DCA (entradas/DCAs del flujo en signal_run_events). Con false puede incluir cualquier posición elegible por notional.
  • Ejecución: órdenes MARKET reduce-only (misma API que otros cierres). Requiere claves Binance en el panel; si solo usas Finandy sin API, no se puede cerrar por este camino.
  • Entradas vs DCA vs este cierre: el run de entradas sí respeta la ventana horaria. El DCA hoy no la consulta (puede seguir añadiendo fuera de ventana si tus reglas lo permiten). Este job solo actúa fuera de la ventana y no sustituye a TP/SL en Binance.
  • Eventos: en la actividad aparecen como scalping_binance_outside_window_close (y variantes dry/fallo). Cuentan para reconciliación de trades análoga a TP en analytics.

Flujo de entradas (resumen)

  1. Universo: lista fija, ganadores/perdedores o similar (según configuración por usuario y SCALPING_BINANCE_MOVERS_TOP u overrides). Eso solo elige qué pares mirar; el lado del trade lo marca el touch de OB (y FVG si aplica). Si quieres limitar long/short por lista 24h, usa SCALPING_BINANCE_MOVERS_LOSERS_SIDE y SCALPING_BINANCE_MOVERS_GAINERS_SIDE (both = sin filtro extra; long_only / short_only).
  2. Activación: umbrales de movimiento 24h e intradía (si los configuras) para filtrar símbolos “vivos”.
  3. Sin posición previa en ese contrato por encima del mínimo de notional (no duplica si ya hay exposición).
  4. Cooldown por símbolo tras una entrada, y opcionalmente cooldown tras stop si lo usas.
  5. Touch OB en LTF: detección de order blocks y de entradas en la vela cerrada; el lado debe coincidir con long/short permitidos.
  6. FVG HTF (opcional): si require_htf_fvg_bias está activo, se pide coherencia entre el sesgo FVG del HTF y el lado del touch.
  7. Caps: máximo de posiciones concurrentes long y short en paralelo.
  8. Ejecución: en Binance API (MARKET + órdenes de protección/TP) o envío mínimo a Finandy si configuraste ese destino; no hay llamada a IA.

Flujo de DCA (resumen)

  1. Solo posiciones elegibles (rastreadas por el ciclo de eventos de la app; posiciones abiertas “a mano” fuera de este flujo pueden ignorarse).
  2. Modo simple (adverse %): si no activas “señal estilo entrada”, el precio debe haberse movido en contra respecto a la entrada media por un % mínimo (dca_adverse_move_pct).
  3. Modo entry-style: si activas dca_require_entry_style_signal, el mismo tipo de lógica que en entradas (touch OB en LTF en la vela cerrada, más FVG HTF si lo exiges) debe darse para permitir el add; el **filtro FVG del DCA** puede ir aparte del de entradas con dca_require_htf_fvg_bias (si no lo defines, el DCA hereda la regla de entradas).
  4. Monotonic mark (por defecto): cada nuevo add debe ejecutarse en un mark más desfavorable que el anterior add (evita promediar en rebotes).
  5. Separación mínima entre adds respecto al precio de referencia anterior.
  6. Cooldown entre adds y techo de USDT DCA acumulado por posición.
  7. Tamaño del slice: USDT fijo; si no, opcionalmente % del capital de cuenta (SCALPING_BINANCE_DCA_SLICE_PCT_OF_CAPITAL, misma fuente que ENTRY_CAPITAL_SOURCE); si no, progresión desde el notional de entrada ya dimensionado (incluye ENTRY_NOTIONAL_PCT_OF_CAPITAL); si no, SCALPING_BINANCE_DCA_SLICE_POSITION_PCT explícito sobre notional abierto; si no, por defecto SCALPING_BINANCE_DCA_DEFAULT_SLICE_PCT_OF_OPEN (175 = 1,75× el notional abierto antes de cada add, incremental).

DCA: progresión ×M y presupuesto (referencia rápida)

Con SCALPING_BINANCE_DCA_SLICE_PROGRESSION_MULTIPLIER = M (> 1, p. ej. 1,75) y sin slice fijo ni % de capital, el objetivo de cada add escala como potencias de M sobre el notional de entrada ya resuelto E (el mismo baseNotional que usa el job DCA: columna o % de capital según configuración). El bot no expone un “máximo 3 DCAs” por contador: el tope práctico es el presupuesto max_dca_usdt / MAX_DCA_PCT_OF_CAPITAL (y mínimos de orden).

Para tres adds en esa progresión, el orden de magnitud del presupuesto USDT (antes de redondeos LOT / min_order_notional_usdt) es:

max_dca ≳ E · (M + M2 + M3)

Ejemplo con E = 25 USDT y M = 1,75:

25 × (1,75 + 1,752 + 1,753) = 25 × 8,859375 ≈ 221,48 USDT

Si operás presupuesto solo en % del capital, misma idea: fijá SCALPING_BINANCE_MAX_DCA_PCT_OF_CAPITAL de forma que capital × pct/100 cubra ese orden de magnitud (más un margen si querés holgura).

Manual de lógica — orden de un scalping:binance-run

Por cada minuto y por cada usuario activo, el servicio ejecuta más o menos este orden (si un paso corta el flujo, lo siguiente no corre para ese usuario en ese tick):

  1. Interruptor global SCALPING_BINANCE_MASTER_ENABLED y existencia de fila activa (o fallback por .env).
  2. Credenciales: si ejecutas por API Binance y no hay claves, se omite el usuario (Finandy sin claves puede seguir con klines públicos).
  3. Ventana horaria (SCALPING_BINANCE_TRADING_WINDOWS_JSON + SCALPING_BINANCE_TIMEZONE): fuera de ventana, el run termina para ese usuario.
  4. Universo de símbolos (lista, movers, etc.) y un fetch de ticker 24h compartido.
  5. Tamaño de entrada: si ENTRY_NOTIONAL_PCT_OF_CAPITAL > 0, el notional objetivo se calcula como capital × pct / 100 según ENTRY_CAPITAL_SOURCE (wallet | available | margin), con piso min_order_notional_usdt y techos opcionales ENTRY_NOTIONAL_MAX_USDT y/o ENTRY_NOTIONAL_MAX_PCT_OF_CAPITAL (se aplica el más restrictivo). Con pct = 0 se usa NOTIONAL_USDT fijo.
  6. Snapshot de posiciones (API positionRisk): filas “relevantes” y la suma de notionales abiertos Σ(|cantidad| × mark).
  7. Puertas de cuenta (solo si hay snapshot + API firmada): una sola lectura de cuenta USDT‑M.
    • Exposición máxima (MAX_OPEN_EXPOSURE_PCT, 0 = apagado): si (notional abierto total) / (capital) > límite%, no se procesa ningún símbolo en ese minuto. El “notional abierto” es la suma API de todas las posiciones USDT‑M (igual que sumar la columna “tamaño”/notional de cada fila en tu tabla de posiciones), no el PnL no realizado de cada fila (−0,5 USDT, etc.) ni un “300” leído por símbolo.
    • PnL no realizado: con SKIP_NEW_ENTRIES_UNREALIZED_PNL_GTE_PCT > 0, no hay nuevas entradas si el totalUnrealizedProfit ≥ capital × pct / 100 (misma fuente de capital). Si no, opcionalmente SKIP_NEW_ENTRIES_UNREALIZED_PNL_GTE_USDT (umbral fijo en USDT). Solo aplica con beneficio flotante; PnL flotante negativo no dispara la regla.
    • No confundir con el widget de “% del wallet” por PnL: el mensaje de bloqueo por exposición habla de notional abierto total frente al límite % del capital, no del porcentaje de pérdida/ganancia del saldo.
    En esos bloqueos se puede registrar un evento scalping_binance_account_gate para ver el motivo en la consola del panel.
  8. Sincronización de brackets / SLX (si aplica).
  9. Por símbolo: activación 24h/intraday, sin posición previa relevante, cooldowns, slots long/short, touch de order block en LTF, FVG en HTF si está exigido, cálculo de cantidad y envío MARKET + SL/TP (o webhook Finandy).

Apalancamiento vs volumen (USDT)

  • SCALPING_BINANCE_LEVERAGE (o el del JSON) fija el apalancamiento en Binance antes de la orden; no multiplica el notional en USDT que calcula el bot.
  • El “volumen” que dimensionas en la app es notional en USDT (tamaño de la posición en dólares de contrato), no “% de margen × leverage” como en otros frontends. Ej.: wallet ~100 USDT y 20 USDT de notional por entrada → ENTRY_NOTIONAL_PCT_OF_CAPITAL=20.

Tabla de actividad y base de datos

  • Los eventos visibles en la consola de scalping salen de la tabla signal_run_events (modelo SignalRunEvent), con event_type como scalping_binance_entry, DCA, TP/SL, cierre fuera de ventana (scalping_binance_outside_window_close), scalping_binance_account_gate, etc.
  • Para borrar historial de scalping (no órdenes en Binance): php artisan scalping:reset-history --user=ID --dry-run / --force.

Comandos útiles

  • php artisan scalping:diagnose — destino de ejecución, flags del scheduler, entry_notional_pct, dca_slice_pct_of_capital, exposición máxima, umbral de PnL, usuarios activos y si el executor usa solo .env.
  • php artisan scalping:binance-run / scalping:binance-dca / scalping:binance-outside-window-close — lo mismo que el scheduler (útil en SSH para ver líneas de log). Para el cierre fuera de ventana: --dry / --live según orders_dry_run del usuario.

Configuración: .env vs panel

Los valores por defecto viven en config/scalping_binance.php (prefijos SCALPING_BINANCE_*). En el panel puede haber una fila por usuario con notional, SL/TP, caps, claves API, y un JSON de executor. Si marcas “Executor: use only server config / .env” (executor_uses_env_only), el universo, timeframes, cooldowns, DCA, límites de exposición/PnL y demás claves del executor siguen el archivo de entorno y no el JSON del panel.

Tras cambiar variables de entorno en servidor, conviene php artisan config:clear y, si usas caché, php artisan config:cache.

Seguridad y pruebas

  • Dry run: por usuario y/o flags global puede simular órdenes sin enviarlas; revisa los mensajes del comando.
  • Operar futuros con apalancamiento implica riesgo de liquidación; los umbrales y el presupuesto DCA deben alinearse con tu tolerancia.

← Índice de ayuda · Cómo funciona el bot (OB + IA) · Cómo se generan las señales