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