Solana

Changelog.

• v0.2.2 (2026-10-14; replaces v0.2.1, publish hash 0531d1cf081f925629f2190c7d1b3ebd965bfa727157ebb4de4e0dadb1aac05b): the page record now shows the published status, version, publish date and proof. Body wording: the policy line now names the Learning Hub. No claim changes.
• v0.2.1 (2026-10-06; replaces v0.2, sha256 a040ab78d2c8fcf3948a45979fcf33a3a2b531fa64959d05a7c344f595984f35): cited the opening "proof-of-stake" description to Solana's Staking page, added as a source, because the page cited before did not use that phrase.
• v0.2 (2026-10-06; replaces v0.1, sha256 aa4bfcdd99a68c8beda8c9d6eac266dcd27700f5751ccf17c8d7213fa05cacf8): cut an unsourced single-chain claim from the opening line; replaced "main validator software" (a client-share claim) with the fact that protocol upgrades ship in Agave releases; defined the lamport from Solana's Terminology page, added as a source; noted that the prioritization fee is a flat lamport total in the new v1 transaction format; added Anza's SDK source, pinned to a commit, as the source that the inflation figures are yearly; rewrote the mainnet RPC source in the chain-state format with a fresh, reproducible read (epoch 1050, slot 453,977,078) and its returned values; rewrote the 2,000-validator cap using Solana's validator-admission page, added as a source, which says validators outside the top 2,000 by stake are excluded for that epoch; removed an unsupported claim that misbehaving validators lose rewards but not stake; removed an uncited sentence about third-party client trackers; relabeled the learning hub from "The File" to "Library".

1. What it is

Solana is a proof-of-stake blockchain [16]. Its native token is SOL, which pays transaction fees and is staked to validators [3][4]. Anatoly Yakovenko's white paper introduced its signature idea, Proof of History (PoH): a way to record the order of events and the time that passes between them inside the ledger itself [10].

Solana's protocol upgrades ship in releases of Agave, the validator client maintained by Anza [5][6]. A second, independent client, Firedancer, is built by Jump Crypto [11]. Protocol changes are written up as Solana Improvement Documents (SIMDs) and switched on through on-chain "feature gates" [6][7].

Solana is partway through several protocol changes at once [5]. Alpenglow, described by the Solana Foundation as "Solana's first major consensus replacement since TowerBFT," is still pending [6]. Meanwhile its slot time is being cut from 400 milliseconds to 200, and storage deposits are being cut by 90% [7][8]. This dive describes the network as it runs on October 6, 2026, and flags which pieces are still pending.

2. How it works

Accounts and programs

Everything on Solana is stored in accounts [1]. Each account has five fields: its balance in lamports (one lamport is 0.000000001 SOL), its data, its owner, an executable flag and a deprecated rent field [1][15]. Programs, Solana's smart contracts, are accounts with the executable flag set [2]. Programs hold no state of their own [2]. All changeable state lives in separate data accounts that are passed to the program [2]. A program can be upgraded while it has an upgrade authority, and becomes immutable once that authority is revoked [2].

Every account must hold a minimum balance sized to its data [8]. Solana calls this "rent," but it works as a refundable deposit [8]. When the account is closed, the whole amount goes back to whoever closes it [8].

Leaders, slots and Proof of History

Time on Solana is divided into slots [7]. For each slot, one pre-assigned validator, the leader, builds the block [6]. Each leader gets four slots in a row [7]. Validators with more stake delegated to them are chosen as leader more often [4]. An epoch is a fixed 432,000 slots [7].

Transactions are forwarded directly to the upcoming leader, a design Solana calls Gulf Stream [7]. The leader's PoH stream emits 64 "tick" entries per slot, evenly spaced, which pace block production today [6]. Block data is spread across the network by a protocol called Turbine [6].

Consensus today: TowerBFT

Under the current consensus protocol, TowerBFT, validators vote by sending transactions [6]. A block is final once enough of those votes have stacked up over 32 slots, which takes about 12.8 seconds [6]. Most applications read at the faster "confirmed" level, which arrives in about one slot [6]. Solana's docs note that a confirmed block could, in principle, still be dropped [6].

Fees

Every transaction pays a base fee of 5,000 lamports per signature [3]. Half of the base fee is burned and half goes to the validator [3]. Users can add a prioritization fee, which goes entirely to the validator [3]. In older transaction formats it is priced per compute unit [3]. In the new v1 format it is a flat lamport total [3]. A transaction can request at most 1.4 million compute units [3]. Since Agave 4.1, a block can hold 100 million compute units, up from 60 million [5].

Staking and issuance

SOL holders stake by delegating to validators, who charge a commission on rewards [4]. Solana's staking documentation says there is currently no slashing in the protocol, though it could be added in the future [4].

New SOL is issued on a fixed schedule [12]. Mainnet reports an initial rate of 8% a year, falling by 15% each year toward a long-term rate of 1.5% [12][14]. For epoch 1050, the network reported a current inflation rate of about 3.6% [12].

3. What changed

Shorter slots. SIMD-0525 cuts slot time from 400 milliseconds to 200 in four steps of 50 milliseconds, each behind its own feature gate [7]. Three steps are live, so mainnet runs at 250 milliseconds [7]. The last step is scheduled for epoch 1052, and the rollout pauses if block skip rates rise too high [7]. Ticks per slot, the four-slot leader span and the epoch length in slots stay the same [7]. One knock-on effect: a transaction's blockhash expires after 150 blocks, so it now goes stale after about 50 seconds rather than 80 [7].

Cheaper storage deposits. SIMD-0437 cuts the per-byte deposit from 6,960 lamports to 696, a 90% reduction, in five feature-gated steps [8]. The first step took effect at epoch 1028 on September 3, 2026 [8]. Steps 3 to 5 are planned for Agave 4.4, expected in November 2026 [8].

Bigger transactions. The maximum transaction size rose from 1,232 bytes to 4,096 bytes on September 15, 2026, through a new "v1" transaction format [9]. Older formats still work, and apps that want the extra room must switch to v1 [9].

Validator admission. The Validator Admission Ticket (VAT) is a step toward Alpenglow [6]. Since it went live on July 22, 2026, validators that have not registered a BLS public key are excluded from the admitted set and stop taking part in consensus [6]. Solana's upgrade page lists a maximum of 2,000 admitted validators [5]. It also lists a 1.6 SOL VAT fee that applies after the full Alpenglow migration [5].

Alpenglow. Alpenglow replaces TowerBFT [6]. Its first phase, Votor, has validators send votes directly to each other and bundle them into certificates instead of posting vote transactions [6]. A block is final after one round if at least 80% of stake votes for it, or after a second round with 60% thresholds [6]. Solana targets finality of about 150 milliseconds, down from about 12.8 seconds [6]. Votor is designed to keep working with 20% of stake acting maliciously plus another 20% offline [6]. Under Alpenglow, PoH no longer paces block production, ticks leave the ledger, and "confirmed" and "finalized" become the same level [6]. The second phase, Rotor, would replace Turbine and "is not yet scheduled" [6]. Execution, transaction formats and fees do not change [6].

4. What is open

When Alpenglow reaches mainnet. Solana's Alpenglow page, updated September 2026, gives an expected mainnet date of "Q3 2026, on Anza's v4.3 release schedule" [6]. The upgrades index lists Agave 4.3 as "Expected October 2026" and "In Development" [5]. On October 6, 2026, a mainnet RPC node running Agave 4.3.0 returned null for the Alpenglow genesis certificate, which Solana's docs say means the cluster is still on TowerBFT [6][12]. No mainnet activation date appears in the primary sources we reviewed.

Rotor. The data-spreading half of Alpenglow has no schedule [6]. Until it ships, Turbine stays in place [6].

A new trust model for the clock. Under Alpenglow, a block's timestamp is set by its leader within a bounded range, instead of being the stake-weighted median of validator votes [6]. Solana's docs say a dishonest leader can push the clock ahead, and the room to do so grows after skipped slots [6]. Programs that depend on precise time will need to be rechecked [6].

A capped validator set. The VAT admits at most 2,000 validators [5]. Solana's VAT page says validators with a registered BLS key but outside the top 2,000 by stake are left out of the admitted set for that epoch [13].

No slashing. Solana's staking documentation says there is no slashing in the protocol today [4]. The same page links to a slashing roadmap but gives no date for adding slashing [4].

Client concentration. Firedancer's repository describes two products [11]. Full Firedancer shares no code with Agave [11]. Frankendancer is a hybrid that still uses Agave for execution and consensus [11]. We found no primary measurement of how much stake runs each client, so this page gives no share figures.

Many moving parts at once. Slot-time cuts, rent cuts, a new transaction format, validator admission and a new consensus protocol are all rolling out within a few months [5][6][7][8][9]. Each step is gated and can be paused [7]. The combined risk of changing these pieces together is not assessed in the sources.

What this page leaves out. By Learning Hub policy, this dive carries no price, market value, staking-yield or usage-volume figures. Transaction counts in particular will drop when vote transactions leave blocks under Alpenglow, which Solana says is "an accounting change, not a throughput regression" [6].

Not financial advice.