Page record
Changelog.
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].
Analogy, not the mechanism itself: PoH is like a ticking clock printed into every page of a logbook, so anyone reading it can see what came first and how much time passed.
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]. A feature gate is an on-chain switch that turns a change on for the whole network at a set point.
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.
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].
Analogy, not the mechanism itself: a program is like a calculator with no memory; you hand it the notebooks (data accounts) it should read and write each time.
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].
Time on Solana is divided into slots [7]. A slot is a short, fixed time window in which one block can be made. 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].
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].
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]. A compute unit is Solana's measure of how much processing a transaction uses. 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].
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].
| Date | Event | Source |
|---|---|---|
| May 2026 | Agave 4.1: 100M compute-unit blocks; Validator Admission Ticket code | [5] |
| Jul 8, 2026 | BLS key management in vote accounts (SIMD-0387) live on mainnet | [6] |
| Jul 22, 2026 | Validator Admission Ticket (SIMD-0357) live on mainnet | [6] |
| Aug 4, 2026 | Firedancer v1.1.3 tagged "mainnet ready" | [11] |
| Aug 2026 | Agave 4.2 ships | [5] |
| Aug 21, 2026 | Slot time cut to 350ms (epoch 1020) | [7] |
| Aug 28, 2026 | Slot time cut to 300ms (epoch 1024) | [7] |
| Sep 3, 2026 | First rent cut: 6,960 to 6,333 lamports per byte | [8] |
| Sep 15, 2026 | Maximum transaction size raised to 4,096 bytes | [9] |
| Sep 18, 2026 | Slot time cut to 250ms (epoch 1037) | [7] |
| Pending | 200ms slots, scheduled for epoch 1052 | [7] |
| Pending | Alpenglow consensus (Agave 4.3) | [5][6][12] |
What changed. 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]. A blockhash is the recent-block reference each transaction carries.
Why it mattered. Blocks come faster, and apps have less time before a signed transaction goes stale [7].
What changed. 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].
Why it mattered. Creating accounts that store data needs a smaller deposit, starting with the first step [8].
What changed. 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].
Why it mattered. Builders can fit more into one transaction if they switch to v1 [9].
What changed. 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]. A BLS key is a type of signing key whose signatures can be combined. 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].
Why it mattered. Validator operators had to register a BLS key to keep taking part in consensus [6].
What it would change. 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].
Analogy, not the mechanism itself: TowerBFT is like voting by mailing ballots that get filed in the public record; Votor is like a show of hands tallied into a signed certificate.
Why it matters. Solana's stated target is finality of about 150 milliseconds; it is not live yet [6].
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.
The data-spreading half of Alpenglow has no schedule [6]. Until it ships, Turbine stays in place [6].
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].
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].
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].
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.
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.
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].
getEpochInfo, getInflationGovernor, getInflationRate, getAgGenesisCert and getVersion, epoch 1050, slot 453,977,078. Endpoint https://api.mainnet-beta.solana.com (JSON-RPC POST, no params), queried October 6, 2026 at 2:06 p.m. ET; all five calls answered within epoch 1050, between slots 453,977,078 and 453,977,111 (getEpochInfo before and after). Returned: getInflationGovernor initial 0.08, taper 0.15, terminal 0.015, foundation 0.0; getInflationRate epoch 1050, total 0.03615736122411238; getAgGenesisCert null; getVersion solana-core "4.3.0", feature-set 3383571666. getInflationGovernor, getInflationRate, getAgGenesisCert and getVersion take no slot and report the state at query time; getVersion reports the answering node's own software, not the whole cluster. No explorer cross-check available. Method references: https://solana.com/docs/rpc/http/getepochinfo and https://solana.com/docs/rpc/http/getinflationgovernorinflation/src/lib.rs (commit 891412d, September 22, 2026). https://github.com/anza-xyz/solana-sdk/blob/891412dceb0a7d3d4116ac295eef519882138090/inflation/src/lib.rsNot financial advice.