gRPC API for Solana: How It Works and When to Use It Instead of JSON-RPC or WebSockets

A gRPC API lets your Solana application receive chain events as they happen, already filtered, instead of asking the network what changed. This guide explains how that works, how it differs from the JSON-RPC and WebSocket interfaces every Solana RPC node exposes, and what it takes to run a stream reliably.

01In short#

• A gRPC API is a typed, binary interface over HTTP/2 that supports long-lived streams. On Solana, the node pushes updates to you instead of you polling for them.
• The Solana RPC API has two native modes: HTTP JSON-RPC (request and response) and WebSocket PubSub (subscriptions). Both suit wallets and dashboards. Both strain when you cannot afford to miss or reorder events.
• Yellowstone gRPC is built on the validator's Geyser plugin interface. It streams accounts, transactions, slots, blocks and entries, with filters applied on the server.
• Streaming complements HTTP RPC rather than replacing it. Most production systems stream live state over gRPC and keep JSON-RPC for lookups, sending transactions and backfill.
• The hard part is operational: choosing a commitment level, handling reorgs, reconnecting without gaps, and keeping up with the stream.

02What a gRPC API is, and what it is not#

gRPC is an open-source remote procedure call framework. Three design choices explain why blockchain data pipelines use it.

1. Schema-first, binary messages. Services and messages are declared in a .proto file using Protocol Buffers. Client libraries for Rust, TypeScript, Go and Python are generated from it. Messages are compact binary rather than JSON text, and every field has a declared type, so a 64-bit amount is never parsed as a float by accident.
2. HTTP/2 transport. Many calls and streams share one connection. HTTP/2 also has built-in flow control, which lets a receiver tell a sender to slow down.
3. Four call shapes. A call can be unary (one request, one response), server-streaming, client-streaming, or bidirectional streaming. Streaming calls stay open and carry many messages in either direction.

Yellowstone, the Solana interface covered below, uses the bidirectional shape. Per its subscription guide, Subscribe is a bidirectional streaming call: you send SubscribeRequest messages and receive SubscribeUpdate messages. You can change your filters mid-stream by sending a new request on the same connection.

Two things a gRPC API does not do:

• It does not change what the node knows. The data still comes from one node's view of the chain, at the commitment level you ask for. A gRPC endpoint on a lagging node is a fast feed of stale data.
• It does not run in a browser by itself. Browsers cannot speak native gRPC, so a web app needs a backend or a gRPC-Web proxy between it and the stream. This is one reason wallet front ends still lean on WebSockets.

03How Solana RPC works today, and where it strains#

The Solana RPC reference describes methods to read network state, send transactions, simulate execution and subscribe to live updates. For reading live state there are two built-in paths.

HTTP JSON-RPC polling. You call a method such as getAccountInfo on a timer. It is simple and universal. As Syndica's streaming guide points out, polling only captures the state at the slot when the request is made, so changes between polls are invisible, and requests are wasted when nothing has changed.

WebSocket PubSub. You open one persistent connection and send accountSubscribe, programSubscribe, signatureSubscribe, slotSubscribe or similar. The WebSocket reference describes the protocol as JSON-RPC 2.0 over a persistent connection, with a numeric subscription ID attached to every notification. Where a subscription method accepts a commitment parameter and you omit it, the default is finalized.

WebSockets are the right tool for many apps, and nothing here argues against using them for a wallet balance or a transaction-status toast. The strain shows up when missing or misordering an event has a cost. Three issues recur across independent sources:

• Connections drop, and subscriptions go with them. Syndica notes that interrupted connections can cause missed notifications, and that extra streams, verification or backfilling may be needed to be fault-tolerant. The Solana reference page does not describe disconnect behavior, so test it against your provider rather than assuming.
• No ordering or replay. A Bitquery analysis says the PubSub specification makes no ordering promise across notifications, and that there is no replay or gap detection after a disconnect. Bitquery sells competing streaming products, so weigh its framing accordingly, but both points match what other guides report.
• Fan-out is expensive. Syndica notes that accountSubscribe covers one account per subscription, so watching many accounts means many subscriptions. RPC Fast's streaming guide lists subscription explosion, dropped logs during bursts, slot race conditions and duplicate processing after reconnects among the failures teams hit in production.

Even teams with large production codebases hedge against this. Drift's TypeScript SDK, for example, includes a polling fallback because, in its own comment, WebSocket notifications can stall or get dropped under real-world conditions.

04Where Solana's gRPC interface comes from: Geyser and Yellowstone#

Solana validators can load plugins through the Geyser interface. Syndica describes a Geyser plugin as a modular extension that streamlines the flow of blockchain data handled by validators, exposing accounts, slots, blocks and transactions. The catch it notes is operational: you must run the plugin on a Solana validator or RPC node, and setup and maintenance are complex.

Yellowstone gRPC is the open-source Geyser plugin that turns that internal feed into a network service. In RPC Fast's description, it taps directly into the Geyser plugin system and delivers binary Protobuf over HTTP/2, with advanced subscription filters. The practical consequences:

• Data comes from inside the node. Updates are taken as the validator processes them rather than rebuilt by the RPC layer after the fact.
• Filtering happens on the server. You describe which accounts, programs or transactions you want, so only matching updates cross the network. WebSocket subscriptions also filter, but with fewer options.
• One connection carries many subscriptions. A single stream can combine account, transaction, slot and block filters, and you can add or remove filters without reconnecting.

┌──────────────── Validator or RPC node ─────────────────┐
│                                                        │
│   chain activity                                       │
│        │                                               │
│        ├──► Yellowstone plugin ──── filtered updates ──┼──►┐
│        │    (Geyser interface)  ◄── SubscribeRequest ──┼───┤
│        │                                               │   │   your app
│        └──► RPC layer ─────────── responses, notifs ───┼──►│
│             (JSON-RPC, WebSocket) ◄─ requests, subs ───┼───┘
│                                                        │
└────────────────────────────────────────────────────────┘

Because the protocol is open, several providers expose Yellowstone-compatible endpoints. That matters in practice: the same client library and the same .proto definitions work across them, which keeps switching costs low. If you want to run the plugin yourself rather than use a managed endpoint, our Solana Geyser plugin guide covers building, deploying and the failure modes to expect.

05Anatomy of a Yellowstone subscription#

A subscription is one SubscribeRequest built from named filters. Each filter map uses a string key of your choosing, such as "client". You can define several filters of the same type, and each update tells you which filter matched it through its filters field. The request types and their filters, per the Yellowstone subscription guide and RPC Fast's reference:

Four request-level fields sit beside those maps:

• commitment sets how settled the data must be (more in the next section).
• accounts_data_slice returns only chosen byte ranges of account data, which cuts bandwidth when you need a few fields of a large account.
• ping keeps an idle connection alive. Providers' examples send one every 5 to 30 seconds. The server also sends ping updates; answer them with a ping request of your own.
• from_slot replays updates from a past slot, within the server's available history (see the production section).

Here is a minimal TypeScript subscriber that streams non-vote, non-failed transactions touching one program, at confirmed. It is a sketch: check the constructor options and field casing against your provider's docs and library version.

import Client, { CommitmentLevel, SubscribeRequest } from "@triton-one/yellowstone-grpc";

const client = new Client("https://YOUR-ENDPOINT", "YOUR_TOKEN", undefined);
await client.connect();
const stream = await client.subscribe();

// Request fields you do not use must still be present, as empty values.
const empty = {
  accounts: {}, accountsDataSlice: [], slots: {}, blocks: {},
  blocksMeta: {}, entry: {}, transactionsStatus: {},
};

const request: SubscribeRequest = {
  ...empty,
  commitment: CommitmentLevel.CONFIRMED,
  transactions: {
    myProgram: {                  // the key is your own label
      vote: false,
      failed: false,
      accountInclude: ["<PROGRAM_ID>"],
      accountExclude: [],
      accountRequired: [],
    },
  },
};

stream.on("data", (update) => {
  if (update.transaction) {
    console.log(update.filters, update.transaction.slot);
  }
  if (update.ping) {
    // Server pings carry no ID. Answer with a ping of your own so the
    // connection is not treated as idle by load balancers in between.
    stream.write({ ...empty, transactions: {}, ping: { id: 1 } });
  }
});
stream.on("error", (err) => console.error("stream error", err));

stream.write(request);

Two habits keep a stream healthy. First, subscribe narrowly and widen only when your consumer has headroom, as RPC Fast recommends: filter on account_include or a program before reaching for whole blocks. Second, prefer blocks_meta or transactions_status when you only need to know that something happened, because blocks with include_accounts and include_transactions is the heaviest message you can ask for. For a Python version of the same pattern, see our Yellowstone gRPC in Python guide.

06Commitment levels in a stream: speed against the risk of being wrong#

Choose a commitment level by asking what a wrong update costs you. Solana defines three, and Yellowstone's protocol exposes them as an enum: PROCESSED, CONFIRMED and FINALIZED. According to the Yellowstone commitment guide, typical behavior is:

Handling rollbacks. At processed, a block can be dropped after you have seen it. Yellowstone's slot updates carry a status that tells you what happened: the guide lists SLOT_PROCESSED, SLOT_CONFIRMED and SLOT_FINALIZED, plus SLOT_DEAD, which includes a dead_error field. Bitquery makes the related point that rollbacks at processed arrive with no explicit notice, so you must watch slot progress yourself. Two practical rules follow:

• Subscribe to slots alongside your data filters, and leave filter_by_commitment off if you want to see every status. With it on, you only receive updates at your chosen level.
• Key your state by slot. When a slot is marked dead, undo what you applied from it.

A pattern that works well, and that RPC Fast also recommends: act on processed data in a fast path, and reconcile in a separate handler that trusts only confirmed or finalized updates. Keeping the two handlers separate stops optimistic state from leaking into records that must be right.

07Polling, WebSockets, gRPC and shreds side by side#

The four ways to follow Solana differ less in speed than in what they guarantee and what they ask of you.

Two notes on reading the table. First, it describes the interfaces, not any provider's performance: latency depends on your region, your distance to the current leader and the load on the node, so benchmark candidates yourself. Second, shred feeds sit upstream of everything else and carry data before execution. The best-known free service, Jito ShredStream, shut down on September 5, 2026, and Jito recommends DoubleZero Edge as the replacement. Our Jito ShredStream migration guide covers moving off it, and the Solana Shredstream guide explains how shred feeds work.

For a deeper look at the two push transports alone, see Yellowstone gRPC vs WebSockets. If your real need is history rather than live data, a stream is the wrong tool. Our guide to historical blocks vs live streams explains when each applies.

08Running a stream in production#

A stream that works in a demo and one that survives a month are separated by a handful of habits. Most come straight from the failure patterns above.

1. Reconnect and resubscribe automatically. The Yellowstone guide recommends reconnection logic for network interruptions but leaves the details to you. Use exponential backoff with jitter: RPC Fast's WebSocket guide warns that unthrottled reconnects turn into a self-inflicted outage when many clients drop together.
2. Record the last slot you fully processed, and resume from it. from_slot replays updates from a given slot, but only within the server's available history. The guide says to call the SubscribeReplayInfo RPC and read first_available to learn the earliest slot you can ask for. Providers differ in how much history they keep, so ask before you depend on it.
3. Backfill what replay cannot cover. If the gap is older than the server's history, fill it over HTTP RPC, then switch back to the live stream. This is the same hybrid design RPC Fast describes: re-sync state over HTTP to close gaps. Our indexer architecture guide walks through backfilling history and switching to live gRPC without missing slots.
4. Make handlers idempotent. Reconnects produce duplicates. Key writes on slot plus signature (or slot plus account) so processing the same update twice changes nothing.
5. Never block the read loop. Read messages as fast as they arrive and hand them to a bounded queue and a worker pool. Decide in advance what happens when the queue fills: drop, or replay later from from_slot. RPC Fast notes that WebSockets lack built-in flow control. HTTP/2 gives gRPC a flow-control mechanism, but a consumer that cannot keep up will still fall behind.
6. Measure lag, not just uptime. Subscribe to slots and alert on the difference between the newest slot you have seen and the last slot your pipeline finished. A stream can be connected and healthy while your processing is a minute behind.
7. Keep subscriptions few and narrow. One connection with several named filters beats many connections. Providers set per-plan limits on concurrent streams, so check them before you design around many parallel ones.
8. Keep JSON-RPC for what it does best. Sending transactions, simulating them and one-off reads still go through HTTP RPC. How much request capacity you need for those is a separate question, covered in our guide to sizing your Solana RPC plan.

09Choosing an approach, and what to check in Solana RPC providers#

Match the interface to the cost of a missed or late event, not to what sounds most advanced.

• Wallet balances, a user's own transaction status, light dashboards: WebSocket subscriptions or modest polling against a standard Solana RPC API. A browser front end cannot use gRPC directly anyway.
• Indexers, analytics, any backend that must not lose events: Yellowstone gRPC at confirmed, resuming with from_slot and backfilling over HTTP.
• Trading and monitoring where reaction time matters: Yellowstone gRPC with processed for the fast path and confirmed for reconciliation. Only consider shred feeds after you have measured that the extra step pays for its complexity.
• Historical research and backtests: not a streaming problem. Use block history.

When you compare Solana RPC providers for the gRPC side, these are the questions that separate a usable endpoint from a risky one:

Pricing varies enough to be worth checking directly. As of August 11, 2026, RPC Fast's comparison listed Alchemy's Yellowstone gRPC at $75 per TB, QuickNode including Solana gRPC from its $499 per month Scale plan, and Shyft's flat Build plan from $199 per month. Treat those as a snapshot from a competitor's roundup and confirm current prices with each vendor.

For a wider survey, see our top Solana RPC providers comparison and the anatomy of a sub-50ms Solana RPC request, which explains where latency actually comes from. To try a Yellowstone stream against a live endpoint, start with the NoLimitNodes Yellowstone gRPC quickstart, or see the plans on our Yellowstone gRPC page.

10Frequently asked questions#

11Sources#

Research as of November 12, 2026. Pricing and product details in this space change quickly; confirm them with each vendor before relying on them.

• Yellowstone gRPC: subscribing guide
• Yellowstone gRPC: commitment levels
• Solana docs: RPC overview and WebSocket methods
• Syndica: Solana data streaming
• RPC Fast: Solana data streaming guide, WebSocket subscriptions guide and Yellowstone gRPC reference
• RPC Fast: Triton One alternatives, provider pricing checked August 11, 2026 (competitor roundup)
• RPC Fast: October 2026 roundup, for the Alpenglow activation date
• Bitquery: Solana RPC WebSockets vs streams (vendor analysis with competing products)
• Jito docs: ShredStream sunset notice
• Drift SDK: WebSocket account subscriber