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

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

LevelDescriptionLatencyOrderingRevert Risk
ProcessedIncluded in the most recent block the node knows about; no cluster-wide votes yet~400msAscending slot order (may break during forks)Small chance of slots being skipped or forked
ConfirmedSupermajority of stake (≥66%) has voted on the block (optimistic confirmation)A few secondsStrictly orderedNegligible
FinalizedConfirmed and at least 31 additional confirmed blocks built on top (32-vote lockout)~12-15 secondsStrictly orderedEffectively irreversible