How a Solana transaction travels
From signed instruction to confirmed block — a step-by-step map without wallet tutorials.
When newcomers ask how Solana “processes a payment,” they often picture a single server accepting a file. On Solana, a transaction is a bundle of instructions signed by one or more accounts, submitted to the network, scheduled by leaders, executed in parallel where possible, and recorded when a supermajority of stake agrees on the result.
Signing and structure
Your wallet constructs a message listing program invocations — for example, moving lamports between accounts or interacting with a token program. The private key proves authorisation; the public key identifies the fee payer. Unlike some networks, Solana separates accounts (data containers) from programs (executable logic).
Submission paths
Transactions reach validators through RPC nodes — public or private. The RPC performs basic checks, then forwards to the current block producer. Congestion during popular mints or liquidations can delay inclusion; fees prioritize ordering within the leader’s queue, not a global auction in the same form as legacy gas markets.
Execution and confirmation
Leaders produce blocks on a tight schedule. Validators replay execution to verify state transitions match. Confirmation depth depends on how many subsequent blocks build on your slot; wallets often display “confirmed” after a threshold suited to their risk model.
What readers should verify
- Account balances and rent exemption status before sending
- Program IDs against official documentation
- Fee payer has sufficient lamports for base fee plus priority fee if set
Further reading
See our Reading Room beginner path and the official Solana documentation on transactions and accounts.