> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbitflare.com/llms.txt
> Use this file to discover all available pages before exploring further.
# OrbitFlare Jetstream v2
> Next-generation gRPC streaming for Solana — enrichment, slot events, and dynamic filters
Jetstream v2 is the next generation of OrbitFlare's transaction stream: the same low-latency
pipeline, with **opt-in per-transaction enrichment**, **slot lifecycle events**, and **dynamic
filters** you can change without reconnecting.
## 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](/data-streaming/jetstream-v2-vs-v1).
## 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](/authentication) for setup details.
## Connecting
1. Pick the [region endpoint](/data-streaming/jetstream-v2-reference#available-endpoints) closest to
your infrastructure (same hosts as v1).
2. Generate a client from the `jetstream.v2` protobuf definition — see
[Code Generation](/data-streaming/jetstream-v2-reference#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.
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.
## 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
The full v1-vs-v2 comparison and what each capability saves you.
Full v2 Protocol Buffer specification, endpoints, and code generation.
The v1 overview, client examples, and filtering guide.
Full-fidelity Geyser-based streaming with inner instructions and complete metadata.
## Support
For technical support or questions about Jetstream v2, please contact our support team or join our
[Discord community](https://discord.gg/orbitflare).