How a Transaction Flows

A Solana transaction travels from your client through the network to a block-producing leader, executes atomically on-chain, and earns votes until it reaches your chosen commitment level. Understanding this path explains latency, failures, and retry strategy.

Recipe

Quick-reference recipe card - copy-paste ready.

Client build → Sign → sendTransaction → Leader receives (Gulf Stream)
→ PoH ordering → Sealevel execution → Block propagation (Turbine)
→ Validator votes (TowerBFT) → RPC confirmation polling

import { createSolanaRpc, createSolanaRpcSubscriptions } from "@solana/kit";
 
const rpc = createSolanaRpc("https://api.devnet.solana.com");
const rpcSubs = createSolanaRpcSubscriptions("wss://api.devnet.solana.com");
 
// After sendTransaction returns a signature:
const sub = await rpcSubs.signatureNotifications(signature, { commitment: "confirmed" });

When to reach for this:

• Debugging why a transaction was dropped vs rejected
• Choosing the right commitment level for your UX
• Understanding retry timing relative to blockhash expiry
• Explaining sub-second "processed" vs ~12s "finalized" to users
• Designing idempotent transaction resubmission

Working Example

import {
  createSolanaRpc,
  createSolanaRpcSubscriptions,
  createKeyPairSignerFromBytes,
  createTransactionMessage,
  setTransactionMessageFeePayer,
  setTransactionMessageLifetimeUsingBlockhash,
  appendTransactionMessageInstruction,
  signTransactionMessageWithSigners,
  getSignatureFromTransaction,
  pipe,
} from "@solana/kit";
import { getTransferSolInstruction } from "@solana-program/system";
import { readFileSync } from "node:fs";
 
const rpc = createSolanaRpc("https://api.devnet.solana.com");
const rpcSubs = createSolanaRpcSubscriptions("wss://api.devnet.solana.com");
 
const secret = Uint8Array.from(
  JSON.parse(readFileSync(process.env.HOME + "/.config/solana/id.json", "utf8")),
);
const signer = await createKeyPairSignerFromBytes(secret);
 
// 1. Fetch recent blockhash (transaction lifetime)
const { value: blockhash } = await rpc.getLatestBlockhash().send();
 
// 2. Build and sign
const message = pipe(
  createTransactionMessage({ version: 0 }),
  (m) => setTransactionMessageFeePayer(signer.address, m),
  (m) => setTransactionMessageLifetimeUsingBlockhash(blockhash, m),
  (m) =>
    appendTransactionMessageInstruction(
      getTransferSolInstruction({
        source: signer.address,
        destination: signer.address, // self-transfer demo
        amount: 1n,
      }),
      m,
    ),
);
 
const signed = await signTransactionMessageWithSigners(message, [signer]);
const signature = getSignatureFromTransaction(signed);
 
// 3. Submit
await rpc.sendTransaction(signed, { encoding: "base64" }).send();
console.log("Submitted:", signature);
 
// 4. Wait for confirmed commitment
const notifications = await rpcSubs.signatureNotifications(signature, {
  commitment: "confirmed",
});
for await (const note of notifications) {
  if (note.value.err) {
    console.error("Failed on-chain:", note.value.err);
  } else {
    console.log("Confirmed at slot:", note.context.slot);
  }
  break;
}

What this demonstrates:

• Blockhash binds the transaction to a recent ledger state (~60-90 seconds validity)
• sendTransaction broadcasts to the RPC, which forwards via Gulf Stream
• WebSocket signatureNotifications is more efficient than polling getSignatureStatuses
• confirmed means supermajority voted on the block; finalized is stronger

Deep Dive

How It Works

1. Build - client assembles instructions, accounts, and recent blockhash
2. Sign - required signers produce Ed25519 signatures
3. Submit - RPC node receives and forwards to the current/upcoming leader
4. Schedule - leader orders transactions using Proof of History ticks
5. Execute - Sealevel runs instructions in parallel where account locks permit
6. Commit - transaction changes are written to the accounts database
7. Vote - validators vote on the block; TowerBFT accumulates lockouts
8. Confirm - RPC reports status at the requested commitment level

Commitment Levels

Failure Modes

• Dropped - never landed in a block (leader skip, low priority fee, expired blockhash)
• Rejected - landed but program returned an error (insufficient funds, constraint violation)
• Simulation failure - RPC preflight caught the error before submission

Gotchas

• Treating processed as final - forks can reorder at this level. Fix: wait for confirmed or finalized before irreversible UX.
• Not refreshing blockhash on retry - expired transactions are silently dropped. Fix: fetch new blockhash and re-sign on each retry.
• Ignoring preflight errors - skipPreflight: true hides simulation failures. Fix: simulate first in development; decode errors before retrying.
• Polling in a tight loop - hammers RPC and still misses fast confirmations. Fix: use WebSocket signature subscriptions.
• Same signature resubmission - valid and idempotent, but useless if blockhash expired. Fix: only resubmit the same signature within the blockhash window.
• Leader skip during congestion - transactions queue longer. Fix: add priority fees via Compute Budget Program.

383k393a3c3q3e393a3o1r3e3k3x383c3e3k1v201x3x1v1t1v1z1t20

Alternatives

FAQs

Related

• Solana Basics - trace end-to-end example
• Slots, Blocks & Epochs - timing context
• Keypairs & Addresses - signing step

Stack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, and LiteSVM 0.6.x.