Solana Deep Dive: Proof of History, Turbine, Gulf Stream and Why It's Fast

Most coverage frames Solana as "fast Ethereum." That framing obscures the actual design decision. Solana is a monolithic chain that treats hardware as a scaling lever rather than an externality to minimise. Every subsystem — clock, consensus, propagation, execution, storage — was co-designed to saturate modern server hardware: many-core CPUs, NVMe SSDs, and 1 Gbps+ network links. The result is an architecture that cannot be understood by examining any single component in isolation. Pull one piece out, and the performance story collapses.

Anatoly Yakovenko's background at Qualcomm, designing CDMA wireless systems, is not incidental colour. Wireless protocols must establish precise time synchronisation across distributed nodes under adversarial radio conditions. The core Solana insight, articulated in the 2017 whitepaper, was: if you can establish a trustless ordering of events before consensus, you can pipeline every other operation — signature verification, execution, propagation, state writes — in parallel. That single idea, Proof of History, became the foundation on which seven other subsystems were layered.

This bet was explicitly against the modular thesis that Ethereum adopted with its rollup-centric roadmap. By March 2026, both approaches have delivered real results. Ethereum's L2 ecosystem processes significant aggregate volume; Solana's monolithic L1 processes more individual transactions than any other base layer, with non-vote throughput consistently between ~800 and ~2,000 TPS and total throughput (including consensus votes) between ~2,500 and ~5,000 TPS. Neither number approaches the frequently cited 65,000 TPS figure, a theoretical maximum from 2020 testnet conditions that has never materialised on mainnet. A practitioner always separates non-vote from vote transactions — roughly 60–80% of all Solana transactions are validator vote messages, which is consensus overhead, not user activity.

The trade-off is real and worth stating directly: Solana requires validator hardware that costs ~$1,000–3,000 per month to operate (256 GB+ RAM, 24+ CPU cores, 2 TB+ NVMe, 1 Gbps symmetric bandwidth). Ethereum beacon chain validators run on a Raspberry Pi. This is not a bug in Solana's design — it is the design. Whether that trade-off is acceptable depends on what you optimise for, and the honest answer is that reasonable engineers disagree.

Proof of History is the most commonly misunderstood component of the Solana stack. It is not a consensus mechanism. It does not determine which fork is canonical. It is a cryptographic clock — a sequential computation that produces a verifiable record of elapsed time between events.

The mechanism is recursive SHA-256 hashing. Each hash takes the output of the previous hash as its input, forming a chain where every entry proves that a specific amount of sequential computation occurred before it could have been produced. Because SHA-256 cannot be meaningfully parallelised (each step depends on the prior output), producing the sequence takes a deterministic amount of real time given a known processor speed. Solana validators target approximately 400,000 hashes per second to maintain the PoH sequence, with each batch of hashes forming a tick.

When a transaction arrives, its hash is "mixed into" the PoH stream — inserted between ticks. This creates a cryptographic proof that the transaction existed at a specific point in the sequence, which maps to a specific point in time. The resulting data structure is a time-ordered log of events that requires no external clock and no consensus to produce.

Here is the property that makes PoH operationally powerful: generation is sequential, but verification is embarrassingly parallel. A verifier can split the hash chain into segments and check each segment on a separate core simultaneously, because each segment's start and end hashes are known. This asymmetry — slow to produce, fast to verify — is the defining characteristic of a verifiable delay function (VDF), and it means the rest of the network can cheaply confirm the leader's claimed ordering.

The hardware assumption underlying PoH deserves scrutiny. Its VDF property depends on commodity CPUs being close to the SHA-256 performance frontier. If an entity produced a custom SHA-256 ASIC with significantly higher single-threaded throughput, they could precompute PoH sequences faster than real time, potentially manipulating the leader schedule or producing dishonest time proofs. As of 2026, this attack remains theoretical — Bitcoin ASICs optimise for parallel hashing, not single-threaded sequential chains — but it is a structural assumption worth monitoring, not an impossibility.

Traditional Practical Byzantine Fault Tolerance (PBFT) requires O(n²) message exchanges per consensus round because every validator must communicate with every other validator to agree on ordering and timing. This communication overhead is why classical BFT systems cap at a few dozen nodes.

Tower BFT is Solana's PBFT-derivative consensus protocol. Its key innovation is using PoH as a shared, trustless clock source to replace most of the inter-validator messaging that classical BFT demands. Instead of exchanging timestamps via gossip, validators can independently verify the passage of time by checking the PoH sequence. This reduces the communication complexity to near-linear.

Validators participate in Tower BFT by submitting votes on PoH slots. Each vote carries an exponentially increasing lockout period — a commitment that the validator will not vote for a conflicting fork. A validator's first vote might lock them for 2 slots; each subsequent confirmatory vote on the same fork doubles the lockout, to 4, 8, 16 slots, and so on. After 32 consecutive votes on a fork, the lockout becomes so large (~4 billion slots, roughly 54 years) that the vote is effectively irreversible. This creates a mechanism where switching forks becomes exponentially more expensive the deeper a validator has committed, providing finality guarantees without the explicit two-phase commit of protocols like Casper FFG.

The practical consequence is that Solana achieves optimistic confirmation in roughly 400 ms (a single slot) and full finality in approximately 12–13 seconds (32 confirmations). Compared to Tendermint's instant finality per block (but with single-slot latency of several seconds and limited validator sets) or Ethereum's ~13-minute finality epochs, Tower BFT occupies a distinct point in the design space: fast optimistic confirmation, moderate finality latency, and support for a larger validator set than classical BFT.

The failure mode that matters most: Tower BFT inherits the standard BFT requirement that more than two-thirds of stake must be honest and online for both liveness and safety. If more than one-third of stake goes offline, the network halts — which is exactly what happened during several of Solana's historical outages.

In Bitcoin and Ethereum, unconfirmed transactions sit in a mempool — a globally gossiped holding area where every node maintains its own view of pending transactions. This architecture creates two problems: gossip overhead scales poorly, and the mempool becomes a transparent staging ground for MEV extraction.

Gulf Stream eliminates the traditional mempool entirely. Because the PoH-derived leader schedule is deterministic and known an entire epoch in advance (~2–3 days), clients and RPC nodes can forward transactions directly to the current leader and the next several anticipated leaders before their slots arrive. By the time a leader's slot begins, its Transaction Processing Unit (TPU) already holds a queue of pending transactions ready for execution.

Transactions carry a TTL of approximately 60–90 seconds, enforced via recent blockhash expiry. Each transaction references a recent blockhash; if the referenced blockhash ages out (~150 slots), the transaction becomes invalid and is dropped. This prevents stale transaction accumulation without requiring garbage collection of a global mempool.

The implication most people get wrong: "no mempool" does not mean "no MEV." Transactions still queue at the leader's TPU ingress buffers, creating a de facto mini-mempool at each leader. The leader (or infrastructure with access to the leader's transaction flow) can observe, reorder, or insert transactions. Jito Labs recognised this reality early and built an out-of-protocol block engine — a service where searchers submit transaction bundles with tips, and validators running the Jito-modified client include these bundles preferentially. By March 2026, the Jito client runs on validators controlling over ~90% of staked SOL, making it the de facto standard for Solana block production.

Since the adoption of the QUIC transport protocol in 2023, replacing the original UDP-based transaction ingestion, Gulf Stream also incorporates stake-weighted Quality of Service (QoS). Validators and staked connections receive proportionally more bandwidth for submitting transactions to the leader's TPU. This was arguably the single most important reliability improvement in Solana's history — under the old UDP model, spam bots could flood leaders with cheap transactions and crash them, which was a root cause of multiple congestion events in 2022.

Naive block broadcasting — where a leader sends the full block to every validator — requires O(n) bandwidth at the leader node. For a network with ~1,900 validators and blocks approaching megabytes in size, this quickly exceeds any single node's upload capacity.

Turbine solves this with a BitTorrent-inspired fanout tree. The leader breaks each block into shreds — data units of 1,228 bytes each, sized to fit within a single UDP/QUIC packet. These shreds are then erasure-coded using a Reed-Solomon scheme: for each set of 32 data shreds, 32 parity (coding) shreds are generated. Any 32 of the 64 total shreds suffice to reconstruct the original data, meaning a validator needs only ~67% of the shreds in each set to recover the full block.

Shreds are propagated through a hierarchy of neighbourhoods, each containing roughly ~200 validators. The leader sends shreds to the first neighbourhood. Validators in that neighbourhood retransmit to the next layer, and so on. This reduces per-node bandwidth requirements from O(n) to O(log n), since the tree depth is log₂₀₀(n) — for 1,900 validators, that is approximately 2 layers deep.

The neighbourhood structure introduces a subtlety that rarely appears in popular coverage: validators are assigned to layers based on stake weight, with higher-stake validators placed closer to the root of the tree. This means large validators systematically receive shreds earlier than smaller ones. The latency difference is small in absolute terms (milliseconds) but meaningful for MEV extraction. A validator two layers deep receives block data one retransmission hop later than a root-layer validator. In a market where arbitrage opportunities close within single slots, this creates an implicit advantage for well-staked nodes — a centralisation pressure baked into the protocol's propagation mechanics.

Restructuring of the Turbine tree happens each epoch. The tree topology is derived from the leader schedule and stake distribution, making it deterministic but variable over time.

Ethereum's EVM executes transactions sequentially because a transaction's full state access pattern is unknown until runtime — a CALL instruction might touch any storage slot. Solana sidesteps this limitation with a fundamental design requirement: every transaction must declare the complete set of accounts it will read from and write to in its header, before execution begins.

Sealevel, Solana's parallel runtime, uses these declared account sets to construct a dependency graph. Transactions that touch entirely disjoint sets of accounts can execute simultaneously across different CPU cores. Transactions that share read-only access to the same account can also parallelise (multiple readers, no writers). Only transactions that write to the same account must serialise.

The runtime executes programs compiled to SBF (Solana Bytecode Format), an eBPF-derived instruction set. Programs are written primarily in Rust (with some C support), compiled to BPF bytecode, and executed in a sandboxed virtual machine (rbpf). The account model is fundamentally different from Ethereum's: programs are stateless code deployed to specific addresses, and all state lives in separate account data structures. A single program serves all users — unlike Ethereum, where each deployed contract owns its storage. This separation is what enables Sealevel's account-level parallelism.

The practical limit of Sealevel's parallelism is hot account contention. When a popular DEX pool or an oracle price account is written to by a large percentage of transactions in a block, those transactions serialise against each other regardless of how many CPU cores are available. During high-activity periods — a memecoin launch, a liquidation cascade — a single hot account can become the throughput bottleneck for the entire network. This is not a theoretical concern; it is the normal operating condition for high-demand applications and the motivation behind local fee markets, which price congestion at the per-account level rather than globally.

Solana's Transaction Processing Unit (TPU) operates as a four-stage hardware pipeline, analogous to instruction pipelining in modern CPUs. The stages are: data fetch (receiving transaction packets via QUIC), signature verification (offloaded to GPU for parallel Ed25519 verification), banking (CPU execution of transactions via Sealevel), and writing (committing state changes to the accounts database). Each stage operates continuously, with the output of one feeding the input of the next. While the banking stage processes batch N, the sigverify stage is already processing batch N+1, and the fetch stage is ingesting batch N+2.

Cloudbreak is Solana's custom accounts database, designed for concurrent reads and writes across NVMe SSDs. Accounts are indexed by public key and memory-mapped, allowing the operating system's virtual memory subsystem to manage page caching. The design assumes high-IOPS storage — a traditional spinning disk would be a fatal bottleneck. Cloudbreak supports horizontal scaling across multiple SSDs and is optimised for the access pattern that Sealevel creates: many concurrent reads and a smaller number of concurrent writes, all to known addresses.

This is where the hardware requirement discussion becomes concrete. Solana validators in 2026 need ~256 GB of RAM because the active accounts dataset (hundreds of millions of accounts) must be largely resident in memory for the banking stage to maintain slot-time execution. They need 24+ cores because Sealevel parallelises across all available cores. They need 1 Gbps+ bandwidth because Turbine propagates shreds continuously at high throughput. And they need high-IOPS NVMe because Cloudbreak memory-maps the accounts store.

For anyone tracking SOL staking returns against these costs, a validator running on appropriate bare-metal hardware faces ~$1,000–3,000 per month in infrastructure costs plus ~1 SOL per day in vote transaction fees. You can model expected returns using our staking calculator with current inflation parameters (~5.4% annualised, decreasing 15% per year toward a 1.5% floor) and Jito MEV tip estimates.

Solana's original fee model was simple: 5,000 lamports (0.000005 SOL) per signature, regardless of computational complexity. This was intentionally cheap, but it created a problem — when network demand spiked, there was no price signal to differentiate high-value transactions from spam.

Priority fees, introduced progressively from 2022 onward, added a second fee dimension: users specify a price in microlamports per compute unit (CU). Each transaction has a compute budget — 200,000 CU by default, up to 1,400,000 CU maximum — and the total block is capped at 48,000,000 CU. Higher priority fee bids receive preferential inclusion by the leader's scheduler.

The more sophisticated evolution is local fee markets, which price congestion at the per-account level. The scheduler tracks write-lock contention on individual accounts. If a specific account — say, a heavily traded Raydium pool — is experiencing high contention, priority fees for transactions touching that account rise without affecting transactions touching unrelated accounts. This prevents the scenario where a memecoin launch makes a simple SOL transfer expensive, which was a real problem in 2022–2023.

Compared to Ethereum's EIP-1559 base fee mechanism, Solana's approach is more granular (per-account rather than per-block) but less formalised (there is no algorithmic base fee that adjusts automatically — priority fees are set by users and filtered by the scheduler). The local fee market implementation continues to evolve, and its effectiveness depends heavily on the scheduler's contention detection logic.

For active traders, exchanges like MEXC support Solana deposits and withdrawals at minimal fees, taking advantage of the low base transaction cost that persists for non-congested accounts.

The "Solana has no MEV" narrative died sometime in 2022 and should not be repeated. What Solana lacks is a globally visible mempool — but MEV extraction requires only the ability to observe and reorder transactions at the point of block construction, and Solana's architecture provides exactly that opportunity at the leader level.

Jito Labs built the infrastructure that formalised Solana MEV. The Jito-Solana validator client includes a block engine — an off-chain service where searchers submit transaction bundles (ordered sets of transactions) along with tips (SOL payments to the validator). The block engine simulates bundles, selects profitable non-conflicting ones, and passes them to the validator for inclusion. Validators earn tips on top of standard rewards and priority fees; by cumulative figures through early 2026, Jito tips have exceeded ~5M SOL.

With roughly 90% of staked SOL running the Jito-modified client, this infrastructure is not an edge case — it is the primary pathway for Solana block construction. The implications are significant. First, it concentrates block construction intelligence in an off-chain service operated by a single entity (Jito Labs), creating a centralisation point analogous to Flashbots' MEV-Boost relay dominance on Ethereum. Second, it creates a two-tier transaction system: bundled transactions with tips receive deterministic ordering and atomicity guarantees, while unbundled transactions are subject to the scheduler's default ordering. Third, Jito MEV tips (~1–2% additional APY on top of inflation rewards) have become a meaningful component of validator economics, particularly for validators that offer liquid staking tokens like jitoSOL.

The philosophical difference from Ethereum's approach is worth noting. Ethereum has pursued proposer-builder separation (PBS) as a protocol-level mechanism, with MEV-Boost as an intermediate step. Solana's MEV infrastructure remains entirely out-of-protocol — a client modification, not a consensus change. This gives Solana more flexibility (Jito can iterate quickly) but less formal governance over the MEV supply chain.

As of early 2026, the Solana network has approximately ~1,900 validators and ~2,700+ RPC nodes. Total staked SOL sits around ~380M out of ~590M circulating supply, a staking ratio of roughly ~65%. The Nakamoto coefficient — the minimum number of validators that could collude to halt the network — ranges from ~19 to ~31 depending on methodology.

The inflation schedule is deterministic: it started at 8% and decreases by 15% per year, heading toward a 1.5% terminal floor. In early 2026, the effective inflation rate is approximately ~5.4%. Nominal staking yield lands around ~6.5–7.5% APY before accounting for MEV tips, which add approximately ~1–2% for validators running Jito. Commission rates vary, but the typical range for major delegation-receiving validators is 5–10%.

Validator costs are non-trivial. Infrastructure runs ~$1,000–3,000 per month for appropriate bare-metal hardware, and vote transaction fees cost roughly ~1 SOL per day (~365 SOL per year), a significant fixed expense that creates a minimum economic threshold for viable operation. A validator without substantial delegated stake will operate at a loss. There is no protocol-enforced minimum stake, but economic viability typically requires attracting at least several thousand SOL in delegations.

Liquid staking has grown substantially, with protocols like Marinade (mSOL), Jito (jitoSOL), and BlazeStake (bSOL) collectively holding a significant share of staked SOL. These tokens enable stakers to earn yield while maintaining DeFi composability — using staked positions as collateral in lending protocols or liquidity pools. For UK-based holders, both staking rewards and any gains on liquid staking tokens are taxable events under HMRC rules. Tracking cost basis across these instruments is non-trivial, and tools like Koinly handle Solana staking and DeFi transactions with native SPL token support.

Stake concentration remains an active concern. The top ~20 validators by stake control enough to theoretically halt the chain, and liquid staking protocols' delegation strategies materially influence this distribution. The community has debated stake-weighted governance and algorithmic delegation strategies, but stake concentration has not meaningfully decreased since 2024.

Solana operated for its first four years as a single-client network. Every validator ran the same codebase (originally Solana Labs, now maintained as Agave by Anza). This meant a single bug could — and repeatedly did — halt the entire network. The Feb 2023 outage lasted ~20 hours; the Feb 2024 outage required a coordinated cluster restart. Both traced to bugs in the single client.

Firedancer, developed by Jump Crypto (now Jump Trading's engineering arm), is not a port of the Agave client to a different language. It is a ground-up reimplementation of the Solana validator in C, using a tile-based architecture inspired by high-frequency trading systems. Each functional component — networking, QUIC handling, signature verification, banking stage, shred processing — runs in an isolated "tile" pinned to a dedicated CPU core. Tiles communicate via zero-copy shared memory rings, eliminating the overhead of kernel-mediated IPC. This architecture is what produces the headline ~1M+ TPS figures in isolated benchmarks.

The Frankendancer hybrid — using Firedancer's networking and shred handling with Agave's execution engine — has been running on mainnet validators since late 2024. The full Firedancer client entered progressive mainnet rollout through 2025 and continues deployment into 2026. The strategic value is not primarily speed — mainnet throughput is bottlenecked by consensus and network propagation, not single-node execution. The strategic value is that if an Agave-specific bug triggers a crash, Firedancer validators continue producing and voting on blocks, maintaining network liveness.

Client diversity on Solana remains behind Ethereum's (which has four major execution clients and five consensus clients), but the trajectory is the right one. The validator community's adoption of Firedancer will be the single most important factor in whether Solana's outage history remains a historical footnote or a recurring operational reality.

Honesty about failure modes is what separates useful technical analysis from advocacy. Solana has experienced multiple significant outages, and the root causes illuminate architectural constraints that remain relevant even as mitigations improve.

The September 2021 outage (17 hours) was caused by resource exhaustion during a Raydium IDO. Bots flooded the network with transactions, overwhelming the leader's ability to process them. The scheduler had no mechanism to prioritise legitimate transactions over spam, and the forwarding pipeline (Gulf Stream, pre-QUIC) had no rate limiting. Validators' memory usage spiralled, and the network halted. The root cause was architectural: Gulf Stream's mempool-less design assumed transaction volume would be self-limiting, which proved wrong under adversarial conditions.

The February 2023 outage (~20 hours) stemmed from a bug in the consensus layer that caused validators to diverge on their view of the ledger state. A cluster restart was required, meaning validators coordinated off-chain to agree on a snapshot and restart from a common point. This revealed the fragility of a single-client network — every validator hit the same bug simultaneously.

The February 2024 outage (~5 hours) again required a cluster restart, with the root cause traced to a bug in the banking stage of the Agave client.

Engineering responses to these events have been substantial. The QUIC migration (2023) replaced UDP with a connection-oriented protocol that enables per-connection rate limiting and stake-weighted bandwidth allocation. Local fee markets (2023–2024) introduced per-account congestion pricing. Scheduler improvements (ongoing since v1.17+) added more sophisticated contention detection and transaction ordering. These changes have materially improved reliability — the period from mid-2024 through early 2026 has been Solana's most stable operational stretch.

Design limitations that remain structurally relevant:

Transaction size constraint. Solana transactions are capped at 1,232 bytes — sized to fit in a single IPv6 packet minus headers. This limits the number of accounts a transaction can reference and the amount of instruction data it can carry. Address Lookup Tables (ALTs) mitigate this by compressing 32-byte public keys into 1-byte indices, allowing up to 256 account references, but complex cross-program invocations still strain the limit.

Hot account serialisation. Sealevel's parallelism degrades linearly with the number of transactions writing to the same account. Popular DeFi pools, oracle price accounts, and token mints become serialisation bottlenecks under load. No amount of CPU cores helps when the dependency graph funnels through a single write-locked account.

Clock drift. PoH time and wall-clock time can diverge. Slot skip rates of ~3–5% mean that the expected 400 ms slot time is an average, not a guarantee. Applications relying on Solana's clock for time-sensitive operations (liquidations, oracle staleness checks) must account for this drift.

Validator restart coordination. When the network halts, recovery requires off-chain social coordination to select a restart slot and distribute a snapshot. There is no automated recovery mechanism. This process has improved with practice but remains a manual, trust-dependent operation.

State growth. Solana's accounts database grows continuously. The rent mechanism (requiring a minimum SOL balance per account) provides some pressure against state bloat, but the long-term storage burden on validators increases hardware requirements over time.

If you have read this far, you understand why attributing Solana's performance to "Proof of History" or "parallel execution" misses the point. PoH is useless without Tower BFT using it as a clock. Tower BFT's reduced messaging is meaningless without Gulf Stream pre-forwarding transactions to a known leader. Gulf Stream's pre-forwarding fails without a deterministic leader schedule derived from PoH epochs. Sealevel's parallelism produces nothing without Cloudbreak's concurrent I/O feeding it account data. Turbine's propagation tree is irrelevant without the TPU pipeline producing blocks fast enough to fill it.

The dependency graph is a cycle, not a tree. Each subsystem's performance assumptions are met by the properties of the others. This is what makes Solana fundamentally different from chains that bolt on a faster execution engine or a better consensus algorithm and expect proportional throughput gains. The speed is emergent from the co-design — and so are the failure modes. When the scheduler chokes, everything downstream chokes. When Turbine propagation lags, Tower BFT votes arrive late and the leader loses the slot. The system either works as a unit or degrades as a unit.

This co-design also explains why Solana is difficult to replicate. SVM forks (Eclipse, Neon, and others) take pieces of the Solana execution environment and deploy them in different contexts — as Ethereum L2s, as alternative L1 components — but they inherit only Sealevel's parallelism, not the full subsystem synergy. Whether those projects deliver comparable performance will test whether the co-design thesis is correct or whether the execution engine alone accounts for most of the value.

For those securing SOL holdings across this ecosystem, a hardware wallet like Ledger with Solana app support remains the most robust custody approach, particularly given the frequency of wallet-draining exploits targeting hot wallets connected to Solana DeFi.

Primary sources and live data to validate every claim in this article:

• ›Solana Explorer (explorer.solana.com): Real-time TPS, slot times, epoch info, validator count, and the vote/non-vote transaction breakdown. Check the "Cluster Stats" panel for current non-vote TPS.
• ›Validators.app (validators.app): Nakamoto coefficient tracker, stake distribution heatmaps, validator performance scores, skip rates by validator.
• ›Jito Explorer (explorer.jito.wtf): MEV tip tracking, bundle statistics, Jito client adoption percentage, cumulative tip totals.
• ›Solana Beach (solanabeach.io): Epoch-level validator performance, stake concentration metrics, inflation rate tracking.
• ›Solana Documentation (docs.solana.com): Canonical reference for PoH mechanics, Tower BFT voting, Turbine parameters, compute budget limits, and fee market specifications.
• ›Firedancer GitHub (github.com/firedancer-io/firedancer): Source code, architecture documentation, and the tile-based design specification.
• ›Anatoly Yakovenko's original PoH whitepaper (solana.com/solana-whitepaper.pdf): The 2017 paper that describes the cryptographic clock concept.
• ›Helius RPC Documentation (docs.helius.dev): Practical guidance on priority fees, compute unit estimation, and transaction optimisation for developers.
• ›Solana Foundation Validator Health Report (solana.org/validators): Periodic reports on network health, client diversity percentages, and hardware requirement updates.
• ›Stakewiz (stakewiz.com): Independent validator comparison tool with commission rates, APY estimates, and Jito MEV tip distributions.

Cross-reference the non-vote TPS on Solana Explorer against the claims in this article. Check the Nakamoto coefficient on Validators.app against the range given here. Verify the inflation rate on Solana Beach. Every figure in this piece is designed to be auditable against live on-chain data — and if any number has drifted by the time you read this, the sources above will tell you by how much.