Before a Solana transaction runs, it declares the accounts it will read or change, the programs it will call and a recent blockhash. A validator can then schedule transactions that do not compete for the same writable state in parallel. That execution model—not a headline transactions-per-second figure—is the foundation of Solana’s performance.
Solana is a public proof-of-stake blockchain launched on mainnet beta in 2020. SOL pays fees, supports staking and is used by applications across trading, payments, tokens, games and other onchain markets.
The account model
Solana stores state in accounts identified by addresses. An account can hold lamports—the smallest unit of SOL—and data, and it has an owner program. Programs are executable accounts containing code; they are largely stateless, with mutable data kept in separate accounts supplied to an instruction.
An instruction tells one program what operation to perform and which accounts it may use. A transaction groups one or more instructions and executes atomically: either the transaction’s changes are committed together or they are not. The Solana core concepts connect accounts, programs, instructions, transactions, program-derived addresses and cross-program invocations.
This differs from an account-based virtual machine where contracts commonly keep state inside their own storage. Developers and users must understand both the program being called and the authorities attached to relevant accounts.
Where Proof of History fits
Proof of History (PoH) is a cryptographic sequence used as a clock and ordering mechanism. It is not, by itself, the network’s consensus algorithm. Solana combines PoH with proof-of-stake voting and leader scheduling so validators can agree on blocks and the state of the ledger.
For users, a visible consequence is the recent blockhash inside a transaction. It helps validators reject stale or replayed transactions, but it also means an unsigned or poorly broadcast transaction can expire. Wallets and applications need current blockhashes, healthy RPC connections and appropriate confirmation logic.
Fees, compute units and priority
Every transaction pays a base fee per signature. A sender can also add a prioritisation fee, calculated from a compute-unit price and requested compute-unit limit for current legacy and v0 transactions. The fee documentation notes that the fee is charged even if execution fails.
Low typical fees make small onchain actions practical, but “cheap” is not the same as free or guaranteed. Congestion, compute settings, account contention and priority choices affect whether and when a transaction lands. A swap also includes price impact and slippage, which are trading costs rather than network fees.
Programs can be upgradeable
Solana’s program documentation distinguishes code from the data accounts it operates on. A deployed program can retain an upgrade authority. If that authority remains active, whoever controls it may replace the program; revoking the authority makes that deployment immutable.
This is a critical due-diligence question. A protocol may call itself decentralised while a small group can upgrade its code, pause an interface, control an oracle or alter a token authority. Base-layer validation confirms that authorised instructions followed network rules; it does not prove that the authorised rules are safe.
SOL, staking and validators
Validators process transactions, vote on the chain and can receive stake delegated by SOL holders. Delegation supports the consensus system without giving a validator custody of the delegated SOL, but rewards are variable and validators differ in commission and performance.
Economic stake is only part of operational resilience. Hardware and bandwidth requirements, stake concentration, client diversity, RPC infrastructure and the leader schedule affect how the network behaves under load or software faults.
Confirmation is a spectrum
A transaction signature is not the same as final settlement. Solana clients use commitment levels such as processed, confirmed and finalized, reflecting different confidence levels. Applications must decide which level fits the action and handle expired blockhashes, dropped forks and delayed RPC nodes.
The official confirmation guide recommends consistent commitment settings and monitoring the last valid block height instead of assuming that one submission guarantees inclusion. Users see the result as a pending or failed transaction; developers need to manage the full lifecycle.
Network history belongs in the risk analysis
Solana has experienced periods when consensus stopped and validators coordinated restarts. An official report on the February 2024 incident attributes an outage of roughly five hours to a software failure and documents the restart. Historical incidents do not establish current uptime, but they show why client software, testing and restart procedures matter.
Application risk sits above that base layer: contract bugs, upgrade authorities, compromised front ends, malicious tokens, oracles and bridges can cause losses even while the network is producing blocks normally. Our DeFi guide maps several of those dependencies.
Reading a Solana transaction critically
Before signing, identify the program, writable accounts, token mint, amount, delegate or authority changes, compute budget and minimum output. After submission, check the signature at the commitment level appropriate to the action.
Solana’s architecture trades a demanding validator and application environment for parallel execution and low-latency settlement. Its value is best judged transaction by transaction: which program runs, who can upgrade it, which state can change and what failure the user can tolerate.
Editorial note: this guide was fully reviewed and rewritten on September 3, 2026.
