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

# Delivery Guarantees

> Understand LaserStream's delivery guarantees, including exactly-once delivery, message ordering, slot notification behavior, and fork handling.

LaserStream provides the exact same delivery guarantees as Geyser nodes. This guide covers what you can expect from the message delivery behavior of your LaserStream streams.

<Info>
  These guarantees apply to **standard subscriptions** (transactions, accounts, slots, blocks). [Preprocessed transactions](/shred-delivery/preprocessed-transactions) (part of Shred Delivery) operate under separate, best-effort delivery guarantees.
</Info>

## Exactly-once delivery

LaserStream guarantees **exactly-once delivery**. Each message is delivered to your stream exactly one time — you will never receive duplicate messages and no messages will be skipped.

LaserStream achieves this by connecting to multiple Solana nodes simultaneously and deduplicating incoming data before forwarding it to your stream. This multi-node architecture also eliminates single points of failure, ensuring maximum uptime without sacrificing delivery correctness.

## Message ordering by commitment level

Delivery ordering depends on the commitment level of the messages:

### Confirmed and finalized

All **confirmed** and **finalized** messages are delivered in order. You can rely on these commitment levels to provide a consistent, sequential view of on-chain state.

### Processed

All **processed** messages are emitted in ascending slot order unless there is a fork. In the event of a fork, the slot order may temporarily deviate as the network reorganizes around the canonical chain. Once the fork resolves, ascending order resumes.

<Warning>
  At the processed commitment level, there is a small chance  that a processed slot may later be skipped or forked away. Geyser does **not** send explicit rollback notifications for forked-away updates. If your application consumes processed-level data, you must account for the possibility that some updates may belong to slots that are ultimately abandoned. For applications that require certainty, use the **confirmed** or **finalized** commitment level.
</Warning>

## Ordering within a slot

Within a single slot, LaserStream delivers account updates and transactions with the following guarantees:

### Account updates before transactions

For each transaction, the account updates it caused are delivered **before** the transaction itself:

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

### Cross-transaction ordering

LaserStream preserves the same ordering as [Agave's Geyser plugin](https://docs.solanalabs.com/validator/geyser#ordering-guarantees). Whether updates from different transactions arrive in a deterministic order depends on their **write locks**:

* **Same write lock** (e.g., three trades on the same Raydium pool): always deterministic. Agave executes these sequentially since they write to the same account.
* **Different write locks** (e.g., two unrelated transactions): not necessarily deterministic. Agave may execute these in parallel, and their updates may be intermingled in the stream.

To reconstruct a fully deterministic order regardless of write locks, use the **block/transaction index** from the transaction data.

### Write version normalization

LaserStream normalizes write versions across its multi-node architecture. Unlike raw Geyser or Yellowstone — where write versions are local to each node and may differ — LaserStream provides consistent write versions you can rely on for ordering processed-level account updates.

<Note>
  **Temporary exception:** Accounts larger than 512KB are currently buffered in the Geyser plugin for performance reasons, which can affect deterministic ordering for those accounts. This limitation is being removed soon.
</Note>

## Slot notifications

**Processed slot notifications** arrive after all messages for that slot have been delivered. This means that when you receive a processed slot notification, you can be confident that all transaction and account update data associated with that slot has already been sent to your stream. You can use slot notifications as a signal to flush or release buffered data for that slot.

## Data continuity on disconnect

LaserStream maintains a buffer of recent slot data, enabling [historical replay](/laserstream/historical-replay) for up to **24 hours** (\~216,000 slots) of past data. If your application disconnects, you can reconnect and resume from your last processed slot without missing any data.

When using a [LaserStream SDK client](/laserstream/clients), this recovery is handled automatically — the client tracks your streaming position by slot number and reconnects seamlessly. No manual reconnection logic is required.

## Commitment level reference

| Level         | Description                                                                          | Latency         | Ordering                                      | Revert Risk                                   |
| ------------- | ------------------------------------------------------------------------------------ | --------------- | --------------------------------------------- | --------------------------------------------- |
| **Processed** | Included in the most recent block the node knows about; no cluster-wide votes yet    | \~400ms         | Ascending slot order (may break during forks) | Small chance of slots being skipped or forked |
| **Confirmed** | Supermajority of stake (≥66%) has voted on the block (optimistic confirmation)       | A few seconds   | Strictly ordered                              | Negligible                                    |
| **Finalized** | Confirmed and at least 31 additional confirmed blocks built on top (32-vote lockout) | \~12-15 seconds | Strictly ordered                              | Effectively irreversible                      |