# Kaldera gRPC > Yellowstone gRPC streams for accounts, transactions, slots, blocks and entries. Source: https://docs.constant-k.com/kaldera/ Kaldera is constant-k's Yellowstone (Geyser) gRPC service. Any Yellowstone client works against it without code changes, given a Kaldera endpoint and your API key as `x-token`. ## Endpoints | Region | Endpoint | | :-------- | :---------------------------------------------------- | | New York | `https://kaldera-newyork.constant-k.com` (port 443) | | Frankfurt | `https://kaldera-frankfurt.constant-k.com` (port 443) | Connections use TLS. See [Authentication](https://docs.constant-k.com/get-started/authentication/). ## Server version and protocol files Kaldera runs yellowstone-grpc `v16.1.1+solana.4.3.0`, the upstream release with no local changes. A client generated from the protocol files of that release matches the server field for field. `GetVersion` reports the running release, its protocol version and the Agave version behind it. | Protocol file | Source | | :--------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `geyser.proto` | [rpcpool/yellowstone-grpc at v16.1.1+solana.4.3.0](https://github.com/rpcpool/yellowstone-grpc/blob/v16.1.1%2Bsolana.4.3.0/yellowstone-grpc-proto/proto/geyser.proto) | | `solana-storage.proto` | [rpcpool/yellowstone-grpc at v16.1.1+solana.4.3.0](https://github.com/rpcpool/yellowstone-grpc/blob/v16.1.1%2Bsolana.4.3.0/yellowstone-grpc-proto/proto/solana-storage.proto) | Client packages from that release: `yellowstone-grpc-client` 15.0.0 and `yellowstone-grpc-proto` 14.0.1 on `tonic` 0.14, or `@triton-one/yellowstone-grpc` 9.0.0 for TypeScript. ### Methods The `geyser.Geyser` service defines ten RPCs. The table records what each returns on Kaldera, measured against a live endpoint. | RPC | On Kaldera | | :-------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------- | | `Subscribe` | Served on Blade Runner and Nexus, on every Kaldera endpoint | | `SubscribeDeshred` | Served on Blade Runner and Nexus, on every Kaldera endpoint, the [Turbo Kaldera](https://docs.constant-k.com/kaldera/turbo-kaldera/) ones included | | `SubscribeReplayInfo` | Served. Returns `first_available`, the oldest slot that region can replay. See [Replay](https://docs.constant-k.com/kaldera/replay/). | | `Ping` | Served. Confirms the token and the route without opening a stream. | | `GetVersion` | Served. Returns the running release, protocol version and Agave version. | | `SubscribeGossip` | `UNIMPLEMENTED` (12) | | `GetSlot`, `GetBlockHeight`, `GetLatestBlockhash`, `IsBlockhashValid` | `UNIMPLEMENTED` (12), with the detail `use RPC`. These chain queries belong on the [Solana RPC](https://docs.constant-k.com/rpc/) endpoint. | ## What Kaldera adds to Yellowstone | Feature | Behaviour | | :----------------- | :--------------------------------------------------------------------------------------------------------------------------------------- | | Shred acceleration | Updates can reach your stream ahead of a stream fed by completed blocks alone. | | Isolated streams | Each subscription is served on its own. A slow consumer elsewhere cannot stall yours, and your bandwidth allowance is yours alone. | | Replay | A reconnect that carries `fromSlot` resumes where the stream stopped, within a window of up to 24 hours. See [Replay](https://docs.constant-k.com/kaldera/replay/). | | Pre-execution path | [Turbo Kaldera](https://docs.constant-k.com/kaldera/turbo-kaldera/) serves the same `Subscribe` call with decoded pre-execution transactions. | ## Streams and limits Kaldera accepts every Yellowstone filter type: accounts, transactions, transaction status, slots, blocks, block meta and entries. Each subscription picks one commitment level: `PROCESSED`, `CONFIRMED` or `FINALIZED`. An account set can also be sent as a [compressed filter](https://docs.constant-k.com/kaldera/filters/#compressed-account-filters) rather than a list, which is how a set larger than the list limits is tracked. See [Filters](https://docs.constant-k.com/kaldera/filters/) for every option, the per-stream filter limits and the gRPC status returned when a subscription is refused. Kaldera is included on Blade Runner and Nexus. Limits apply per region. | | Blade Runner | Nexus | | :----------------------------- | :----------: | :--------: | | Concurrent `Subscribe` streams | 75 | 200 | | `Subscribe` bandwidth | 37.5 MB/s | 150 MB/s | | Compression | gzip, zstd | gzip, zstd | A stream that goes over its plan's bandwidth limit is throttled. Kaldera buffers up to 64 MB of your data while you catch up. If the buffer fills, Kaldera drops the oldest queued updates and keeps you on the newest data. The full tables are on [Plans & Limits](https://docs.constant-k.com/get-started/plans-and-limits/). ## Compression Compression lowers bandwidth, which matters most on streams carrying many accounts and on streams close to the Blade Runner limit. **TypeScript** ```ts import Client from "@triton-one/yellowstone-grpc"; const client = new Client( "https://kaldera-newyork.constant-k.com", process.env.CK_API_KEY, { grpcDefaultCompressionAlgorithm: 1, // 0 = gzip, 1 = zstd grpcMaxDecodingMessageSize: 64 * 1024 * 1024, // room for large account updates }, ); await client.connect(); ``` **Rust** ```rust use yellowstone_grpc_proto::tonic::codec::CompressionEncoding; let client = GeyserGrpcClient::build_from_shared("https://kaldera-newyork.constant-k.com")? .x_token(Some(std::env::var("CK_API_KEY")?))? .tls_config(ClientTlsConfig::new().with_native_roots())? .accept_compressed(CompressionEncoding::Zstd) .connect() .await?; ``` ## Clients | Language | Package | Version Kaldera runs | | :--------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------- | | TypeScript | [`@triton-one/yellowstone-grpc`](https://www.npmjs.com/package/@triton-one/yellowstone-grpc) | 9.0.0 | | Rust | [`yellowstone-grpc-client`](https://crates.io/crates/yellowstone-grpc-client) with [`yellowstone-grpc-proto`](https://crates.io/crates/yellowstone-grpc-proto) | 15.0.0 with 14.0.1 | | Other | A client generated from the [protocol files](#server-version-and-protocol-files) | — | ### Minimum versions for transaction v1 Mainnet carries version 1 transactions as well as legacy and version 0. Nothing about Kaldera changes for them: the same endpoints, the same `x-token` key, the same `SubscribeRequest` and the same filters. The client changes: a proto that does not know the new fields cannot read a version 1 transaction that arrives on a stream you already hold. | Crate | Minimum for version 1 | Version Kaldera runs | | :------------------------ | :-------------------- | :------------------- | | `yellowstone-grpc-client` | 13.3.0 | 15.0.0 | | `yellowstone-grpc-proto` | 12.6.0 | 14.0.1 | > **The two crates are versioned separately and must move together:** Pinning `yellowstone-grpc-client` and letting `yellowstone-grpc-proto` resolve on its own produces a build with a proto that cannot parse a version 1 transaction. Both belong in your `Cargo.toml`. In other languages, the newest client release carries the fields. A self-generated client needs protocol files at `yellowstone-grpc-proto` 12.6.0 or later; the files above are 14.0.1. See [Transaction v1](https://docs.constant-k.com/rpc/transaction-v1/). ## Kaldera, Turbo Kaldera, ShredPrism or WebSockets | | Kaldera | Turbo Kaldera | ShredPrism | WebSockets | | :------------------------------------- | :------------------------------------- | :------------------------------------------------ | :--------------------------------------------------------- | :-------------------------------- | | Data | Executed accounts, transactions, slots | Decoded pre-execution transactions | Serialized entries, from the block the leader is producing | Accounts, logs, signatures, slots | | Execution results (fees, logs, status) | Yes | No | No | Yes | | Filtering | Rich, server-side | Account filters on transactions | None: the full feed | Per subscription | | Protocol | Yellowstone gRPC | Yellowstone gRPC | gRPC | Solana PubSub | | Plans | Blade Runner, Nexus | Nexus, or Blade Runner through `SubscribeDeshred` | Nexus | Operator and up | [Data Stages](https://docs.constant-k.com/get-started/data-stages/) sets out the pipeline these four sit on, and the stage each one delivers at. The [Benchmarks](https://www.constant-k.com/benchmarks/) page compares Kaldera with another Yellowstone provider in each region and publishes the results live. ## Related - [Quickstart](https://docs.constant-k.com/kaldera/quickstart/) - [Filters](https://docs.constant-k.com/kaldera/filters/) - [Replay](https://docs.constant-k.com/kaldera/replay/) - [Turbo Kaldera](https://docs.constant-k.com/kaldera/turbo-kaldera/)