Proto and Versioning

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

Source

Use the proto from the official yellowstone-grpc repository.

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 cubestech 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}' \
  geyser.sol.cubestech.online:443: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.