Carbium for Wallet Developers

Wallet apps usually need three things:

• reliable RPC reads for balances and account state
• a safe swap flow that returns a transaction for the user to sign
• a way to handle users who do not already hold enough SOL for fees

Carbium's published docs cover those building blocks today:

• RPC for standard Solana JSON-RPC reads and writes
• Swap API for quote and swap flows
• Gasless Swaps for no-SOL onboarding flows
• gRPC for real-time backend listeners when polling is no longer enough

Part of the Carbium Solana infrastructure stack.

What to use for each wallet job

For most wallet teams, the practical starting point is RPC + Swap API. Add gRPC later if you need lower-latency backend listeners for deposits, strategy triggers, or transaction-heavy automation.

Recommended architecture

The safest production pattern is:

1. Keep both Carbium keys on your backend.
2. Let the client request quotes and unsigned transactions through your backend.
3. Have the wallet sign the returned transaction client-side.
4. Send the signed transaction through your backend over Carbium RPC.

This matches Carbium's published security guidance: keep keys server-side, not in browser bundles or mobile client code.

Minimal wallet flow

1. Backend: request an executable quote

Carbium's swap execution guides document a quote flow where adding user_account returns a txn field that is ready for signing.

const url = new URL("https://api.carbium.io/api/v2/quote");
url.searchParams.set("src_mint", "So11111111111111111111111111111111111111112");
url.searchParams.set("dst_mint", "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v");
url.searchParams.set("amount_in", "100000000");
url.searchParams.set("slippage_bps", "50");
url.searchParams.set("user_account", walletAddress);

const response = await fetch(url, {
  headers: {
    "X-API-KEY": process.env.CARBIUM_API_KEY!,
    "Accept": "application/json",
  },
});

if (!response.ok) {
  throw new Error(`Quote failed: ${response.status}`);
}

const quote = await response.json();

if (!quote.txn) {
  throw new Error("Quote missing transaction payload");
}

Use this on the server, not in the wallet client. That keeps the API key private and gives you one place to enforce rate limits, abuse checks, and analytics.

2. Client: sign the transaction

Once your backend returns quote.txn, the wallet can deserialize and sign it locally.

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

const txn = VersionedTransaction.deserialize(
  Buffer.from(quote.txn, "base64")
);

const signed = await wallet.signTransaction(txn);
const signedBase64 = Buffer.from(signed.serialize()).toString("base64");

At this point the user's wallet has approved the transaction, but your Carbium keys are still not exposed to the client.

3. Backend: submit through Carbium RPC

Send the signed transaction through Carbium RPC using the documented endpoint pattern:

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

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

const signedTx = VersionedTransaction.deserialize(
  Buffer.from(signedBase64, "base64")
);

const signature = await connection.sendTransaction(signedTx, {
  skipPreflight: false,
  maxRetries: 3,
});

const finalStatus = await connection.confirmTransaction(signature, "confirmed");

console.log(signature, finalStatus);

This split keeps the UX wallet-native while still routing RPC traffic through your controlled backend environment.

When to use Gasless Swaps

Gasless support matters most when your wallet serves:

• first-time users who received tokens but no SOL
• embedded wallet experiences with low-friction onboarding
• swap-first UX where asking users to fund gas upfront hurts conversion

Carbium's public Gasless Swaps docs describe the high-level behavior clearly:

• Carbium advances the SOL network fee from an internal pool
• the swap still settles on-chain normally
• the fee pool is rebalanced from the output side of the trade

Carbium's swap reference also documents a gasless flag on the swap surface. Treat Gasless Swaps as an explicit product decision in your wallet flow, not a default assumption for every route.

When to add gRPC

Basic wallet apps can launch on standard RPC alone. Add gRPC when you need backend services that react to chain activity faster or with less polling overhead.

Good examples:

• deposit or transfer listeners
• transaction-centric alerts
• high-volume wallet monitoring
• backend services that already need Business-tier throughput

If your wallet is mostly balance views, swap flows, and normal send/confirm behavior, start with RPC and add streaming later.

Launch checklist for wallet teams

Before shipping, verify:

• Swap API and RPC keys live only in backend env vars or a secret manager
• your RPC endpoint is restricted where practical
• wallet clients only receive quote data and unsigned transaction payloads
• signed transactions are submitted by a trusted backend service
• your expected request volume fits the Carbium plan's RPS and monthly limits
• Gasless Swaps are only enabled where the UX really needs them