Skip to main content
After building a swap transaction via POST /api/v1/swap, sign it, submit it to the network, and wait for confirmation.

​
Full flow

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

const connection = new Connection("https://rpc.fogo.network");

const txBuffer = Buffer.from(swapData.transaction, "base64");
const transaction = VersionedTransaction.deserialize(txBuffer);

transaction.sign([wallet]);

const signature = await connection.sendRawTransaction(transaction.serialize(), {
  skipPreflight: false,
  maxRetries: 3,
});

const confirmation = await connection.confirmTransaction({
  signature,
  blockhash: transaction.message.recentBlockhash,
  lastValidBlockHeight: swapData.lastValidBlockHeight,
});

if (confirmation.value.err) {
  throw new Error(`Transaction failed: ${JSON.stringify(confirmation.value.err)}`);
}

console.log(`Confirmed: ${signature}`);

​
Transaction expiry

Every transaction includes a lastValidBlockHeight. If the transaction is not confirmed by that block height, it expires and can never be included. This is typically around 60 seconds from when the transaction was built. If a transaction expires:
  1. Get a fresh quote (prices may have changed).
  2. Build a new transaction.
  3. Sign and submit again.
Do not resubmit an expired transaction. It will never confirm. Always rebuild from a fresh quote.

​
Retry strategy

ScenarioAction
sendRawTransaction throws network errorRetry the same signed transaction (it’s idempotent)
Transaction lands but fails on-chainGet a new quote and rebuild. Pool state has changed.
Transaction doesn’t confirm within 30sCheck getSignatureStatuses. It may still land.
lastValidBlockHeight passedTransaction expired. Rebuild from scratch.

​
Preflight checks

By default, skipPreflight: false runs a simulation on the RPC node before broadcasting. This catches obvious failures early (wrong signer, insufficient balance, etc.). Set skipPreflight: true only if:
  • You already validated via the /api/v1/swap simulation.
  • You need the lowest possible submission latency.

​
Confirmation levels

LevelMeaningUse case
processedTransaction seen by the RPC nodeFastest, but can be rolled back
confirmedVoted on by supermajority of validatorsSafe for most use cases
finalizedRooted in the chain, irreversibleRequired for high-value operations
The default confirmTransaction waits for confirmed level, which is appropriate for most swap integrations.