Migrate from Helius to Carbium

Move standard Solana RPC traffic from Helius to Carbium, map auth and streaming endpoints, and identify which Helius-specific APIs need a separate migration plan.

Migrate from Helius to Carbium

If you use Helius for standard Solana RPC, the first migration step is simple: replace your endpoint, update the auth format, and re-run your existing health checks.

The important caveat is that not every Helius product maps 1:1. Helius documents separate product surfaces for RPC, data streaming, Wallet API, DAS and Enhanced APIs, webhooks, and LaserStream. Carbium's public docs today are strongest on JSON-RPC, transaction streaming over grpc.carbium.io, and Swap API / CQ1.

This page shows what can move cleanly now, what needs extra validation, and how to cut over without breaking production traffic.

Part of the Carbium Solana infrastructure stack.

What migrates cleanly today

For most backend services, bots, and standard Solana app traffic, this is the safe path:

Helius surfaceCarbium surfaceMigration confidence
Shared Solana JSON-RPC endpointhttps://rpc.carbium.io/?apiKey=YOUR_RPC_KEYHigh
Standard request/response methods like getBalance, getSlot, sendTransactionSame Solana JSON-RPC methodsHigh
Helius RPC URL stored in env varsCarbium RPC URL or RPC key stored in env varsHigh
Helius transaction-oriented real-time feedwss://grpc.carbium.io/?apiKey=YOUR_RPC_KEY with transactionSubscribeMedium

What does not map 1:1

Do not treat these as drop-in replacements unless you validate them in your own integration:

Helius productCurrent Carbium docs statusWhat to do
Wallet APINo direct wallet-data REST equivalent is publicly documentedKeep Helius for wallet enrichment or rebuild on raw RPC plus your own indexing
DAS / Enhanced APIsNo direct Carbium DAS-style API is published in current docsReplace case by case instead of assuming parity
Standard WebSocket subscriptions such as accountSubscribe or logsSubscribeNot published in Carbium's live public docs at time of writingValidate separately before moving account or log subscriptions
LaserStream / Helius-specific streaming productsDifferent product surfaceRe-test streaming behavior rather than porting config blindly

The fastest way to get into trouble is to migrate a Helius app as if every higher-level API were just "RPC with a different hostname". It is not.

Endpoint and auth mapping

JSON-RPC

Helius tells users to copy their RPC URL from the dashboard and use it directly with existing Solana SDK clients. Carbium publishes one shared JSON-RPC endpoint with query-param or header auth:

ProviderPublished pattern
HeliusDashboard-issued RPC URL
Carbiumhttps://rpc.carbium.io/?apiKey=YOUR_RPC_KEY
Carbium header authX-API-KEY: YOUR_RPC_KEY

Streaming

Helius documents multiple real-time paths:

  • standard WebSockets at wss://mainnet.helius-rpc.com?api-key=YOUR_API_KEY
  • enhanced WebSockets at wss://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY
  • LaserStream as a separate product tier

Carbium's public streaming docs currently publish:

  • wss://grpc.carbium.io/?apiKey=YOUR_RPC_KEY for WebSocket clients
  • https://grpc.carbium.io with x-token: YOUR_RPC_KEY for Rust / HTTP-2 style clients

Carbium also documents that gRPC access starts at the Business tier.

Minimal cutover for standard RPC traffic

If your Helius usage is mostly normal Solana RPC calls, cut over in this order:

  1. Create a Carbium RPC key in the Carbium dashboard.
  2. Replace the Helius URL with https://rpc.carbium.io/?apiKey=YOUR_RPC_KEY.
  3. Keep the same Solana SDK client code.
  4. Re-run a small smoke test like getVersion, getSlot, and one read from your most common method.
  5. Watch for auth errors, throttling, and any workload that depended on Helius-only enhanced APIs.

TypeScript before and after

import { Connection } from "@solana/web3.js";

// Before: Helius
const helius = new Connection(process.env.HELIUS_RPC_URL!, "confirmed");

// After: Carbium
const carbium = new Connection(
  `https://rpc.carbium.io/?apiKey=${process.env.CARBIUM_RPC_KEY}`,
  "confirmed"
);

async function smokeTest() {
  const [version, slot] = await Promise.all([
    carbium.getVersion(),
    carbium.getSlot(),
  ]);

  console.log(version["solana-core"]);
  console.log(slot);
}

cURL smoke test

curl -X POST "https://rpc.carbium.io/?apiKey=$CARBIUM_RPC_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getVersion",
    "params": []
  }'

Migrating transaction streaming

If your Helius app uses transaction-level streaming, Carbium publishes a compatible transactionSubscribe path over grpc.carbium.io.

WebSocket example

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,
        },
      ],
    })
  );
});

Use this path when your current Helius integration is transaction-centric. Do not assume every other Helius WebSocket subscription pattern is documented on Carbium yet.

How to handle Helius-only APIs

If your current Helius stack depends on wallet enrichment, transaction parsing, or NFT/data APIs, the cleanest migration is usually hybrid first, full replacement later.

Recommended approach:

  1. Move plain JSON-RPC traffic to Carbium first.
  2. Move transaction-streaming workloads only if transactionSubscribe covers your use case.
  3. Keep Helius for Wallet API or DAS-dependent features until you have a tested replacement architecture.
  4. Revisit Carbium Data or CQ1 pages only where the published docs actually match your requirements.

This keeps the migration reversible and avoids rewriting your wallet or analytics layer in the same deploy window as your core RPC cutover.

Migration checklist

Use this before flipping production traffic:

  • CARBIUM_RPC_KEY exists in your secret store
  • Helius endpoint URLs are replaced only in the services you intend to move
  • Smoke tests pass for getVersion, getSlot, and one high-volume production method
  • Retry and rate-limit behavior has been checked against Carbium plan limits
  • Any Helius Wallet API, DAS, Enhanced API, or webhook dependency has a separate owner and migration plan
  • Streaming clients are validated against grpc.carbium.io before traffic is cut over

When Carbium is a good fit

Carbium is the right next step if your Helius usage is centered on:

  • standard Solana RPC reads and writes
  • transaction streaming
  • trading, routing, or execution systems that already use low-level Solana primitives

It is not a true same-day drop-in for teams whose application depends heavily on Helius's high-level wallet enrichment and enhanced data APIs.

📘If your app still needs Helius Wallet API or DAS responses, migrate the RPC path first and keep the higher-level data layer separate until your replacement architecture is tested.
🔶Ready to move your core Solana traffic off Helius? Start with Carbium RPC setup and plan selection at carbium.io.