Install
@grpc/grpc-js and yaml are optional peer dependencies. Install them only if you use JetStream (or YAML config).
Building the client
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
Full example
A stream that watches Raydium AMM swaps and prints each transaction’s signature and instruction count.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.
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 aTransactionFilter 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.
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.