OrbitFlare Jetstream v2

​

Overview

OrbitFlare Jetstream v2 is a high-performance gRPC service for real-time streaming of Solana transactions. It delivers the same minimal-latency feed as v1 over a richer, more flexible protocol — letting you adjust your subscription on the fly and receive pre-computed transaction metadata so your client does less work. v2 is served on the same endpoints as v1 (the JetstreamV2 service is routed by gRPC method path over the same connection), so nothing about your network setup changes — only the protocol you generate a client from.

​

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, priority_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 stream.
• Enrichment on demand — a v2 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.

For a full side-by-side breakdown of every capability and what each one saves you, see What’s New in v2.

​

Authentication

Authentication is the same as v1: 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 (same hosts as v1).
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.)
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 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.

​

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 did not complete before timeout.

Each event includes the current_leader (32-byte pubkey, when the leader schedule is available) and the parent_slot.

​

Choosing v1 or v2

v2 is the recommended protocol for new integrations — it’s where enrichment, slot events, and dynamic filtering live. v1 remains available and supported; if you have an existing v1 client there’s no forced migration. The two services run side by side on the same endpoints.

​

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

​

Support

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