Layer 1 blockchain
Solana ticker SOL
Summary
Proof-of-stake validator cluster. A leader drawn from a stake-weighted schedule orders transactions into slots, Proof of History supplies a verifiable ordering and elapsed-time sequence, and validators vote on forks under lockout rules (TowerBFT). Solana's terminology defines finality as nodes holding 2/3 of stake sharing a common root. Alpenglow (SIMD-0326, migration plan SIMD-0384) would replace this voting layer; the Foundation's upgrade page lists it as active on testnet and devnet but not activated on Mainnet as of 2026-09-27. Slot times are being cut in stages: the Foundation's upgrades page lists 300ms live on Mainnet since August 25, 2026 and 250ms as not yet scheduled, while its September 18, 2026 changelog lists the 250ms change under Mainnet. A target slot time is not a finality time. 2567891325
Design
- System
- Layer 1 blockchain
- Settlement family
- Solana / SVM
- Scarce resource
- Stake (proof of stake)
- State model
- Accounts
- Finality
- Other
- Who makes blocks
- Validators on a stake-weighted leader schedule computed per epoch; each leader may produce at most one block in its slot.
- Fork choice
- Validators vote on forks and are locked out from switching for a period; a block is rooted once it reaches maximum lockout and final when 2/3 of stake share the root. This is stake-vote based, not work-weighted longest chain. It describes the current TowerBFT model, which Alpenglow would replace once activated on Mainnet.
Qualifications
- Finality · Applies. A block is final once validators holding 2/3 of stake share it as a common root under vote lockouts. Solana's staking documentation says there is no in-protocol slashing today, so reverting a finalized block would not destroy stake. It is therefore classed as committee finality without slashing, not as economic finality. Recheck when slashing or Alpenglow is activated on Mainnet.
- Block time · Partial. Slots are scheduled leader opportunities; skipped slots produce no block, so slot rate and block rate differ. Target slot time is not confirmation or finality latency.
- Tps · Contested. No transactions-per-second figure is recorded here. Headline Solana TPS numbers circulate without a stated class, window or hardware; they are not used.
- Consensus upgrade · Partial. Alpenglow (SIMD-0326, migration plan SIMD-0384) is active on testnet and devnet but not activated on Mainnet as of 2026-09-27, per the Foundation's upgrade page, which expects Mainnet activation in Q3 2026 with Agave v4.3. The SIMDs' Review status describes the document process, not deployment. The fork-choice and finality text here describes the current TowerBFT model; recheck at the end of September 2026.
Tradeoffs
- Emphasizes
- Scalability Contested
- Gives up
- Operational decentralization: Anza's published specs (256GB+ RAM for validators with a 512GB-capable ECC board suggested, 512GB+ RAM for RPC nodes with all account indexes, 2-10 Gbps for staked nodes, multiple high-endurance NVMe drives) put full participation beyond typical home setups.Whether rising hardware requirements are an acceptable trade for throughput is disputed; multiple validator clients (Agave, Firedancer) address client risk, not hardware cost. This profile records requirements, not a verdict.
- Full node at home
- Data-center class 15Anza lists 1 Gbps symmetric for unstaked nodes and 2 Gbps minimum (10 Gbps recommended) for staked nodes; 256GB+ RAM for validators (ECC suggested, 512GB-capable board suggested) and 512GB+ for RPC nodes with all account indexes; 12 cores/24 threads for validators and 16 cores/32 threads for RPC nodes; separate 1TB+ NVMe drives for accounts and ledger plus 500GB+ for snapshots; and a public IPv4 address. Anza also warns that cloud deployment needs more expertise; the data-center rating here describes the hardware needed, not where the node must run.
- Throughput claims
- Theoretical peak: 100,000,000 9101112131415Theoretical peak; not comparable across chains or with observed load.Compute units per 400ms of slot time: the SIMD-0286 block limit set for 400ms slots. Shorter slots get proportionally smaller blocks. Not transactions per second.Network nodes are expected to meet Anza's published validator/RPC requirements, which exceed typical home hardware.This is a budget per unit of time, not the current per-block figure. SIMD-0525 and the Agave v4.3 code scale the block limit with slot time: 75 million compute units per 300ms block and 62.5 million per 250ms block, keeping about the same budget per second. Which stage is live is unresolved: the Foundation's upgrades page lists 300ms on Mainnet with 250ms not yet scheduled, while its September 18, 2026 changelog lists the 250ms change under Mainnet and, in a discussion summary, says blocks are fixed at 100M compute units. Recheck. A block compute ceiling is a capacity limit, not observed usage; blocks need not be full. Compute units do not convert to a fixed transaction count because transactions request different compute. The figure ignores propagation, state growth and vote traffic; it is not comparable to another chain's TPS headline.
Scaling layers
No scaling layer recorded in this profile.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Built into the protocolLimited scope | Transactions: instructions in one transaction execute all-or-nothing, so two parties can swap on-chain assets in a single multi-signer transaction that settles in full or not at all. Scope is limited to the same chain: no trust-minimized cross-chain mechanism using hash time locks was established. 3 |
| Authenticated data publication | Unknown | Not yet assessed under this row's current definition. |
| Light clients | Unknown | Not yet assessed under the current definitions; Solana's terminology defines a light client role, but no light-verification method that consensus supports and no deployed trust-minimized light client were established from the cited source. RPC responses are provider reports, and trusting a server is not light verification. 2 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No documented payment or state channel layer anchored to Solana was reviewed. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | Programs are executable sBPF code; program-derived addresses let a program authorize for accounts without a private key. 14 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | Not yet assessed under the current definitions; a token issuer can give a mint a permanent delegate (a Token Extensions program feature) that may transfer or burn that token from any holder's account, and holders cannot revoke it. That is an issuer control acting on holders, so it does not count for this row, and it does not apply to SOL. No protocol-level sender reclaim or cancellable delayed transfer of a SOL payment, and no timed recovery vault, was found. 26 |
| Rollups | Unknown | No rollup settling to Solana was verified in this review; absence was not exhaustively checked. |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | Established in the ecosystemOrca, Jupiter (swap routing) | Orca describes itself as a concentrated-liquidity DEX on Solana. Jupiter routes swaps across its own and third-party routers; it is routing infrastructure, not itself an AMM. Liquidity depth was not measured. 1718 |
| Issuer-native stablecoins | Established in the ecosystemUSDC (Circle) | Circle lists natively issued USDC on Solana (mint EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v). Native here means issuer-issued on Solana, not bridged; it is not a protocol asset. 19 |
| Algorithmic stablecoins | Unknown | Algorithmic or hybrid stablecoins on Solana were not reviewed. |
| Bridges | Established in the ecosystemCircle CCTP (USDC) | Circle's CCTP V2 lists Solana (domain 5) for burn-and-mint USDC transfers. Other bridges were not reviewed. Risk: CCTP moves only USDC and depends on Circle's attestation service; it is not a general asset bridge, and other bridges carry their own signer or verifier assumptions. 20 |
| Block explorers | First-partySolana Explorer | The Solana Foundation maintains an open-source explorer. Third-party explorers were not reviewed; explorer output is provider-indexed, not consensus proof. 16 |
| Hardware wallets | Established in the ecosystemLedger, Trezor | See the Ledger and Trezor custody entries in this profile: both vendors document Solana support in their own apps. 212223 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | Native supportSame as native: Yes | Can: Send and receive SOL and SPL tokens in Ledger Wallet Can: Stake SOL to validators from Ledger Wallet Can: Sign with the device through Phantom or Solflare 21 |
| Trezor | Native supportSame as native: Yes | Can: Send, receive and manage SOL and SPL tokens in Trezor Suite on Trezor Safe 3, Safe 5, Safe 7 and Model T Can: Stake SOL in Trezor Suite by delegating to Trezor's staking partner Everstake (at least 1 SOL); the stake account's authorities stay with the device Can: Connect the device to Backpack or NuFi Cannot: Use Trezor Model One (Trezor states it does not plan Solana support) 222324 |
Public data
Your AI can request these lookups through the connection. The website itself runs no lookups. Networks: mainnet.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Available | Mainnet native SOL balance only, finalized commitment. |
| Tokens and assets | Needs a provider key on our server | Prepared Helius DAS indexed inventory for SPL/Token-2022 fungibles, NFTs and compressed assets, with bounded page/limit. |
| NFTs | Not available yet | Not implemented in this build |
| Transactions | Available | Mainnet signature status with provider history search. |
Sourced developments
Developments: Review overdue Reviewed Sep 26, 2026; next review was due Oct 6, 2026.
Publication date · newest first
-
Solana Foundation announced two leadership appointments
Ecosystem-organization update, not protocol consensus: the Solana Foundation appointed Rachel Conlan as Chief Strategy Officer and Jamal Raees as General Manager of Payments. The announcement does not establish a chain upgrade, adoption metric or service-health result.
- Stage:Released
Sources: Solana Foundation — Solana Foundation leadership appointments (external site) · Solana Foundation — Solana News RSS (external site)
-
Firedancer v26.09.4 published as a Mainnet-ready client release
Validator-client release, not a protocol activation or adoption claim: Firedancer v26.09.4 was labeled Mainnet ready and included Solana 4.3 feature support, memory reductions and operator-facing configuration changes. Each operator still chooses and verifies its deployed client version.
- Stage:Released
Sources: Jump Crypto contributors — Firedancer Mainnet Release v26.09.4 (external site) · Jump Crypto contributors — Firedancer releases Atom feed (external site)
-
Mainnet target slot time reduction to 250ms reported activated
The September 18 changelog listed the 250ms slot-time reduction as a Mainnet activation. Target slot duration is not guaranteed confirmation or finality latency.
- Stage:Activated
Source: Solana Foundation — Solana Changelog: September 18, 2026 (external site)
-
Mainnet rent parameter reduction to 5,080 lamports per byte reported activated
The September 18 changelog listed a Mainnet storage-rent parameter activation. Applications should use current runtime calculations rather than treating this dated parameter as timeless.
- Stage:Activated
Source: Solana Foundation — Solana Changelog: September 18, 2026 (external site)
-
Transaction v1 reported active on Mainnet
The September 18 changelog reported Transaction v1 among Mainnet feature activations. This is activation evidence from the official engineering changelog, not a general promise that every wallet, SDK or application supports the format.
- Stage:Activated
Source: Solana Foundation — Solana Changelog: September 18, 2026 (external site)
-
Agave v4.3.0 published as a stable release
Anza published Agave v4.3.0 on September 18 and labeled it suitable for Testnet, Devnet and Mainnet Beta. A release does not by itself prove adoption by a particular validator or activation of every shipped feature.
- Stage:Released
Sources: Anza — Agave releases (external site) · Anza — Feature gate tracker schedule (external site)
-
Transaction v1 activation was delayed to epoch 1035
The September 10 changelog announced a delay to give applications more preparation time. The later September 18 activation record supersedes the delay as current activation evidence while preserving the rollout history.
- Stage:Announced
Sources: Solana Foundation — Solana Changelog: September 10, 2026 (external site) · Solana Foundation — Solana Changelog: September 18, 2026 (external site)
-
SIMD-0286 block limit increase reported activated on Mainnet
Protocol activation: the July 30 official changelog reported that Mainnet activated the SIMD-0286 feature gate, raising the per-block compute limit to 100 million compute units. This capacity ceiling does not guarantee that every block is full or that transaction fees and latency remain constant.
- Stage:Activated
Source: Solana Foundation — Solana Changelog: July 30, 2026 (external site)
-
SIMD-0553 resource and inclusion fee design was accepted
Accepted protocol proposal, not activation: SIMD-0553 specifies a base inclusion fee paid to the leader and a resource-based fee burned according to requested cost units. The proposal was merged on July 20; this record is dated by the changelog that reported it. Acceptance and repository merge do not prove implementation, feature-gate activation or Mainnet use.
- Stage:Proposal
Sources: Solana Foundation — Solana Changelog: July 23, 2026 (external site) · Solana Foundation and contributors — SIMD-0553: Resource and Inclusion Fee (external site)
Publication date unknown
-
Alpenglow migration specification remained in Review
SIMD-0384 described migration from TowerBFT to Alpenglow but carried Review status when checked. Review status is not implementation or Mainnet activation.
- Stage:Proposal
Sources: Solana Foundation and contributors — SIMD-0384: Alpenglow migration (external site) · Solana Foundation and contributors — SIMD-0001: Solana proposal process (external site)
Topics your AI can explain
Your AI can explain these topics for Solana through the connection, with sources.
Known gaps
What this profile's review did not establish:
- No primary-source transactions-per-second figure with a stated class and window was recorded; only the block compute budget per unit of slot time is listed.
- The current Mainnet slot time is unresolved: the Foundation's upgrades page says 300ms with 250ms not yet scheduled, while its September 18, 2026 changelog lists the 250ms change under Mainnet (a public RPC read on 2026-09-27 showed that feature gate activated, but RPC output is a provider report). The live per-block compute limit (75M or 62.5M compute units) depends on this and was not confirmed; recheck.
- Alpenglow was not activated on Mainnet as of 2026-09-27 but is expected in Q3 2026 per the Foundation; recheck at the end of September 2026, because the fork-choice and finality text describes the TowerBFT model and will go out of date on activation.
- No rollup or channel layer anchored to Solana was verified, so no scaling options are listed pending research.
- Trezor's pages disagree on the Model T: the Solana coin page lists only Safe 3, 5 and 7, while Trezor's Solana article and staking guide include the Model T.
- Hardware figures are Anza's recommendations for the Agave client; Firedancer's requirements were not reviewed.
- Only the permanent delegate extension was reviewed for reversible transfers and recovery; other token-extension authorities and wallet-level recovery schemes were not.
- Solana's staking documentation says slashing is not implemented in the protocol today; slashing proposals were not reviewed. If slashing is activated, the finality class should be revisited.
- Light-client verification status is unverified.
- Third-party explorers, other bridges and algorithmic stablecoins were not reviewed.
Sources
Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.
- Solana core concepts (external site)
- Solana terminology (external site)
- Transactions (external site)
- Programs (external site)
- Solana Leader Rotation (external site)
- SIMD-0326: Alpenglow (external site)
- SIMD-0384: Alpenglow migration (external site)
- Alpenglow (external site)
- Reduced Slot Times (external site)
- 100M CU Blocks (external site)
- SIMD-0525: Reduce Slot Times (external site)
- Agave v4.3 runtime slot parameters (slot_params.rs) (external site)
- Solana Changelog: September 18, 2026 (external site)
- Solana Changelog: July 30, 2026 (external site)
- Agave validator requirements (external site)
- Solana Explorer repository (external site)
- Jupiter developer documentation (external site)
- Orca documentation (external site)
- USDC contract addresses (external site)
- CCTP supported blockchains (external site)
- Solana wallet (external site)
- Solana wallet (external site)
- Solana: what it is and how it works with Trezor (external site)
- Staking Solana (SOL) in Trezor Suite (external site)
- Staking on Solana (external site)
- Permanent Delegate (Token Extensions) (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding