> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Preconfirmations: la señal de transacción más temprana en Solana > Transmite transacciones de Solana antes de que se conviertan en shreds: preconfirmaciones de Helius con estado de ejecución, además de Jito BAM, en una sola suscripción WebSocket. **Usa [Sender Max](/docs/es/sending-transactions/sender-max) (propina mínima: 0.001 SOL) para actuar según las Preconfirmations.** Una preconfirmación solo resulta útil si tu transacción se registra primero; Sender Max es la forma más rápida de lograrlo. Desarrolla con Sender Max desde el principio para aprovechar al máximo las Preconfirmations. ## Descripción general Preconfirmations transmite las transacciones en el punto más temprano en que pueden observarse: **antes** de que se agrupen en entradas y se conviertan en shreds. Esta es la señal de transacción con menor latencia que ofrece Helius, anterior a [Shred Delivery](/docs/es/shred-delivery/raw-shreds) y a los flujos con nivel de compromiso processed. Te suscribes mediante WebSocket con el método `preconfSubscribe` y recibes cada transacción a medida que ocurre. El flujo combina dos fuentes, ambas incluidas de forma predeterminada, que emiten en distintos puntos del proceso: * **Preconfirmaciones de Helius** de validadores que las reenvían a Helius. Se emiten en el instante en que el líder **ejecuta** la transacción, junto con su estado de ejecución: el primer momento en que el resultado existe en cualquier lugar. * **[Preconfirmaciones de BAM](#preconfirmaciones-de-bam)** de validadores que ejecutan el cliente Block Assembly Marketplace (BAM) de Jito. Se emiten cuando el validador **se compromete a ejecutar** la transacción, antes de que se ejecute, por lo que no incluyen un estado de ejecución. Preconfirmations se proporciona desde el endpoint de [Gatekeeper](/docs/es/gatekeeper/overview) de Helius, `wss://beta.helius-rpc.com`. El nombre de host `beta` hace referencia al despliegue de Gatekeeper, no a la madurez de Preconfirmations; se convertirá en el endpoint estándar a medida que el tráfico migre a Gatekeeper. Las transacciones se entregan antes que los shreds y los flujos con nivel de compromiso processed Suscríbete una vez con `preconfSubscribe` y recibe preconfirmaciones de Helius y BAM en un solo flujo Plan Professional o superior; 10 créditos por mensaje (cada transacción transmitida) Reacciona a la actividad en cadena antes de que se registre, para propAMM, francotiradores, operadores de copia y bots de liquidación ## Dónde se ubica Preconfirmations en el proceso Una transacción pasa por varias etapas dentro de un validador antes de registrarse en la cadena. La latencia aumenta de izquierda a derecha: cuanto más a la derecha observes, más tarde conocerás la transacción. Transaction latency flow inside a validator: User Tx to TPU to Scheduler to Preconf (scheduled transaction) to Shreds, with latency increasing left to right. Las preconfirmaciones de Helius se emiten desde la etapa de **ejecución**: en el instante en que el líder ejecuta la transacción y se conoce su estado, pero antes de que el resultado se registre en una entrada y se convierta en shreds. Este es el primer punto del ciclo de vida en el que el resultado de una transacción existe y puede comunicarse. Las preconfirmaciones de BAM se emiten una etapa antes, cuando el validador se compromete a ejecutar la transacción, pero antes de haberla ejecutado. Ambas llegan antes de que la transacción se convierta en shreds, por lo que tienen una latencia estrictamente menor que la entrega basada en shreds para la misma transacción. ## Preconfirmaciones de BAM [BAM (Block Assembly Marketplace)](https://bam.dev/docs/bam/bam-overview/) es el sistema de creación de bloques de Jito para Solana. Los validadores que ejecutan clientes compatibles con BAM emiten una preconfirmación en el instante en que se comprometen a ejecutar una transacción. Helius las obtiene de los endpoints regionales de BAM de Jito y las entrega mediante la misma suscripción `preconfSubscribe` y la misma carga binaria que las preconfirmaciones de Helius. En el lanzamiento, BAM añadió cobertura de validadores que representaban más del 34 % de la participación de la red. Las preconfirmaciones de BAM siguen la misma estructura de carga, pero difieren en algunos campos: * `tx_index` siempre es `0`. BAM ordena las transacciones por ID de secuencia y posición en el paquete, en lugar de por un índice de slot; ninguno se corresponde con el campo de Helius ni se incluye en el flujo. Consulta [Cómo distinguir las dos fuentes](/docs/es/pre-confirmations/preconf-subscribe#distinguir-las-dos-fuentes). * `regionInclude` corresponde al endpoint regional de BAM que emitió la preconfirmación, no a la región de Helius que la recibió. * Una pequeña proporción de transacciones llega a Helius a través de ambas fuentes, por lo que la misma firma puede llegar dos veces. Consulta [Notificaciones duplicadas](/docs/es/pre-confirmations/preconf-subscribe#notificaciones-duplicadas). Para recibir solo preconfirmaciones de Helius, pasa `includeBam: false` en el [filtro de suscripción](/docs/es/pre-confirmations/preconf-subscribe#filtrado). ## Cuándo usar Preconfirmations propAMM, francotiradores, operadores de copia y bots de liquidación: cualquier estrategia que necesite reaccionar a una transacción lo antes físicamente posible. Para obtener datos históricos completos o confirmados, usa [LaserStream](/docs/es/laserstream) o [Enhanced WebSockets](/docs/es/rpc/websocket/transaction-subscribe). Para obtener datos sin procesar de la red, consulta [Shred Delivery](/docs/es/shred-delivery/raw-shreds). Una preconfirmación es una señal temprana, no una garantía. La transacción aún no se ha registrado en la cadena y todavía podría descartarse; además, el estado de ejecución de una preconfirmación de Helius refleja el resultado local del líder, que no es definitivo hasta que se confirma el bloque. Confirma el registro mediante comprobaciones estándar del nivel de compromiso antes de considerarlo definitivo. ## Precios Preconfirmations requiere un **plan Professional o superior** y cuesta **10 créditos por mensaje** —un mensaje por cada transacción transmitida—, que se facturan con cargo a tu plan. Consulta [Créditos](/docs/es/billing/credits) para obtener más información. Preconfirmations es un producto nuevo y los precios están sujetos a cambios. ## Cobertura Preconfirmations solo está disponible para transacciones programadas por validadores que reenvían su flujo a Helius o ejecutan un cliente compatible con BAM. La cobertura aumenta según la proporción de participación de la red que cubren esas dos fuentes, por lo que el flujo **no es continuo**. Configurar `includeBam: false` limita la cobertura a los validadores que reenvían directamente a Helius. Es normal que haya interrupciones. Durante los slots cuyo líder no esté cubierto por ninguna de las fuentes, no recibirás mensajes de preconfirmación para ese slot. Diseña tu integración para tolerar estas interrupciones: no des por hecho que el flujo será ininterrumpido y recurre a otras señales, como [LaserStream](/docs/es/laserstream) o [Shred Delivery](/docs/es/shred-delivery/raw-shreds), cuando necesites cobertura continua. La cobertura aumenta a medida que más validadores reenvían a Helius. Si operas un validador, puedes [ayudar a cerrar estas brechas y obtener ingresos](/docs/es/pre-confirmations/for-validators). ## Para validadores ¿Operas un validador? Puedes obtener ingresos reenviando tu flujo de preconfirmaciones a Helius y mejorar la cobertura para todos los que usan Preconfirmations. Aprende a comenzar a reenviar preconfirmaciones y obtener ingresos. ## Próximos pasos Consulta cómo suscribirte, el formato de los mensajes y un ejemplo completo de WebSocket. Combina Preconfirmations con Sender para actuar según lo que ves con el registro más rápido.