How Solana works

05 September 2026

Solana is a blockchain designed for high throughput and low latency. It processes thousands of transactions per second at sub-cent fees. To do this, it makes architectural choices that differ from most other blockchains. Understanding those choices - and their trade-offs - is essential if you interact with the network beyond sending a single token transfer.

This page maps the entire system: the mechanisms that make it fast, the tools you use to interact with it, the costs you pay, the errors you hit, the risks you need to manage, and the misconceptions that keep spreading. Each section points to a deeper spoke page that covers that topic completely.

Core architecture: clock, consensus, and execution

Solana’s claim to fame is that it can order transactions without waiting for validators to agree on time. That is the job of Proof of History (PoH) - a cryptographic clock that timestamps events before they enter consensus. PoH is not a consensus mechanism. It is a sequencing device that lets validators know the order of transactions without having to gossip about it first.

Consensus itself is handled by Tower BFT, a variant of Practical Byzantine Fault Tolerance optimized to use PoH as a global clock. Validators vote on blocks they believe are canonical, and those votes are weighted by stake. Because PoH already provides ordering, Tower BFT avoids the fork-resolution overhead of other BFT implementations. The result is fast finality: most transactions reach optimistic confirmation in under a second, with full finality after a few hundred milliseconds.

For a deeper walkthrough of how validators vote and what "optimistic confirmation" actually means, see How Solana consensus works: Tower BFT and optimistic confirmation.

Transaction execution on Solana is not serial. Sealevel is the parallel smart contract runtime. It processes transactions in parallel by analyzing which accounts each transaction reads and writes. Transactions that touch different accounts run simultaneously. Transactions that touch the same account are serialized. This is not "everything runs at once" - write contention still serializes - but for most workloads, the parallelism is dramatic.

For a full explanation of how Sealevel detects non-overlapping state and schedules execution, see How Sealevel enables parallel transaction execution on Solana.

Solana also uses Pipelining, assigning different stages of transaction processing to different hardware cores. The validator node handles data fetch, signature verification, banking (execution), and ledger writing on separate threads. This is a standard CPU pipeline design applied to blockchain validation.

Transaction lifecycle: submission, fees, and forwarding

Submitting a transaction on Solana is not like submitting one on Ethereum. There is no global mempool. Instead, Gulf Stream forwards transactions to the expected leader ahead of time. Each validator knows, from the leader schedule, which validator will produce the next block. Clients and RPC nodes send transactions directly to that leader before its slot arrives. This eliminates the need for a mempool and reduces confirmation latency.

The leader schedule is derived from stake weight and a Verifiable Random Function (VRF). It is recalculated every epoch - a fixed period of approximately 432,000 slots, roughly two days. Within an epoch, the order of leaders is deterministic. Scheduled leader transitions happen at fixed slot boundaries, so there are no forks in the consensus path.

For a detailed breakdown of how Gulf Stream forwards transactions and what happens when the leader changes, see How Gulf Stream forwards Solana transactions without a mempool.

Transaction fees on Solana have three components. The base fee is a fixed 5000 lamports per signature. The prioritization fee is an optional per-compute-unit tip that raises your transaction's chance of being included. Compute units (CU) meter how much work a transaction can do - the default limit is 1.4 million CU per transaction. If your transaction consumes more CU than the limit, it fails with "Computational budget exceeded." If it uses fewer, you get the unused CU back.

The fee model also includes local fee markets. When many transactions compete for the same account - say, a popular NFT mint - the prioritization fee for that account rises independently of the rest of the network. This prevents a single hot account from pricing out all other traffic.

For a complete guide to setting fees, estimating compute units, and avoiding overpayment, see Solana transaction fees: base fee, priority fee, and compute units explained.

Transaction references rely on blockhash expiry. Each transaction includes a recent blockhash, valid for approximately 150 slots. After that, the blockhash is expired and the transaction is rejected with "Blockhash not found." If you need a transaction that outlives that window, durable nonces provide an alternative: a nonce account whose value stays valid until explicitly advanced.

For how to implement durable nonces and retry logic, see Solana durable nonces for transactions that outlive blockhash expiry.

Account model and data storage

Everything on Solana is an account. Accounts hold lamports (the native unit of SOL), data bytes, and an owner program. The account model is flat: there is no contract storage mapping. Programs own accounts and can modify only accounts they own. This is different from Ethereum's state trie.

Program Derived Addresses (PDAs) are deterministic addresses derived from a program ID and a set of seeds. PDAs have no private key. They are controlled by the program that derived them. This enables programs to manage accounts without needing a secret key.

Associated Token Accounts (ATAs) are a standard PDA pattern: for each token mint and each wallet, there is a deterministic account that holds that token. You do not need to create a new token account for every mint-wallet pair; the ATA is derivable.

For a full explanation of account ownership, PDA derivation, and ATA mechanics, see Solana account model, program derived addresses, and associated token accounts.

Rent is a cost for storing data on-chain. Accounts must maintain a minimum balance - the rent-exempt threshold - or they are charged rent periodically. Most users simply deposit enough lamports to reach rent exemption and never think about rent again. The rent-exempt minimum for a token account is approximately 0.00203928 SOL. If an account's balance falls below that threshold, it can be evicted by a rent collector. "Insufficient funds for rent" is a common error when creating accounts with too little SOL.

Cloudbreak is the accounts database design. It optimizes for sequential reads and concurrent writes, reflecting Solana's parallel execution model.

Archivers handle long-term ledger storage. Full validators do not need to store the entire transaction history. Archivers are nodes that store chunks of the ledger and prove they are storing them correctly. This keeps validator hardware requirements manageable.

Programs, development, and composability

On-chain programs on Solana compile to BPF/SBF bytecode (Berkeley Packet Filter variant), not EVM bytecode. Solana is not Ethereum-compatible. Programs are deployed to executable accounts and are called via instructions.

Native programs are built into the runtime: System Program (creates accounts, transfers SOL), Stake Program (staking), Vote Program (validator voting), BPF Loader (deploys and upgrades programs). You cannot modify native programs.

For custom programs, Anchor is the dominant development framework. It handles serialization, deserialization, account validation, and error handling. Most Solana developers use Anchor rather than raw Rust.

For getting started writing programs, see How to build Solana programs with Anchor framework in Rust.

Cross-Program Invocation (CPI) lets one program call another within a single transaction. The runtime enforces instruction introspection limits: a maximum CPI depth of 4 and strict rules about which accounts can be passed. This prevents reentrancy attacks and keeps execution predictable.

Address Lookup Tables (ALTs) extend the 32-account limit on legacy transactions. A versioned transaction can reference accounts via an ALT, allowing up to 256 accounts per transaction. This is essential for complex DeFi operations and NFT mints that touch many accounts.

For how versioned transactions and ALTs work together, see Solana versioned transactions and address lookup tables explained.

Token-2022 is the next-generation token standard, adding features like transfer fees, confidential transfers, and permanent delegates. It coexists with the original SPL Token standard. The choice between them depends on whether you need those additional features.

For a comparison of the two standards, see Solana Token-2022 vs original SPL Token standard differences.

Staking, validators, and economic security

Staking on Solana means delegating SOL to a validator. The validator earns rewards and passes them to delegators, minus a commission. You can stake natively using the Solana CLI or a wallet like Phantom or Solflare. Or you can use liquid staking, where you deposit SOL into a protocol and receive a token (mSOL, JitoSOL, bSOL) that represents your staked position and can be traded or used in DeFi.

The choice between native staking and liquid staking involves trade-offs in liquidity, risk, and yield. Native staking locks your SOL for an epoch (plus warmup and cooldown periods). Liquid staking tokens can be sold immediately but carry smart contract risk and can depeg under stress.

For a detailed comparison, see How to stake SOL: native staking vs liquid staking explained.

Validators are selected by stake weight. The leader schedule rotates through validators proportional to their stake. Validators who equivocate (sign two conflicting blocks) or go offline for extended periods can be slashed - a penalty that reduces their stake. Slashing is rare on Solana but not theoretical.

Stake centralization is a real concern. A superminority of validators controlling more than one-third of total stake could halt the network or censor transactions. The Nakamoto coefficient - the minimum number of validators needed to reach superminority - is a better measure of decentralization than raw validator count.

For the current state of stake distribution and the risks of superminority collusion, see Solana validator stake centralization and superminority risks explained.

Tools, clients, and infrastructure

Most users interact with Solana through a wallet. Phantom and Solflare are the two dominant non-custodial wallets. Phantom has broader dApp integration and a larger user base. Solflare offers native staking dashboards and Ledger support. Both support token swaps, NFT viewing, and dApp connections.

For a feature-by-feature comparison, see Phantom vs Solflare: which Solana wallet is better.

RPC infrastructure is critical. Public RPC endpoints are rate-limited and unreliable for production use. Commercial providers - Helius, Triton, QuickNode - offer higher rate limits, dedicated nodes, webhooks, and enhanced APIs. Helius specializes in Solana-specific features like webhook-based transaction monitoring. Triton offers bare-metal performance. QuickNode is multi-chain with Solana support.

For choosing the right provider for your use case, see Solana RPC providers compared: Helius vs Triton vs QuickNode vs public.

The Solana CLI is the official command-line tool for everything from account creation to program deployment. Solana Explorer and third-party explorers like Solscan and SolanaFM let you inspect transactions, accounts, tokens, and programs.

For transaction submission, the default client uses QUIC as the transport protocol, replacing the older UDP-based system. QUIC provides better congestion control and connection management. Stake-weighted QoS prioritizes connections from validators and high-stake accounts, meaning your transaction may be throttled if you connect from a low-stake account.

DeFi, NFTs, and the ecosystem

Solana's DeFi ecosystem centers on Jupiter, a DEX aggregator that routes swaps across all major liquidity sources. Jupiter finds the best price by splitting orders across Raydium (AMM), Orca (concentrated liquidity), Meteora (dynamic fees), and other venues. It also handles price-impact analysis and slippage protection.

For how Jupiter discovers routes and executes swaps, see How Jupiter DEX aggregator routes swaps across Solana liquidity.

Lending protocols include Solend (now Save), Marginfi, and Kamino. Solend is the oldest and most liquid. Marginfi focuses on risk-adjusted lending with isolated pools. Kamino automates liquidity provision and lending strategies.

For a comparison of rates, risk models, and user experience, see Solana lending protocols: Solend vs Marginfi vs Kamino compared.

NFT marketplaces are dominated by Magic Eden and Tensor. Magic Eden has the largest user base and supports multiple chains. Tensor offers pro trading features like real-time order books and sweep functionality.

For choosing between them, see Magic Eden vs Tensor: which Solana NFT marketplace is better.

Jito Labs operates a modified validator client that introduces an out-of-protocol block space auction. Users can submit bundles of transactions with tips, and validators include the highest-paying bundles in their blocks. This creates an effective mempool and enables MEV strategies like arbitrage and sandwich attacks. Jito also offers JitoSOL, a liquid staking token that distributes MEV rewards to stakers.

For how Jito's block engine works and how it changes transaction submission, see How Jito MEV and block space auctions work on Solana.

Errors, risks, and misconceptions

Solana's error messages are often cryptic. "Transaction simulation failed" is a generic preflight failure that tells you nothing about the cause. "Blockhash not found" means your transaction expired. "Computational budget exceeded" means you ran out of compute units. "Error processing Instruction 0: custom program error: 0x1" is a program-specific error that you must decode from the program's error enum.

For a comprehensive list of errors, their meanings, and fixes, see Common Solana transaction errors and how to fix them.

Risks on Solana extend beyond typical blockchain risks. Sending SOL to a PDA without proper derivation permanently locks the funds. Signing a malicious transaction that drains your wallet is the most common attack vector. Unverified program upgrade authorities allow developers to replace program logic. Token-2022's permanent delegate and clawback features give issuers control over user tokens.

Many misconceptions persist. Solana is not centralized because it has "few" validators - the Nakamoto coefficient matters more than raw count. Solana does not "go down all the time" - it has had liveness failures, but they are infrequent and usually resolved within minutes. Proof of History is not a consensus mechanism. Failed transactions are not free - you pay the fee for block inclusion even if the program returns an error. Parallel execution does not mean every transaction runs simultaneously - write conflicts serialize.

Understanding these nuances is the difference between using Solana successfully and getting stuck on a cryptic error or losing funds to a preventable mistake.

Each of the topics above has a dedicated spoke page that goes deeper. The pillar gives you the map. The spokes give you the detailed terrain. Start with the area that matches your current problem - transaction fees, staking, errors, development - and follow the links to the full treatment.

Back to solana