Yellowstone gRPC

The protocol lives in yellowstone-grpc on rpcpool/GitHub. The wire format is protobuf. There are first-party clients in Rust, TypeScript, Go, and Python. A client opens a single bidirectional stream and sends one SubscribeRequest with rules like "every transaction touching the Pump.fun program," "every account write owned by the SPL Token program with a specific mint," or "every finalized slot."

The plugin runs inside an Agave validator. The validator pushes Geyser callbacks into the plugin, the plugin filters and serializes, and the gRPC layer fans out matching messages to subscribed clients. Because the work happens in process on the validator, latency from "validator saw the transaction" to "client received the parsed bytes" is single- digit milliseconds inside the same datacenter.

The protocol supports commitment levels of processed, confirmed, and finalized on every subscription. You pick the tradeoff per stream: a sniper takes processed and accepts the rare rollback, a settlement indexer takes finalized and waits.

One opinion: do not roll your own gRPC plugin unless you have a hard requirement Yellowstone cannot meet. The maintainers are responsive, the protocol is stable, and the network effects on the client side are real. The right place to add value is in a typed decoder layer that sits above Yellowstone, not in replacing the transport itself.

Yellowstone gRPC is what every serious Solana streaming product runs on, including ours. The most common subscription patterns are filtering by program ID (for example 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P for Pump.fun) or by account owner. You will see it referenced in client SDKs as geyser.proto oryellowstone-grpc-proto.

We run Yellowstone gRPC on every streaming node we operate. Our gRPC nodes expose the Yellowstone protocol directly. Our Enhanced Streams sit on top and decode the bytes against program IDLs so you don't have to.