Carbium gRPC

If you are evaluating Carbium for real-time Solana data, the main question is not "does Carbium have streaming?" It does. The practical question is which Carbium streaming path matches your client and workload.

This page owns the canonical setup path for Carbium's public gRPC docs:

• native Yellowstone-style gRPC over HTTP/2 for clients that speak gRPC directly
• WebSocket JSON-RPC streaming for clients that are not using a native Yellowstone gRPC client

Part of the Carbium Solana infrastructure stack.

Direct answer

Carbium's current public docs publish grpc.carbium.io in two access patterns:

Both paths use the same RPC dashboard key. Carbium's published pricing docs also place gRPC at the Business tier and above.

If you only need standard wallet reads, balance checks, or occasional submission status, stay on JSON-RPC. If your app reacts to transaction flow continuously, validates on-chain activity in near real time, or is burning requests through constant polling, this is the page you need.

When gRPC is the right tool

Use Carbium's streaming path when one or more of these are true:

• you need transaction or slot updates as they happen instead of polling every few seconds
• you run trading, indexing, monitoring, or alerting systems that stay hot all day
• your current JSON-RPC traffic is dominated by repeated "is there something new yet?" reads
• several services need the same feed and you want one upstream listener instead of many polling workers

Stay on standard JSON-RPC when:

• your app mostly performs direct reads like balances, account fetches, or send-and-confirm flows
• freshness measured in seconds is acceptable
• your team has not yet validated that streaming changes the architecture enough to justify the extra moving parts

📘

gRPC is not the default answer for every Solana app. It is the better answer when polling waste, event timing, or shared listener architecture has become a real problem.

Choose the right Carbium streaming path

The biggest source of setup confusion is mixing transport style with client type.

The important split:

• rpc.carbium.io is the normal JSON-RPC surface
• grpc.carbium.io is the published real-time streaming surface
• the RPC dashboard key is reused across both

If your client supports both a native gRPC mode and a fallback WebSocket mode, choose one intentionally. Do not wire both into production until you know which transport owns the workload.

Minimal setup: WebSocket stream path

Use this when you are following Carbium's published JS / TS stream pattern.

import WebSocket from "ws";

const ws = new WebSocket(
  `wss://grpc.carbium.io/?apiKey=${process.env.CARBIUM_RPC_KEY}`
);

ws.on("open", () => {
  ws.send(
    JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "transactionSubscribe",
      params: [
        {
          vote: false,
          failed: false,
          accountInclude: ["6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P"],
          accountExclude: [],
          accountRequired: [],
        },
        {
          commitment: "confirmed",
          encoding: "base64",
          transactionDetails: "full",
          showRewards: false,
          maxSupportedTransactionVersion: 0,
        },
      ],
    })
  );
});

ws.on("message", (data) => {
  const msg = JSON.parse(data.toString());
  console.log(msg);
});

This is the safer entry point when your team wants a working stream quickly without standing up a native Yellowstone client first.

Minimal setup: Yellowstone over HTTP/2

Use this when you are running a native Yellowstone-compatible client instead of the WebSocket bridge.

import { Client } from "@rpcpool/yellowstone-grpc";

const ENDPOINT = "https://grpc.carbium.io";
const API_KEY = process.env.CARBIUM_RPC_KEY!;

async function main() {
  const client = new Client(ENDPOINT, API_KEY, {});
  const stream = await client.subscribe();

  stream.on("data", (data) => {
    console.log("stream update", data);
  });

  await client.subscribeUpdate({
    slots: { slots: {} },
  });
}

main().catch(console.error);

Carbium's live partner-access page and local docs both publish the HTTP/2 endpoint as https://grpc.carbium.io with the RPC key passed as the client token.

Production checks before you commit to streaming

Treat gRPC as an architecture decision, not just another endpoint to paste into a client.

1. Validate plan access first

Carbium's published pricing puts gRPC at the Business tier and above. If streaming is mandatory for your workload, confirm plan access before you design the system around it.

2. Budget reconnect behavior

A real-time client is only as good as its reconnect policy. Before production, test:

• what happens when the stream drops
• how your worker resubscribes
• whether duplicate listeners can start accidentally after reconnect

3. Keep one upstream listener when possible

If multiple workers need the same feed, prefer one stream consumer that fans out internally. That is usually cleaner than letting every worker open its own hot stream.

4. Keep auth and routing simple

Use the RPC key only on the RPC and gRPC surfaces. Do not mix it with the separate Swap API key used on api.carbium.io.

Common mistakes

What this page does not own

This page explains Carbium's published gRPC access paths and when to use them. It does not own:

• workload-specific examples and routing by persona: use GRPC Use Cases
• plan comparison and upgrade choice: use RPC Pricing and Usage Tiers
• full auth mapping across RPC, gRPC, and Swap API: use Carbium Auth Matrix

🔶

Need a streaming-capable Solana stack? Start with the published Carbium RPC tiers, validate the gRPC path your client actually uses, and then build out from carbium.io.