Skip to main content

Install

Building the client

Minimal:
URL falls back to ORBITFLARE_JETSTREAM_URL env var. All builder methods are identical to the gRPC client - same defaults, same behavior.

Writing a YAML config

JetStream supports transaction and account filters. No slots, blocks, or commitment - those are Yellowstone-specific.

YAML filter reference

transactions - named filters. account_include matches transactions involving those addresses. account_exclude removes matches. account_required means all listed addresses must appear. accounts - watch specific addresses with account, or all accounts owned by a program with owner. Supports ${ENV_VAR} expansion.

Subscribing and reading events

From YAML

Programmatically

With the typed builder

SubscribeRequestBuilder and TransactionFilter build the same request without hand-writing proto. Each TransactionFilter exposes account_include, account_exclude, and account_required, and accepts any iterator of string-like values.

Reading the stream

Closing, multiple streams, reconnection, and ping/pong all work identically to the gRPC client.

Full example

A stream that watches Raydium AMM swaps and prints each transaction’s signature and instruction count.
With this jetstream.yml:

JetStream v2

JetStream v2 (orbitflare_sdk::jetstream::v2) runs on the same endpoints and authentication as v1 and is fully additive: v1 keeps working unchanged. What v2 adds:
  • Runtime-managed filters - add and remove filters on a live stream without reconnecting.
  • Per-message sequence numbers - every response carries a monotonic sequence, so you can detect dropped messages.
  • Opt-in enrichment - request fee payer, program ids, compute-unit price, compute limit, resolved address-table addresses, and more, per transaction.
  • Slot lifecycle events - a separate server stream of slot alive/complete/dead events.
The v2 client lives under jetstream::v2. The builder is identical to v1 (same methods, defaults, ORBITFLARE_JETSTREAM_URL env var, and failover):

Building typed filters

Each filter is a TransactionFilter with a client-chosen id (via .with_id()). The id is echoed back on every matching transaction and in the filter-validation acknowledgement, so you can correlate matches and remove the filter later.
A filter must set at least one of account_include, account_exclude, or account_required; empty (match-everything) filters are rejected. include_enrichment is optional (default off) and applies to the whole subscription: if any active filter enables it, every transaction you receive is enriched.

Subscribing to transactions

Managing filters on a live stream

Take a handle from the stream and add or remove filters without reconnecting. Removals reference the filter id you assigned with .with_id().

Slot lifecycle events

subscribe_slots() is a separate server stream and takes no filters.

Health probes

get_version() and ping() are unary calls with the same failover as the streams.
For the full protobuf specification, message shapes, enrichment fields, and slot statuses, see the JetStream v2 Protocol Reference.