Yellowstone gRPC
Production-grade Solana data streaming designed for performance and throughput.
Yellowstone gRPC is a structured Solana data stream built on the Geyser model. It exposes real-time blockchain events over gRPC, with support for transactions, transaction status, accounts, slots, blocks, block metadata, and entries streaming.
Yellowstone gRPC has better throughput and latency than the standard Solana WebSocket API because it uses protobuf over gRPC instead of JSON-RPC over WebSocket, supports richer structured payloads, and is better suited for long-lived high-throughput ingestion pipelines.
What Yellowstone gRPC provides
Yellowstone gRPC gives applications a single bidirectional subscription interface for Solana streaming.
Supported streamed data includes:
accounts
slots
transactions
transaction status updates
blocks
block metadata
entries
Use cases
Yellowstone gRPC is designed for applications that continuously consume Solana data and process it server-side.
Typical use cases include:
indexers
real-time analytics pipelines
trading infrastructure
alerting systems
event-driven backend services
database ingestion workers
queue and stream processors
gRPC subscription model
Yellowstone uses a bidirectional gRPC stream. The client opens a subscription, sends a SubscribeRequest, and then receives matching updates continuously.
A single request can include filters for multiple stream categories at once.
Top-level request fields
Common top-level fields include:
accountsslotstransactionstransactions_statusblocksblocks_metaentryaccounts_data_slicecommitmentping
Filter semantics
Yellowstone filters are designed to reduce client-side discard work.
General behavior:
different filter fields are combined with logical AND
values inside arrays are combined with logical OR
account
filtersare combined with logical ANDempty filters usually mean a broad stream for that category, unless provider-side limits disallow it
Commitment levels
Yellowstone supports three commitment levels:
processedconfirmedfinalized
For latency-sensitive ingestion, processed is usually the default choice. If you require stronger consensus confidence, confirmed or finalized may be more appropriate.
Supported filters
Accounts
Account subscriptions can be filtered by:
accountownerfilters
filters follows the same model as getProgramAccounts, including dataSize and Memcmp.
For accounts:
fields are combined with logical AND
values inside arrays are combined with logical OR
nested
filtersare also treated as logical AND
Transactions
Transaction subscriptions can be filtered by:
votefailedsignatureaccount_includeaccount_excludeaccount_required
For transactions:
empty filters broadcast all transactions
fields are combined with logical AND
values inside arrays are combined with logical OR
Slots
Slots support filter_by_commitment, which restricts slot updates to the selected commitment level instead of streaming every slot lifecycle update.
Blocks
Block subscriptions support:
account_includeinclude_transactionsinclude_accountsinclude_entries
Block metadata
blocks_meta provides block-level metadata without the full block payload.
Entries
Entries are a fundamental building block of Proof of History. Each entry contains a unique ID that is the hash of the Entry before it, plus the hash of the transactions within it. Entries cannot be reordered, and its field num_hashes represents an approximate amount of time since the last Entry was created.
Yellowstone gRPC vs WebSocket
The standard Solana WebSocket interface uses JSON-RPC PubSub over WebSocket. Yellowstone uses gRPC over HTTP/2 with protobuf payloads.
In practice, this means Yellowstone is usually a better fit for:
higher-throughput streaming workloads
lower-overhead backend ingestion
typed decoding with protobuf clients
richer data flows than typical WebSocket subscriptions
long-lived service-to-service streaming
WebSocket subscriptions are still useful for lightweight apps, dashboards, and simpler live-update flows. Yellowstone is the stronger choice when the stream feeds backend logic, analytics, storage, or trading systems.
Usage limits
RPC Fast applies concurrent connection and filter limits to keep Yellowstone gRPC performance predictable under shared high-load usage.
Max concurrent Yellowstone gRPC connections by plan
One active gRPC connection counts as one stream.
Multiple filters sent over the same connection still count as one stream.
Stream
up to 10 streams
Aperture
up to 25 streams
Filter limits
RPC Fast’s Yellowstone limits are designed for targeted subscriptions rather than unrestricted firehose filters.
Global
Filter name length: up to 128 characters
Accounts
1 accounts filter
Empty filter (match everything) is not supported
Up to 10 pubkeys in
accountUp to 10 pubkeys in
ownerUp to 2
accounts_data_sliceranges
Slots
1 slots filter
Transactions
1 transactions filter
Empty filter (match everything) is not supported
Up to 10 pubkeys in
account_includeUp to 10 pubkeys in
account_excludeUp to 10 pubkeys in
account_required
Transaction status
1 transaction-status filter
Empty filter (match everything) is not supported
Up to 10 pubkeys in
account_includeUp to 10 pubkeys in
account_excludeUp to 10 pubkeys in
account_required
Entries
1 entries filter
Block metadata
1 block-metadata filter
Blocks
1 blocks filter
Up to 10 pubkeys in
account_includeEmpty
account_includeis not supportedTransactions are included
Accounts and entries inclusion is disabled
Keep-alive and long-lived subscriptions
Long-lived gRPC subscriptions should enable both transport-level and application-level keepalive.
RPC Fast recommends:
TCP keepalive enabled
HTTP/2 keepalive enabled
handling Yellowstone
pingmessages on the stream
This helps reduce disconnects caused by load balancers, proxies, NAT timeouts, and idle connection cleanup.
Code examples
Replace YOUR-TOKEN-HERE with your Yellowstone gRPC token.
Summary
Yellowstone gRPC is RPC Fast’s developer-oriented streaming interface for Solana backends that need:
structured real-time data
server-side filtering
richer payloads than standard WebSocket subscriptions
low client-side parsing overhead
stable long-lived streaming over gRPC
For backend services that ingest, enrich, persist, or react to Solana events continuously, Yellowstone gRPC is generally the preferred integration surface.
Last updated