> ## 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.

# Garantías de entrega

> Conoce las garantías de entrega de LaserStream, incluidas la entrega exactamente una vez, el orden de los mensajes, el comportamiento de las notificaciones de slots y la gestión de bifurcaciones.

LaserStream ofrece exactamente las mismas garantías de entrega que los nodos Geyser. Esta guía explica qué puedes esperar del comportamiento de entrega de mensajes de tus flujos de LaserStream.

<Info>
  Estas garantías se aplican a las **suscripciones estándar** (transacciones, cuentas, slots y bloques). Las [transacciones preprocesadas](/docs/es/preprocessed-transactions/overview) (parte de Shred Delivery) funcionan con garantías de entrega independientes basadas en el mejor esfuerzo.
</Info>

## Entrega exactamente una vez

LaserStream garantiza la **entrega exactamente una vez**. Cada mensaje se entrega a tu flujo una sola vez: nunca recibirás mensajes duplicados ni se omitirá ninguno.

LaserStream lo consigue conectándose simultáneamente a varios nodos de Solana y eliminando los datos duplicados antes de reenviarlos a tu flujo. Esta arquitectura multinodo también elimina los puntos únicos de fallo, lo que garantiza la máxima disponibilidad sin sacrificar la entrega correcta.

## Orden de los mensajes por nivel de compromiso

El orden de entrega depende del nivel de compromiso de los mensajes:

### Confirmado y finalizado

Todos los mensajes **confirmados** y **finalizados** se entregan en orden. Puedes confiar en que estos niveles de compromiso proporcionen una vista coherente y secuencial del estado en cadena.

### Procesado

Todos los mensajes **procesados** se emiten en orden ascendente de slot, salvo que haya una bifurcación. Si se produce una bifurcación, el orden de los slots puede desviarse temporalmente mientras la red se reorganiza alrededor de la cadena canónica. Una vez resuelta la bifurcación, se reanuda el orden ascendente.

<Warning>
  En el nivel de compromiso procesado, existe una pequeña probabilidad de que un slot procesado se omita posteriormente o quede fuera debido a una bifurcación. Geyser **no** envía notificaciones explícitas de reversión para las actualizaciones descartadas por una bifurcación. Si tu aplicación consume datos de nivel procesado, debes tener en cuenta que algunas actualizaciones pueden pertenecer a slots que finalmente se abandonen. Para las aplicaciones que requieren certeza, usa el nivel de compromiso **confirmado** o **finalizado**.
</Warning>

## Orden dentro de un slot

Dentro de un mismo slot, LaserStream entrega las actualizaciones de cuentas y las transacciones con las siguientes garantías:

### Actualizaciones de cuentas antes que las transacciones

Para cada transacción, las actualizaciones de cuentas que provocó se entregan **antes** que la propia transacción:

```
<accounts updated by tx X> → <tx X> → <accounts updated by tx Y> → <tx Y>
```

### Orden entre transacciones

LaserStream conserva el mismo orden que el [plugin Geyser de Agave](https://docs.solanalabs.com/validator/geyser#ordering-guarantees). Que las actualizaciones de distintas transacciones lleguen en un orden determinista depende de sus **bloqueos de escritura**:

* **Mismo bloqueo de escritura** (por ejemplo, tres operaciones en el mismo pool de Raydium): siempre determinista. Agave las ejecuta de forma secuencial porque escriben en la misma cuenta.
* **Bloqueos de escritura diferentes** (por ejemplo, dos transacciones no relacionadas): no necesariamente determinista. Agave puede ejecutarlas en paralelo y sus actualizaciones pueden intercalarse en el flujo.

Para reconstruir un orden completamente determinista sin importar los bloqueos de escritura, usa el **índice de bloque/transacción** de los datos de la transacción.

### Normalización de versiones de escritura

LaserStream normaliza las versiones de escritura en toda su arquitectura multinodo. A diferencia de Geyser o Yellowstone sin procesar, donde las versiones de escritura son locales para cada nodo y pueden diferir, LaserStream proporciona versiones de escritura coherentes que puedes usar para ordenar las actualizaciones de cuentas de nivel procesado.

<Note>
  **Excepción temporal:** Por motivos de rendimiento, actualmente las cuentas de más de 512KB se almacenan en búfer en el plugin Geyser, lo que puede afectar el orden determinista de esas cuentas. Esta limitación se eliminará pronto.
</Note>

## Notificaciones de slots

Las **notificaciones de slots procesados** llegan después de que se hayan entregado todos los mensajes de ese slot. Esto significa que, cuando recibes la notificación de un slot procesado, puedes tener la certeza de que todos los datos de transacciones y actualizaciones de cuentas asociados con ese slot ya se enviaron a tu flujo. Puedes usar las notificaciones de slots como señal para vaciar o liberar los datos almacenados en búfer correspondientes a ese slot.

## Continuidad de los datos tras una desconexión

LaserStream mantiene un búfer con datos de slots recientes, lo que permite la [reproducción histórica](/docs/es/laserstream/historical-replay) de hasta **24 horas** (\~216,000 slots) de datos anteriores. Si tu aplicación se desconecta, puedes volver a conectarte y reanudar desde el último slot procesado sin perder ningún dato.

Cuando usas un [cliente del SDK de LaserStream](/docs/es/laserstream/clients), esta recuperación se gestiona automáticamente: el cliente registra tu posición en el flujo mediante el número de slot y vuelve a conectarse sin interrupciones. No necesitas implementar lógica de reconexión manual.

## Referencia de niveles de compromiso

| Nivel          | Descripción                                                                                           | Latencia         | Orden                                                                | Riesgo de reversión                                                                |
| -------------- | ----------------------------------------------------------------------------------------------------- | ---------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| **Procesado**  | Incluido en el bloque más reciente que conoce el nodo; todavía no hay votos de todo el clúster        | \~400ms          | Orden ascendente de slots (puede romperse durante las bifurcaciones) | Pequeña probabilidad de que los slots se omitan o queden fuera por una bifurcación |
| **Confirmado** | Una supermayoría de la participación (≥66%) ha votado por el bloque (confirmación optimista)          | Unos segundos    | Orden estricto                                                       | Insignificante                                                                     |
| **Finalizado** | Confirmado y con al menos 31 bloques confirmados adicionales construidos encima (bloqueo de 32 votos) | \~12-15 segundos | Orden estricto                                                       | Prácticamente irreversible                                                         |