How Solana gRPC streaming really works with Yellowstone Geyser — setup, subscription filters, and the connection-leak, memory, and reconnection gotchas we hit running a dual-region firehose in production. Written from a live pipeline, not a docs page.
Disclosure: This article contains affiliate links. If you sign up through them, MadeOnSol may earn a commission at no extra cost to you. This never affects our rankings, ratings, or reviews.
If you are building anything on Solana that needs real-time data — trading bots, analytics dashboards, copy-trading systems, or token monitors — you have probably hit the limitations of traditional RPC polling. Calling getAccountInfo or getSignaturesForAddress in a loop is slow, wastes resources, and misses events between polls.
gRPC streaming solves this. Instead of asking the network "what changed?" every second, you tell it "notify me when something changes." The difference in latency, reliability, and efficiency is dramatic.
This guide explains how Solana gRPC streaming works, how to set it up using Yellowstone and Geyser plugins, and the practical patterns that power production applications.
This isn't theory for us. MadeOnSol runs a production Yellowstone gRPC pipeline across two regions (Frankfurt + New York), processing the full Solana DEX trade firehose and every buy and sell from 1,000+ tracked wallets in real time — hundreds of millions of swaps. The setup below is the standard path; the production gotchas near the end are the things that actually broke for us at scale and aren't in anyone's docs.
Geyser is Solana's plugin system for validators. It allows validators to stream real-time data about accounts, transactions, slots, and blocks to external consumers as they are processed — not after they are confirmed, not after you poll for them, but as they happen.
The Geyser interface defines several types of updates:
Without Geyser, the fastest way to detect a change is WebSocket subscriptions via accountSubscribe or logsSubscribe. These work but have significant limitations: connection instability, missing events during reconnection, no historical replay, and limited filtering capabilities.
Geyser plugins, particularly the Yellowstone gRPC plugin, solve all of these problems.
Yellowstone is the most widely adopted Geyser plugin implementation. Developed originally by Triton and now maintained as open source, it exposes Geyser data over a gRPC interface that clients can subscribe to with fine-grained filters.
Solana Validator → Geyser Plugin → Yellowstone gRPC Server → Your Client
The data flow:
Building a product on Solana data?
Skip the Geyser pipeline — embed KOL flow, deployer reputation, and the all-DEX firehose over REST, WebSocket, or webhooks. White-label it under your brand on Enterprise.
Tools mentioned
Live health scores, average ratings, and direct links on MadeOnSol.
Low-latency Solana RPC + data streaming for high-scale dApps, HFT, DeFi, and on-chain analytics.
Multi-chain RPC provider with free and paid Solana nodes — shared and dedicated endpoints for dApps, bots, and analytics
Web3 data warehouse with Solana archival RPC and real-time streams
The developer platform for building on Solana
Enterprise-grade Solana RPC nodes with global infrastructure
Build with MadeOnSol API
KOL tracking, deployer intelligence, DEX streaming, and webhooks. Free API key — 200 requests/day.
import { MadeOnSol } from "madeonsol";
// Get a free API key at madeonsol.com/pricing
const client = new MadeOnSol({ apiKey: "msk_your_key" });
const { trades } = await client.kol.feed({ limit: 10 });
const { alerts } = await client.deployer.alerts({ limit: 5 });
const { tools } = await client.tools.search({ q: "trading" });Building a product on Solana data?
MadeOnSol isn't an RPC or another generic token API — it's Solana memecoin intelligence that's painful to build in-house, pulled from dual-region gRPC shred streams: sub-second from the on-chain event to your app.
Signals you'd otherwise build
KOL & smart-money flow from 1,000+ labeled wallets, deployer reputation, coordination clusters, linked-wallet entity resolution, and an all-DEX firehose.
Embed it under your brand
Enterprise adds white-label & redistribution rights, dedicated rate limits beyond Ultra, and custom endpoints — on an annual contract.
Evaluate first, commit later
Test everything on a free ULTRA key — no commitment. If it fits, we scope volume or white-label pricing.
Keep reading
Developer Tools
Understand what Solana APIs are, what types exist, and how developers use them to build trading bots, portfolio trackers, and analytics dashboards. Covers RPC, enhanced APIs, data APIs, and when to use each.
Trading Tools
Solana has no traditional mempool, but pending transactions are still observable. Learn how Solana mempool monitoring works with Jito bundles, gRPC streams, leader TPU forwarding, and ShredStream — plus practical tools and use cases for MEV detection, frontrun protection, and latency optimization.
Developer Tools
If you're building a trading terminal, bot, dashboard, or AI agent on Solana, the memecoin-intelligence layer — KOL flow, deployer reputation, coordination signals, a MEV-stripped DEX firehose — is the part that's painful to build in-house. This is the builder's guide to embedding it instead: what the data is, how to access it (REST, WebSocket, webhooks, MCP, SDKs), and when to white-label it under your own brand.
Developer Tools
A deep dive into the dual-region Yellowstone gRPC pipeline, pg_notify event bus, and sub-2-second alert delivery that powers MadeOnSol's KOL tracking and deployer intelligence.
Engineering
A walkthrough of the production pipeline that moves a Solana KOL trade from on-chain confirmation to a signed HTTP webhook in under 1.5 seconds — covering dual-region gRPC ingestion, pg_notify fan-out, and per-rule signal evaluation.
Developer Tools
Learn how to set up Solana webhooks for real-time blockchain alerts. Compare Helius, QuickNode, Shyft, and Triton webhook providers, with TypeScript code examples for wallet monitoring, NFT sales alerts, and payment confirmation.
Enjoyed this article?
Solana ecosystem insights, KOL reports, and new MadeOnSol features — one email a week, no fluff.
The latency from validator processing to your client receiving the data is typically 1-10 milliseconds, compared to 500-2000ms for RPC polling.
| Feature | WebSocket RPC | Yellowstone gRPC |
|---|---|---|
| Latency | 100-500ms | 1-10ms |
| Filtering | Basic (program, account) | Rich (memcmp, datasize, owner, txn type) |
| Reconnection | Lose events | Replay from slot |
| Throughput | ~100 updates/sec | 10,000+ updates/sec |
| Reliability | Connections drop frequently | Persistent with health checks |
| Backpressure | None (events dropped) | Built-in flow control |
You need access to a gRPC endpoint. The major providers offering Yellowstone gRPC:
import { Client } from '@triton-one/yellowstone-grpc';
const client = new Client(
'https://your-grpc-endpoint.example.com',
'your-auth-token'
);
const stream = await client.subscribe();
// Handle incoming updates
stream.on('data', (update) => {
if (update.account) {
console.log('Account updated:', update.account.account.pubkey);
}
if (update.transaction) {
console.log('Transaction:', update.transaction.transaction.signature);
}
});
// Subscribe to account updates for a specific program
await stream.write({
accounts: {
myFilter: {
owner: ['675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8'], // Raydium AMM
filters: []
}
},
transactions: {},
slots: {},
blocks: {},
blocksMeta: {}
});
The power of Yellowstone gRPC is in its filtering. You can subscribe to exactly the data you need:
By account owner (program): Monitor all accounts owned by a specific program. This is how you watch all Raydium pools, all Pump.fun bonding curves, or all token accounts for a specific mint.
By account pubkey: Monitor specific accounts by their public key. Useful for tracking a specific liquidity pool, a whale's token account, or a program's state account.
By memcmp filter: Match accounts whose data contains specific bytes at a specific offset. This lets you filter for token accounts holding a specific mint, or pool accounts containing a specific token pair.
By transaction reference: Monitor transactions that reference specific accounts in their account keys list. This captures all interactions with a specific program or account.
To detect new tokens as they are created on Pump.fun:
// Subscribe to transactions involving the Pump.fun program
await stream.write({
transactions: {
pumpFunTx: {
accountInclude: ['6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P'], // Pump.fun
accountExclude: [],
accountRequired: []
}
},
accounts: {},
slots: {},
blocks: {},
blocksMeta: {}
});
When a new token is created, you receive the full transaction data including the mint address, deployer wallet, initial bonding curve parameters, and metadata URI — all within milliseconds of the transaction being processed.
Track a list of whale wallets for any token swaps:
const whaleWallets = [
'wallet1_pubkey',
'wallet2_pubkey',
// ... more wallets
];
await stream.write({
transactions: {
whaleWatch: {
accountInclude: whaleWallets,
accountExclude: [],
accountRequired: []
}
},
accounts: {},
slots: {},
blocks: {},
blocksMeta: {}
});
Every transaction involving any of these wallets — swaps, transfers, program interactions — arrives at your client in real time. This is the same approach that powers copy-trading bots and smart money tracking tools.
Monitor specific DEX pools for trades, liquidity additions, or removals:
// Monitor a specific Raydium pool account
await stream.write({
accounts: {
poolWatch: {
account: ['specific_pool_account_pubkey'],
owner: [],
filters: []
}
},
transactions: {},
slots: {},
blocks: {},
blocksMeta: {}
});
Every time the pool state changes (a swap occurs, liquidity is added or removed), you receive the updated account data. By parsing the pool's data layout, you can calculate the new price, reserves, and any other pool metrics in real time.
gRPC connections should be treated as long-lived. Do not open and close connections for each query. Instead:
GOAWAY frame gracefully (the server is shutting down — reconnect to another node)If your application cannot process updates as fast as they arrive, the gRPC stream will buffer them. If the buffer overflows, you will lose updates. To prevent this:
The most important performance optimization is subscribing only to the data you need. Every additional filter you add reduces the volume of data your client must process. A common mistake is subscribing to all transactions for a program and filtering client-side — this works for low-throughput programs but will overwhelm your client for high-throughput ones like Jupiter or Raydium.
Not every application needs raw gRPC access. Several services provide higher-level abstractions:
Helius Webhooks: Helius lets you configure webhooks that trigger on specific on-chain events. You define the filter (program, account, transaction type) and Helius sends an HTTP POST to your endpoint when the event occurs. Simpler to set up than gRPC but higher latency (~200-500ms).
Shyft Callbacks: Similar to webhooks but with built-in transaction parsing. Shyft decodes the transaction data into human-readable format before sending it to your callback URL.
Jito Block Engine: For MEV-sensitive applications, Jito's block engine provides a separate stream of pending transactions from Jito validators, allowing you to see transactions before they are confirmed.
The setup above gets you a working stream. Keeping it alive and leak-free for months is where the real lessons are. These are the things that actually broke our pipeline at scale:
new Client() per reconnect. The intuitive reconnection pattern (catch the error, construct a fresh client, re-subscribe) leaks sockets. Each new client opens new HTTP/2 connections and the old ones don't always close, so your file descriptors and memory climb until the process dies hours later. Construct the client once; on disconnect, just re-issue the subscription on the existing client.If you need the data rather than the infrastructure, you don't have to run any of this. The whole point of MadeOnSol's API is that we already run the dual-region gRPC pipeline, handle every gotcha above, and expose the result as plain REST + webhooks + a WebSocket firehose: live KOL/smart-money trades, the all-DEX trade stream, Pump.fun deployer events, and token risk — sub-second from the on-chain event. For most teams, consuming a real-time Solana data API is hours of work; standing up and babysitting your own Yellowstone consumer is an ongoing operational commitment. Build it if real-time infra is your product; buy it if it's a means to an end. Our guide to embedding a Solana memecoin data API covers the access patterns — REST, WebSocket, webhooks, MCP — and the white-label path for shipping it inside your own product.
| Use Case | Best Approach |
|---|---|
| Trading bot (sub-100ms latency needed) | gRPC direct |
| Analytics dashboard (1-5s updates fine) | WebSocket subscriptions |
| Alert system (notifications on events) | Webhooks (Helius/Shyft) |
| Historical analysis | RPC with pagination |
| Portfolio tracking | Polling + caching |
gRPC is the right choice when latency matters and you need to process a high volume of updates reliably. For most analytics and monitoring use cases, webhooks or WebSocket subscriptions are simpler and sufficient.
Solana gRPC streaming through Yellowstone and Geyser plugins represents the lowest-latency, highest-reliability way to consume on-chain data. It is the infrastructure layer that powers the fastest trading bots, the most responsive dashboards, and the most accurate copy-trading systems on Solana.
The learning curve is steeper than RPC polling or WebSocket subscriptions, but the payoff is significant. If your application requires real-time data with guarantees about delivery and ordering, gRPC is the production-grade solution.
Start with a provider like Helius or Triton for managed gRPC access, build a simple subscriber for your use case, and iterate from there. The ecosystem's tooling has matured to the point where setting up a production gRPC consumer takes hours, not weeks.
gRPC endpoints are significantly more expensive than standard RPC because they require dedicated validator infrastructure. Most providers offer gRPC on their highest-tier plans — expect to pay $200-500/month for a dedicated gRPC endpoint. Standard RPC plans start at $0-50/month. The cost is justified if your application requires sub-10ms latency and guaranteed event delivery.
Yes, but it requires running a full Solana validator with the Geyser plugin installed. This means significant hardware (256GB+ RAM, fast NVMe storage, high-bandwidth connection) and operational expertise. For most teams, using a managed gRPC provider is more cost-effective than self-hosting. Self-hosting makes sense if you need custom filtering logic or want to avoid third-party dependencies. Bear in mind that the validator client itself moves fast — major releases can shift behavior and even cause network instability, as we documented in our writeup of the Agave 4.0 upgrade and the outages it caused.
When a connection drops, you miss updates during the disconnection period. Yellowstone supports replay from a specific slot number, allowing you to request all updates from the slot where you lost connection. Your client should track the last processed slot and use it as the starting point when reconnecting. This ensures no events are missed.
Most providers only offer gRPC streaming for mainnet-beta. If you need gRPC on devnet for testing, you will likely need to run your own validator with the Yellowstone plugin. An alternative for testing is to use mainnet gRPC with read-only subscriptions (monitoring without trading) to validate your parsing logic before deploying to production.