Solana is an open-source Layer 1 blockchain designed to process transactions and run programmable applications through a high-performance execution environment.
Its native cryptocurrency is SOL.
The production network launched in March 2020, following development that began several years earlier around a blockchain architecture proposed by Solana co-founder Anatoly Yakovenko.
Solana is known for several technical design choices that differ from networks such as Bitcoin and Ethereum.
It uses Proof of Stake for consensus, while Proof of History provides a cryptographic mechanism for establishing the order and passage of time between events.
Its execution environment, commonly called the Solana Virtual Machine or SVM, is designed to process independent transactions in parallel.
The network also uses short slots, stake-weighted validators and a leader schedule to organize block production.
Understanding Solana therefore requires separating Proof of History, consensus, transaction execution and the SOL asset itself.
Solana vs SOL#
Solana is the blockchain network.
SOL is its native cryptocurrency.
SOL is used to:
pay transaction fees
stake with validators
participate in network security
fund storage requirements for onchain accounts
transfer value
and interact with applications built on Solana
One SOL is divided into:
1,000,000,000 lamports
A lamport is the smallest native unit of SOL.
SOL itself is the protocol-level currency of Solana. It should not be confused with SPL tokens created through Solana’s token programs.
When Did Solana Launch?#
The core idea behind Solana began with Anatoly Yakovenko’s work on Proof of History in 2017.
The Solana team subsequently developed a broader blockchain architecture around that concept, including a Proof-of-Stake consensus system, parallel transaction execution and high-throughput networking.
Solana Mainnet Beta launched in March 2020.
The term “Mainnet Beta” has remained visible in Solana tooling and infrastructure, although current documentation also commonly refers to the production cluster simply as Mainnet.
The protocol has changed substantially since launch.
Network upgrades have altered validator software, fees, transaction formats, account storage costs, block capacity and slot timing, while additional validator clients and a new consensus design called Alpenglow are being developed.
Does Solana Use Proof of History for Consensus?#
Not by itself.
Solana’s current consensus architecture combines Proof of Stake with Tower BFT.
Proof of History, or PoH, acts as a cryptographic clock.
It provides a verifiable sequence that helps establish when events occurred relative to one another.
Tower BFT uses this time structure as part of Solana’s stake-weighted consensus process.
This distinction is important because Proof of History does not independently decide which blockchain history validators accept.
Validators still vote according to a Proof-of-Stake consensus mechanism.
What Is Proof of History?#
Distributed systems need a way to agree on the order in which events occurred.
Ordinary computer networks can rely on trusted clocks or external time servers.
A decentralized blockchain cannot simply assume that every participant’s clock is trustworthy.
Proof of History creates a continuously verifiable sequence using repeated cryptographic hashing.
Each output becomes an input to the next step.
Because those steps must be performed sequentially, the resulting chain provides evidence that a particular amount of computation occurred between two points in the sequence.
Data can be inserted into this sequence, creating a verifiable ordering of events.
Other validators can verify the sequence much faster than recreating the entire timing process themselves.
PoH therefore gives Solana a shared notion of ordering without requiring validators to communicate repeatedly just to establish when every event occurred.
What Is Tower BFT?#
Tower BFT is Solana’s current consensus algorithm.
It is a Byzantine Fault Tolerant system designed to take advantage of the ordering provided by Proof of History.
Validators vote on blocks and forks.
Those votes are weighted according to stake.
As validators repeatedly vote on a chain, earlier votes become increasingly difficult to reverse because of lockout rules.
This helps the network converge on one canonical history.
Tower BFT and Proof of History therefore perform different jobs.
Proof of History helps organize time and ordering.
Tower BFT and Proof of Stake determine consensus.
How Solana Validators Work#
Validators are computers running Solana validator software.
They perform functions including:
receiving transactions
executing transactions
verifying blocks
voting on the ledger
maintaining blockchain state
and producing blocks when selected as leader
Solana assigns leaders to particular slots through a leader schedule.
A leader receives transactions and assembles a block during its assigned slot.
Other validators replay that block, verify its execution and participate in consensus through stake-weighted voting.
A validator’s influence in consensus is related to the amount of SOL delegated to it.
What Is the Leader Schedule?#
Solana does not have every validator attempt to create a block simultaneously.
Instead, validators are assigned leader slots.
The leader schedule determines which validator has the opportunity to produce blocks during particular slots.
Stake influences the probability of receiving leader assignments.
A validator with more active stake generally receives proportionally more opportunities to lead.
The schedule allows transactions to be forwarded toward upcoming leaders rather than relying entirely on a traditional global mempool.
This is one element of Solana’s design for reducing latency.
How Does SOL Staking Work?#
SOL holders can delegate stake to validators.
Delegated SOL increases the stake weight associated with that validator and can earn protocol staking rewards.
Delegation does not give the validator ownership of the holder’s SOL.
Stake is managed through dedicated stake accounts controlled by authorized keys.
Rewards depend on factors including:
the network’s inflation rate
the amount of SOL staked across the network
validator performance
and validator commission
Staking returns are therefore variable rather than guaranteed.
Activating or deactivating native stake also occurs according to Solana’s epoch-based staking rules, so native delegated stake is not always immediately available the moment a user requests a change.
Can Staked SOL Be Slashed?#
Solana has slashing concepts, but its current implementation differs from networks where penalties are automatically deducted whenever a validator commits a slashable offense.
Solana documentation states that slashing is not automatic.
In severe circumstances, such as malicious behavior contributing to a network halt, stake can potentially be slashed during the network recovery process.
Poor validator uptime can also reduce rewards without necessarily resulting in a direct token-destruction penalty.
Delegators therefore need to distinguish missed rewards from slashing.
Liquid staking protocols can add separate smart-contract, validator-selection and token-liquidity risks beyond native Solana staking.
How Fast Are Solana Blocks?#
Solana divides time into short periods called slots.
Historically, Mainnet targeted approximately 400-millisecond slots.
During 2026, protocol upgrades began progressively reducing that target through shorter slot-time feature gates.
The rollout has moved through 350ms, 300ms and shorter configurations as validator software and network infrastructure are upgraded.
A slot does not necessarily contain a block.
If the assigned leader fails to produce a valid block, the network moves on to later slots.
This makes “slot time” different from a guarantee that every transaction will settle within exactly that amount of time.
Processed, Confirmed and Finalized Transactions#
Solana applications can request different levels of transaction commitment.
Processed means a transaction has been observed in a block processed by a node.
Confirmed provides greater confidence through validator voting.
Finalized represents a stronger commitment level after the relevant block has become rooted under the consensus rules.
These stages allow applications to balance speed against certainty.
A low-value application may display a transaction quickly after confirmation, while infrastructure handling larger amounts may wait for stronger finality.
Under the current Tower BFT architecture, full finalization takes longer than Solana’s short block-production interval.
This distinction is one reason a sub-second slot should not automatically be described as sub-second irreversible finality.
What Is the Solana Virtual Machine?#
The Solana Virtual Machine, or SVM, is the execution environment used for Solana programs and transactions.
Solana’s execution design is substantially different from the Ethereum Virtual Machine.
Programs are commonly written in Rust and compiled into Solana Bytecode Format, or sBPF.
Onchain programs are largely stateless.
Mutable information is stored separately in accounts supplied to the program when an instruction executes.
This separation between program code and account state is a fundamental part of the Solana development model.
What Are Solana Programs?#
A program is Solana’s equivalent of what is commonly called a smart contract.
A deployed program contains executable code.
Applications interact with that program by including instructions in transactions.
Programs can be used for activities such as:
token exchanges
lending
payments
games
NFT marketplaces
stablecoins
governance systems
derivatives
and asset issuance
A program can also call another program through a mechanism known as a Cross-Program Invocation.
This makes it possible to combine multiple protocols within one transaction.
What Are Solana Accounts?#
Solana stores blockchain state in accounts.
Accounts can contain:
SOL
program data
application state
token balances
configuration information
and other blockchain data
Every account has an address.
Programs are given explicit access to the accounts they need to read or modify.
This design is important for performance because the runtime can know in advance which pieces of state a transaction intends to access.
Why Can Solana Execute Transactions in Parallel?#
Solana’s runtime is designed around parallel execution through technology historically referred to as Sealevel.
Transactions identify the accounts they intend to read and write.
If two transactions do not attempt to modify conflicting state, the runtime can execute them in parallel.
For example, two unrelated applications interacting with different accounts may be processed concurrently.
Transactions that need to modify the same writable account can conflict and may need to be scheduled sequentially.
This means Solana’s throughput depends partly on workload composition.
A network handling many independent transactions can parallelize more effectively than one experiencing heavy contention around the same accounts.
Does Solana Process 65,000 Transactions Per Second?#
Solana has historically been associated with figures such as 50,000 or 65,000 transactions per second.
Those numbers largely originated from benchmarks, architectural estimates or particular testing conditions.
They should not be treated as a fixed real-world capacity guarantee.
Observed throughput depends on:
hardware
validator software
transaction complexity
account contention
block compute limits
network conditions
and how transactions are counted
Solana’s raw transaction metrics can also include validator-related activity, so comparisons between blockchain TPS figures require consistent methodology.
The more useful technical point is that Solana was designed to increase throughput through short slots, parallel execution, high network bandwidth and relatively high validator hardware requirements.
How Solana Transaction Fees Work#
Every Solana transaction requires a fee paid in SOL.
The fee system contains a base fee and an optional prioritization fee.
The current base fee is:
5,000 lamports per signature
Transactions performing more complicated operations are also limited through compute units.
Applications can add a priority fee to improve the likelihood of inclusion when blockspace is in demand.
Modern transaction formats have continued evolving, so the exact mechanism used to specify priority fees can differ by transaction version.
A failed transaction can still consume a fee because validators performed work attempting to process it.
What Happens to Solana Transaction Fees?#
The current base transaction fee is split between burning and validator compensation.
Half of the base fee is burned.
The other half is paid to the block-producing validator.
Priority fees are paid to the validator rather than burned.
This means transaction activity creates a small supply-reducing mechanism while Solana’s inflation schedule simultaneously creates new SOL for staking rewards.
The net SOL supply therefore reflects both issuance and burning.
Does SOL Have a Maximum Supply?#
No.
SOL does not have a fixed maximum supply comparable with Bitcoin’s 21 million BTC limit.
Solana uses an inflation schedule.
The protocol began with an annual inflation target of 8%.
That rate is designed to decline by approximately 15% per year until reaching a long-term inflation rate of:
1.5% annually
Newly issued SOL primarily supports staking rewards.
Because the inflation rate changes over time and some transaction fees are burned, total SOL supply is dynamic.
A current supply figure is therefore a snapshot rather than a permanent protocol constant.
Is SOL an SPL Token?#
No.
SOL is Solana’s native protocol asset.
SPL tokens are assets managed through Solana token programs.
Applications that require SOL to behave like a conventional token can use wrapped SOL.
Wrapped SOL is represented through the token-program architecture while remaining redeemable for the underlying native SOL held by its token account.
The distinction is similar in concept to native ETH and WETH on Ethereum.
What Are SPL Tokens?#
Solana supports fungible and non-fungible assets through token programs.
The original Token Program provides functionality for creating mints, issuing tokens, transferring balances and managing token accounts.
Token-2022, also called the Token Extensions Program, adds optional functionality.
Depending on the token configuration, extensions can support features such as:
transfer fees
confidential transfers
pausable tokens
transfer hooks
permanent delegates
interest-bearing display logic
non-transferable tokens
and additional metadata or control features
These capabilities are defined by the token issuer.
The presence of an administrative extension does not mean Solana itself controls the asset.
Solana and Tokenized Assets#
Token-2022 has expanded the types of financial assets that can be represented directly through Solana’s token infrastructure.
Features such as transfer restrictions, pausing, confidential-transfer functionality and permanent delegates can be useful for issuers with compliance or operational requirements.
This allows regulated or institutionally managed assets to use token-level controls without recreating every feature through a separate custom contract.
Those controls also create different trust assumptions from a token whose mint and administrative authorities have been permanently removed.
Users need to evaluate the configuration of the particular asset they are using.
Solana and DeFi#
Solana supports decentralized exchanges, lending markets, derivatives, liquid staking protocols, stablecoins and other financial applications.
These applications run through onchain programs and accounts while inheriting Solana’s underlying settlement environment.
Application security remains separate from blockchain consensus.
A Solana program can contain a vulnerability even while the Solana network itself operates normally.
DeFi users can therefore face smart-contract, oracle, liquidity, governance and economic risks in addition to the risks of holding SOL.
Solana and Payments#
Low base transaction fees and short block intervals make Solana suitable for applications involving frequent transfers and payment flows.
Stablecoins and tokenized assets can be transferred through the same general transaction infrastructure used by other Solana applications.
Payment experience can still depend on:
wallet infrastructure
priority fees
network congestion
token-account creation
merchant systems
and the design of the asset being transferred
A low protocol fee does not necessarily mean every payment service built on Solana charges the same amount.
Has Solana Experienced Network Outages?#
Yes.
Solana experienced several significant network interruptions during its earlier years.
Incidents in 2021 and 2022 included periods where consensus stalled and validators coordinated network restarts.
On February 6, 2024, block finalization stopped for approximately five hours after a validator software bug triggered an infinite recompilation loop across most of the network’s active stake.
The affected software was patched and validators coordinated a restart.
Reliability subsequently improved substantially.
In September 2026, the Solana Foundation reported that the network had operated without downtime since the February 2024 incident.
Solana’s public status page also provides ongoing incident history.
Historical outages remain relevant when evaluating the network, while more recent uptime provides additional evidence about how the software has evolved.
What Are Agave and Firedancer?#
A blockchain is more resilient when independent software implementations can participate in consensus rather than every validator relying on one identical codebase.
Agave is the validator client maintained by Anza and descended from the original Solana Labs validator implementation.
Firedancer is an independently developed validator client created by Jump Crypto.
Firedancer has reached mainnet release builds and continues to receive performance and compatibility updates.
Other validator-client work also exists within the ecosystem.
Independent implementations can reduce the risk that one software bug affects every validator in exactly the same way.
Client diversity only provides that benefit when independent clients are sufficiently mature and actually used by meaningful portions of network stake.
What Is Alpenglow?#
Alpenglow is Solana’s planned next-generation consensus protocol.
It is intended to replace the current Tower BFT architecture and substantially reduce finality time.
Solana’s 2026 upgrade roadmap targets approximately:
150 milliseconds
for finality under Alpenglow’s intended operating conditions.
As of September 23, 2026, Alpenglow is not yet the active Solana Mainnet consensus protocol.
Solana’s upgrade documentation places it with the planned Agave 4.3 release and describes mainnet deployment as upcoming.
Current Mainnet still relies on Tower BFT and Proof of History.
This distinction matters because roadmap performance should not be presented as already-active network behavior.
What Is Changing on Solana in 2026?#
Solana is undergoing several performance and protocol upgrades.
During 2026, network upgrades have included or begun rolling out:
shorter slot times
higher block compute capacity
lower account-storage requirements
larger transaction formats
Transaction V1
new validator-client releases
and groundwork for Alpenglow
The September 2026 changelog also lists continuing releases for both Agave and Firedancer.
Some upgrades activate through feature gates over time rather than appearing everywhere immediately when a software version is released.
Network behavior can therefore change during a staged rollout.
Who Controls Solana?#
Solana does not have one administrator capable of directly editing the public ledger.
Validators independently run software and participate in consensus according to stake.
Several organizations nevertheless play important roles in development and ecosystem coordination.
The Solana Foundation supports ecosystem and validator initiatives.
Anza develops Agave and contributes heavily to core protocol engineering.
Jump Crypto develops Firedancer.
Other teams contribute tooling, validator software, infrastructure and protocol proposals.
Protocol changes can be proposed through Solana Improvement Documents, commonly called SIMDs, and implemented through validator software and network feature activation.
Stake distribution, client adoption, infrastructure concentration and the influence of major engineering organizations remain relevant when evaluating practical decentralization.
Is Solana Private?#
No.
Solana is a public blockchain.
Wallet addresses, SOL transfers, token balances and application interactions can generally be inspected through blockchain explorers.
Addresses are pseudonymous rather than automatically containing a person’s real identity.
External information from exchanges, applications or transaction analysis can still connect blockchain activity with identifiable users.
Solana should therefore not be treated as a privacy network.
Some token and application technologies can add privacy-related functionality, but that does not make ordinary Solana transactions private by default.
What Are the Main Risks of Using Solana?#
Solana’s performance-focused architecture involves several trade-offs.
Validator requirements#
Running a performant validator requires comparatively capable hardware and networking infrastructure, which can affect who is able to participate directly.
Stake concentration#
Consensus influence is stake-weighted, so the distribution of delegated SOL across validators matters.
Software risk#
Validator-client bugs can affect network availability or consensus.
Smart-contract risk#
Solana programs can contain vulnerabilities or economic flaws.
Application risk#
A decentralized application can fail even while the base blockchain remains healthy.
Staking risk#
Validator performance, commission, stake activation rules and potential slashing scenarios can affect stakers.
Token risk#
SPL and Token-2022 assets can contain issuer-controlled authorities and extensions.
Infrastructure risk#
Wallets, RPC providers, indexers and other services can fail independently of Solana consensus.
Market risk#
SOL is a freely traded cryptocurrency whose price can move substantially.
Network throughput or technical development does not guarantee the market value of SOL.
How to Research Solana Independently#
Solana’s technical documentation is publicly available.
Useful primary sources include the Solana documentation, original whitepaper, staking documentation, fee documentation, network upgrade tracker, changelog and public status page.
The Solana Explorer can be used to inspect accounts, transactions and network activity.
Validator-client development can also be followed through the public Agave and Firedancer repositories.
Because Solana is changing quickly, technical claims involving slot time, transaction limits, validator software or upcoming consensus upgrades need to be checked against current network documentation.
For structured network information and official links, see the Solana (SOL) profile on Chainquiry.
Final Perspective#
Solana is a Proof-of-Stake Layer 1 blockchain designed around high-throughput execution and short block-production intervals.
Proof of History is one of its defining technologies, but it is not a standalone consensus mechanism.
PoH provides a cryptographic clock, while stake-weighted validators and Tower BFT currently determine consensus.
The Solana Virtual Machine provides the programmable execution layer.
Its account model allows the runtime to identify independent transactions and process compatible workloads in parallel, helping the network make use of modern multi-core hardware.
SOL powers transaction fees and staking, while protocol inflation supplies staking rewards and part of each base transaction fee is permanently burned.
Unlike Bitcoin, SOL has no fixed maximum supply.
Solana’s architecture has also continued changing.
Token-2022 expanded asset functionality, multiple validator clients are improving software diversity, slot times are being reduced through staged upgrades, and Alpenglow is being prepared as a future replacement for Tower BFT with a target of substantially faster finality.
The network’s history includes significant outages, particularly during its earlier years, alongside a much longer period of uninterrupted operation since February 2024.
Taken together, Solana is best understood not simply as a “fast blockchain,” but as a system built around coordinated timekeeping, stake-weighted consensus, parallel execution and progressively optimized validator infrastructure.
