Migrating to Carbium

Treat migration as two separate jobs:

1. move the provider-neutral path first: standard Solana JSON-RPC
2. move provider-specific products second: streaming, trading APIs, wallet/data APIs, and managed pipelines

That split is what keeps migration fast without turning it into a platform rewrite.

Part of the Carbium Solana infrastructure stack.

What every migration has in common

For standard RPC traffic, the core Carbium path is the same regardless of your current provider:

Use environment variables from day one:

CARBIUM_RPC_KEY=your_rpc_key_here
CARBIUM_API_KEY=your_api_key_here

Start with the provider you are moving off

Helius

Read Migrate from Helius to Carbium if your stack relies on:

• standard Helius RPC
• Helius Wallet API, DAS, or enhanced data APIs
• Helius streaming paths that need a staged cutover

That guide is the right place to separate plain RPC migration from Helius-specific higher-level APIs.

QuickNode

Read Migrate from QuickNode to Carbium if your stack relies on:

• QuickNode HTTP and WSS endpoints
• Yellowstone Geyser gRPC
• Streams
• Metis or other QuickNode add-ons

QuickNode's Solana docs split those surfaces clearly, and the safest migration does the same.

Triton / Triton One

If you mainly use Triton as a standard Solana RPC provider, the first step is still a normal JSON-RPC endpoint swap. If you depend on Triton-specific streaming or operational tooling, treat that as a second-stage migration rather than assuming it maps directly.

Jupiter / public swap APIs

Read Migrate from Jupiter to Carbium if your current integration is centered on:

• Jupiter quote and swap APIs
• wallet or backend flows that pass quoteResponse into a separate transaction-build step
• advanced Jupiter execution options that need case-by-case validation before cutover

That guide covers the request-shape changes and the main architectural difference: Carbium's current execution docs return txn from the quote step when user_account is provided.

Safe cutover sequence

Use this order for production systems:

1. Inventory what you use today: standard RPC, WebSockets, gRPC, add-ons, webhooks, data APIs.
2. Move plain JSON-RPC reads first.
3. Move writes and transaction submission paths next.
4. Validate streaming clients against grpc.carbium.io only if your documented use case matches.
5. Migrate trading APIs, wallet/data APIs, or managed pipelines as their own workstreams.

This keeps rollback simple. If a provider-specific feature needs more work, you can still finish the core RPC migration without blocking on every add-on.

Quick smoke test after endpoint replacement

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": []
  }'

Then repeat with one method your production system depends on most.

Before you call the migration complete

Make sure:

• keys are stored server-side
• RPC endpoints are restricted by trusted domain or IP where practical
• rate-limit behavior has been checked on the Carbium plan you intend to use
• no provider-specific feature was moved just because it looked similar on the surface

📘The fastest successful migrations are narrow first. Move standard RPC, prove stability, then migrate streaming and product-specific layers with separate owners.

🔶Ready to switch your Solana stack to Carbium? Start with the documented setup flow at carbium.io.