Solana (SOL): How Transactions and Validators Work

State lives in accounts

Every piece of persistent Solana state is held in an account identified by a 32-byte address. An account records lamports, data, an owner program and execution-related fields. The owner is the program allowed to change that account data; it is not necessarily the human who controls a wallet key.

Solana programs are executable accounts containing sBPF bytecode. A program is generally treated as stateless because mutable application state lives in separate accounts supplied to each instruction. This lets the runtime see which accounts a transaction will read or write before execution and schedule work that does not contend for the same writable state.

Wallets, token accounts and PDAs

A wallet address can own SOL and authorize transactions, but an SPL token balance normally sits in a token account associated with a mint and owner. A Program Derived Address is deterministically derived from a program ID and seeds; the program can authorize for it through runtime rules even though no private key exists for the address.

Before sending a token, confirm the mint, destination token account and program being invoked. A familiar ticker or wallet label is not proof that a mint is canonical. Closing, creating or reallocating accounts may also move lamports, so the transaction summary should be reviewed beyond the headline token amount.

Message, signatures and instructions

The message lists account addresses, a recent blockhash and compiled instructions. Each instruction names a program and identifies the accounts it can use. Required signers authorize the message, and versioned transactions can use address lookup tables to reference more accounts without placing every address directly in the packet.

Freshness and confirmation

A recent blockhash prevents an ordinary transaction from remaining valid indefinitely. If it expires before processing, the transaction must be rebuilt and signed again; rebroadcasting the old signature does not create a fresh transaction. Durable nonce workflows exist for specialized offline or delayed signing and require separate handling.

RPC clients expose processed, confirmed and finalized commitment levels. A fast interface may show processed results before stronger cluster agreement is reached. Deposits, bridges and dependent application actions should wait for the level required by that service and should verify the signature through a current RPC or explorer.

Base and priority components

Every transaction pays a base fee in SOL for required signatures. The protocol expresses SOL in lamports, and the base amount therefore depends on signature count rather than the value of a payment or token swap. A failed transaction can consume the base fee because signature verification and execution were attempted.

An optional prioritization fee is based on the requested compute-unit limit and chosen compute-unit price. The limit is a budget, not a prediction of actual use, so setting it much higher than necessary can overpay the priority component. Wallet estimates should use recent conditions and transaction simulation instead of copying a fixed fee from another application.

Operational checks

Keep enough SOL for the fee even when the transferred asset is an SPL token. Review any compute-budget instructions, because they can change the requested limit and priority price. Also distinguish transaction fees from account funding, rent-related balances, swap price impact and application charges; they are separate costs even if one wallet summarizes them together.