Skip to main content

Install

@grpc/grpc-js and yaml are optional peer dependencies. Install them only if you use JetStream (or YAML config).

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 accountInclude, accountExclude, and accountRequired, so you get autocomplete and compile-time checking on the filter shape.

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 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.
Import it from the jetstream/v2 entry point. 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 .withId()). 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 accountInclude, accountExclude, or accountRequired; empty (match-everything) filters are rejected. includeEnrichment 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 .withId().

Slot lifecycle events

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

Health probes

getVersion() 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.