Solana Geyser Plugins, Explained

What Geyser actually is

Geyser is a plugin interface compiled into the Solana validator. Where standard RPC reads state back out of the node on request, Geyser does the opposite: it lets data flow out of the validator process the moment it changes. As the validator processes accounts, transactions, slots, and blocks, it calls into any loaded Geyser plugin and hands it those events directly.

A plugin loads as a dynamic library named in the validator's config. From that vantage point - inside the validator, at the source - it sees state as the node itself sees it, before anything is read back over an RPC connection. What the plugin does with that firehose is up to it: write to a database, push to a message queue, or expose it as a stream.

RPC makes the validator answer questions. Geyser lets the validator narrate what's happening, from the inside, as it happens.

Push, not pull

This is the heart of why Geyser matters. Standard JSON-RPC is a pull model - your client asks, the node computes an answer and returns it. WebSocket subscriptions soften that, but under the hood you're still asking the node to watch specific things and notify you, and that mechanism doesn't fan out gracefully to thousands of accounts.

Geyser is a push model. Nothing loops, nothing asks "anything new?" The validator emits each event as it's processed and the plugin receives it. We went deep on why the pull model falls behind for time-sensitive work in Why RPC Polling Can't Keep Up - Geyser is the architecture that removes the poll interval entirely.

What it streams

A Geyser plugin sees four kinds of update, and a good implementation lets you filter each one server-side so you only receive the slice you care about:

• Accounts - every account write, filterable by owner program, account key, or data size.
• Transactions - filterable by account inclusion, plus vote and failed flags.
• Slots - slot status transitions as the validator moves through commitment levels.
• Blocks - full block metadata as blocks are assembled.

Because the filtering happens at the source rather than on your client, you're not shipping a firehose across the network and discarding 99% of it. The work happens next to the data.

Yellowstone: the gRPC implementation

Geyser is the interface. You still need an implementation to turn those raw events into something a remote client can consume. Yellowstone gRPC is the widely-used one: it takes the events Geyser emits and exposes them as a long-lived gRPC stream with the server-side filters described above.

From the client's side it's a single subscription. You describe what you care about once, then read updates as they arrive:

// one stream, server-side filters, processed commitment
const req = {
  accounts: {
    amm: { owner: [RAYDIUM_AMM] },
  },
  transactions: {
    swaps: { accountInclude: [RAYDIUM_AMM] },
  },
  commitment: "processed",
};
 
const stream = await client.subscribe(req);
for await (const update of stream) {
  strategy.onUpdate(update); // pushed, not polled
}

One connection multiplexes accounts, transactions, slots, and blocks, with proper backpressure under load. We compare it directly to the request/response model in Yellowstone gRPC vs Standard RPC.

Running it yourself vs using a provider

Here's the catch: a Geyser plugin only runs inside a validator. To consume one yourself, you run your own validator - synced, tuned, and ideally co-located near the cluster - then load the plugin and maintain it. That's a real infrastructure commitment, not a config flag.

For most teams the answer is a hosted Yellowstone endpoint. You get the same push stream without operating a validator, and a provider that racks its nodes beside the stake clusters usually delivers data earlier on the wire than a self-run node a region away would.

One notch faster: decoded shreds

Geyser is as early as you can read from inside a validator, but there's a layer further upstream. Geyser surfaces data at the validator's processed commitment - after the node has taken the event in. The earliest possible view is one step before that, at the propagation layer, where blocks travel as shreds before any node assembles them.

Decoding transactions directly from decoded shreds gives you a first-seen, pre-confirmation view - upstream of even Geyser.

The takeaway

Geyser is the interface that turns the validator from something you query into something that streams. Yellowstone is the gRPC implementation most teams actually consume, and unless you're running your own validator you'll reach it through a provider. Layer it the right way - shreds for first-seen, Geyser for live state, RPC for confirmed truth - and put it all next to the cluster, where the milliseconds are cheapest to win.