Transaction Building Best Practices

Every Solana transaction has an implicit compute unit (CU) budget. Unless you call ComputeBudgetProgram.setComputeUnitLimit, the budget defaults to 200,000 CU per instruction (up to a hard cap of 1,400,000 CU for the whole transaction). Swaps, multi-hop DEX routes, and complex DeFi interactions routinely need explicit CU limits — relying on defaults means your transaction fails on-chain even though it was delivered successfully.

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

// 1. Simulate first to measure real usage
const sim = await connection.simulateTransaction(transaction);
const actualCU = sim.value.unitsConsumed ?? 200_000;

// 2. Set limit to 1.2x measured
transaction.add(
  ComputeBudgetProgram.setComputeUnitLimit({
    units: Math.ceil(actualCU * 1.2),
  })
);

These are two separate things — you can use both, neither, or either. Understanding the difference matters for optimizing cost.

Solana transactions have a hard 1232-byte size limit. Complex transactions (multi-hop swaps, bundled operations) hit this limit quickly because every account referenced consumes 32 bytes. Address Lookup Tables let you reference accounts by a 1-byte index instead — a single ALT can shrink a 1200-byte transaction to 400 bytes.

Use an ALT when your transaction references more than ~20 accounts, or when you see "Transaction too large" errors.

import {
  PublicKey,
  TransactionMessage,
  VersionedTransaction,
  AddressLookupTableAccount,
} from "@solana/web3.js";

// Fetch your ALT(s) — each can hold up to 256 addresses
const alt = await connection
  .getAddressLookupTable(new PublicKey("YOUR_ALT_ADDRESS"))
  .then(r => r.value!);

// Build a v0 message that references the ALT
const message = new TransactionMessage({
  payerKey: payer.publicKey,
  recentBlockhash: (await connection.getLatestBlockhash()).blockhash,
  instructions: [ /* your instructions */ ],
}).compileToV0Message([alt]);

const tx = new VersionedTransaction(message);
tx.sign([payer]);

// tx.serialize() now produces a much smaller payload

A common frustration: simulateTransaction returns success, but when you submit, the transaction fails on-chain. This almost always comes down to state changes between simulation and execution.

• •Pool prices moved — your slippage check now fails.
• •Another transaction consumed the liquidity you were targeting.
• •A signer's balance changed (e.g., a parallel transaction drained their SOL below the rent-exempt threshold).
• •Your blockhash expired between simulation and landing.

Transaction Size Debugging

If your transaction is rejected as too large, check in this order:

1. Count the unique accounts referenced. Each one is 32 bytes.
2. Count your signatures. Each one is 64 bytes plus a 1-byte index.
3. Sum instruction data sizes — some programs serialize large payloads (complex swap routes often do).
4. If the sum exceeds 1232 bytes, move the heaviest account list into an ALT and resubmit as a v0 transaction.

Blockhash Expiration

Regular transactions reference a recent blockhash and must land within 150 slots (~60 seconds at 400ms per slot). When preflight is enabled, an expired blockhash is surfaced as a BlockhashNotFound RPC error; with skip_preflight=true, the transaction is quietly dropped on-chain. This is especially common when:

• •You sign far in advance (e.g., signing on a mobile device, then submitting from a backend).
• •Your delivery path has high latency — the transaction arrives on-chain too late.
• •You retry a failed transaction without refreshing the blockhash.