Skip to main content

Overview

OrbitFlare Jetstream is a high-performance gRPC service for real-time streaming of Solana transactions. It delivers a minimal-latency feed over a rich, flexible protocol — letting you adjust your subscription on the fly and receive pre-computed transaction metadata so your client does less work.

Highlights

  • Dynamic filters — add and remove filters while the stream is open, each with a client-chosen filter_id that is echoed on every matching transaction. No reconnect required, and each change is acknowledged with a FilterResult.
  • Opt-in enrichment — request fee_payer, writable_accounts, program_ids, compute_unit_price (the compute-unit price, micro-lamports/CU — not the total fee), compute_limit, tx_size, and resolved address-lookup-table addresses directly on each transaction, instead of re-deriving them client-side.
  • Slot lifecycle streaming — a dedicated SubscribeSlots stream emits ALIVE / COMPLETE / DEAD events per slot, with the current leader and parent slot.
  • Built-in liveness — every message carries a monotonic sequence number for gap detection, and the server emits a Heartbeat on an idle transaction stream.
  • Enrichment on demand — a transaction is one flat message with the core fields by default; switch on enrichment per subscription to add the extra fields whenever you want them.

Authentication

Supply your API key in the x-token gRPC metadata header, or use IP-whitelist authentication. See Authentication for setup details.

Connecting

  1. Pick the region endpoint closest to your infrastructure.
  2. Generate a client from the jetstream.v2 protobuf definition — see Code Generation in the reference.
  3. Authenticate with your x-token API key (or from a whitelisted IP) and open a stream.

How streaming works

SubscribeTransactions is a bidirectional stream — you manage your subscription with the same connection you receive data on:
  1. Open the stream and send an AddFilters request containing one or more filters. Each filter needs at least one of account_include / account_exclude / account_required. (Empty match-everything filters are rejected.) account_required is any-of — a transaction matches if it references at least one of the listed accounts, not all of them.
  2. The server replies with a FilterResult per filter (accepted, or a rejection_reason).
  3. Matching transactions arrive as FilteredTransaction messages, each listing the filter_id values it matched.
  4. Send AddFilters / RemoveFilters at any time to change what you receive — no reconnect.
  5. On an idle transaction stream the server sends Heartbeat messages; use them (and Ping/Pong) to confirm liveness.
  6. Track the sequence number to detect any gap, and reconnect (re-sending your filters) if the stream closes.
To receive enriched transactions, set include_enrichment: true on a filter.
Enrichment is subscription-wide: if any one of your active filters sets include_enrichment, every transaction the session receives is enriched. Turn it on per subscription whenever you want the extra fields — it adds no latency to the stream; the only difference is a modestly larger message.

Slot events

Open SubscribeSlots (a separate, server-streaming RPC, no parameters) to receive a SlotEvent for each slot transition:
  • ALIVE — the first shred of the slot was received.
  • COMPLETE — the slot’s last shred was received.
  • DEAD — the slot was skipped, or was superseded by later slots without completing.
Each event includes the current_leader (32-byte pubkey, when the current leader is available) and the parent_slot.

Migrating from v1

The earlier Jetstream v1 protocol is deprecated but still available for existing integrations. If you are on v1, both services run side by side on the same endpoints, so migration is a client-side protocol change with no network changes. See Migrating from v1 for a field-by-field mapping, or the deprecated v1 overview.

Best Practices

  1. Filtering — always set at least one account constraint, and use a stable unique filter_id per filter so you can correlate matches and remove filters later.
  2. Enrichment — keep it off unless you need the extra fields; it applies to the whole subscription.
  3. Reconnection — track sequence for gaps and reconnect automatically, re-sending your filters.
  4. Liveness — rely on Heartbeat / Ping to detect a stalled connection.

See Also

Migrating from v1

The field-by-field v1-to-Jetstream mapping and what each capability saves you.

Protocol Reference

Full Protocol Buffer specification, endpoints, and code generation.

Jetstream v1 (deprecated)

The deprecated v1 overview, client examples, and filtering guide.

Yellowstone gRPC

Full-fidelity Geyser-based streaming with inner instructions and complete metadata.

Support

For technical support or questions about Jetstream, please contact our support team or join our Discord community.