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.protosolana-storage.proto- Required Google protobuf files
Pin a release
Do not pull the repository default branch during a production build.
- Pick an upstream release.
- Pin the SDK to the matching release.
- Store the proto commit in your dependency manifest.
- Regenerate clients in a controlled upgrade.
- 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/PingUpgrade 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.