# yellowstone-grpc: a Geyser-backed gRPC interface for streaming Solana data

> yellowstone-grpc is Triton One's gRPC interface for Solana, built around the Geyser plugin interface so a validator can push slots, blocks, transactions, deshred pre-execution transactions and account updates to subscribers. It ships a plugin, a Rust client, a Node.js client, and examples in four languages, and it is AGPL-3.0 licensed.

**rpcpool/yellowstone-grpc** — Triton's Dragon's Mouth Yellowstone gRPC service for high-performance Solana streaming

- Repository: https://github.com/rpcpool/yellowstone-grpc
- Website: https://triton.one
- Stars: 1,016 · Forks: 375
- Language: Rust
- License: AGPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/rpcpool-yellowstone-grpc

## What it is: a Geyser plugin with a gRPC face

The repository contains a fully functional gRPC interface for Solana, built and maintained by Triton One, and it is built around Solana's Geyser interface. The README states it plainly, that this repo has the plugin and sample clients for multiple languages. The practical architecture follows from Geyser. A Solana validator can load plugins that receive the chain data as it happens, and this project provides such a plugin, the yellowstone-grpc-geyser component, which then republishes that data over gRPC so that ordinary clients in any language can subscribe. The data it provides is slots, blocks, transactions, deshred pre-execution transactions, and account update notifications, over a standardised path. The primary language is Rust, the licence is AGPL-3.0, the homepage is triton.one, and the last push to the repository was on 2026-10-14.

## Running it: a validator flag and a config check

The validator section is a single command, solana-validator with the geyser-plugin-config flag pointing at the plugin's config.json, and the config lives in the yellowstone-grpc-geyser directory. There is a separate config check command, cargo-fmt followed by cargo run with the config-check binary and the config path, which is the step to run before you restart a validator, since a malformed plugin config takes the validator down with it. The documentation for the service itself is hosted separately at the Triton One docs for the RPC pool gRPC subscriptions. The release tags follow a pattern worth noting for anyone pinning a version, with v16.1.1+solana.4.3.0 released on 2026-10-09, so the build identifies both its own version and the Solana release it targets.

```bash
solana-validator --geyser-plugin-config yellowstone-grpc-geyser/config.json
```

```bash
cargo-fmt && cargo run --bin config-check -- --config yellowstone-grpc-geyser/config.json
```

## Listener configuration, and three address formats

The recommended way to configure gRPC listeners is grpc.listen, an array where each item can define an address which is required, an optional per-listener TLS config and an optional per-listener authentication mode. The address accepts a TCP socket as a string such as 0.0.0.0:10000, a Unix domain socket as a string such as unix:///var/run/geyser.sock, or a Unix domain socket object with an explicit permissions mode, where the mode is given in decimal and the example value of 432 is 0o660. The permissions option is the one that matters in practice, because a gRPC socket that is world readable on a shared host is a socket anyone can subscribe to. The README also notes that TLS is ignored for Unix domain sockets, which follows from the filesystem permissions doing the work instead, and that ALPN is configured for HTTP/2 automatically.

```json
{
   "address": {
      "path": "unix:///var/run/geyser.sock",
      "mode": 432
   }
}
```

## TLS: two certificate forms, and hot swapping without dropping connections

TLS can be configured in two ways, an identity pair with cert_path and key_path, or a certificate directory with cert_dir containing PEM files. Both forms accept an optional watch_file flag which defaults to false, and when it is true the server watches the relevant paths on disk and hot-swaps the served certificate in place, without dropping existing connections or requiring a restart. The two cases differ in what is watched. For the identity pair, the server watches cert_path and key_path individually and rebuilds the identity when either changes. For the certificate directory, it watches the directory recursively and rebuilds the SNI resolver when any file under it changes. That is a genuinely useful operational property, because certificate rotation on a service that a validator depends on does not normally mean a restart, and for a streaming service a restart is a gap in the data.

```json
{
   "tls": {
      "cert_dir": "/etc/yellowstone/certs",
      "watch_file": true
   }
}
```

## Three authentication modes, and what each one trusts

Auth is configured per listener with a type, and the three options trust different things. The http type validates requests using an external HTTP resolver, expecting the host and token query parameters, with a successful payload including a subscription_id and rate limits. The contract is a GET to the resolver URL with the host extracted from the incoming gRPC request URI and the token from the incoming x-token header, where 200 OK means a valid pair and 404 Not Found means an invalid one, and the README stresses that the 404 behaviour matters because the gRPC server treats it as an unauthenticated request for that host and token pair. The file type validates against a local JSON mapping file containing an array of objects with token, host and subscription_info. The trusted-metadata type trusts the incoming x-subscription-id header and skips external auth checks entirely, which is the one to use only when something upstream has already authenticated the caller.

```json
{
   "auth": {
      "type": "file",
      "subscription_resolver_path": "/etc/yellowstone/subscriptions.json"
   }
}
```

## Billing monitoring, and the rate limit that is not implemented

Billing monitoring is configured under listen[].auth.billing and is optional, with a report_interval that defaults to 5s if omitted, and billing events sent as NDJSON. There is one line in the README that deserves more attention than its position in the document deserves, a note that method rate-limit is not yet implemented. That matters because the configuration schema accepts per-method rate limits, and the example resolver response shows a rate_limits map with an entry for every gRPC method, from /geyser.Geyser/Subscribe and SubscribeReplayInfo down to Ping, GetLatestBlockhash, GetBlockHeight, GetSlot, IsBlockhashValid and GetVersion, each with a value like 2000. So the limits are declared in the subscription info the resolver returns, and the server is expected to enforce them, but the enforcement is documented as not yet implemented. A team building a metered service on this would be relying on something the documentation says is not there.

```json
{
   "auth": {
      "type": "http",
      "subscription_resolver_url": "http://127.0.0.1:8080/",
      "billing": {
         "type": "http",
         "billing_endpoint_url": "http://127.0.0.1:8081/billing",
         "report_interval": "5s"
      }
   }
}
```

## The known bug in block reconstruction, and the workspace layout

The Known bugs section is short and specific. Block reconstruction inside the gRPC plugin is based on information provided by BlockMeta, and unfortunately the number of entries for blocks generated on validators is always equal to zero, so those blocks will always have zero entries, with a pointer to the issue in the Solana repository. That is a data correctness limitation rather than a crash, and for a subscriber counting transactions per block it is a silent gap. The repository layout shows the same decomposition. There is yellowstone-grpc-geyser for the plugin, yellowstone-grpc-proto for the protocol definitions, yellowstone-grpc-client for the Rust client, yellowstone-grpc-client-nodejs for the Node client built on napi, yellowstone-grpc-tools, and the yellowstone-grpc-e2e-test and yellowstone-grpc-e2e-macros crates for end to end testing. There are also examples/ directories for golang, python, rust and typescript, each with its own licence file, and a Cargo workspace tying them together with edition 2021.

## The dependency list, and what it says about the implementation

The workspace dependencies read like a description of the service's internals. prost and prost-types with protoc-bin-vendored handle the protobuf encoding, tonic and hyper with hyper-util and http provide the gRPC and HTTP stack, and rustls rather than OpenSSL supplies the TLS, which is why the TLS configuration is a Rust-level concern rather than a system one. tokio and futures carry the async work, and crossbeam-channel, dashmap, moka and arc-swap are the concurrency and caching primitives. The client also uses instrument-like helpers such as local-ip-address and num_cpus, and the metrics side uses prometheus, which tells you the service exposes its own telemetry. reqwest, tracing-adjacent logging via env_logger and log, and clap for the command line round out the list. There is also a LICENSING.md and a deny.toml for cargo-deny, so the dependency licences are audited rather than assumed.

## Conclusion

yellowstone-grpc suits a team building a Solana indexer, backtester or trading tool that needs the full stream of chain data over a single subscription API rather than polling a public RPC. It is the wrong choice if you only need occasional account reads, since the whole point is a high throughput subscription, and a poor fit if your validator does not expose the Geyser plugin interface, because that is the mechanism everything is built on. Before deploying it, read the known bugs section, because block reconstruction inside the plugin has a known defect with zero entries for validator-generated blocks, and note that method rate limiting is documented as not yet implemented even though the configuration accepts per-method limits.

## FAQ

### What is yellowstone-grpc?

It is a fully functional gRPC interface for Solana, built and maintained by Triton One around Solana's Geyser interface. It provides slots, blocks, transactions, deshred pre-execution transactions and account update notifications over a standardised path, and the repository includes the plugin plus sample clients for multiple languages. The licence is AGPL-3.0.

### How do I run the yellowstone-grpc plugin on a validator?

Start the validator with the geyser-plugin-config flag pointing at the plugin's config.json in the yellowstone-grpc-geyser directory. You can check the config before restarting with cargo-fmt and cargo run with the config-check binary and the config path, so a malformed config does not take the validator down.

### What authentication modes does yellowstone-grpc support?

Three, configured per listener with a type. The http type validates requests with an external HTTP resolver that receives host and token query parameters, the file type validates against a local JSON mapping file of token, host and subscription_info entries, and the trusted-metadata type trusts the incoming x-subscription-id header and skips external checks.

### Can yellowstone-grpc rotate TLS certificates without a restart?

Yes, if you set the optional watch_file flag, which defaults to false. With it enabled the server watches the relevant paths on disk and hot-swaps the served certificate in place without dropping existing connections, watching cert_path and key_path individually for an identity pair and the cert_dir recursively for a certificate directory.

### What known bug does yellowstone-grpc have?

Block reconstruction inside the gRPC plugin is based on information provided by BlockMeta, and the number of entries for blocks generated on validators is always zero, so those blocks always have zero entries. The README links the corresponding issue in the Solana repository.

## Sources

- [License: AGPL-3.0](https://github.com/rpcpool/yellowstone-grpc/blob/master/LICENSE)
- [Project website](https://triton.one)
- [README](https://github.com/rpcpool/yellowstone-grpc/blob/master/README.md)
- [Releases](https://github.com/rpcpool/yellowstone-grpc/releases)
- [rpcpool/yellowstone-grpc on GitHub](https://github.com/rpcpool/yellowstone-grpc)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rpcpool-yellowstone-grpc