Skip to main content
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.
These guarantees apply to standard subscriptions (transactions, accounts, slots, blocks). Preprocessed transactions (part of Shred Delivery) operate under separate, best-effort delivery guarantees.

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

​
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:

​
Cross-transaction ordering

LaserStream preserves the same ordering as Agave’s Geyser plugin. 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.
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.

​
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 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, 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