Everything the chain is doing. Right now.

The leader hashes in a loop with SHA-256, feeding each output into the next step, so the count of hashes shows that time has passed. Transactions are mixed into the chain, which fixes their order and when they arrived. Other validators check the sequence in parallel by splitting it into segments, one per core. The stream is cut into ticks, 64 per slot.

Why it mattersValidators share a clock without exchanging messages first, so leaders rotate on a fixed schedule and the network never waits for a missing node.

• First described publicly in a Solana post dated 2018-04-18.
• Each tick is 39,062 hashes at 250 ms slots, down from 62,500 at 400 ms.
• Listed first among Solana's eight innovations in a post dated 2019-07-28.

By Anatoly Yakovenko · On mainnet since 2020-03

Solana whitepaper v0.8.13, Anatoly YakovenkoSolana: Proof of History, a clock for blockchain (2018)Agave v4.3.0 source: slot parameters

Validators vote on blocks with on-chain vote transactions. Each new vote doubles the lockout on the votes beneath it, so abandoning a fork costs more with every vote. A block is confirmed once 66% of stake has voted on it and finalized once 31 or more confirmed blocks are built on top of it.

Why it mattersThe growing timeouts are measured in PoH, which is recorded in the ledger, so validators can enforce them without extra rounds of messages.

• Lockouts start at 2 slots and double with each vote; a vote 32 deep is at maximum lockout.
• Finalized trailed processed by 32 slots, about 8.5 s, on 2026-10-02.
• Validators approved its replacement, Alpenglow, in a vote that opened 2025-08-27.

By Solana Labs · On mainnet since 2020-03

Solana: Tower BFT, a PBFT implementation (2019)Anza docs: Tower BFTAnza docs: commitment status

Time is divided into slots, and each slot has one leader allowed to produce a block. The schedule for a whole epoch is computed in advance from a seed and stake weights, so every validator knows the upcoming leaders. Each leader gets four consecutive slots. The target slot time has been 250 ms since 2026-09-18; it was 400 ms from launch until 2026-08-21.

Why it mattersKnown leaders let clients send transactions straight to them, and shorter slots shrink a leader's window from 1.6 s to 1 s, limiting how long one node controls ordering.

• SIMD-0525 gates for 350, 300 and 250 ms activated 2026-08-19, 08-26 and 09-16; each cut applied from the next epoch.
• Measured block time on 2026-10-02: 263 to 269 ms.
• The 200 ms step is pending; its feature gate did not exist on mainnet on 2026-10-02.

By Solana Labs · On mainnet since 2020-03

Anza docs: leader rotationSIMD-0525: Reduce slot timesSolana Foundation: slot time reduction effects (2026-09-28)

An epoch is 432,000 slots. New delegations, the leader schedule and feature activations take effect only at epoch boundaries. Within an epoch, leader slots and voting weight follow each validator's share of active stake. At the block time measured on 2026-10-02, an epoch lasts about 32 hours.

Why it mattersFreezing stake for an epoch lets every node compute the same schedule and weights locally, with no extra coordination.

• Mainnet was in epoch 1047 on 2026-10-02.
• SIMD-0525 keeps 432,000 slots per epoch, so epochs get shorter as slots do.
• 672 active validators held 440.7M SOL of stake on 2026-10-02.

By Solana Labs · On mainnet since 2020-03

Anza docs: leader rotationSIMD-0525: Reduce slot timesSolana docs: staking

Alpenglow replaces Tower BFT's voting and finality and retires Proof of History ticks. In its Votor layer, validators send votes directly to each other and aggregate them into BLS certificates, and a block finalizes in one round with 80% of stake or in two rounds with 60%. Its Rotor layer would replace Turbine's relay tree with a single layer of relays, but it needs its own SIMD and has no release date. Votes stop being on-chain transactions.

Why it mattersSimulations with mainnet stake put median finality near 150 ms, against about 8.5 s under Tower BFT today.

• Validators approved SIMD-0326 in a vote opened 2025-08-27: 98.27% of votes cast were yes, with 52% of stake voting.
• Active on testnet and devnet; the mainnet feature gate did not exist on 2026-10-02.
• Designed to tolerate 20% adversarial plus 20% offline stake.

By Quentin Kniep, Kobi Sliwinski and Roger Wattenhofer (Anza)

Anza: Alpenglow, a new consensus for Solana (2025-05-19)SIMD-0326: AlpenglowSolana Foundation: Alpenglow upgrade status

The leader splits each block into small packets called shreds and adds coding shreds so missing pieces can be rebuilt. It sends them to a first layer of nodes, and each node forwards what it receives to a set of nodes in the next layer. The order of nodes comes from a stake-weighted shuffle.

Why it mattersNo single node uploads the whole block to everyone, so the leader's bandwidth stops limiting block size, and propagation time grows only logarithmically with the number of nodes.

• Described in a Solana post dated 2019-07-10.
• Shuffle ChaCha rounds cut from 20 to 8 on 2026-03-25 (SIMD-0332).
• Up to 20,480 data shreds per block at 250 ms slots.

By Solana Labs · On mainnet since 2020-03

Anza docs: Turbine block propagationSolana: Turbine, block propagation (2019)SIMD-0332: ChaCha rounds for Turbine

Solana has no shared mempool. Because the leader schedule is known ahead of time, clients, RPC nodes and validators forward transactions directly to the leaders about to produce blocks. Each transaction references a recent blockhash, so it expires if it does not land in time.

Why it mattersLeaders receive transactions before their slots begin, which cuts confirmation time and spares validators from holding a large pool of unconfirmed transactions.

• Described in a Solana post dated 2019-06-19.

By Solana Labs · On mainnet since 2020-03

Solana: Gulf Stream, mempool-less forwarding (2019)Helius: Gulf Stream explained

Transaction intake moved from raw UDP to QUIC, which adds connections, flow control and acknowledgments that leaders use to throttle abusive senders. Under stake-weighted QoS, a validator holding 1% of stake may send up to 1% of the packets a leader accepts. RPC operators can peer with staked validators to use that capacity.

Why it mattersSpam from unknown or low-stake senders can no longer crowd out traffic from staked peers at the leader's front door.

• Both were listed as live on mainnet in the Solana Foundation status page of 2022-12-14.
• Unstaked connections get shorter lifetimes and less bandwidth than staked ones.

By Solana Labs · On mainnet since 2022

Solana Foundation: network upgrades status, 2022-12-14 (archived)Solana docs: stake-weighted QoSAnza: transaction landing on TPU (2026-02-11)

Each node keeps a replicated table of cluster information and trades updates with peers through push and pull messages about every tenth of a second. Nodes use it to find each other's network addresses and software versions. Some vote traffic also travels over gossip today; Alpenglow sends votes as direct messages.

Why it mattersNodes discover each other and learn the shape of the cluster without a central directory.

• Mainnet nodes reported 10 different client IDs through gossip on 2026-10-02.

By Solana Labs · On mainnet since 2020-03

Anza docs: gossip serviceAnza: Alpenglow, a new consensus for Solana

DoubleZero joins dedicated fiber links from independent contributors into one network with direct routes between data centers. Validators and RPC nodes connect at the edge, and their traffic rides these links in place of public internet paths. An on-chain control plane manages the network, and contributors earn the 2Z token.

Why it mattersDirect routes cut hops and latency between validators, and the network can filter excess traffic before it reaches them.

• Mainnet-beta launched 2025-10-02 with 70+ links from 11 contributors in 25+ locations.
• 386 validators holding 20.78% of stake had joined by launch day.

By DoubleZero Foundation · On mainnet since 2025-10

DoubleZero: mainnet-beta launch (2025-10-02)DoubleZero: mainnet-beta is liveAnza: the Internet Capital Markets roadmap (2025-07-24)

Every transaction lists in advance each account it will read or write. The runtime runs transactions without conflicting writes across many cores at once. Transactions that write the same account run one after another.

Why it mattersDeclared access lets one validator use all of its cores, so throughput grows with hardware.

• Described in a Solana post dated 2019-09-08.

By Solana Labs · On mainnet since 2020-03

Solana: Sealevel, parallel smart contracts (2019)Solana: 8 innovations (2019-07-28)

Programs are written mostly in Rust, and also in C, Zig or assembly, then compiled through LLVM to sBPF, Solana's variant of eBPF. Agave runs them in the rBPF virtual machine, and Firedancer runs its own VM built to the same instruction set. The name SVM is often used for the whole transaction processing pipeline, beyond the VM itself.

Why it mattersOne fixed instruction set lets independent clients run the same programs with identical results.

• sBPF has four versions, v0 to v3.
• SIMD-0500 will accept only v3 for new deployments, expected November 2026.

By Solana Labs, then Anza · On mainnet since 2020-03

Anza: the Solana eBPF virtual machine (2024-10-14)Solana Foundation: sBPFv3 programs

Every instruction consumes compute units (CUs): 200,000 by default and at most 1.4M per transaction. A leader stops adding transactions once its block reaches the cap, and one writable account may use at most 40% of it. SIMD-0286 set the cap at 100M CUs for a 400 ms slot, and SIMD-0525 scales it with slot time, to 62.5M CUs per 250 ms block.

Why it mattersThe cap bounds how long a block takes to replay, so all validators keep up. Scaling it with slot time keeps capacity per second unchanged as slots get shorter.

• Cap per 400 ms slot: 48M (set Dec 2021), 50M (2025-04-10), 60M (2025-07-23), 100M (2026-07-29).
• At 250 ms slots: 62.5M CUs per block and 25M per writable account.

By Solana Labs, Anza and Jito Labs

SIMD-0286: Raise block limits to 100M CUsAgave v4.3.0 source: slot parametersSolana docs: compute budget

Because transactions declare the accounts they write, congestion stays local to hot accounts. Each writable account has its own compute cap per block, so demand for one market cannot fill a block. Senders bid a compute-unit price, and since Agave 1.18 in May 2024 the scheduler orders contending transactions by priority.

Why it mattersUsers of quiet state keep paying low fees while traffic to hot accounts competes on price.

• Listed as live on mainnet in the Solana Foundation status page of 2022-12-14.
• Per-account cap: 40% of the block limit since SIMD-0306.

By Solana Labs · On mainnet since 2022

Helius: the truth about local fee markets (2025)Solana Foundation: network upgrades status, 2022-12-14 (archived)SIMD-0306: Raise account CU limits

Legacy transactions list every account address inline, which caps them at about 32 accounts within 1,232 bytes. The v0 format references addresses stored in on-chain lookup tables by a 1-byte index. A table holds up to 256 addresses, and the runtime loads at most 64 accounts per transaction.

Why it mattersMore accounts per transaction let complex operations stay atomic in a single transaction.

• Enabled on mainnet 2022-10-10 at slot 154,656,004.
• The v1 format from 2026 drops lookup tables and fits 64 addresses inline.

By Solana Labs · On mainnet since 2022-10

Solana docs: versioned transactionsSolana cookbook: address lookup tablesFeature gate 3KZZ6Ks1885a on Solana Explorer

SIMD-0296 sets the larger size and SIMD-0385 delivers it through a new v1 transaction format. V1 moves compute and data-size limits into the message itself and fits up to 64 account addresses inline. Legacy and v0 transactions keep working, and apps opt in to v1.

Why it mattersBigger transactions fit ZK proofs, large multisigs and batched instructions that did not fit before.

• Activated at the start of epoch 1035, 2026-09-15 about 01:00 UTC.
• V1 senders must set compute and data limits explicitly; both default to zero.
• Program deploys sent as v1 pay about four times less in fees.

By Jacob Creech and Andrew Fitzgerald · On mainnet since 2026-09

Solana Foundation: larger transaction sizesSIMD-0296: Larger transaction sizeSolana changelog, 2026-09-18

SPL Token defines mints and token accounts and the instructions to create, move and burn tokens. Each owner's balance of a given mint sits in a token account that the program controls. Since 2026-05-13 its program address runs P-Token code, which keeps the same instructions.

Why it mattersOne shared program gives every wallet and app the same token interface, and because it runs in so many transactions, its compute cost shapes how much fits in each block.

• Launched with Solana 1.3 in 2020.
• Ran in nearly 40% of non-vote transactions (Solana Foundation, August 2025).

By Solana Labs · On mainnet since 2020

Solana Foundation: year in review 2020Solana Foundation: increase bandwidth, reduce latency (2025-08-21)Solana docs: tokens

Token-2022 adds extensions such as transfer fees, transfer hooks, confidential transfers and permanent delegates. Extensions are chosen when a mint or token account is created, and most cannot be added later. Some cannot be combined, such as a non-transferable token with transfer fees.

Why it mattersIssuers get fees, compliance checks and private balances inside the token program, without writing custom token code.

• The first extensions shipped with the v1.17 validator release, announced 2024-01-24.

By Solana Labs · On mainnet since 2024-01

Solana docs: token extensionsSolana Foundation: token extensions (2024-01-24)

P-Token replaced the code at the SPL Token program address on 2026-05-13. It keeps the existing instruction set, so wallets and apps work unchanged, and adds batch, withdraw_excess_lamports and unwrap_lamports. The rewrite removes needless data copying and memory use.

Why it mattersToken instructions run in a large share of transactions, so cheaper token operations free compute for more transactions per block.

• Transfer: 4,645 CUs on SPL Token, 76 on P-Token.
• The Solana Foundation estimates about 10% less total block space use.

By febo and Jon Cinque (Anza) · On mainnet since 2026-05

SIMD-0266: Efficient Token programSolana Foundation: optimized token programFeature gate ptokFjwyJtrw on Solana Explorer

All account state lives in account files on disk that the validator memory-maps, with an index from each address to a file and offset. The 2019 Cloudbreak design spread reads and writes across concurrent SSD threads in place of a general-purpose database. Snapshots of the account files let a new validator catch up without replaying all history.

Why it mattersParallel execution needs many accounts read and written at once, and this layout keeps storage from becoming the bottleneck.

• Cloudbreak was described in a Solana post dated 2019-07-22.
• Lattice-based account hashing (SIMD-0215) activated 2025-06-17.

By Solana Labs · On mainnet since 2020-03

Anza and Sig: a deep dive into AccountsDB (2024-08-12)Solana: Cloudbreak, horizontally scaled state (2019)SIMD-0215: Homomorphic hashing of account state

Every account must hold a minimum balance of (128 + data bytes) × lamports_per_byte, returned in full when the account is closed. Rent fee collection was switched off on 2025-03-14 by SIMD-0084. SIMD-0437 lowers lamports_per_byte from 6,960 to 696 in five feature-gated steps.

Why it mattersThe deposit keeps state from growing for free, and a lower rate makes new accounts cheaper to create.

• Step 1 to 6,333 on 2026-09-03; step 2 to 5,080 on 2026-09-11.
• Steps 3 to 5 (2,575, 1,322 and 696) are expected with Agave 4.4.
• SIMD-0438 adds a standby gate that can restore 6,960 if state grows too fast.

By Solana Labs; SIMD-0437 by Igor Durovic (Anza)

Solana Foundation: reduced rentSIMD-0437: Incrementally reduce lamports_per_byteSIMD-0084: Disable rent fees collection

An app keeps a concurrent Merkle tree whose root sits in an on-chain account while the leaf data is recorded in the ledger. Indexers read the ledger to serve the data, and each change is checked against the stored root. Compressed NFTs were the first use.

Why it mattersEach new item updates a tree in place of creating a new deposit-holding account, which cuts storage cost by orders of magnitude.

• Solana Foundation, 2023-04-06: storing 100 million compressed NFTs costs about 50 SOL, against about 1.2 million SOL uncompressed.

By Solana Labs and Metaplex · On mainnet since 2023

Solana Foundation: state compression (2023-04-06)

ZK Compression keeps account data in the ledger and only tree roots in on-chain accounts. A transaction that uses compressed accounts carries a validity proof, verified on-chain, that the data matches the root. The proof is a constant 128 bytes however many accounts it covers.

Why it mattersAccounts can be created without a rent deposit, which cuts the cost of creating token accounts by about 99%.

• Announced by Light Protocol and Helius in 2024.
• The account compression program was deployed and executable on mainnet on 2026-10-02.

By Light Protocol and Helius

ZK Compression docsHelius: ZK compression keynote, Breakpoint 2024Light Protocol on GitHub

The 2019 design used Archivers, light clients paid to store pieces of the ledger and prove it with proofs of replication; the partial code was removed in May 2020. Validators keep only recent ledger data in their own database. RPC nodes fall back to Google Bigtable for older blocks and transactions, and Triton One's Old Faithful project publishes full history as content-addressed archives, also on Filecoin.

Why it mattersKeeping deep history outside validators bounds their storage while the full record stays available.

• Archivers were described in a Solana post dated 2019-07-17.
• Archiver code was removed on 2020-05-15 (solana-labs PR 9992).
• Old Faithful's README says it is in RFC stage.

By Solana Labs (Bigtable) and Triton One (Old Faithful)

Anza docs: long term RPC transaction historyAnza docs: ledger replicationOld Faithful on GitHub

Agave is the validator client maintained by Anza, a firm started in 2024 by former Solana Labs executives and engineers. Anza forked the Solana Labs code into Agave on 2024-03-02. Jito's, BAM's and Harmonic's clients are built on Agave code.

Why it mattersIts releases set the minimum version that feature activations wait for, so its schedule paces protocol upgrades.

• Agave 4.3.0 was released 2026-09-18.
• Mainnet minimum supported version on 2026-10-02: Agave 4.2.2.
• Major releases: 2.0.0 (2024-06-21), 3.0.0 (2025-08-21), 4.0.0 (2026-05-16).

By Anza · On mainnet since 2024-03

Anza: the Solana Labs to Agave fork (2024-03-05)Agave release v4.3.0Anza: feature gate schedule and version floor

Validators running Jito's client connect to the Jito Block Engine, which simulates bundles from searchers and sends the most profitable set to the leader. A bundle holds up to five transactions that execute in order and all-or-nothing. Tips attached to bundles go to the validator and are shared with its stakers. Its nodes report the client ID JitoLabs.

Why it mattersBundles give traders ordered, atomic execution, and tips add validator and staker income beyond fees and inflation.

• Minimum bundle tip: 1,000 lamports.

By Jito Labs

Jito docs: low latency transaction sendJito-Solana on GitHub

Firedancer reimplements the whole validator in a new C codebase built for speed. It runs in a restrictive sandbox with almost no system calls. The Solana Foundation's Breakpoint recap reported it live on mainnet in December 2025, and its first public full-client mainnet release, v1.1.3, followed on 2026-08-04.

Why it mattersAn independent second client means a bug in one codebase cannot take down the whole network, and its design targets much higher throughput.

• Latest mainnet release on 2026-10-02: v26.09.5, published 2026-09-28.

By Jump Crypto · On mainnet since 2025-12

Firedancer on GitHubSolana Foundation: Breakpoint 2025 recapFiredancer release v1.1.3

Frankendancer runs Firedancer's networking stack and block-production components and uses Agave code for execution and consensus. Its version numbers encode the bundled Agave version, so v0.1204.40300 carries Agave 4.3.0.

Why it mattersIt put Firedancer's faster leader path on mainnet before the full client was ready.

• First mainnet release, v0.113.20007, on 2024-09-20.

By Jump Crypto · On mainnet since 2024-09

Firedancer on GitHubFrankendancer release v0.113.20007

The BAM client is an update to Jito's Agave-based client, and FireBAM brings the same to Frankendancer. A BAM validator receives an ordered stream from one BAM Node, must execute it in exactly that order, and reports results back. It still processes Jito bundles.

Why it mattersExecuting the order a BAM Node attested to lets outsiders check that the leader did not reorder transactions.

• Client code was open-sourced after an OtterSec audit, September 2025.
• FireBAM went live on testnet and mainnet, announced 2026-05-13.

By Jito Labs · On mainnet since 2025-09

BAM docs: overviewBAM monthly roundup, September 2025BAM: introducing FireBAM (2026-05-13)

Harmonic is registered in the Solana Foundation's client ID list as HarmonicAgave, HarmonicFiredancer and HarmonicFrankendancer. Its public Agave fork adds a Harmonic scheduler, a tip manager and DoubleZero multicast shred forwarding. Anza lists Harmonic bundles as one way to land transactions and found Harmonic validators placing transactions near the end of the slot.

Why it mattersIt is one of several competing block builders, giving validators another way to pack and price their blocks.

• HarmonicAgave and HarmonicFiredancer nodes were on mainnet on 2026-10-02.

By Harmonic

Solana Foundation: validator client ID registryHarmonic's Agave fork (salsa) on GitHubAnza: transaction landing on TPU (2026-02-11)

Every transaction pays 5,000 lamports for each signature it carries, including signatures checked by precompiles. Half of the base fee is burned and half goes to the leader. The fee is charged whether the transaction succeeds or fails.

Why it mattersA small fixed charge prices signature checks and makes spam cost something while normal use stays cheap.

• SGP-0003, which would have added a fully burned resource fee, was rejected (recorded 2026-08-28).

By Solana Labs

Solana docs: fee structureSGP-0003: Resource and inclusion fee

A transaction sets a compute-unit price in micro-lamports, and its priority fee is that price times its compute-unit limit. Leaders schedule higher bids first when transactions compete for the same accounts. Since SIMD-0096 activated on 2025-02-12, the leader keeps 100% of priority fees; before that, half was burned.

Why it mattersUrgent transactions can pay to land during congestion, and paying leaders in full removes the reason to take payments off-chain.

• Validators approved SIMD-0096 with 77.7% yes.
• Priority fee = CU price × CU limit / 1,000,000 lamports.

By Solana Labs; SIMD-0096 by Tao Zhu · On mainnet since 2022

Solana docs: fee structureSIMD-0096: Reward full priority fee to validatorHelius: Solana governance, a comprehensive analysis (2025)

Inflation began on 2021-02-10 at epoch 150 with an 8% annual rate that shrinks by 15% each year until it reaches 1.5%. New SOL goes to stake accounts in proportion to stake and their validators' vote credits. SGP-0002, accepted on 2026-08-28 with 67.001% yes, backs doubling the yearly cut to 30% through SIMD-0550, which is not yet active.

Why it mattersIssuance pays for security; the faster cut would reach the 1.5% floor in about 2.8 years in place of 5.7.

• Inflation rate 3.62% on 2026-10-02.
• SIMD-0228, a market-based emissions plan, failed with 61.39% yes in March 2025.
• SIMD-0525 raised slots per year so shorter slots leave wall-clock inflation unchanged.

By Solana Labs · On mainnet since 2021-02

Anza docs: protocol-based rewardsSGP-0002: Double disinflation rateHelius: Solana issuance and inflation schedule

SOL holders delegate to a validator through stake accounts and share its rewards minus commission. A validator earns vote credits for its votes on slots that get rooted, and each epoch's rewards are split by credits and stake. Since timely vote credits (SIMD-0033) activated on 2024-11-26, a vote landing within 2 slots earns 16 credits, one fewer for each extra slot.

Why it mattersPaying more for fast votes ended the gain from voting late to see which fork wins, which tightens consensus.

• Validators approved SIMD-0033 with 98.4% yes in April 2024.
• 440.7M of 635.1M SOL was staked on 2026-10-02.
• There is no slashing in the protocol today.

By Solana Labs; SIMD-0033 by Bryan Ischo · On mainnet since 2020

Solana docs: stakingAnza: feature gate spotlight, timely vote credits (2024-11-25)SIMD-0033: Timely vote credits

With no public mempool, searchers who need a set order go through block engines. They send bundles with tips to the Jito Block Engine, which runs auctions in 50 ms ticks and forwards the highest-paying combination to the leader. Bundles that touch different accounts compete in separate auctions. Tips go to validators and are shared with stakers.

Why it mattersAn open price for ordering routes MEV income to validators and their stakers through a public process.

• Minimum tip: 1,000 lamports.
• Jito shut its mempool service on 2024-03-08.

By Jito Labs

Jito docs: low latency transaction sendHelius: Solana MEV, an introduction

BAM Nodes receive transactions and bundles, order them inside trusted execution environments that keep them hidden until execution, and send the sequence to the leader. Nodes and validators publish attestations of the ordering and execution, so anyone can check the leader followed it. Plugins let applications add their own sequencing rules.

Why it mattersPrivate, attested ordering limits harmful MEV and makes execution within a slot predictable for traders.

• Announced 2025-07-21; the first mainnet validators joined in the last week of September 2025.
• BAM Nodes ran in Amsterdam, Frankfurt and New York in September 2025.

By Jito Labs · On mainnet since 2025-09

BAM: introducing the Block Assembly Marketplace (2025-07-21)BAM monthly roundup, September 2025BAM docs: overview

ACE would give applications millisecond-level control over ordering in their own markets, for example running cancels before taker orders. Anza's July 2025 roadmap aims protocol-enforced ACE at around 2027, alongside multiple concurrent leaders. Until then, BAM plugins are designed to let apps set sequencing rules inside BAM, outside the base protocol.

Why it mattersAnza calls market microstructure the most important problem on Solana, and ACE lets each market choose its own ordering rules.

Anza: the Internet Capital Markets roadmap (2025-07-24)BAM: introducing the Block Assembly Marketplace

Today one leader per slot decides which transactions get in and in what order. Anza's Constellation design, published 2026-03-25, adds proposers that collect transactions at the same time and attesters that timestamp what they see. The leader still assembles the block, but it must include transactions that enough attesters saw and cannot reorder them. It runs on a 50 ms cycle in front of Alpenglow.

Why it mattersSpreading inclusion across proposers in many regions removes one leader's power to censor or delay, and brings in information from around the world at once.

• Anza's July 2025 roadmap aimed multiple concurrent leaders at 2027.

By Brennan Watt and Max Resnick (Anza)

Anza: Solana Constellation (2026-03-25)Anza: the Internet Capital Markets roadmap (2025-07-24)

Substantial protocol changes, such as to consensus, networking or transaction rules, are written up as SIMDs and reviewed in public on GitHub. The author gathers feedback from core contributors on the Agave and Firedancer teams, who decide whether it is accepted, revised or withdrawn. Accepted changes usually ship behind a feature gate. Under the Solana Constitution, SIMDs pass without a vote unless enough stake elevates one to a governance vote.

Why it mattersA written spec lets independent client teams build the same behavior, which a multi-client network depends on.

• SIMD-0001, which defines the process, was created 2022-10-18 by the Solana Foundation.

By Solana Foundation

SIMD-0001: Solana proposal processHelius: Solana governance, a comprehensive analysis (2025)SGP-0001: The Solana Constitution

Consensus-changing code ships disabled behind a feature identified by a public key. Once enough stake runs a release that supports it, the key holder activates it with a transaction, and every node switches at the start of the next epoch. Anza publishes the activation order and a minimum supported version for each cluster.

Why it mattersEvery node changes rules at the same slot, so an upgrade cannot split the chain.

• Six gates were pending mainnet activation in Anza's schedule on 2026-10-02, including 200 ms slots and Alpenglow.

By Solana Labs · On mainnet since 2020

Anza: feature gate schedule and version floorHelius: Solana governance, a comprehensive analysis (2025)

From 2023 to 2025, validators voted with SPL tokens issued in proportion to stake and sent to yes, no or abstain addresses, and the results were advisory. SGP-0001 ratified the Solana Constitution and the svmgov voting program, in which stakers can override their validator's vote. A Solana Governance Proposal needs a one-third stake quorum and a two-thirds yes majority over a three-epoch vote.

Why it mattersVotes record stake-weighted consent for economic and consensus changes before client teams ship them.

• SGP-0001 passed with 86% and SGP-0002 with 67.001%; SGP-0003 failed (recorded 2026-08-28).
• SIMD-0228 failed in March 2025 with 61.39% yes and 74.3% turnout.

By Validators and stakers; svmgov by Turbine, ExoTech, Jito and the Solana Foundation · On mainnet since 2020-12

SGP-0001: The Solana ConstitutionHelius: Solana governance, a comprehensive analysis (2025)Solana governance proposals repository