Skip to main content

Available Endpoints

Jetstream is available in all OrbitFlare regions. Connect to the region closest to your infrastructure for the lowest latency.
Jetstream uses plain http:// (not https://) for gRPC connections. gRPC negotiates its own transport security over HTTP/2. Use https:// only if your dedicated node explicitly requires it.

Authentication

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

Protocol Buffer Specification

This document outlines the Protocol Buffer (protobuf) specification used by OrbitFlare Jetstream. The complete specification can be found in our GitHub repository — download jetstream_v2.proto there to generate your client, or use the definition reproduced below. The protobuf package is named jetstream.v2.

Service Definition

Request Messages

SubscribeTransactions is a bidirectional stream. The client sends a sequence of request messages — each carrying exactly one payload — to manage its subscription while the stream is open.

SubscribeTransactionsRequest

Adding Filters

Filters are added dynamically while the stream is open. Each filter carries a client-chosen filter_id that is echoed back on every matching transaction and in the validation acknowledgement.
A filter must specify at least one of account_include / account_exclude / account_required. Empty (match-everything) filters are rejected — see FilterResult.

Removing Filters

Response Messages

SubscribeTransactionsResponse

Every message on the stream carries a server timestamp and a monotonically increasing sequence number (per stream) so clients can detect gaps. Exactly one payload is set.

Filter Validation

After each AddFilters / RemoveFilters, the server returns one FilterResult per filter, acknowledging acceptance or explaining the rejection.

Heartbeat

Filtered Transaction

Each matched transaction lists the filter_id values it matched, followed by the transaction itself.

Shared Types

Transaction versions (SIMD-0385)

Solana has three transaction formats: legacy, v0, and v1 (SIMD-0385). The config field (23) and priority_fee_lamports field (24) were added for transaction v1 and are additive — a client generated from an older copy of this definition skips them as unknown fields and decodes every other field normally.
“Transaction v1” is not “Jetstream v1”. Transaction v1 is a Solana transaction format (SIMD-0385) that this current Jetstream protocol fully supports. “Jetstream v1” refers to the separate, now-deprecated Jetstream protocol. The current Jetstream is the one that carries transaction v1.
Identify the version from two fields. Check config first, because versioned is true for both v0 and v1:
Ranking by fee: use priority_fee_lamports (field 24), not compute_unit_price (field 17). Field 17 is micro-lamports per compute unit read from a SetComputeUnitPrice instruction — a v1 transaction has no such instruction, so field 17 is absent for every v1 transaction, and sorting on it alone ranks all v1 traffic last. Field 24 is total lamports and is populated for all three versions (both fields 23 and 24 are emitted only under enrichment for the derived value; config itself is always sent for v1).

Slot Streaming

SubscribeSlots is a server stream of slot lifecycle events. It takes no parameters — open the stream and receive events as slots progress.

Non-streaming Methods

Using the Protocol

A typical client:
  1. Generate client code from the jetstream.v2 definition above.
  2. Open the SubscribeTransactions bidirectional stream and authenticate (x-token header or IP whitelist).
  3. Send an AddFilters request with one or more TxFilter entries, each with a unique filter_id.
  4. Read the FilterResult acknowledgements, then the stream of FilteredTransaction messages.
  5. Add or remove filters at any time without reopening the stream.
  6. Track sequence to detect gaps, and treat a connection close as a signal to reconnect.
  7. Optionally open SubscribeSlots (a separate stream) for slot lifecycle events.

Code Generation

For TypeScript/JavaScript:
For Rust:

Best Practices

  1. Filtering
    • Always set at least one account constraint; empty filters are rejected.
    • Use a stable, unique filter_id per filter so you can correlate matches and remove filters later.
  2. Enrichment
    • Leave include_enrichment off unless you need the extra fields — lean output is smaller. Enabling it adds no latency; the only cost is a modestly larger message.
    • Enrichment is subscription-wide: enabling it on any one filter enriches every transaction the session receives.
  3. Sequence & Reconnection
    • Track the sequence number to detect dropped messages.
    • Implement automatic reconnection; on reconnect, re-send your AddFilters.
  4. Liveness
    • Use Heartbeat and Ping/Pong to confirm the stream is healthy and measure latency.

See Also

Jetstream Overview

The streaming model, enrichment, slot events, and getting started.

Jetstream v1 Reference (deprecated)

The deprecated v1 Protocol Buffer specification.

Support

For technical questions about the protocol or implementation details, please join our Discord community.