Solana: Speed Philosophy

Concepts: What Is Solana, Proof of History, Architecture, Programming Model, SPL Tokens, Ecosystem, Issues

:::section{mins=2} What Is Solana :::

:::lead If every [[gloss:blockchain|blockchain]] works in roughly the same way, why is Solana an order of magnitude faster than [[gloss:ethereum|Ethereum]]? The answer is one decision: it removed a step the others treated as mandatory. :::

:::p{html} When Anatoly Yakovenko was sketching out Solana in 2017, he was a network engineer at Qualcomm and looked at blockchains through that lens: he could not understand why all those [[gloss:node|nodes]] constantly polled each other just to figure out what order [[gloss:transaction|transactions]] arrived in, when timekeeping has been a solved problem in computer science for decades — we have atomic clocks. From that observation came Solana's central idea: instead of agreeing on order through voting, use time itself as a cryptographic primitive. Every [[gloss:transaction|transaction]] gets a provable position in a continuous chain of [[gloss:hash|hashes]], and order becomes a property of the message rather than the result of a negotiation between [[gloss:node|nodes]]. :::

:::p{html} That move gave Solana a speed neither [[gloss:bitcoin|Bitcoin]] nor [[gloss:ethereum|Ethereum]] could match. A [[gloss:block|block]] is produced every ~400 milliseconds — about 30 times faster than [[gloss:ethereum|Ethereum]]. A [[gloss:transaction|transaction]] costs around one tenth of a cent. In live operation the network processes 2-4 thousand real [[gloss:transaction|transactions]] per second, against [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]]'s 15-30. In tests with the new Firedancer client the network has shown more than a million TPS, although nothing close to that level of demand is hitting production yet. :::

:::p{html} Economically, Solana sits in the top ten cryptocurrencies by market cap: as of April 2026, SOL trades around $82-85 and the market cap is roughly $47 billion. The network is supported by about 750-800 [[gloss:validator|validators]]. Ecosystem [[gloss:tvl|TVL]] is $5.5-6 billion; it sat near $9 billion earlier in the year, but the Drift Protocol exploit on April 1, 2026 removed about $285 million in value and tightened liquidity noticeably. :::

:::p{html} Behind that speed lies a fundamental architectural choice that runs opposite to [[gloss:ethereum|Ethereum]]'s → 2.2 [[gloss:ethereum|Ethereum]]. Since 2020, [[gloss:ethereum|Ethereum]] has pursued a [[gloss:rollup|rollup]]-centric strategy — a thin, slow [[gloss:l1|L1]] as a security base, with speed and cheapness pushed onto [[gloss:layer 2|L2s]]. By 2026 this strategy is going through a public revision (see → 2.2 §7 Roadmap): [[gloss:l1|L1]] itself has started to scale, and many decisions that were planned for [[gloss:layer 2|L2]] are coming back to the base layer. Solana made the opposite bet from the very beginning: everything on a single layer, throughput coming from more powerful hardware on the [[gloss:validator|validator]] side, with no division into tiers. These are not just different architectures. They are two different philosophies of what a [[gloss:blockchain|blockchain]] network is supposed to be. :::

:::callout{icon=💡} Picture a city's transportation system. [[gloss:ethereum|Ethereum]] is a classic metro: heavy infrastructure, tens of thousands of employees monitoring every section of track, trains run every 12 minutes, a ticket costs $2-10, but the system has operated for 50 years without a single day of downtime. Solana is a magnetic levitation train (maglev): the train flies above the rails at 400 km/h, a ticket costs $0.001, but launching the system requires high-end stations costing millions of dollars, and sometimes technical failures happen — then all passengers wait for hours. Both approaches work, but for different tasks. :::

:::keypoints{label="Key Points"}

  • Solana grew out of an engineer's frustration: Anatoly Yakovenko, a former Qualcomm networking specialist, could not understand why [[gloss:node|nodes]] have to negotiate [[gloss:transaction|transaction]] order if timekeeping is already a solved problem in computer science
  • The speed PoH delivers: a [[gloss:block|block]] every 400 milliseconds, 2-4 thousand real [[gloss:transaction|transactions]] per second, a fee of one tenth of a cent — two orders of magnitude cheaper, and noticeably faster, than [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]]
  • Solana made the opposite bet: instead of splitting into [[gloss:l1|L1]] + [[gloss:layer 2|L2]] like [[gloss:ethereum|Ethereum]], everything happens on a single layer, and speed grows by raising the hardware bar for [[gloss:validator|validators]]
  • Solana sits in the top ten by market cap (~$47B, rank #7), but on [[gloss:tvl|TVL]] and [[gloss:validator|validator]] count it trails [[gloss:ethereum|Ethereum]] by orders of magnitude — and that gap is the sharpest trade-off of the monolithic design :::

:::details{badge=Advanced title="Solana Timeline: From Boom to Crash to Revival"} :::p{html} Yakovenko published the Proof of History [[gloss:whitepaper|whitepaper]] in 2017, and the [[gloss:mainnet|Mainnet]] Beta went live in March 2020. During 2021, SOL rocketed from $1 to $260 as the ecosystem attracted billions in capital and new projects. Then came November 2022: the collapse of FTX, whose parent company Alameda Research held roughly 10% of the SOL supply, crashed the token by 97% to $8. Many wrote Solana off, but the ecosystem survived on the strength of its organic developer community, which kept shipping through the bear market. :::

:::p{html} Through 2023 and 2024, Solana staged a comeback: Jump Crypto pushed Firedancer toward [[gloss:mainnet|mainnet]], the memecoin wave brought retail activity back, and DePIN projects like Helium and Render chose Solana as their settlement layer. By 2025, the network had stabilized and regained market confidence. ::: :::

:::details{badge=Advanced title="Monolithic Philosophy vs Modularity"} :::p{html} This is a fundamental industry debate. [[gloss:ethereum|Ethereum]] bets on modularity: execution moves to [[gloss:layer 2|L2]], settlement stays on [[gloss:l1|L1]], and data lives in [[gloss:blob|blob]] [[gloss:transaction|transactions]] or on dedicated networks like Celestia. Solana makes the opposite bet: everything on one layer, with speed coming from more powerful hardware. Both models work and both have proven viable in practice. [[gloss:ethereum|Ethereum]] has the edge on security and [[gloss:decentralization|decentralization]]; Solana wins on user experience and [[gloss:transaction|transaction]] cost. :::

:::p{html} The trade-offs are concrete. Modular [[gloss:ethereum|Ethereum]] lets independent [[gloss:layer 2|L2]] teams innovate on execution without risking [[gloss:l1|L1]] security, but introduces bridging friction, liquidity fragmentation across dozens of [[gloss:layer 2|L2s]], and a more complex developer experience. Monolithic Solana offers a single unified network state where any application can call any other in a single [[gloss:transaction|transaction]] (this is what people mean by composability), instant [[gloss:finality|finality]], and a uniform user experience — but a bug in core [[gloss:consensus|consensus]] code can halt the entire network, and the hardware bar limits who can validate. :::

:::p{html} Neither approach has "won." The open question is whether Solana can keep raising the real performance ceiling — through faster [[gloss:validator|validator]] clients and parallel [[gloss:transaction|transaction]] execution — fast enough to outpace demand, or whether [[gloss:ethereum|Ethereum]]'s [[gloss:layer 2|L2]] roadmap can deliver an equivalent user experience while preserving low [[gloss:validator|validator]] requirements. Most serious analysts expect the two models to coexist: Solana for applications with tight latency requirements, [[gloss:ethereum|Ethereum]] and its [[gloss:layer 2|L2s]] for applications where long-term [[gloss:decentralization|decentralization]] matters more. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-2-3-s1 correct=1 explanation="Correct. Solana's philosophy is to keep everything on one monolithic chain and squeeze maximum throughput from [[gloss:validator|validator]] hardware — through parallel execution and a faster client codebase — rather than splitting work across [[gloss:layer 2|L2s]] or shards as [[gloss:ethereum|Ethereum]]'s modular roadmap does."} What distinguishes Solana's architectural approach from [[gloss:ethereum|Ethereum]]'s?

  • Solana uses sharding to split [[gloss:transaction|transactions]] across many chains
  • Solana processes everything on a single monolithic layer, scaling through hardware
  • Solana offloads execution to [[gloss:layer 2|L2]] [[gloss:rollup|rollups]] like [[gloss:ethereum|Ethereum]] plans to
  • Solana uses [[gloss:proof of work|Proof of Work]] like [[gloss:bitcoin|Bitcoin]] for maximum security :::

:::section{mins=3} Proof of History :::

:::lead PoH is a cryptographic clock that ticks on its own, with the order of every [[gloss:transaction|transaction]] baked into it. Sounds like magic, but in practice it's a stream of about two million [[gloss:hash|SHA-256]] [[gloss:hash|hashes]] per second, each one depending on the previous. :::

:::p{html} To see what Solana changed, you first have to see the problem every other [[gloss:blockchain|blockchain]] solves the same way. When a [[gloss:transaction|transaction]] goes out into the network, it reaches different [[gloss:node|nodes]] at different times — faster on some, slower on others, depending on distance and link quality. The [[gloss:node|nodes]] are then left with a question: in what order should these [[gloss:transaction|transactions]] be counted? Whose [[gloss:transaction|transaction]] was first? [[gloss:bitcoin|Bitcoin]] and [[gloss:ethereum|Ethereum]] solve this through voting — [[gloss:node|nodes]] exchange messages with each other, agree on an order, and only then [[gloss:move|move]] forward. It works, but it is slow: in [[gloss:ethereum|Ethereum]] a single round of agreement takes around 12 seconds per [[gloss:block|block]], in [[gloss:bitcoin|Bitcoin]] around 10 minutes. Messages between [[gloss:node|nodes]] in different parts of the world take tens of milliseconds, and several rounds are needed. :::

:::p{html} Solana removed this step entirely. PoH creates a shared clock that every [[gloss:node|node]] consults independently. Technically it is a sequence of [[gloss:hash|SHA-256]] [[gloss:hash|hashes]]: [gloss:hash|hash] is some starting seed, and [gloss:hash|hash] is SHA256 of [gloss:hash|hash]. The chain can only be computed strictly sequentially — every next [[gloss:hash|hash]] depends on the previous one, you cannot skip ahead. But verifying a finished chain can be done in parallel and very quickly. Solana takes advantage of exactly this: the leader [[gloss:validator|validator]] spins the chain at roughly one [[gloss:hash|hash]] per 500 nanoseconds (about two million [[gloss:hash|hashes]] per second) and inserts each [[gloss:transaction|transaction]] between specific [[gloss:hash|hashes]]. When a [[gloss:node|node]] receives a [[gloss:transaction|transaction]], it sees the [[gloss:hash|hash]] mark and the position in the chain. No negotiation needed. :::

:::p{html} A subtlety that often gets confused: PoH is not [[gloss:consensus|consensus]]. It is just an ordering mechanism. [[gloss:consensus|Consensus]] — agreement on which [[gloss:transaction|transactions]] are valid and made it into the [[gloss:block|block]] — is handled by a separate component, Tower BFT → 1.3 BFT [[gloss:consensus|Consensus]], a modified version of classical PBFT (Practical [[gloss:byzantine fault tolerance|Byzantine Fault Tolerance]]). PoH says "this is the order in which everything happened," Tower BFT says "and we all agree that this is true." The two mechanisms work as a pair: one sets the order, the other certifies the truth. :::

:::p{html} Important context as of April 2026: PoH and Tower BFT are running in production, but their days are numbered. In September 2025 the Solana community approved the Alpenglow upgrade by an overwhelming majority (98% in favor) — the largest [[gloss:consensus|consensus]] rebuild in the network's history. Alpenglow replaces both PoH and Tower BFT: instead of a shared cryptographic clock, every [[gloss:validator|validator]] will run a local timer; instead of Tower BFT's 32-level voting, a new protocol called Votor finalizes a [[gloss:block|block]] in one or two rounds. Network [[gloss:finality|finality]] drops from the current ~13 seconds to 100-150 milliseconds. [[gloss:mainnet|Mainnet]] launch is expected at the end of 2026; see → § 3 "Firedancer and Alpenglow" for more. :::

:::callout{icon=💡} Think of a wire-service newsroom where every incoming dispatch is stamped with a sequential serial number the moment it arrives. Dispatch #4012 came before #4013 — you do not need to ask the reporter, check the clock on the wall, or poll other desks. The serial number alone proves the order. If someone tries to slip in a fake dispatch between #4012 and #4013, the gap in the numbering immediately exposes the forgery. PoH works the same way: a continuous chain of [[gloss:hash|SHA-256]] [[gloss:hash|hashes]] acts as the serial stamp, and any [[gloss:node|node]] can verify the sequence without asking its neighbours. :::

:::keypoints{label="Key Points"}

  • Each [[gloss:hash|hash]] in a PoH chain depends on the previous one — this gives a cryptographically provable order of events that does not need to be agreed on with anyone
  • The chain can only be built strictly in order (this is what a Verifiable Delay Function is), but verifying a finished chain happens instantly and in parallel on any [[gloss:node|node]]
  • PoH sets the order but does not decide who is right — agreement on network state is handled by a separate mechanism, Tower BFT, a modification of the classical PBFT algorithm
  • The main practical win: [[gloss:node|nodes]] don't spend seconds messaging each other about "whose order is whose" — they just read the [[gloss:transaction|transaction]]'s position from the shared clock :::

:::details{badge=Advanced title="How the PoH Generator Works"} :::p{html} The PoH generator runs at around 2 million [[gloss:hash|SHA-256]] [[gloss:hash|hashes]] per second on a single thread. Solana's clock is structured in fixed units: each tick is 12,800 sequential [[gloss:hash|hashes]] (~6.25 ms), and 64 ticks make one slot of ~400 ms. [[gloss:transaction|Transactions]] are inserted at specific positions in this stream. Single-threading is a fundamental constraint: generation cannot be parallelised because each [[gloss:hash|hash]] depends on the previous one. :::

:::p{html} Verification, however, is the mirror image: once the [[gloss:hash|hash]] chain is published, [[gloss:validator|validators]] slice it into segments and check them in parallel across many CPU cores. A chain that the leader built sequentially over the course of a slot can be verified in a fraction of that time. This asymmetry — slow to produce, fast to verify — is the core property that makes PoH useful as a time source. ::: :::

:::details{badge=Advanced title="Criticism and Limitations of PoH"} :::p{html} PoH has three real architectural limitations. First, the hardware homogeneity assumption: if one [[gloss:node|node]] runs a significantly faster CPU than the rest, it produces [[gloss:hash|hashes]] faster and could attempt to outpace the rest of the network. In practice, modern server-grade CPUs are close enough in [[gloss:hash|SHA-256]] throughput that this rarely matters, but it ties Solana's security assumptions to the homogeneity of the CPU market — unlike [[gloss:proof of work|PoW]] chains, where what matters is total [[gloss:hashrate|hashrate]], not individual chip speed. :::

:::p{html} Second, the single-threaded bottleneck: PoH generation cannot be parallelised, so the speed of one CPU core puts a hard ceiling on how fast the clock can tick. Faster cores improve PoH throughput, but you cannot scale by adding more cores. :::

:::p{html} Third, long-range attack defence: the Solana [[gloss:whitepaper|whitepaper]] notes that overwriting old history would require an attacker to "outpace the speed of the PoH generator" — that is, to produce a faster valid chain than the live network. This is a real defence, but it relies on the rest of the network actually being faster, which depends on the same hardware homogeneity assumption above. :::

:::p{html} Many of these constraints are exactly what motivated Alpenglow, which removes PoH entirely and replaces it with local timeouts on each [[gloss:validator|validator]] — a simpler design that does not require a network-wide cryptographic clock. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-2-3-s2 correct=0 explanation="Correct. PoH is a Verifiable Delay Function that creates a cryptographic timeline. It is not [[gloss:consensus|consensus]] itself — [[gloss:consensus|consensus]] is handled by Tower BFT on top of PoH. The key benefit is that each [[gloss:node|node]] can independently verify the order of [[gloss:transaction|transactions]] without asking other [[gloss:node|nodes]]."} What does Proof of History provide for the Solana network?

  • A verifiable ordering of events without [[gloss:node|nodes]] needing to agree on time
  • Full [[gloss:consensus|consensus]] and [[gloss:finality|finality]] in a single mechanism
  • Encryption of all [[gloss:transaction|transactions]] for privacy
  • A [[gloss:proof of work|Proof of Work]] alternative using CPU power :::

:::section{mins=3} Architecture :::

:::lead Solana's speed isn't one trick but a stack of eight components, each shaving its own slice off the throughput problem. The big one — [[gloss:sealevel|Sealevel]] — runs [[gloss:transaction|transactions]] in parallel, on multiple CPU cores at the same time. :::

:::p{html} Solana is not a single big idea but an engineered stack of eight components, each solving its own problem. PoH we already covered in § 2: it handles ordering. To understand the rest, it's enough to look closely at three key pieces — Tower BFT, [[gloss:sealevel|Sealevel]], and Turbine — and mention the four remaining ones briefly, with a pointer to the advanced [[gloss:block|block]] below. :::

:::p{html} Tower BFT is the [[gloss:validator|validator]] voting layer that runs on top of PoH. When a leader assembles a [[gloss:block|block]] and writes its [[gloss:hash|hash]] into the shared clock, the other [[gloss:validator|validators]] vote: "agreed, we see the same thing." This is a modified version of classical PBFT (Practical [[gloss:byzantine fault tolerance|Byzantine Fault Tolerance]]), an algorithm invented in 1999 for distributed systems. Solana's main modification: instead of [[gloss:validator|validators]] constantly exchanging messages to synchronize their clocks, they use PoH marks as a replacement for timestamps. That makes voting in Solana substantially faster than in classical PBFT — but not free: as of April 2026, [[gloss:validator|validator]] votes take up about 75% of Solana's [[gloss:block|block]] space and cost each [[gloss:validator|validator]] roughly $5,000 per month. This is exactly the problem the upcoming Alpenglow upgrade solves (see § 2 and the advanced [[gloss:block|block]] below): it moves voting off-chain onto direct UDP messages between [[gloss:validator|validators]], freeing three quarters of [[gloss:block|block]] space for user [[gloss:transaction|transactions]]. :::

:::p{html} [[gloss:sealevel|Sealevel]] is parallel [[gloss:transaction|transaction]] execution, and it's the main source of Solana's speed. The [[gloss:evm|EVM]] → 2.2 [[gloss:evm|EVM]] in [[gloss:ethereum|Ethereum]] works like a single cashier at a supermarket: even if your basket only has bread and milk while mine has twenty items, mine gets rung up first, then yours. [[gloss:sealevel|Sealevel]] is several checkout lanes at once. If you're transferring USDC and someone else is minting an [[gloss:nft|NFT]], and the two operations touch different accounts, there is no reason to queue them. They run in parallel on different CPU cores. That is why every [[gloss:transaction|transaction]] in Solana has to declare in advance which accounts it will read and write — it lets the scheduler distribute work across cores without conflicts. :::

:::p{html} Turbine is [[gloss:block|block]] propagation across the network, designed on the same principle as BitTorrent. When the leader has built a [[gloss:block|block]], it does not send the [[gloss:block|block]] to every [[gloss:node|node]] individually — it slices the [[gloss:block|block]] into small pieces (Solana calls them shreds, "fragments") and distributes the shreds across a tree of [[gloss:node|nodes]]. Each [[gloss:node|node]] receives its piece, then exchanges with its neighbors. After a few network hops everyone has the full [[gloss:block|block]]. If you have ever downloaded a Steam update via peer-to-peer, you have seen the same principle in action. The upcoming Alpenglow upgrade replaces Turbine with a new protocol called Rotor: instead of propagating through a tree of [[gloss:node|nodes]], [[gloss:block|blocks]] will travel through relay [[gloss:node|nodes]] in a single network hop, cutting latency by another ~40% (see § 2). :::

:::p{html} The other four components — Gulf Stream (forwarding [[gloss:transaction|transactions]] to the future leader before they hit the [[gloss:mempool|mempool]], the queue of unconfirmed [[gloss:transaction|transactions]]), Pipelining (assembly-line processing of validation), Cloudbreak (a horizontally scalable database for network state), and Archivers (distributed storage of historical data) — are infrastructure optimizations. Each one gives a small gain on its own. Together they add up to an architecture capable of squeezing thousands of TPS out of a single machine. Details on each are in the advanced [[gloss:block|block]]. :::

:::p{html}

Innovation Purpose
Proof of History Cryptographic clock
Tower BFT [[gloss:consensus|Consensus]] on top of PoH
Turbine [[gloss:block|Block]] propagation (BitTorrent-style)
Gulf Stream [[gloss:transaction|TX]] forwarding before confirmation
[[gloss:sealevel|Sealevel]] Parallel [[gloss:transaction|TX]] execution
Pipelining Conveyor processing
Cloudbreak Horizontally scalable DB
Archivers Distributed storage
:::

:::callout{icon=💡} Picture a highway system designed from scratch. Instead of a single two-lane road where every car waits behind a slow truck, Solana builds eight parallel lanes ([[gloss:sealevel|Sealevel]]), on-ramps that feed traffic directly to the correct lane (Gulf Stream), overhead signs announcing which toll plaza is open next (leader schedule), and a split-second toll scanner so nobody stops (Turbine shreds). [[gloss:ethereum|Ethereum]]'s approach is more like a single main road with plans to add express bus lanes later ([[gloss:layer 2|L2]]). Both [[gloss:move|move]] people from A to B, but Solana's bet is that building all the lanes on day one avoids the need for separate bus systems. :::

:::keypoints{label="Key Points"}

  • Solana's speed is the sum of eight engineering decisions, each small on its own, but together producing an architectural leap
  • [[gloss:sealevel|Sealevel]] is the main source of speed: [[gloss:transaction|transactions]] touching different accounts run in parallel on different CPU cores
  • The leader schedule is known in advance, so [[gloss:transaction|transactions]] go directly to the future leader bypassing the [[gloss:mempool|mempool]] — this removes the "waiting to be included in a [[gloss:block|block]]" delay
  • Time on Solana is measured in slots (every 400 milliseconds) and epochs (about two days) — all the important events happen on the epoch boundary: refresh of the leader schedule for the next epoch, staker payouts, and proposal votes :::

:::details{badge=Advanced title="Leader Schedule and Slot Mechanics"} :::p{html} Leader schedule is a table that specifies in advance which [[gloss:validator|validator]] will be the leader in each slot for the next 2-3 epochs. The schedule is computed from [[gloss:validator|validator]] stake (the larger your stake share, the more often you become leader) and is publicly known to every [[gloss:node|node]] in the network. Each leader holds four consecutive slots in a row (about 1.6 seconds) before the baton passes to the next one. This gives the leader time to "warm up" and process several [[gloss:block|blocks]] back to back without losing milliseconds on context switching. :::

:::p{html} Gulf Stream uses knowledge of the schedule directly: instead of user [[gloss:transaction|transactions]] first landing in the shared pool of unconfirmed [[gloss:transaction|transactions]] (the [[gloss:mempool|mempool]]) and then [[gloss:validator|validators]] pulling them out, in Solana the client sends the [[gloss:transaction|transaction]] straight to the [[gloss:validator|validator]] that will be the next leader. This removes an entire waiting stage and trims latency by hundreds of milliseconds. :::

:::p{html} Turbine optimizes delivery of the [[gloss:block|blocks]] themselves. When the leader has assembled a [[gloss:block|block]], it doesn't send it to the whole network at once — it slices it into small pieces (shreds, "fragments") and spreads them across a tree of neighboring [[gloss:node|nodes]]. Each [[gloss:node|node]] passes its piece on, and after a few network hops everyone has the full [[gloss:block|block]]. One slot lasts about 400 milliseconds, one epoch is roughly two days (~432,000 slots). On epoch boundaries the leader schedule is refreshed and stakers receive their payouts. ::: :::

:::details{badge=Advanced title="Firedancer and Alpenglow"} :::p{html} Firedancer (Jump Crypto) is a fully independent [[gloss:validator|validator]] client rewritten from scratch in C/C++ — whereas the original Solana client, Agave, is written in Rust. The hybrid Frankendancer shipped to [[gloss:mainnet|mainnet]] first, in September 2024 — a version that combined Firedancer's fast networking layer with Agave's battle-tested execution environment. The full Firedancer (no Agave dependencies) reached [[gloss:mainnet|mainnet]] in December 2025. As of April 2026, Firedancer and its variants are run by about 20-25% of [[gloss:validator|validators]]. Why this matters: before Firedancer, a single codebase controlled almost the entire network, and a critical bug in it could have halted Solana wholesale. Having a second independent client cuts that risk by an order of magnitude. :::

:::p{html} Alpenglow (SIMD-0326) is the largest [[gloss:consensus|consensus]] upgrade in Solana's history. In September 2025 the proposal passed a [[gloss:validator|validator]] vote with 98.27% in favor. Alpenglow removes both PoH and Tower BFT, replacing them with two new components: Votor (fast voting using BLS signature aggregation and UDP messages instead of on-chain votes) and Rotor ([[gloss:block|block]] propagation via relay [[gloss:node|nodes]] in a single network hop). Target [[gloss:finality|finality]] is 100-150 milliseconds, versus ~12.8 seconds today — roughly an 85x improvement. [[gloss:mainnet|Mainnet]] launch is expected at the end of 2026, after community testing and audits; as of April 2026 Alpenglow is running on private test clusters. :::

:::p{html} Compute Units (CU) are the unit of computational work for a [[gloss:transaction|transaction]] — Solana's analogue of [[gloss:gas|gas]]. The default limit is 200,000 CU per [[gloss:transaction|transaction]] (up to 1.4 million CU on request via an additional budget instruction). The system is less granular than [[gloss:ethereum|Ethereum]]'s [[gloss:gas|gas]]: the same operation on Solana always costs the same number of CU regardless of network state, whereas [[gloss:ethereum|Ethereum]] [[gloss:gas|gas]] reacts to load through the priority fee. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-2-3-s3 correct=2 explanation="Correct. [[gloss:sealevel|Sealevel]] is the key innovation: it analyses which accounts each [[gloss:transaction|transaction]] touches and runs non-overlapping [[gloss:transaction|transactions]] in parallel. [[gloss:ethereum|Ethereum]]'s [[gloss:evm|EVM]] executes [[gloss:transaction|transactions]] strictly one after another. This is a fundamental architectural difference that gives Solana its throughput advantage."} What enables Solana's parallel [[gloss:transaction|transaction]] execution?

  • Sharding — splitting the chain into multiple parallel shards
  • Running multiple independent blockchains with bridges between them
  • [[gloss:sealevel|Sealevel]] — if [[gloss:transaction|transactions]] touch different accounts, they execute simultaneously
  • Using GPU processing instead of CPU for [[gloss:transaction|transaction]] validation :::

:::section{mins=2} Programming Model :::

:::lead In [[gloss:ethereum|Ethereum]], a [[gloss:smart contract|smart contract]] is a single box where code and data sit together. In Solana these are two separate boxes: the program is one place, the data is another. Sounds strange at first — but this inversion is exactly where half of Solana's speed comes from. :::

:::p{html} If you've ever looked at a Uniswap [[gloss:smart contract|smart contract]] on [[gloss:ethereum|Ethereum]], you saw code and data stored inside one object. The list of token pairs, pool balances, trade history — all of it lives in the contract's own storage (its persistent storage). Solana inverts this, and the inversion is one of the main reasons the network can execute [[gloss:transaction|transactions]] in parallel. :::

:::p{html} In Solana's model, everything is an account. The word here means more than "[[gloss:wallet|wallet]]" — it's a broader idea: a container of data. There are three kinds of accounts: program (holds executable code, only changeable through a special upgrade mechanism — the deployer typically retains this right and may explicitly relinquish it later, freezing the program into immutability), data (holds state — balances, settings, parameters — modified by a program), and SOL account (your [[gloss:wallet|wallet]] with its balance). A program never stores anything inside itself — it reads from and writes to data accounts passed to it as arguments. Every [[gloss:transaction|transaction]] explicitly says: "I will operate on accounts X, Y, Z." Knowing those addresses in advance lets the scheduler be smarter. :::

:::p{html} Why bother with all this? Remember [[gloss:sealevel|Sealevel]] from the previous section — parallel execution? For the scheduler to run two [[gloss:transaction|transactions]] at once, it needs to know they touch different data. In [[gloss:ethereum|Ethereum]] that's significantly harder to know before execution — a contract can touch anything, and most current [[gloss:evm|EVM]] clients execute [[gloss:transaction|transactions]] sequentially (a few newer clients like Reth are starting to experiment with parallel execution via access lists, but it's not yet mainstream practice). In Solana, every [[gloss:transaction|transaction]] arrives with an explicit account list: "I will read account A, write to account B." The scheduler looks at these lists, finds non-overlapping pairs, and runs them in parallel. Without code-data separation this optimization wouldn't be possible. :::

:::p{html} Technically, programs are written in Rust — a systems language known for strict memory control and high performance. It's harder than [[gloss:solidity|Solidity]], the language of [[gloss:ethereum|Ethereum]], but it gives more control. To make life easier for developers, Anchor was created — a framework wrapper around Rust for Solana (closer in role to OpenZeppelin Contracts in the [[gloss:ethereum|Ethereum]] world: a set of ready-made components and macros that hide much of the boilerplate). Programs are executed by [[gloss:svm|SVM]] — the Solana Virtual Machine, built on eBPF, a Linux-kernel technology used for fast and safe network packet filtering. [[gloss:svm|SVM]] is faster than [[gloss:evm|EVM]] for several reasons. The main one is architectural: Solana's program model with explicit code-data separation lets the scheduler run [[gloss:transaction|transactions]] in parallel → 2.2 [[gloss:evm|EVM]], which the [[gloss:evm|EVM]] in its classical form cannot do. Additionally, [[gloss:svm|SVM]] uses JIT compilation: on first execution, [[gloss:bytecode|bytecode]] is converted into native machine code and runs as a regular program from there on. Most [[gloss:ethereum|Ethereum]] clients still operate as interpreters (though newer clients like Reth are starting to apply similar optimizations). :::

:::callout{icon=💡} Think of a public library. The books (data) sit on numbered shelves, and the librarians (programs) are stateless workers: they read a catalog card, walk to the right shelf, retrieve or update the book, and [[gloss:move|move]] on. No librarian keeps books at their desk. If two librarians need different books from different shelves, they work at the same time without blocking each other. An [[gloss:ethereum|Ethereum]] contract is more like a private office where the lawyer keeps case files in a locked drawer — code and data bundled together, so only one task runs at a time. :::

:::keypoints{label="Key Points"}

  • In Solana everything is an account: programs (with code), data accounts (with state), and SOL accounts ([[gloss:wallet|wallets]]); this unified model is what fundamentally distinguishes Solana from [[gloss:evm|EVM]]-style chains
  • Programs do not store data inside themselves — they read from and write to external data accounts, and this is what makes parallel execution in [[gloss:sealevel|Sealevel]] possible
  • Development happens in Rust with the Anchor framework — harder than [[gloss:solidity|Solidity]], but it gives strict memory control and predictable performance
  • [[gloss:svm|SVM]] uses JIT compilation: the first execution is slower (compilation to machine code is needed), but every execution after that runs at native-program speed rather than at interpreter speed, which is how most [[gloss:evm|EVM]] clients still operate :::

:::details{badge=Advanced title="Rent, CPI, and PDA"} :::p{html} Rent (storage rent). Every account on Solana takes up space in the network state, and that space has to be paid for. In Solana's early model, accounts had a small SOL "rent" periodically deducted, and if the balance dropped below the minimum, the account was deleted. That model is now retired: the SIMD-0084 proposal disabled rent collection on [[gloss:mainnet|mainnet]], and now every new account must be rent-exempt from creation — meaning it must hold a permanent SOL deposit sized to the account's data. The deposit is around 0.00089 SOL for an empty 128-byte account (roughly $0.07 at April 2026 prices); a token account of 165 bytes requires about 0.002 SOL. The deposit is locked while the account exists and is returned to the owner when the account is closed. :::

:::p{html} CPI (Cross-Program Invocation). This is the mechanism by which one program calls another — the functional analogue of [[gloss:evm|EVM]]'s CALL instruction. Most complex operations on Solana are chains of CPIs: for instance, the Jupiter aggregator takes a token swap request, calls Raydium via CPI for one leg of the route, then Orca via CPI for the next, and so on. CPI has a hard nesting limit (4 levels by default, up to 8 with explicit permission), which [[gloss:block|blocks]] recursive attacks. :::

:::p{html} PDA (Program Derived Address). These are account addresses with no [[gloss:private key|private key]]: they are computed deterministically from a program ID and a set of "seeds" (arbitrary byte strings chosen by the program). PDAs are needed so that a program can own accounts and sign [[gloss:transaction|transactions]] on their behalf without ever storing a [[gloss:private key|private key]]. A typical example: a Raydium liquidity pool is an account at a PDA, controlled only by the Raydium program itself; a user cannot sign on it directly, which is what keeps the pool secure. ::: :::

:::details{badge=Advanced title="SVM as Rollup and Eclipse"} :::p{html} [[gloss:svm|SVM]] is gradually no longer just an internal Solana component — it's starting to be used as a standalone execution environment outside the home network. The most visible example is [[gloss:eclipse|Eclipse]], a project that launched [[gloss:mainnet|mainnet]] in November 2024 and runs as an [[gloss:layer 2|L2]] on top of [[gloss:ethereum|Ethereum]]: [[gloss:svm|SVM]] executes [[gloss:transaction|transactions]], data is stored on Celestia, and final state and settlement are periodically anchored to [[gloss:ethereum|Ethereum]]. The idea is a simple combination of strengths: [[gloss:svm|SVM]]'s speed and parallelism, paired with [[gloss:ethereum|Ethereum]]'s settlement security. [[gloss:eclipse|Eclipse]]'s experience has been mixed: by early 2026 ecosystem activity has noticeably slowed, and the team has shifted focus from attracting external developers to building first-party applications. :::

:::p{html} The emergence of an [[gloss:svm|SVM]] stack outside Solana shows that the program model and virtual machine are seen by the industry as a self-contained engineering unit — that is, parallel execution, code-data separation, JIT compilation and the SBF [[gloss:bytecode|bytecode]] format are interesting to developers regardless of which network they run on. Technically the path from source code to execution is the same everywhere: a developer writes a program in Rust or C, the compiler turns it into SBF [[gloss:bytecode|bytecode]] (Solana [[gloss:bytecode|Bytecode]] Format — a lightweight modification of eBPF), and on the [[gloss:node|node]] SBF goes through JIT compilation into native machine code and runs. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-2-3-s4 correct=3 explanation="Correct. In Solana everything is accounts: programs (executable accounts) never store data inside themselves — they read from and write to separate data accounts. This separation enables parallel execution via [[gloss:sealevel|Sealevel]] and is a fundamental difference from [[gloss:ethereum|Ethereum]]'s contract model."} How does Solana's programming model differ from [[gloss:ethereum|Ethereum]]'s?

  • Solana stores code and data together in one contract like [[gloss:ethereum|Ethereum]]
  • Solana only supports JavaScript for [[gloss:smart contract|smart contracts]]
  • Solana uses the [[gloss:evm|EVM]] as its execution environment
  • Programs are stateless — code and data stored in separate accounts :::

:::section{mins=2} SPL Tokens :::

:::lead In [[gloss:ethereum|Ethereum]], every token is its own [[gloss:smart contract|smart contract]]. In Solana, all tokens live inside one global program. What does that change in practice? Less code duplication, higher speed, and you can give tokens "special properties" right at the standard level — without writing a contract at all. :::

:::p{html} If you've ever looked at a list of [[gloss:ethereum|Ethereum]] tokens, you've noticed something odd: USDC and USDT are two different [[gloss:smart contract|smart contracts]] at two different addresses. DAI is a third contract. UNI is a fourth. Every time someone issues a new token on [[gloss:ethereum|Ethereum]], they deploy a new contract against the ERC-20 standard — fifty lines of code repeating the same transfer, balanceOf, approve functions. By 2026 there are hundreds of thousands of such near-identical copies on [[gloss:ethereum|Ethereum]]. It works, but it's redundant: [[gloss:node|nodes]] have to store, execute, and validate every copy separately. :::

:::p{html} Solana takes the opposite approach. There is one global contract — the SPL Token Program — and every token in the network uses it. Creating a new token doesn't mean writing code; it means creating a mint account: a special issuer account that records name, symbol, supply, and who is allowed to mint new units. This mint lives in a shared registry served by a single program. The difference is similar to how gift cards work: you can have every store print its own cards in its own format ([[gloss:ethereum|Ethereum]]), or there's one universal format and a store simply says "I'd like a card with my logo on it" (Solana). The second approach is simpler, cheaper, and faster across the board. :::

:::p{html} But there's a subtler win, too. Because SPL Token is a single program, you can build extra capabilities into it that every token gets to use. That's how Token-2022 came about (officially renamed the Token Extensions Program in 2024) — an expanded version of the standard program with options that on [[gloss:ethereum|Ethereum]] would have to be reimplemented by hand each time. Want a token that automatically deducts a percentage to the project's treasury on every transfer (transfer fees)? Just flip a flag at mint creation. Want a token with confidential transfers, where the amount is hidden via zero-knowledge proofs (confidential transfers)? Another flag. A token where holders accrue interest automatically (interest-bearing tokens)? Another flag. On [[gloss:ethereum|Ethereum]] each of those features is a separate contract with its own audits and bugs. On Solana it's part of the standard. :::

:::callout{icon=💡} Picture a shopping mall with gift cards. In [[gloss:ethereum|Ethereum]]'s system, each store prints its own cards — different design, different technology, different rules. Want a Zara gift card? Separate card. H&M? Another card. Every new store must design a card from scratch. In Solana's system, the mall itself issues one universal card format: every store reads the same chip, only the balance and logo differ. A developer who integrates the card reader once can accept any store's card without extra work. The trade-off is flexibility: if a store needs an unusual feature — say, a time-limited promotional balance — it has to wait for the mall operator to add that option to the universal format rather than printing a custom card on its own. :::

:::keypoints{label="Key Points"}

  • In Solana, one global SPL Token Program serves every token in the network — each new token is just a new record (a mint), not a new contract
  • Token-2022 (the Token Extensions Program since 2024) adds advanced capabilities — transfer fees, confidential transfers, interest accrual — built into the standard, with no [[gloss:smart contract|smart contract]] to write
  • [[gloss:nft|NFTs]] on Solana use several Metaplex standards: the legacy Token Metadata, the newer Core (launched in 2024 and recommended for new projects), and Bubblegum for compressed [[gloss:nft|NFTs]] — bulk-minting cheap collections
  • Token balances are stored in separate accounts called ATAs (Associated Token Accounts) — each user has one ATA per token, which fits the broader "everything is accounts" model :::

:::details{badge=Advanced title="Compressed NFTs and Token Accounts"} :::p{html} Compressed [[gloss:nft|NFTs]] (cNFTs) are a workaround for a fundamental Solana constraint: every regular [[gloss:nft|NFT]] is a separate account with its own rent-exempt deposit, and for collections of millions that gets expensive even on cheap Solana. Compressed [[gloss:nft|NFTs]] work differently: the entire collection is stored in a single account via a [[gloss:merkle tree|Merkle tree]], while each [[gloss:nft|NFT]]'s data lives in the [[gloss:transaction|transaction]] log and is proven cryptographically on demand. The program implementing this is called Bubblegum — a Metaplex protocol component built specifically for compressed [[gloss:nft|NFTs]]. The cost of minting a single cNFT in large collections drops to fractions of a tenth of a cent (about 5.35 SOL — roughly $444 at April 2026 prices — for one million cNFTs, versus thousands of dollars for a regular [[gloss:nft|NFT]] mint of the same volume). :::

:::p{html} The savings come with trade-offs. Compressed [[gloss:nft|NFTs]] can't be viewed directly in a [[gloss:block|block]] explorer — you need RPC providers with special Digital Asset Standard API support (Helius, Triton, and similar) to read the metadata. The size of a single tree is capped around one million [[gloss:nft|NFTs]] for practical reasons, after which proof paths become too long. And operations on cNFTs (transfer, update) are more expensive than on regular [[gloss:nft|NFTs]] because they require validating a cryptographic proof. So this is a tool for mass distribution (souvenirs, event tickets, game items) rather than for high-end collectible PFP projects. The flagship user of Bubblegum is the DRiP platform (acquired by Jupiter in 2025), which gives away millions of artist sticker collectibles for free to subscribers; Tensor, Solana's largest [[gloss:nft|NFT]] marketplace, also supports cNFTs. :::

:::p{html} A separate detail is how token accounts work. Each user's balance for each token lives in a separate account called an Associated Token Account (ATA). One [[gloss:wallet|wallet]] might hold a USDC ATA, a separate USDT ATA, a separate SOL account, and so on. The upside is parallelism: different ATAs are different accounts, and the scheduler can process [[gloss:transaction|transactions]] on them simultaneously. The downside is that every new ATA requires a rent-exempt deposit (about 0.002 SOL), which slightly raises the friction of trying out new tokens. ::: :::

:::details{badge=Advanced title="Metaplex — The NFT Ecosystem Standard"} :::p{html} Metaplex is the de-facto [[gloss:nft|NFT]] standard in the Solana ecosystem. Important caveat: Metaplex isn't part of the Solana protocol — it's an external project (the Metaplex Foundation) — but its components are used by virtually every [[gloss:nft|NFT]] project on the network. By 2026, the protocol covers several different standards under one umbrella, each solving a particular problem. :::

:::p{html} Token Metadata is the oldest standard, in use since 2021. It binds metadata (name, image, attributes) to a token through a separate account, and supports royalties, [[gloss:nft|NFT]] variants (Master Edition, Programmable [[gloss:nft|NFTs]] with enforced royalties), and inter-[[gloss:nft|NFT]] relationships. By 2026, Token Metadata is treated as a legacy system: for new projects the recommendation is not Token Metadata but Core (see below). :::

:::p{html} Metaplex Core is the new standard, launched in 2024. The main difference: one [[gloss:nft|NFT]] is one account, not three or four as in Token Metadata. That gives about 80% savings on minting (around 0.0029 SOL versus 0.022 SOL) and reduces network load. Core has built-in royalty enforcement (via a plug-in system with allowlists/denylists), collection-level operations executable in a single [[gloss:transaction|transaction]], and an extensible plug-in set for non-standard behavior. Bubblegum is a separate Metaplex program serving compressed [[gloss:nft|NFTs]] (see the previous [[gloss:block|block]]). And there's also Candy Machine — a launchpad platform for collections that manages mint queues, pricing, and whitelist access. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-2-3-s5 correct=1 explanation="Correct. In [[gloss:ethereum|Ethereum]] each ERC-20 token is a separate [[gloss:smart contract|smart contract]]. In Solana there is one global Token Program — creating a new token simply means creating a new mint account. This means less code duplication, standardised behaviour, and more efficient parallel execution."} What makes SPL Token standard fundamentally different from [[gloss:ethereum|Ethereum]]'s ERC-20?

  • Each SPL token deploys its own separate [[gloss:smart contract|smart contract]]
  • One global Token Program handles all tokens — creating a new token is just a mint account
  • SPL tokens cannot be transferred between [[gloss:wallet|wallets]]
  • SPL tokens only support [[gloss:nft|NFTs]], not fungible tokens :::

:::section{mins=2} Ecosystem :::

:::lead Solana's ecosystem is four directions, each with one flagship project that pulled the rest along. That's why this story only makes sense told through those four threads. :::

:::p{html} The center of Solana's [[gloss:defi|DeFi]] segment is Jupiter, the decentralized trading aggregator. Roughly 95% of all aggregated swap volume and about half of every DEX trade in the network flows through it — $2-4 billion daily. The aggregator idea is simple: when you want to swap, say, USDC for BONK, Jupiter checks dozens of decentralized exchanges (Raydium, Orca, Phoenix, Lifinity) at the same time, finds the best route — maybe it's cheaper to swap USDC into SOL first, then SOL into BONK across two different exchanges — and packages it all into a single [[gloss:transaction|transaction]]. By 2026, Jupiter has grown into Solana's full "super-app": besides swaps it runs perpetuals (perpetual futures), DCA (dollar-cost averaging on a schedule), its own launchpad (LFG), the JupUSD [[gloss:stablecoin|stablecoin]], the Jupiter Lend lending product, a separate memecoin venue called ApePro, and an integration with the Polymarket prediction market. In April 2025 Jupiter acquired the DRiP Haus platform, expanding into the [[gloss:nft|NFT]] segment as well. Working alongside Jupiter are Raydium and Orca — the two main decentralized exchanges — while Marinade and Jito hold the liquid-staking segment (these are analogues of what Lido is for [[gloss:ethereum|Ethereum]] → 2.2 Staking). :::

:::p{html} The second face of the ecosystem is memecoins and [[gloss:nft|NFTs]], and the headline story here is pump.fun. The platform reduced launching a memecoin to two minutes: enter a name, ticker, image, hit a button, and the token is live. Revenue peaked in January 2025, when pump.fun was earning around $148 million in fees per month — more than [[gloss:ethereum|Ethereum]] on some days. By the start of 2026 revenue had cooled to $30-50 million per month, but the platform crossed $1 billion in lifetime revenue — the first Solana app to do so. In July 2025 pump.fun did its own PUMP token launch and raised $1.3 billion, and in April 2026 it burned about 36% of all circulating PUMP supply as part of an aggressive buyback program. Pump.fun still accounts for 75-80% of all memecoin launches on Solana, and the platform has started expanding to other networks ([[gloss:ethereum|Ethereum]], Base, BSC). Riding the 2024-2025 wave, BONK, WIF, POPCAT, and Fartcoin all broke out — memecoins that became Solana's calling card and pulled retail users into the network. The number-one [[gloss:nft|NFT]] marketplace is Tensor, an analogue of OpenSea but oriented toward speed and trader analytics rather than collecting. :::

:::p{html} The third direction is DePIN (Decentralized Physical Infrastructure Networks). These are projects that build real-world physical services and pay participants in tokens. The undisputed leader of the segment is Helium: a distributed network for cellular connectivity and wireless internet. Hundreds of thousands of router-sized hotspots, owned by private individuals, are deployed worldwide — each covers its slice of the city. Helium Mobile has reached 670,000 subscribers in the US, runs in partnership with T-Mobile, and in March 2026 hit a record $2.5 million in monthly revenue. Render is the next best-known project in the segment: it pools idle GPUs around the world into a distributed rendering and AI-compute network (revenue is more modest, around $100-200 thousand per month as of April 2026). Hivemapper does the same thing for maps: drivers mount a camera on the windshield, drive about their day, collect a map of the world along the way, and earn tokens for every new street. Hivemapper is an order of magnitude smaller than Helium, but visible in the digital-mapping niche. Overall, the Solana DePIN sector has produced more than $22 million in cumulative revenue by 2026 and continues to expand. :::

:::p{html} Finally, [[gloss:wallet|wallets]]. Most Solana users come in through Phantom — it has become the ecosystem's standard the same way MetaMask became the standard for [[gloss:ethereum|Ethereum]]. Solflare is for those who take staking seriously and want to manage [[gloss:validator|validators]]. Backpack is the most interesting of the three: it's a [[gloss:wallet|wallet]] and a built-in exchange (Backpack Exchange) at the same time, which on Solana — where trading and custody are often intertwined — turns out to be a useful combination. :::

:::callout{icon=💡} Imagine a tech-park campus that just opened: office space is almost free, the construction crew can put up a new building in a weekend, and hundreds of startups are running experiments in parallel. A handful have already become billion-dollar tenants — Jupiter (the top trade aggregator), Marinade (liquid staking), Helium (wireless connectivity), Render (GPU rendering). Many others folded just as fast. Once in a while the campus generator trips and the lights go out: on 6 February 2024 a bug knocked out power for five hours before engineers found and patched the fault. Since that repair the campus has run more than 800 consecutive days without a blackout. [[gloss:ethereum|Ethereum]]'s ecosystem is more like an established downtown where rent is steep, permits are slow, but the grid has never failed. :::

:::keypoints{label="Key Points"}

  • Jupiter is the center of [[gloss:defi|DeFi]] on Solana: ~95% aggregator share and roughly half of every DEX trade in the network, totalling $2-4 billion in daily volume
  • Pump.fun reduced creating a memecoin to two minutes and a few clicks — that's what made Solana the main retail-memecoin network of 2024-2025
  • Phantom became to Solana what MetaMask is to [[gloss:ethereum|Ethereum]] — the [[gloss:wallet|wallet]] most users actually arrive through
  • DePIN — decentralized physical infrastructure projects (Helium for wireless, Render for GPU compute, Hivemapper for maps) chose Solana as their settlement layer because of its speed and low fees :::

:::details{badge=Advanced title="Jito and the MEV Problem on Solana"} :::p{html} Jito is the main player in [[gloss:mev|MEV]] → 2.2 [[gloss:mev|MEV]] infrastructure on Solana. It's a stack of three products: a modified Jito-Solana [[gloss:validator|validator]] client, run by about 75% of the network's total stake; the JitoSOL liquid-staking pool, with over 14 million SOL locked (around $1.2 billion — the largest such pool on Solana); and the [[gloss:transaction|transaction]]-auction infrastructure ([[gloss:block|Block]] Engine, Bundles), through which traders pay [[gloss:validator|validators]] for priority inclusion of their [[gloss:transaction|transactions]]. Auction revenue flows partly to [[gloss:validator|validators]] and partly to JitoSOL stakers, which keeps JitoSOL's yield consistently above plain native staking. :::

:::p{html} The mechanism that distributes [[gloss:mev|MEV]] tips across Jito's ecosystem is called Tip Router — an autonomous [[gloss:consensus|consensus]] network (an NCN, [[gloss:node|Node]] [[gloss:consensus|Consensus]] Network) that figures out who gets credited with what, and does it without a central operator. Before Tip Router, tip distribution went through a single centralized service, which was a weak point in the design. :::

:::p{html} [[gloss:mev|MEV]] on Solana is a sore subject. As the ecosystem grew, "sandwich attacks" flourished: a bot spots a large user purchase of a token, slips in to buy the same token right before it (pushing the price up), then sells right after, pocketing the difference at the user's expense. In 2024 the Solana Foundation took the heavy step of removing [[gloss:validator|validators]] caught in sandwich attacks from its stake-delegation program. This sparked a heated debate: on one side, protection of users against predatory [[gloss:mev|MEV]]; on the other, accusations of censorship and central arbitration of which [[gloss:transaction|transactions]] count as "fair." The argument is open: some see this as a justified rare exception, others as a dangerous precedent. :::

:::p{html} A separate Solana UX innovation is Blinks ([[gloss:blockchain|Blockchain]] Links): a technology that turns an ordinary URL into an executable on-chain action. Launched by the Solana Foundation in June 2024, in collaboration with Dialect. The idea is simple: post a link in Twitter or Discord, and anyone with a Phantom or Backpack [[gloss:wallet|wallet]] can vote in a DAO, buy an [[gloss:nft|NFT]], donate, or do a swap straight from the feed without going to a separate site. At launch, support came from Jupiter, Tensor, Sanctum, Helium, and other major projects. The main risk is phishing: a malicious link can look like a Blink, which is why clients like Phantom only render Blinks from Dialect's verified registry. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-2-3-s6 correct=2 explanation="Correct. Solana's sub-cent fees and fast confirmation unlock use cases that are impractical on [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]]: memecoin launches via pump.fun, high-frequency trading through Jupiter, DePIN telemetry from Helium/Render. The ecosystem thrives on volume and experimentation rather than large individual positions."} What characterises Solana's [[gloss:defi|DeFi]] ecosystem compared to [[gloss:ethereum|Ethereum]]'s?

  • Solana [[gloss:defi|DeFi]] has higher [[gloss:tvl|TVL]] than [[gloss:ethereum|Ethereum]]
  • Solana has no DEX or AMM projects
  • Low fees enable high-volume retail activity: memecoins, DePIN, fast-trading aggregators
  • Solana ecosystem focuses exclusively on institutional finance :::

:::section{mins=2} Issues :::

:::lead Until 2024, Solana had a reputation as "the network that goes down." Then — more than 800 days without a single full outage. What happened, and why does that still not mean "problems solved"? :::

:::p{html} In September 2021, Solana stopped for 17 hours. Not "slowed down," not "started dropping [[gloss:transaction|transactions]]" — fully halted. No [[gloss:transaction|transaction]] got through. [[gloss:wallet|Wallets]] returned errors. Exchanges suspended SOL withdrawals. For a [[gloss:blockchain|blockchain]], 17 hours is an eternity. In 2022 there were several more outages of 4–8 hours each. In February 2023 — another 18 hours of downtime. And the most recent incident — February 6, 2024, five hours of full outage. [[gloss:bitcoin|Bitcoin]] and [[gloss:ethereum|Ethereum]], for comparison, have never stopped once in their entire history. Solana earned its reputation: "fast, cheap, but it falls down." :::

:::p{html} Then something nobody expected happened. Since February 2024, Solana has run without a single full outage — by April 2026 that's more than 800 days of continuous uptime. What changed? The main thing: a second client appeared. Until 2024 the entire network ran on a single client, Agave (formerly Solana Labs), and any bug in it could halt everything at once. The Jump Crypto team built an alternative implementation — Firedancer, written from scratch in C, optimized for speed and resilience. Today roughly 25% of [[gloss:validator|validators]] run Firedancer or hybrid builds, with the remaining 75% on the improved Agave. This is what's called client diversity → 2.2 §4 Client Diversity: when a network depends on several independently developed programs, a single bug can't take the whole thing down. :::

:::p{html} But it would be naive to say the problems are solved. The biggest remaining one is the high entry barrier for [[gloss:validator|validators]]. Running a [[gloss:node|node]] requires around $60,000 a year in hardware and roughly $5,000 a month in hosting. For comparison, an [[gloss:ethereum|Ethereum]] [[gloss:validator|validator]] can run on a home PC for $50–100 a month. That's why Solana has only around 750-800 [[gloss:validator|validators]] — versus more than a million on [[gloss:ethereum|Ethereum]]. Solana's Nakamoto coefficient (the minimum number of entities that would have to collude to control one third of the stake) sits at 19-20 as of 2026. That means agreement among the 19-20 largest [[gloss:validator|validators]] would be enough to stop new [[gloss:block|block]] production. On [[gloss:ethereum|Ethereum]] the same coefficient runs into the thousands. Another concentration signal: formally no single [[gloss:validator|validator]] [[gloss:node|node]] controls more than ~3% of stake, but once you aggregate [[gloss:node|nodes]] belonging to a single organization the picture changes — the top three staking providers (Helius, Figment, Jupiter) together hold about 26% of the network's total stake. :::

:::p{html} The third problem is network congestion. At peak load in 2024, up to 75% of [[gloss:transaction|transactions]] were dropped by the network before they reached a [[gloss:block|block]]. Three solutions have been deployed. Local fee markets (proposal SIMD-0096) introduced different fees for different "hot" accounts — if everyone is rushing to mint a particular [[gloss:nft|NFT]] collection, the [[gloss:transaction|transaction]] price for that specific mint account rises while the rest of the network stays accessible. The switch to QUIC (replacing UDP as the transport protocol) gave better control over congestion. Stake-weighted QoS (Quality of Service) prioritizes [[gloss:transaction|transactions]] from [[gloss:validator|validators]] with larger stake — this is a controversial fix, because it de-facto privileges the big players, but in conditions of limited throughput it works. :::

:::callout{icon=💡} Picture a sports car at a track day. It posts the fastest lap times of any vehicle on the circuit: sub-second throttle response, razor-sharp cornering. But after every few laps it pulls into the pits for a coolant check, and once during the season the engine overheated badly enough to red-flag the session. The pit crew has since rebuilt the cooling system (Firedancer), and the car has run clean for the last 800+ laps. A sedan ([[gloss:ethereum|Ethereum]]) never set a track record, but it has never once called for a tow truck either. Both belong in the garage — for different reasons. :::

:::keypoints{label="Key Points"}

  • From 2021 to 2024 Solana was losing the reliability war: full outages of 17 hours (September 2021), 18 hours (February 2023), and 5 hours (February 2024) earned it the reputation of "the network that goes down" — [[gloss:bitcoin|Bitcoin]] and [[gloss:ethereum|Ethereum]] have never had a full outage in their entire history
  • Since February 2024 Solana has run more than 800 days without a full outage — the key fix was client diversity through Firedancer (Jump Crypto's alternative implementation), now used by ~25% of [[gloss:validator|validators]] alongside the improved Agave client
  • The high cost of running a Solana [[gloss:validator|validator]] (~$60K/year in hardware plus ~$5K/month hosting) is why there are only around 750-800 [[gloss:validator|validators]] total — versus more than a million on [[gloss:ethereum|Ethereum]] — and this is the deepest unresolved [[gloss:decentralization|decentralization]] concern
  • Network congestion at peak load (up to 75% [[gloss:transaction|transaction]] drop in 2024) is being addressed through local fee markets, QUIC protocol replacing UDP, and stake-weighted QoS — though the last solution implicitly privileges large [[gloss:validator|validators]] :::

:::details{badge=Advanced title="Downtime Causes and Client Diversity"} :::p{html} If you go through past outages by cause, the conclusion is the same in every case: they were caused by bugs in [[gloss:consensus|consensus]] → 1.3 [[gloss:consensus|Consensus]] or networking code, not by attacks. And in each case the same structural issue made things worse — a monolithic single-client architecture: until 2024 the entire network ran on a single client, Agave (formerly known as Solana Labs), and any bug in it became a network-wide halt. The fix for that is client diversity → 2.2 §4 Client Diversity. The arrival of Firedancer, an independent implementation by Jump Crypto, means a bug in one codebase no longer takes the whole network down: [[gloss:validator|validators]] running the other client keep producing [[gloss:block|blocks]]. :::

:::p{html} The September 2021 outage was triggered by a burst of bot-generated [[gloss:transaction|transactions]] that overwhelmed the networking layer, causing [[gloss:validator|validators]] to fall out of [[gloss:consensus|consensus]]. The February 2023 incident stemmed from a bug in the durable [[gloss:nonce|nonce]] feature that created an infinite loop in [[gloss:block|block]] replay. In each case, recovery required manual coordination among [[gloss:validator|validators]] to agree on a restart slot. Since February 2024, improved congestion control (QUIC, stake-weighted QoS) and Firedancer's independent codebase have eliminated these failure modes. ::: :::

:::details{badge=Advanced title="Validator Economics and Stake Concentration"} :::p{html} Start with how staking works, because the [[gloss:validator|validator]] economics don't make sense without it. A [[gloss:validator|validator]] almost never holds millions of SOL of its own. But other token holders — regular users, funds, exchanges — can "attach" their SOL to a [[gloss:validator|validator]] of their choice. This is what's called delegation. The tokens themselves don't [[gloss:move|move]]: they stay in the owner's [[gloss:wallet|wallet]], no one takes custody of them. The network just adds a record: "these 100 SOL of Bob's are credited to [[gloss:validator|validator]] X." That's how a [[gloss:validator|validator]] accumulates thousands or millions of someone else's SOL under its belt — and the size of that pool determines how often the network will assign it as a [[gloss:block|block]] producer and how much reward will flow in. :::

:::p{html} Yield comes from three sources: [[gloss:block|block]] production rewards (native staking yield, usually 5-7% annualized), priority fees from users willing to pay for fast inclusion, and [[gloss:mev|MEV]] tips through Jito's infrastructure. Together that's roughly 6-8% APY on staked SOL. But that's the total yield to the pool, not the [[gloss:validator|validator]]'s salary. From all earned rewards, the [[gloss:validator|validator]] keeps a small commission — typically 5-10%, set by the [[gloss:validator|validator]] itself — and the network automatically distributes the remaining 90-95% to delegators in proportion to their share. A concrete example: 100,000 SOL is delegated to a [[gloss:validator|validator]]. At 7% total yield, those 100,000 SOL produce 7,000 SOL in rewards over the year. With a 7% commission the [[gloss:validator|validator]] keeps 490 SOL ($40,000 at April 2026 prices) — that's its annual revenue. The remaining 6,510 SOL goes to delegators. :::

:::p{html} The problem is that a [[gloss:validator|validator]]'s fixed costs — about $5,000 a month for vote [[gloss:transaction|transactions]] plus hosting and hardware amortization — barely scale with stake size. Which means a [[gloss:validator|validator]] without enough delegated stake operates at a loss. The empirical break-even is around 80,000-100,000 SOL of delegated stake. Below that, the [[gloss:validator|validator]] either has to attract delegators with discounts and [[gloss:mev|MEV]] auctions, or gradually shut down. Solana Foundation removed its small-[[gloss:validator|validator]] subsidy program in 2025, which dropped the [[gloss:validator|validator]] count from a peak of ~2,500 at the end of 2023 to roughly 750-800 by the start of 2026. :::

:::p{html} This economics directly amplifies centralization. The top three staking providers (Helius, Figment, and Jupiter) together hold about 26% of the network's stake. Formally no individual [[gloss:validator|validator]] [[gloss:node|node]] exceeds the ~3% per-[[gloss:node|node]] ceiling, but a single organization can run multiple [[gloss:node|nodes]] — and the aggregate impact on the Nakamoto coefficient becomes substantial. A related topic — sandwich attacks and the removal of those [[gloss:validator|validators]] from the Solana Foundation's delegation program in 2024 — is covered in detail in the advanced [[gloss:block|block]] of § 6, "Jito and the [[gloss:mev|MEV]] Problem." ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-2-3-s7 correct=0 explanation="Correct. Running a Solana [[gloss:validator|validator]] costs roughly $60K a year in hardware plus ~$5K a month in hosting (versus ~$50–100/month for an [[gloss:ethereum|Ethereum]] [[gloss:validator|validator]]). The result: fewer [[gloss:validator|validators]] (around 750-800 vs more than a million on [[gloss:ethereum|Ethereum]]) and a lower Nakamoto coefficient (19-20). Small [[gloss:validator|validators]] are often unprofitable, which leads to stake concentration among large providers."} What is the main criticism of Solana's [[gloss:decentralization|decentralisation]]?

  • High [[gloss:validator|validator]] hardware costs (~$5K+/month) create a high entry barrier, resulting in only around 750-800 [[gloss:validator|validators]]
  • Solana uses [[gloss:proof of work|Proof of Work]], which concentrates power in [[gloss:mining|mining]] pools
  • A single company controls all [[gloss:validator|validator]] [[gloss:node|nodes]]
  • Solana cannot process more than 10 TPS :::

:::section{mins=2} vs Ethereum :::

:::lead If you've read the previous seven sections and you're thinking "so which [[gloss:blockchain|blockchain]] is actually better?" — that's the wrong question. They're optimized for different things. The right question: which one fits which job? :::

:::p{html} Solana and [[gloss:ethereum|Ethereum]] are often framed as competitors, but that's an oversimplification. They're optimized for different bets on how blockchains should work. From its beginning, [[gloss:ethereum|Ethereum]] followed a [[gloss:rollup|rollup]]-centric strategy — a thin [[gloss:l1|L1]] with execution speed on [[gloss:layer 2|L2]] → 2.2 §7 Roadmap — but in February 2026 Vitalik Buterin publicly acknowledged that in its original form the strategy "no longer makes sense," and [[gloss:l1|L1]] itself has started to scale up. Solana made the opposite bet from day one: a monolithic network, everything on one layer, throughput coming from more powerful [[gloss:validator|validator]] hardware. Each approach has its own set of strengths and trade-offs, and those define which applications go where. :::

:::p{html} The numbers are still very different. Solana processes 2-4 thousand real TPS, [[gloss:block|blocks]] land every 400 milliseconds, fees are around a tenth of a cent. [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]] → 2.2 [[gloss:gas|Gas]] currently does 15-30 TPS, [[gloss:block|blocks]] land every 12 seconds, fees range from a cent to ten dollars. But the upcoming [[gloss:glamsterdam|Glamsterdam]] upgrade will raise the [[gloss:gas|gas]] limit from 60 to 200 million, giving [[gloss:l1|L1]] throughput around 10,000 TPS — and a significant share of the workload that used to migrate to [[gloss:layer 2|L2]] will now live on the [[gloss:mainnet|mainnet]] itself. [[gloss:layer 2|L2s]] aren't going away — they're repositioning: their role is no longer "cheap [[gloss:ethereum|Ethereum]]" but specialization — privacy features, app-specific execution environments, low-latency environments for particular tasks. :::

:::p{html} What [[gloss:ethereum|Ethereum]] does incomparably better is security and [[gloss:decentralization|decentralization]]. It runs on more than a million [[gloss:validator|validators]] against Solana's 750-800, and across its entire history it has never had a full outage — versus more than a dozen serious halts on Solana between 2021 and 2024. Total value locked in [[gloss:ethereum|Ethereum]] [[gloss:defi|DeFi]] sits in the $55-70 billion range — versus $5.5-6 billion on Solana. Which means: for applications dealing with large pools of long-term capital (insurance products, real-world assets, corporate treasuries), [[gloss:ethereum|Ethereum]] remains the default choice. :::

:::p{html} When to pick which one in practice? Solana — for high-frequency operations where speed and cost matter most: DEX trading, memecoins, mobile payments, GameFi, and DePIN networks. If your application has to serve thousands of small-value operations per second, Solana is the natural fit. [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]] — for large [[gloss:defi|DeFi]] protocols, serious assets, anything that needs maximum security. Specialized [[gloss:ethereum|Ethereum]] [[gloss:layer 2|L2s]] — for tasks that specifically need what [[gloss:layer 2|L2s]] are good at: confidential payments on a zk-[[gloss:rollup|rollup]], or an application with its own custom execution rules. :::

:::p{html}

Parameter [[gloss:ethereum|Ethereum]] ([[gloss:l1|L1]]+[[gloss:layer 2|L2]]) Solana
Philosophy Modular, [[gloss:layer 2|L2]]-centric Monolithic
TPS ~15 [[gloss:l1|L1]], ~2000+ [[gloss:layer 2|L2]] 2,000–4,000
[[gloss:block|Block]] 12 [[gloss:sec-regulator|sec]] [[gloss:l1|L1]] ~400 ms
Fee $0.01–$10 ~$0.001
[[gloss:validator|Validators]] ~1M+ ~750-800
[[gloss:tvl|TVL]] ~$55-70B $5.5-6B
Language [[gloss:solidity|Solidity]] Rust
Uptime 100% 99.9%+
:::

:::callout{icon=💡} Think of two airlines serving the same route. The legacy carrier ([[gloss:ethereum|Ethereum]]) charges higher fares and sometimes makes you connect through a hub ([[gloss:layer 2|L2]]), but it has a spotless safety record, a vast loyalty network, and regulators trust it completely. The budget airline (Solana) flies direct for a fraction of the price with brand-new planes, but it has had a few publicized cancellations in its early years and its route map is still growing. Frequent flyers pick the carrier that fits their trip: institutional capital gravitates toward the legacy airline's reliability, while high-volume traders and everyday users prefer the budget carrier's speed and cost. :::

:::keypoints{label="Key Points"}

  • The "Solana vs [[gloss:ethereum|Ethereum]]" comparison is a false dichotomy. These are two different engineering bets optimized for different tasks: one network is faster not because it's better, but because it accepted different trade-offs around hardware and [[gloss:decentralization|decentralization]]
  • Solana's main argument — speed and low cost — is gradually losing its uniqueness: after the [[gloss:glamsterdam|Glamsterdam]] upgrade, [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]] will catch up on throughput, and [[gloss:layer 2|L2s]] already operate at comparable speeds
  • On security and [[gloss:decentralization|decentralization]] [[gloss:ethereum|Ethereum]] is far ahead: more than a million [[gloss:validator|validators]] versus 750-800 on Solana, $55-70B in [[gloss:defi|DeFi]] [[gloss:tvl|TVL]] versus $5.5-6B, never a full outage in its history — for serious capital this still matters more than speed
  • Solana fits high-frequency operations on small amounts: DEX trading, memecoins, mobile payments, gaming, DePIN. [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]] fits large [[gloss:defi|DeFi]] protocols and serious assets. [[gloss:ethereum|Ethereum]] [[gloss:layer 2|L2s]] are repositioning from "cheap [[gloss:ethereum|Ethereum]]" to specialization: privacy, ultra-low latency, app-specific execution environments :::

:::details{badge=Practical title="When to Use Solana, When Ethereum"} :::p{html} When to choose Solana. Anything where [[gloss:transaction|transactions]] are frequent and small — swaps on decentralized exchanges, memecoin trading and quick speculative strategies, mobile payments, game applications with thousands of small operations, DePIN networks where a hotspot or GPU [[gloss:node|node]] racks up thousands of small payouts a day. Any business model where a one-cent [[gloss:transaction|transaction]] fee breaks the unit economics is naturally Solana's territory, because its fee is tenths of a cent and confirmation lands in half a second. :::

:::p{html} When to choose [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]]. When you're dealing with large amounts of money that need to sit safely for a long time without moving. Institutional [[gloss:defi|DeFi]] protocols like Aave and Lido — where a single [[gloss:smart contract|smart contract]] holds billions in collateral and outstanding loans — don't migrate to Solana easily, even where Solana would be faster and cheaper, because for a holder of $50 million the risk of a catastrophic network halt outweighs the savings on fees. The same applies to real-world assets (real estate, bonds, equities in tokenized form), corporate treasuries, products for accredited investors, and anything that depends on regulatory clarity — [[gloss:ethereum|Ethereum]] already has spot ETFs in the US, and a decade-long no-outage track record carries weight with auditors and compliance officers. :::

:::p{html} When to choose an [[gloss:ethereum|Ethereum]] [[gloss:layer 2|L2]]. When you need both high speed and [[gloss:l1|L1]] settlement security: user activity executes on [[gloss:layer 2|L2]] (Arbitrum, Base, Optimism), but final state anchors back to the [[gloss:ethereum|Ethereum]] [[gloss:mainnet|mainnet]]. The trade-off: cheaper and faster than [[gloss:l1|L1]], but with a different trust model (you have to rely on the correctness of the [[gloss:rollup|rollup]]'s proofs). By 2026, [[gloss:layer 2|L2s]] no longer position themselves as a universal "cheap [[gloss:ethereum|Ethereum]]" but specialize for specific niches — private payments on a zk-[[gloss:rollup|rollup]], app-specific execution environments, or low-latency setups for trading applications. ::: :::

:::details{badge=Advanced title="Convergence: Worlds Coming Together"} :::p{html} Despite the different philosophies, both networks are moving toward each other. [[gloss:ethereum|Ethereum]] and its [[gloss:layer 2|L2s]] are catching up to Solana on user experience: [[gloss:transaction|transactions]] on Base or Arbitrum already cost cents and confirm in seconds. What used to be Solana's main argument — that it was friendlier to retail users — is gradually losing that uniqueness, and the development direction of the [[gloss:ethereum|Ethereum]] [[gloss:mainnet|mainnet]] is pulling in the same direction. :::

:::p{html} Solana, in turn, is catching up to [[gloss:ethereum|Ethereum]] on reliability. The arrival of Firedancer as a second independent client is exactly what made it possible for Solana to run more than 800 days without a full outage, and made the architecture more resilient to bugs in any single codebase. This is the approach [[gloss:ethereum|Ethereum]] has long called client diversity, and Solana arrived at it on its own track. :::

:::p{html} There's also mutual technology adoption. [[gloss:svm|SVM]] (Solana's virtual machine) is starting to be used outside Solana — the most visible example is [[gloss:eclipse|Eclipse]], a project that launched [[gloss:mainnet|mainnet]] in November 2024 and runs as an [[gloss:layer 2|L2]] on top of [[gloss:ethereum|Ethereum]]: [[gloss:svm|SVM]] executes the [[gloss:transaction|transactions]], data is stored on Celestia, and final state anchors to [[gloss:ethereum|Ethereum]]. From the [[gloss:ethereum|Ethereum]]-compatible side, [[gloss:monad|Monad]] and [[gloss:sei|Sei]] have appeared — these are new blockchains that use [[gloss:solidity|Solidity]] and the [[gloss:evm|EVM]] but execute [[gloss:transaction|transactions]] in parallel (in roughly the same way [[gloss:sealevel|Sealevel]] does on Solana). Over the next 3-5 years the line between "fast Solana" and "secure [[gloss:ethereum|Ethereum]]" may blur further: each ecosystem is borrowing from its neighbor whatever the neighbor was better at. ::: :::

:::further{label="Further Reading"}

:::quiz{id=q-2-3-s8 correct=3 explanation="Correct. Solana excels at high-frequency, low-value operations: DePIN telemetry, gaming [[gloss:transaction|transactions]], micropayments, and retail trading — use cases where $0.001 per [[gloss:transaction|transaction]] is essential. [[gloss:ethereum|Ethereum]] is a better fit when maximum security, regulatory clarity ([[gloss:etf|ETF]]), or broad [[gloss:layer 2|L2]] composability matters most."} When would you choose Solana over [[gloss:ethereum|Ethereum]] for a project?

  • When maximum security and battle-tested infrastructure are paramount (e.g. institutional custody)
  • When you need 100% uptime guarantee with no historical outages
  • When [[gloss:layer 2|L2]] composability across dozens of [[gloss:rollup|rollups]] matters most
  • When you need sub-cent fees and sub-second [[gloss:finality|finality]] for high-frequency operations like DePIN or payments :::