Breaker block: cambio de función tras fallar un bloque de órdenes

Flujo de trabajo práctico

1. Comience con un bloque conocido.Conservar su zona y marca de tiempo de publicación.
2. Observar la invalidaciónExige un cierre más allá del borde opuesto más el buffer.
3. Crea un breakerUsa un ID nuevo vinculado al bloque original.
4. Evaluar la primera repetición de la pruebaAplica la regla elegida de rechazo del precio y entrada.
5. Salir o cancelarMantenga el límite de parada, el objetivo y el tiempo de vida predeterminados.

Un cambio de polaridad requiere una historia completa.

Un bloque bajista se seguía como resistencia. Un cierre claro sobre él invalida esa hipótesis. Un breaker alcista plantea otra pregunta: ¿la zona sostendrá el primer regreso posterior del precio desde arriba? Un bloque alcista fallido genera la hipótesis bajista equivalente debajo de la zona.

LuxAlgo explica la polaridad del breaker y advierte que las etiquetas Historical Polarity Changes se dibujan hacia el pasado con información conocida después [1]. Una etiqueta histórica atractiva no prueba que la señal estuviera disponible entonces. La documentación temporal de la plataforma distingue la ubicación del dibujo del momento en que se conoció la información [2].

El breaker no demuestra que quienes vendieron antes deban comprar ahora en la zona. Esa explicación puede motivar una hipótesis, pero OHLCV registra precio, actividad y tiempo, no identidades. Crear un nuevo estado de zona nunca debe borrar la pérdida de la operación del bloque original.

De un bloque conocido a un nuevo candidato de retesteo

Parte de un bloque bajista block[a,b] publicado antes. Fija A=ATR14 con datos anteriores a la ruptura y buffer=max(2 ticks,0.10A). Al recibir el cierre de la barra t, si C[t]>b+buffer, marca el bloque original como INVALIDATED y crea un breaker alcista con las mismas coordenadas y parent_ob_id. El candidato admite entradas desde t+1. El buffer y un TTL de ejemplo de 20 barras son decisiones de investigación.

Se requiere evidencia de que el precio cotizó completamente por encima de la zona después de la ruptura antes de evaluar un retorno. Una nueva prueba intersecta la zona, con low≤b+buffer y high≥a, y luego cierra por encima de b+buffer en un máximo de tres barras. Una versión de primer toque consume la oportunidad en ese acercamiento inicial; no puede llamar a un cuarto retorno más atractivo el primer toque. Cancelar si un cierre cae por debajo de a−buffer antes de la confirmación.

Una variante exige BOS, MSS o desplazamiento además de la invalidación; otra solo exige invalidar el bloque. Regístralas por separado para medir el filtro estructural. Si ruptura y aparente retesteo ocurren en la misma vela de creación, OHLC no determina la secuencia necesaria para entrar después de publicar. La versión basada en cierre no opera dentro de esa vela.

Almacene un nuevo ID de evento conservando los límites del bloque original y la marca de tiempo del fallo. Un único objeto mutable cuya dirección cambia de bajista a alcista puede provocar que los informes muestren únicamente la interpretación final exitosa. El linaje de eventos forma parte del diseño de la investigación, no es meramente un registro contable.

EXPIRED, INVALIDATED y CONSUMED son estados terminales de ese breaker. Cancelar una orden no basta si el detector puede reconsiderar la misma zona después; una recuperación tardía no revive un candidato fallido. Registra primero las ejecuciones ocurridas mientras la orden estaba activa, antes de aplicar el cambio de estado al cierre.

on_close(t):
  process_existing_order_events_until_close(t)
  for br in active_bullish_breakers_eligible_before_bar(t):
    if expired(br):
      br.state = EXPIRED; cancel_future_orders(br); continue
    if C[t] < br.low-br.buffer:
      br.state = INVALIDATED; cancel_future_orders(br); continue
    if first_retest_confirmed(br,t):
      signal_for_next_quote_once(br); br.state = CONSUMED
  A = ATR14[t-1]
  if not finite_positive(A): return
  buffer = max(2*tick,0.10*A)
  for ob in active_bearish_OBs_published_before_bar(t):
    if C[t] > ob.high+buffer:
      invalidate_once(ob,at=t)
      create_breaker_once(parent=ob.id,known_at=received_close_time(t),
                          eligible=t+1,buffer=buffer,expiry=t+20)
# Terminal breakers cannot revive; a failed parent creates at most one child.

El volumen distingue las hipótesis sobre la ruptura y el retorno.

Mide RVOL durante la ruptura por separado del volumen de un retesteo de igual duración. Una ruptura con volumen alto seguida de un regreso tranquilo puede ser compatible con menor presión vendedora, pero también con la desaceleración habitual del mediodía. Usa referencias de la misma hora; nunca el volumen diario final para decidir por la mañana.

OB, breaker y BOS pueden pertenecer a una misma secuencia de precios. No asigne riesgos independientes simplemente porque el evento tenga varios nombres. Una familia de eventos puede compartir un presupuesto fijo entre entradas relacionadas. CVD es una función adicional solo cuando su clasificación de operaciones es fiable; el color de la vela no reconstruye el delta.

Conserva también los retesteos con volumen alto. Una respuesta fuerte tras posible absorción puede tener mucha actividad, lo que contradice exigir una contracción estricta del volumen. Prueba esos mecanismos por separado; no cambies la explicación después de ver una operación ganadora.

Ejemplos sintéticos de ganancia y pérdida en la misma zona

Ya se conoce un block[100,102] bajista. Con referencia a ATR=2 y tick=0.05, el buffer es 0.20. Un cierre en 102.50 crea el breaker alcista. El precio luego llega a 104, regresa a un mínimo de 101.80 y cierra 102.40. Comprar en la siguiente cotización ejecutable 102.45, con stop 99.80 y objetivo 107.75, da riesgo 2.65 y recompensa 5.30, o 2R antes de costos.

Si el siguiente objetivo estructural conocido es solo 104.50, esa protección tan amplia podría resultar en una recompensa insuficiente. Rechace según una regla preseleccionada. No mueva el stop a 101.80 después de saber que fue el mínimo de retest exitoso, a menos que el modelo de entrada original haya utilizado explícitamente ese mínimo ya observado.

En una ruta de fallo, el primer retorno cierra 99.70. La versión de confirmación nunca entra y se cancela. Un límite que ya se encontraba en 102 puede haberse ejecutado y luego haber salido en 99.75, perdiendo 2.25. Cualquier posición corta anterior abierta desde el bloque bajista original conserva su propio resultado. Informar solo sobre el breaker ganador posterior tergiversaría la secuencia completa.

Tipo de orden y número de intentos

Elige confirmar y entrar en la siguiente cotización ejecutable, o colocar antes del toque una orden limitada en un borde o punto medio predefinido. Una vela que toca la zona y cierra favorablemente no permite adjudicar el mejor precio limitado y omitir las ejecuciones desfavorables. La ejecución y protección deben respetar las reglas del mercado [3].

El vencimiento, una ruptura más allá del borde opuesto o una condición estructural contraria predefinida pueden cancelar un candidato pendiente. En una posición abierta, un stop de protección y una salida al cierre son distintos. Esperar el cierre no impide ejecutar un stop que ya estaba activo.

Una línea base propuesta permite un intento por bloque principal y una posición por familia de eventos. Si se permite la reentrada, considérela como una nueva operación y conserve los costos acumulados. Elija el objetivo como un swing opuesto conocido o un múltiplo R fijo antes de observar la trayectoria futura.

Probar un stop local más ajustado es útil, pero cambia la hipótesis. Puede mejorar la relación nominal beneficio/riesgo mientras aumenta la frecuencia de stops y la fracción del riesgo consumida por el spread. Compara resultados netos reales, no solo la distancia entre entrada y objetivo en un gráfico ganador.

Compare el breaker con las pruebas habituales de soporte y resistencia

Un control útil es la ruptura y retesteo de un nivel sin historia de bloque de órdenes, emparejado por amplitud, antigüedad, fuerza de ruptura y distancia de entrada. Si el breaker no mejora los resultados tras emparejar, la parte útil puede ser el retesteo en vez del origen del bloque.

Reporta el denominador completo: bloques originales, invalidaciones, retesteos posteriores, confirmaciones y ejecuciones. Conserva las zonas borradas del gráfico final. La reproducción progresiva de los datos debe comprobar que las etiquetas históricas no intervinieron antes de que se conocieran.

Divida cronológicamente y mantenga a cada descendiente de un padre en el mismo conjunto de validación. Evalúe los TTL cercanos, los búferes, las reglas de primer contacto y las suposiciones de costos. Un único gráfico posterior al evento exitoso no estima la probabilidad de éxito de la máquina de estados completa, especialmente cuando el bloque padre generó una pérdida inicialmente.

Errores frecuentes

Lista de verificación antes de usar este método

Marca cada punto después de verificarlo con tus datos. El progreso se guarda en este navegador; no certifica que la estrategia sea rentable.

• El bloque original existía antes de la ruptura.
• Mantén fijos los límites de la zona y el buffer.
• El breaker tiene marcas de tiempo known_at y eligible_from.
• Excluye las etiquetas dibujadas retrospectivamente de las señales.
• Se conservan todos los toques realizados antes de la confirmación.
• No borres retroactivamente una orden limitada que ya se ejecutó.
• El informe incluye resultados del bloque original y del breaker.

Fuentes de investigación

Cada fuente respalda la definición o evidencia descrita a su lado. El pseudocódigo, los ejemplos sintéticos y los parámetros propuestos requieren una validación independiente.

1. Order Blocks & Breaker BlocksLuxAlgo. Se leyó la descripción original y su advertencia de etiquetas dibujadas hacia el pasado; no hay un historial de rendimiento verificado. Verificado el: 2026-10-11.
2. RepaintingTradingView. Se consultó la sincronización de la información y el comportamiento de la visualización. Verificado el: 2026-10-11.
3. Futures Order TypesCME Group. Se consultó la mecánica de las órdenes para distinguir entre confirmaciones y ejecuciones. Verificado el: 2026-10-11.

Métodos relacionados