Yellowstone gRPC nodes for Solana, on bare metal and without a per-event meter

Yellowstone is two things stacked on each other. There's a Geyser plugin that runs inside the Agave validator and listens to the runtime as accounts get written, transactions get packed into slots, and slots get rooted. There's a gRPC server in front of that plugin which serializes those events into Protocol Buffers and ships them out over HTTP/2. The combined thing is what the ecosystem calls Yellowstone, and the source of truth for both halves is github.com/rpcpool/yellowstone-grpc.

Triton built it. They open-sourced the proto and the plugin, then everyone else (Helius for LaserStream, QuickNode for their Yellowstone offering, Chainstack, us) built our own deployments on top. The wire format is identical across vendors. A subscriber written against Triton's SDK works against ours, against QuickNode's, against Chainstack's. The SDK is published for Rust (yellowstone-grpc-client), Python (yellowstone-grpc-proto), and TypeScript (@triton-one/yellowstone-grpc). Go has community ports.

The mental model: you open a single bidirectional stream with Subscribe, you write one or more SubscribeRequest messages describing what you want, and the server pushes back SubscribeUpdate messages forever. You can update the request mid-stream to change filters without disconnecting. That's the entire protocol. Any provider that ships something different on top is layering it.

The Solana data stack has more layers than the marketing pages admit. Knowing which one you're actually buying makes the provider comparison easier.

Layer one (Geyser) is part of the validator. You don't consume it directly unless you're running your own node and writing a plugin. We do that on Geyser plugin hosting; the rest of the time you consume layer two and up.

Layer two (Yellowstone gRPC) is what every provider on this page ships. Same proto, same SDK, same wire format. The differences are deployment quality (how close to leader, how many regions), defaults (max payload, ping cadence), and pricing model.

Layer three (replay tiers) is the LaserStream and Dragon's Mouth angle. They keep N slots of history in a buffer and let you replay from a slot you missed. Genuinely useful if you're an indexer where missing a slot means a permanent gap. Less useful for real-time work where you care about now.

Layer four (decoded streams) is where we ship parsed events for Raydium AMM v4 / CLMM / CPMM, Pump.fun, Orca, Meteora, Jupiter, and a growing list. You skip the IDL load and the discriminator routing. That product line is on Enhanced Streams; this page is the layer-two transport that powers it.

Four providers will show up in your shortlist. We'll be direct about where each one wins.

The decision tree is short. If you need replay, LaserStream or Triton Dragon's Mouth. If you need flat pricing on real-time gRPC plus parsed DeFi events, us. If you need a single-vendor stack that covers RPC, WS, gRPC, and NFT APIs, Helius or QuickNode. If you need the highest SLA on a single contract, Triton.

Yellowstone gives you a lot of rope. The default-everything stream (no filters, all commitments) is roughly 100MB/s of mainnet data. Three patterns separate teams that ship from teams that wonder why their indexer keeps falling behind.

Filter at the server, always. The proto exposes accountInclude, accountExclude, accountRequired, plus vote and failed flags. Use all of them. A sniper bot that filters accountInclude=[Raydium AMM v4], vote=false, failed=false at PROCESSED commitment receives roughly 0.5% of the firehose. Same data, 200x less wire traffic, 200x less parsing in your client.

Multiplex multiple filters on one stream. A single SubscribeRequest can carry several named transactions filters and several named accounts filters. Each named filter produces tagged updates so you know which logical stream the message belongs to. This is better than opening four separate connections; HTTP/2 stream multiplexing handles the rest. We watch teams open one connection per program and saturate their socket budget unnecessarily.

Handle backpressure explicitly. If your client is slower than the message rate, the server will eventually drop you. The fix is to consume fast and offload to a queue (Redis, NATS, an in-memory channel) rather than doing real work in the gRPC handler. The Rust client gives you a tokio mpsc channel by default; the Python and TS clients leave it to you. A 4096-slot bounded channel between gRPC ingest and your business logic is the cheapest insurance you can buy.

One more pattern that earns its keep: ping-pong tracking. The server pushes an UpdatePing every 10 seconds. Track the timestamp of the last ping. If you go 30 seconds without one, force a reconnect. A silent gRPC connection isn't a healthy gRPC connection; it's a TCP connection where the kernel has given up and forgotten to tell you.

Most teams arrive at gRPC after their logsSubscribe pipeline starts dropping messages. The migration is mechanical once you know the field map.

The biggest win is usually parsing. With logsSubscribe you received an array of program log lines and decoded the bincode payload by hand. With gRPC the SubscribeUpdateTransaction carries the full transaction including the structured instruction list, the inner instructions, the loaded addresses, and the meta including pre/post balances and the log array if you still want the strings. You can decode against a program's IDL using the discriminator from the instruction data field directly, no log string parsing required.

The other practical win is filter precision. The mentions filter on logsSubscribe matches transactions that touched the program at all, including via inner instruction. The gRPC accountInclude plus accountRequired combo lets you scope to txs where the program is in the required-signers set, which cuts noise on Jupiter routes and other composed transactions where eight programs touch the same signature.

One last note. If you previously parsed program logs to extract custom event data emitted via msg!, those log strings are still in tx.meta.logMessages on the gRPC update. You don't lose that channel. You just finally get the structured fields next to it.