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

# Garantias de Entrega

> Entenda as garantias de entrega do LaserStream, incluindo entrega exatamente uma vez, ordenação de mensagens, comportamento de notificação de slot e tratamento de forks.

LaserStream fornece as mesmas garantias de entrega que os nós Geyser. Este guia cobre o que você pode esperar do comportamento de entrega de mensagens dos seus streams do LaserStream.

<Info>
  Essas garantias se aplicam a **assinaturas padrão** (transações, contas, slots, blocos). [Transações pré-processadas](/docs/pt-BR/shred-delivery/preprocessed-transactions) (parte da Shred Delivery) operam sob garantias de entrega em um melhor esforço separadas.
</Info>

## Entrega exatamente uma vez

O LaserStream garante **entrega exatamente uma vez**. Cada mensagem é entregue ao seu stream exatamente uma vez — você nunca receberá mensagens duplicadas e nenhuma mensagem será pulada.

LaserStream alcança isso conectando-se a vários nós Solana simultaneamente e deduplicando dados recebidos antes de encaminhá-los para o seu stream. Esta arquitetura multi-nó também elimina pontos únicos de falha, garantindo o máximo de tempo de atividade sem sacrificar a correção da entrega.

## Ordenação de mensagens por nível de compromisso

A ordenação de entrega depende do nível de compromisso das mensagens:

### Confirmado e finalizado

Todas as mensagens **confirmadas** e **finalizadas** são entregues em ordem. Você pode confiar nesses níveis de compromisso para fornecer uma visão consistente e sequencial do estado on-chain.

### Processado

Todas as mensagens **processadas** são emitidas em ordem crescente de slot, a menos que haja um fork. No caso de um fork, a ordem de slot pode temporariamente se desviar à medida que a rede se reorganiza em torno da cadeia canônica. Uma vez que o fork é resolvido, a ordem ascendente é retomada.

<Warning>
  No nível de compromisso processado, há uma pequena chance de que um slot processado possa ser posteriormente pulado ou desviado devido a um fork. O Geyser **não** envia notificações de rollback explícitas para atualizações desviadas por forks. Se seu aplicativo consome dados de nível processado, você deve considerar a possibilidade de que algumas atualizações possam pertencer a slots que são abandonados no final. Para aplicativos que exigem certeza, use o nível de compromisso **confirmado** ou **finalizado**.
</Warning>

## Ordenação dentro de um slot

Dentro de um único slot, o LaserStream entrega atualizações de conta e transações com as seguintes garantias:

### Atualizações de contas antes das transações

Para cada transação, as atualizações de conta que ela causou são entregues **antes** da própria transação:

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

### Ordenação entre transações

O LaserStream preserva a mesma ordenação que o [plugin Geyser do Agave](https://docs.solanalabs.com/validator/geyser#ordering-guarantees). Se as atualizações de diferentes transações chegam em uma ordem determinística depende de seus **locks de escrita**:

* **Mesmo lock de escrita** (ex., três negociações no mesmo pool Raydium): sempre determinístico. O Agave executa estas transações sequencialmente, pois escrevem na mesma conta.
* **Locks de escrita diferentes** (ex., duas transações não relacionadas): não necessariamente determinístico. O Agave pode executar estas em paralelo, e suas atualizações podem ser intercaladas no stream.

Para reconstruir uma ordem totalmente determinística, independentemente dos locks de escrita, use o **índice de bloco/transação** dos dados da transação.

### Normalização da versão de escrita

O LaserStream normaliza as versões de escrita em toda sua arquitetura multi-nó. Ao contrário do Geyser ou Yellowstone bruto — onde as versões de escrita são locais para cada nó e podem diferir — o LaserStream fornece versões de escrita consistentes nas quais você pode confiar para ordenar atualizações de conta de nível processado.

<Note>
  **Exceção temporária:** Contas maiores que 512KB estão atualmente em buffer no plugin Geyser por razões de desempenho, o que pode afetar a ordenação determinística para essas contas. Esta limitação será removida em breve.
</Note>

## Notificações de slot

**Notificações de slot processadas** chegam após todas as mensagens para aquele slot terem sido entregues. Isso significa que, quando você recebe uma notificação de slot processada, pode ter certeza de que todos os dados de atualização de transações e contas associados a esse slot já foram enviados para o seu stream. Você pode usar notificações de slot como um sinal para liberar dados em buffer para aquele slot.

## Continuidade de dados na desconexão

O LaserStream mantém um buffer de dados de slot recentes, permitindo [reprodução histórica](/docs/pt-BR/laserstream/historical-replay) por até **24 horas** (\~216.000 slots) de dados passados. Se o seu aplicativo se desconectar, você pode reconectar e retomar a partir do seu último slot processado sem perder nenhum dado.

Ao usar um [cliente SDK do LaserStream](/docs/pt-BR/laserstream/clients), essa recuperação é tratada automaticamente — o cliente rastreia sua posição no stream pelo número do slot e se reconecta de forma transparente. Não é necessário lógica de reconexão manual.

## Referência de nível de compromisso

| Nível          | Descrição                                                                                           | Latência         | Ordenação                                            | Risco de Reversão                                  |
| -------------- | --------------------------------------------------------------------------------------------------- | ---------------- | ---------------------------------------------------- | -------------------------------------------------- |
| **Processado** | Incluído no bloco mais recente que o nó conhece; ainda não há votos em todo o cluster               | \~400ms          | Ordem crescente de slot (pode quebrar durante forks) | Pequena chance de slots serem pulados ou desviados |
| **Confirmado** | Supermaioria do stake (≥66%) votou no bloco (confirmação otimista)                                  | Alguns segundos  | Estritamente ordenado                                | Negligível                                         |
| **Finalizado** | Confirmado e pelo menos 31 blocos adicionais confirmados construídos em cima (bloqueio de 32 votos) | \~12-15 segundos | Estritamente ordenado                                | Virtualmente irreversível                          |