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 surface | Carbium surface | Migration confidence |
|---|---|---|
| Shared Solana JSON-RPC endpoint | https://rpc.carbium.io/?apiKey=YOUR_RPC_KEY | High |
Standard request/response methods like getBalance, getSlot, sendTransaction | Same Solana JSON-RPC methods | High |
| Helius RPC URL stored in env vars | Carbium RPC URL or RPC key stored in env vars | High |
| Helius transaction-oriented real-time feed | wss://grpc.carbium.io/?apiKey=YOUR_RPC_KEY with transactionSubscribe | Medium |
What does not map 1:1
Do not treat these as drop-in replacements unless you validate them in your own integration:
| Helius product | Current Carbium docs status | What to do |
|---|---|---|
| Wallet API | No direct wallet-data REST equivalent is publicly documented | Keep Helius for wallet enrichment or rebuild on raw RPC plus your own indexing |
| DAS / Enhanced APIs | No direct Carbium DAS-style API is published in current docs | Replace case by case instead of assuming parity |
Standard WebSocket subscriptions such as accountSubscribe or logsSubscribe | Not published in Carbium's live public docs at time of writing | Validate separately before moving account or log subscriptions |
| LaserStream / Helius-specific streaming products | Different product surface | Re-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:
| Provider | Published pattern |
|---|---|
| Helius | Dashboard-issued RPC URL |
| Carbium | https://rpc.carbium.io/?apiKey=YOUR_RPC_KEY |
| Carbium header auth | X-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_KEYfor WebSocket clientshttps://grpc.carbium.iowithx-token: YOUR_RPC_KEYfor 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:
- Create a Carbium RPC key in the Carbium dashboard.
- Replace the Helius URL with
https://rpc.carbium.io/?apiKey=YOUR_RPC_KEY. - Keep the same Solana SDK client code.
- Re-run a small smoke test like
getVersion,getSlot, and one read from your most common method. - 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:
- Move plain JSON-RPC traffic to Carbium first.
- Move transaction-streaming workloads only if
transactionSubscribecovers your use case. - Keep Helius for Wallet API or DAS-dependent features until you have a tested replacement architecture.
- 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_KEYexists 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.iobefore 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.
Updated about 17 hours ago
