Carbium RPC

Carbium gRPC

Connect to Carbium's documented Solana streaming endpoints with the right client path, auth format, and production checks for Yellowstone-style 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 real-time streaming docs. Carbium serves Yellowstone-shaped stream data over WebSocket: the grpc hostname identifies the stream surface, while the client transport is WebSocket.

  • WebSocket streaming for clients that use the published transactionSubscribe JSON-RPC path

Part of the Carbium Solana infrastructure stack.

Direct answer

Carbium's current public Docs publish one customer streaming path:

Path Endpoint Auth Best fit
Yellowstone-shaped streaming over WebSocket wss://grpc.carbium.io/?apiKey=YOUR_RPC_KEY apiKey query parameter Applications using the published transactionSubscribe stream pattern

Use the same RPC dashboard key for the published stream path. Confirm current streaming access before designing a production workload around it.

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.

Client shape Use this path Why
Client that can use WebSocket JSON-RPC wss://grpc.carbium.io/?apiKey=... Carbium's documented streaming transport
Node.js / TypeScript app following Carbium's published subscription example wss://grpc.carbium.io/?apiKey=... Matches the public WebSocket JSON-RPC example
Python or browser-adjacent service wss://grpc.carbium.io/?apiKey=... Uses the published stream path
Standard @solana/web3.js reads and writes https://rpc-service.carbium.io/?apiKey=... This is regular JSON-RPC, not the streaming path

The important split:

  • rpc-service.carbium.io is the normal JSON-RPC surface
  • wss://grpc.carbium.io/?apiKey=... is the published real-time streaming surface
  • the grpc hostname identifies Yellowstone-shaped stream data; use the published WebSocket transport
  • the RPC dashboard key is reused across both

Use the documented WebSocket stream path intentionally. Do not configure a native HTTP/2 gRPC client against the grpc hostname as a production path.

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.

Transport note

Carbium's current public streaming transport is WebSocket. It delivers Yellowstone-shaped stream data through the published transactionSubscribe path at wss://grpc.carbium.io/?apiKey=YOUR_RPC_KEY.

Do not configure a native HTTP/2 gRPC client against https://grpc.carbium.io from this documentation. Use the published WebSocket stream example above and validate subscription, reconnect, and error behavior for your application before production.

Production checks before you commit to streaming

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

1. Validate streaming access first

If streaming is mandatory for your workload, confirm current 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

Mistake What usually happens Fix
Using @solana/web3.js against grpc.carbium.io as if it were standard RPC Client setup is wrong before the first request Keep normal reads and writes on rpc-service.carbium.io
Configuring a native HTTP/2 gRPC client from this page Unsupported transport path Use the published WebSocket stream path with transactionSubscribe
Forgetting that streaming uses the RPC dashboard key Auth failures even though the key exists Reuse the RPC key, not the Swap API key
Choosing streaming before proving polling is the bottleneck More moving parts without a real payoff Start with JSON-RPC and add streaming when the workload demands it

What this page does not own

This page explains Carbium's published real-time streaming path and when to use it. It does not own:

🔶 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.