Developing With Carbium
Start building on Carbium with practical integration guides for wallets, swaps, RPC-backed flows, and production-safe application patterns.
This section is for builders who already know what they want to ship and need the shortest path from idea to working integration.
Use it when you are building with Carbium's live surfaces today:
- RPC for reads, writes, and transaction submission
- Swap API for quotes and executable swap flows
- Gasless flows for no-SOL onboarding paths
- gRPC where transaction-heavy backends need real-time data
Choose your starting point
| If you are building... | Start here | Then go to |
|---|---|---|
| A wallet app | carbium-for-wallets |
executing-swaps |
| A trading bot or execution backend | carbium-for-trading-bots |
solana-grpc |
| A backend-safe swap flow from quote to confirmation | quote-to-swap-integration-guide |
sending-unsigned-transactions-carbium-rpc |
| A transaction that fails simulation or preflight | debug-solana-transaction-simulation |
rpc-errors-reference |
| A transaction flow that hit blockhash expiry | blockhash-expiry-recovery-playbook |
transaction-lifecycle |
| A production app adding backup RPC paths | safe-rpc-failover-checklist |
status-and-metrics-1 |
| A backend that needs scoped program-account reads | getprogramaccounts-without-melting-your-app |
solana-grpc |
| A swap backend deciding between normal send and bundle handoff | jito-bundles-solana-swap-backends |
txn-bundle-copy |
| A swap flow with backend signing boundaries | executing-swaps |
sending-unsigned-transactions-carbium-rpc |
| A backend service that needs RPC reads first | rpc-check-wallet-balance |
your-first-rpc-test-call |
| A mixed-surface app that needs the right key and auth pattern first | carbium-auth-matrix |
api-key-security-best-practices |
| A no-SOL onboarding path | gasless-token-swap |
gasless-swaps |
| A routing or arbitrage workflow | solana-arbitrage-quote-engine |
cq1-routing-engine |
What belongs in this section
Pages in this track should answer implementation questions, not just describe products:
- how to wire Carbium into a real app flow
- which Carbium surface fits a specific job
- where keys, signing, and submission boundaries should live
- what to validate before production traffic
If a page is mainly about product pricing, auth, or service comparison, it should usually stay in the product category instead of being nested here.
Recommended path for most teams
Most teams should start in this order:
- confirm the product surface they actually need
- map the right key and auth format for each surface
- build the smallest working flow
- move secrets and transaction submission to the backend
- add streaming, retries, or gasless behavior only where the app needs it
That keeps the docs flow practical instead of throwing every builder into the full product map at once.
🔶 Building on Solana with Carbium? Start with the guides in this section, then move to product-specific docs only when you need deeper surface detail.