// Tutorial

Yellowstone gRPC tutorial from zero to real-time.

Yellowstone gRPC — also known as Dragon's Mouth — is the standard protocol for streaming real-time Solana data, maintained by Triton One. This tutorial walks you through connecting to a Yellowstone endpoint, subscribing to accounts, transactions, and slots, and streaming on-chain events using the standard client libraries for Node.js and Rust.

Updated Apr 2026·~12 min read·Beginner → Intermediate
Get your API key →Read the docs

What is Yellowstone gRPC?

Yellowstone gRPC is an open-source Geyser plugin for the Solana validator, developed and maintained by Triton One under the rpcpool/yellowstone-grpc repository on GitHub. It is also referred to by its original codename, Dragon's Mouth, which you will see in older documentation and community discussions. The plugin hooks directly into the Solana validator runtime through the Geyser interface — a built-in extension point that allows external code to receive a copy of every piece of data the validator processes, in real time, as it happens.

Unlike JSON-RPC polling or WebSocket subscriptions, Yellowstone does not wait for your client to ask for data. It pushes everything through a persistent gRPC connection the moment the validator processes it. gRPC operates over HTTP/2 using Protocol Buffers (protobuf) as its serialization format — a compact binary encoding that is dramatically more efficient than JSON both in bandwidth and CPU cost. The result is a continuous, low execution latency stream of on-chain events with built-in backpressure, multiplexing, and flow control.

The data types available through Yellowstone are comprehensive. Transactions include the full instruction set, signatures, log messages, and execution status. Account updatesfire whenever any account's data or lamport balance changes. Slot notifications tell you when slots are processed, confirmed, or finalized. Blocks provide summary metadata for completed blocks. Entries (available since v2.0+) give sub-block granularity, exposing individual entries within a slot as they are processed. The latest release, v12.2.0 (March 2026), adds improved compression options and refined entry subscription filters.

You do not need to run your own validator to use Yellowstone gRPC. Several managed providers offer Yellowstone-compatible endpoints that you can connect to with an API key: QuickNode, Chainstack, Solana Tracker, and Subglow all run the plugin infrastructure for you. Subglow goes a step further by adding server-side filtering and pre-parsed JSON output — meaning your client receives only the transactions matching your criteria, already deserialized from Borsh into clean, structured data. For a deeper explanation of how Geyser plugins work at the validator level, see our Solana Geyser plugin guide.

Architecture: how data flows

Understanding the data pipeline from validator to your client helps you reason about latency, failure modes, and where filtering can be applied. The flow is four stages — each one taking single-digit milliseconds under normal conditions.

// 01

Validator produces a slot

The Solana validator processes a batch of transactions and produces a new slot. Each slot can contain thousands of transactions across hundreds of programs, confirmed roughly every 400ms.

// 02

Geyser hooks capture data

The Geyser plugin interface intercepts the data directly from validator memory — transactions, account updates, slot metadata, and entries — before it even hits disk. There is no network hop at this stage; the plugin runs in-process with the validator.

// 03

Yellowstone serializes and streams

The Yellowstone gRPC server takes the raw Geyser output, serializes it into Protocol Buffer messages, applies any subscription-level filters, and pushes the data over persistent gRPC streams to all connected clients.

// 04

Your client receives filtered data

Your client receives the matching events in real-time — no polling delay, no HTTP round trips, no missed slots. With a provider like Subglow, the data arrives pre-parsed as clean JSON, ready for your trading logic.

Connect with Node.js

The official Node.js client for Yellowstone gRPC is the @triton-one/yellowstone-grpc package, maintained by Triton One alongside the plugin itself. It handles the gRPC connection lifecycle, protobuf serialization, and subscription management so you can focus on processing events. Install it with npm, point it at your Yellowstone endpoint, and you are streaming within minutes.

The example below connects to a Yellowstone endpoint, sends a SubscribeRequest with a slot subscription, and prints every slot notification as it arrives. This is the simplest possible subscription — once you have this working, you can extend it to transactions, accounts, and more complex filter configurations. Subglow endpoints work with this exact client library — just change the URL and pass your API key. For a dedicated TypeScript walkthrough, see our Solana gRPC TypeScript guide.

terminal
$ npm install @triton-one/yellowstone-grpc
subscribe-slots.js
const Client = require("@triton-one/yellowstone-grpc");
const ENDPOINT = "https://grpc.subglow.io";
const API_KEY = "YOUR_API_KEY";
async function main() {
const client = new Client(
ENDPOINT,
undefined,
{ "grpc.max_receive_message_length": 64 * 1024 * 1024 }
);
const stream = await client.subscribe(
{ "x-api-key": API_KEY }
);
stream.write({
slots: { slot: { } },
commitment: 1,
});
stream.on("data", (data) => {
if (data.slot) {
console.log(
"Slot:", data.slot.slot,
"Status:", data.slot.status
);
}
});
stream.on("error", (err) => {
console.error("Stream error:", err);
});
}
main();

This works with any Yellowstone-compatible endpoint. To use Subglow, replace the URL with https://grpc.subglow.io and add your API key.

Connect with Rust

The Rust client lives in the same monorepo as the plugin itself: yellowstone-grpc-client. It is the lowest-latency option and the natural choice for production trading bots where every microsecond matters. The crate handles TLS, connection pooling, and protobuf deserialization out of the box. Add it to your Cargo.toml and you are ready to connect.

The example below connects to a Yellowstone endpoint using the GeyserGrpcClient builder, authenticates with an API key via the x_token method (which maps to the x-token metadata header), subscribes to slot updates, and processes the stream. For a Python walkthrough, check our Solana gRPC Python guide.

Cargo.toml
[dependencies]
yellowstone-grpc-client = "2.1"
yellowstone-grpc-proto = "2.1"
tokio = { version = "1", features = ["full"] }
futures = "0.3"
main.rs
use yellowstone_grpc_client::GeyserGrpcClient;
use yellowstone_grpc_proto::prelude::*;
use futures::StreamExt;
use std::collections::HashMap;
#[tokio::main]
async fn main() -> anyhow::Result<()> {
let mut client = GeyserGrpcClient::build_from_shared(
"https://grpc.subglow.io"
)?
.x_token(Some("YOUR_API_KEY".into()))
.connect().await?;
let (mut subscribe_tx, mut stream) = client
.subscribe().await?;
subscribe_tx.send(SubscribeRequest {
slots: HashMap::from([(
"slot_sub".into(),
SubscribeRequestFilterSlots { filter_by_commitment: None }
)]),
..Default::default()
}).await?;
while let Some(msg) = stream.next().await {
match msg?.update_oneof {
Some(UpdateOneof::Slot(slot)) => {
println!("Slot: {} Status: {:?}", slot.slot, slot.status);
}
_ => {}
}
}
Ok(())
}

cargo add yellowstone-grpc-client — same crate used with Triton, Helius, and other Yellowstone endpoints.

Subscribe to transactions

Slot subscriptions are useful for monitoring chain progress, but the real power of Yellowstone gRPC is transaction streaming. The SubscribeRequest message includes a transactions field where you define filters that control which transactions reach your client. Each filter specifies an array of account_include addresses — any transaction that involves one of these accounts (as a program ID, signer, or account key) will be streamed to you.

For trading bots, the most common pattern is filtering by program ID. If you want every Pump.fun transaction, include the Pump.fun program address 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P in your filter. For Raydium v5 AMM swaps, include 675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8. You can also exclude vote transactions to reduce volume dramatically (vote transactions account for the majority of on-chain activity) and exclude failed transactions to only see successful executions.

The commitment field in your subscription controls the finality level of delivered data. A commitment of 0 (processed) gives you the fastest delivery — transactions are streamed the moment the validator processes them, before cluster confirmation. A commitment of 1 (confirmed) waits for supermajority confirmation. A commitment of 2 (finalized) waits for the slot to be rooted. Most trading bots use processed or confirmed for speed. For a deep dive into all available filter fields, see our Yellowstone gRPC filters reference.

subscribe-transactions.js
stream.write({
transactions: {
pumpfun: {
vote: false,
failed: false,
account_include: [
"6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P",
],
},
raydium: {
vote: false,
failed: false,
account_include: [
"675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8",
],
},
},
commitment: 1,
});
stream.on("data", (data) => {
if (data.transaction) {
const sig = data.transaction.transaction.signature;
const slot = data.transaction.slot;
console.log("TX:", sig, "Slot:", slot);
}
});

This subscription filters for Pump.fun and Raydium transactions at the confirmed commitment level, excluding votes and failed executions. The raw transaction data arrives as protobuf-encoded binary — you will need to decode it with the Yellowstone proto definitions. With a provider like Subglow, this same data arrives pre-parsed as clean JSON with labeled fields, eliminating the Borsh deserialization step entirely.

Handle reconnection

gRPC streams are persistent TCP connections, and persistent connections drop. Network hiccups, load balancer rotations, server restarts during upgrades, and even brief bandwidth saturation can all terminate your stream without warning. If your application treats the stream as permanent and does not implement reconnection logic, it will silently stop receiving data after the first disconnection — and you will miss transactions.

The standard pattern is exponential backoff with a maximum retry delay. Start with a short delay (500ms–1s), double it on each consecutive failure, and cap it at 30–60 seconds. Reset the backoff timer whenever you successfully reconnect and receive data. Critically, track the last slot you processed before the disconnection. When you reconnect, you can compare your last seen slot to the current network tip and either backfill the gap via RPC or simply log the missed window depending on your application's requirements.

The code below demonstrates a minimal reconnection wrapper in Node.js. In production, you would add structured logging, metrics on reconnection frequency and gap duration, and alerting when the reconnection rate exceeds a threshold. For the full API reference on error codes and stream lifecycle, see our documentation.

reconnect.js
const MAX_RETRY_MS = 30_000;
let retryMs = 1000;
let lastSlot = 0;
async function connectAndStream() {
try {
const stream = await createStream();
retryMs = 1000;
stream.on("data", (data) => {
if (data.transaction) {
lastSlot = data.transaction.slot;
processTransaction(data.transaction);
}
});
stream.on("error", () => reconnect());
stream.on("end", () => reconnect());
} catch (err) {
console.error("Connection failed:", err.message);
reconnect();
}
}
function reconnect() {
console.log("Reconnecting in", retryMs, "ms...");
console.log("Last seen slot:", lastSlot);
setTimeout(connectAndStream, retryMs);
retryMs = Math.min(retryMs * 2, MAX_RETRY_MS);
}
connectAndStream();

Track last seen slot

Store the slot number of every processed event. On reconnection, compare it to the network tip to measure the gap. For trading bots, a gap of 2+ slots may require backfilling via RPC to avoid missed entries.

Use exponential backoff

Start with 1 second, double on each failure, cap at 30 seconds. This prevents thundering herd problems when multiple clients reconnect simultaneously after a provider restart.

Log disconnection reasons

gRPC provides status codes on stream termination. Log these to distinguish transient network issues (UNAVAILABLE) from authentication failures (UNAUTHENTICATED) or server errors (INTERNAL). Different codes require different responses.

Monitor reconnection rate

Track how often your client reconnects. More than 2–3 reconnections per hour warrants investigation. Frequent disconnections can indicate backpressure, provider issues, or network instability.

Protocol & language guides

Jupiter gRPC

Stream swaps, limit orders, and DCA events from the #1 Solana DEX aggregator.

Read guide →

Pump.fun gRPC

Monitor token launches, buys, sells, and bonding curve migrations in real-time.

Read guide →

Raydium gRPC

Stream AMM swaps, pool creates, and liquidity events from Raydium v5.

Read guide →

Rust Tutorial

Connect with yellowstone-grpc-client. The native Solana language for serious bots.

Read guide →

TypeScript Tutorial

Connect with @triton-one/yellowstone-grpc from Node.js.

Read guide →

Alpenglow & gRPC

How 150ms finality changes trading infrastructure and why execution latency matters more.

Read guide →

Frequently asked questions

What is Yellowstone gRPC?

Yellowstone gRPC is an open-source Geyser plugin developed by Triton One (rpcpool/yellowstone-grpc on GitHub) that streams real-time Solana blockchain data — transactions, account updates, slot notifications, blocks, and entries — directly from the validator over a persistent gRPC connection. It is the standard protocol used by trading bots, indexers, and analytics platforms for low execution latency Solana data.

Do I need my own validator to use Yellowstone gRPC?

No. Running the Yellowstone Geyser plugin requires a full Solana validator or RPC node, which costs thousands per month in hardware and maintenance. Providers like Subglow, QuickNode, and Chainstack operate the infrastructure for you. You connect to their managed endpoint with an API key and start streaming immediately — no validator, no plugin compilation, no ops burden.

What programming languages are supported?

Yellowstone gRPC supports any language with a gRPC client library. The most common options are Node.js/TypeScript via the @triton-one/yellowstone-grpc package, Rust via the yellowstone-grpc-client crate, Python via grpcio with generated protobuf stubs, and Go via grpc-go. The protocol is language-agnostic — if your language can speak gRPC and Protocol Buffers, it can connect to Yellowstone.

How does Subglow relate to Yellowstone gRPC?

Subglow is a Yellowstone-compatible gRPC provider that adds server-side filtering and pre-parsed JSON output on top of the standard protocol. You use the same @triton-one/yellowstone-grpc or yellowstone-grpc-client libraries you already know — just point them to grpc.subglow.io. Subglow handles Borsh deserialization, drops irrelevant transactions before they reach your network, and delivers clean JSON for programs like Pump.fun, Raydium, and Jupiter.

Start streaming Solana data in 5 minutes.

Yellowstone gRPC with pre-parsed JSON, server-side filtering, and zero Borsh decoding.

Get started→Compare plans