Developers
Solana execution
How Solana swaps differ from EVM: no approvals, a base64 VersionedTransaction to sign, and server-side broadcast.
Solana swaps follow the same quote → build → sign → record shape as EVM, with three differences: there is no separate token approval, the build returns a base64 VersionedTransaction, and you broadcast through the API rather than a browser RPC.
1. Quote & build
Call POST /swap/quote with chainKey: "solana" and SPL mint addresses for tokenIn/tokenOut (use the native SOL mint for SOL). Then POST /swap/build with the chosen route. Jupiter builds an unsigned VersionedTransaction, returned as base64 in solanaTransaction.
2. Sign
Deserialize, sign with the user's wallet (Phantom, Solflare) or a local keypair, and re-serialize:
import { VersionedTransaction } from "@solana/web3.js";
const tx = VersionedTransaction.deserialize(Buffer.from(solanaTransaction, "base64"));
tx.sign([keypair]); // or wallet.signTransaction(tx)
const signed = Buffer.from(tx.serialize()).toString("base64");3. Submit
POST /api/swap/submit-solana
{ "signedTransaction": "<base64>" }
→ { "signature": "<txid>", "confirmed": true }Server-side broadcast (via Helius RPC) avoids the 403 errors public Solana endpoints return to browsers and gives more reliable confirmation. On failure the API returns a SOLANA_SUBMIT_FAILED (or more specific) code with HTTP 503.
Tips
- Keep a small SOL balance for priority fees, especially during congested mints.
- Solana transactions reference a recent blockhash that expires — sign and submit promptly, or re-build.
- Record the swap with
POST /swap/record(chainKey: "solana") for attribution.