Jetstream v2 is served on the same endpoints as v1 — there is no separate host. The JetstreamV2
service is exposed over the same HTTP/2 connection and routed by the gRPC method path, so you connect
to the region closest to your infrastructure exactly as you would for v1.
US
Europe
Asia Pacific
City
Region Slug
Endpoint
New York
ny
http://ny.jetstream.orbitflare.com
Salt Lake City
slc
http://slc.jetstream.orbitflare.com
Ashburn
ash
http://ash.jetstream.orbitflare.com
Los Angeles
la
http://la.jetstream.orbitflare.com
City
Region Slug
Endpoint
Frankfurt
fra
http://fra.jetstream.orbitflare.com
Amsterdam
ams
http://ams.jetstream.orbitflare.com
London
lon
http://lon.jetstream.orbitflare.com
Dublin
dub
http://dub.jetstream.orbitflare.com
Siauliai, Lithuania
siau
http://siau.jetstream.orbitflare.com
City
Region Slug
Endpoint
Tokyo
jp
http://jp.jetstream.orbitflare.com
Singapore
sgp
http://sgp.jetstream.orbitflare.com
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 is the same as v1: supply your API key in the x-token gRPC metadata header, or use
IP-whitelist authentication. See Authentication for details.
This document outlines the Protocol Buffer (protobuf) specification used by OrbitFlare Jetstream v2.
The jetstream.v2 package is fully independent of v1 — generate a separate client from the definition
below.
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.
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.
message AddFilters { repeated TxFilter filters = 1;}message TxFilter { string filter_id = 1; // client-provided, max 128 chars SubscribeRequestFilterTransactions filter = 2;}message SubscribeRequestFilterTransactions { repeated string account_include = 1; repeated string account_exclude = 2; repeated string account_required = 3; // Opt-in enrichment. Default false = lean response (core fields only). Set // true to also receive fee_payer / writable_accounts / program_ids / // priority_fee / compute_limit / tx_size. Applies to the whole // subscription: if any of your active filters sets this true, every // transaction you receive is enriched. bool include_enrichment = 4;}
A filter must specify at least one of account_include / account_exclude / account_required.
Empty (match-everything) filters are rejected — see FilterResult.
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.
message Heartbeat { // Server wall-clock at emit time, milliseconds since Unix epoch. Lets // clients measure one-way skew / network delay and age out stale // connections. uint64 server_ts_ms = 1;}
SubscribeSlots is a server stream of slot lifecycle events. It takes no parameters — open the stream
and receive events as slots progress.
// SubscribeSlots takes no request parameters.message SubscribeSlotsRequest {}enum SlotStatus { SLOT_STATUS_UNSPECIFIED = 0; SLOT_STATUS_ALIVE = 1; // first shred of this slot received SLOT_STATUS_COMPLETE = 2; // last shred of this slot received SLOT_STATUS_DEAD = 3; // slot skipped, or not completed before timeout}message SlotEvent { uint64 slot = 1; SlotStatus status = 2; // 32-byte pubkey. Empty bytes (proto3 default) means the leader schedule // is disabled at the server. bytes current_leader = 3; // Parent slot, from the first shred received for this slot. 0 means // "unknown parent" (e.g. a DEAD event for a slot that was never observed). uint64 parent_slot = 4; uint64 sequence = 5; // monotonic per-stream}