# Yellowstone Proto and Versioning

> Pin Yellowstone client versions and keep generated code aligned with the server schema.

Canonical: https://nolimitnodes.com/docs/api-reference/grpc/proto-versioning

Yellowstone request and response fields follow the upstream `geyser.proto`.

## Source

Use the proto from the official [yellowstone-grpc repository](https://github.com/rpcpool/yellowstone-grpc/tree/master/yellowstone-grpc-proto/proto).

Keep these files together:

- `geyser.proto`
- `solana-storage.proto`
- Required Google protobuf files

## Pin a release

Do not pull the repository default branch during a production build.

1. Pick an upstream release.
2. Pin the SDK to the matching release.
3. Store the proto commit in your dependency manifest.
4. Regenerate clients in a controlled upgrade.
5. Run subscription fixtures before deployment.

## Reflection

The NoLimitNodes Yellowstone endpoint does not provide dependable server reflection.

Pass a local proto to `grpcurl`:

```bash
grpcurl \
  -H "x-api-key: YOUR_API_KEY" \
  -import-path ./proto \
  -proto geyser.proto \
  -d '{"count":7}' \
  grpc.nln.clr3.org:443 \
  geyser.Geyser/Ping
```

## Upgrade checklist

- Compare new filter fields.
- Compare oneof update variants.
- Check enum additions.
- Regenerate every language client.
- Compile every sample.
- Replay saved protobuf fixtures.
- Run one live slot subscription.

Unknown fields are safe in protobuf decoders. Renamed application fields still break source code. Treat generated client changes as code changes.