Solana: Node Types, Mempool & Finality Explained

Key Takeaways:

• Solana eliminates traditional mempools through Gulf Stream, forwarding transactions directly to upcoming block leaders for sub-second processing
• Three commitment levels (processed, confirmed, finalized) let developers balance speed against certainty, with finality reaching approximately 12.8 seconds
• RPC nodes serve blockchain data without voting, while validator nodes secure the network through consensus participation and earn rewards
• Tower BFT consensus leverages Proof of History as a cryptographic clock, achieving optimistic confirmation in approximately 500-600 milliseconds
• Alpenglow upgrade (approved September 2025, testnet December 2025, mainnet Q1 2026) promises 100-150ms deterministic finality by replacing Proof of History and Tower BFT entirely

Solana achieves high-performance transaction processing through Gulf Stream’s mempool-less architecture, which forwards transactions directly to predetermined block leaders instead of broadcasting to a shared pool. The network uses Tower BFT consensus built on Proof of History to reach optimistic confirmation in approximately 500-600 milliseconds and full finality in approximately 12.8 seconds. Understanding node types, commitment levels, and transaction flows helps miners and validators optimize infrastructure decisions.

Understanding Solana’s Unique Architecture

Solana stands apart from most blockchains by eliminating the traditional mempool entirely. While networks like Ethereum and Bitcoin maintain shared transaction pools where pending transactions wait for validator selection, Solana pushes transaction caching and forwarding to the network’s edge through a protocol called Gulf Stream^[1].

This architectural decision stems from a fundamental problem with traditional mempool designs. When networks experience high transaction volume, mempools create bottlenecks as validators compete to access and process the same pending transaction set. Solana’s approach distributes this responsibility directly to upcoming block leaders, who can pre-process transactions before their scheduled slot arrives^[2].

The Problem with Traditional Mempools

Traditional blockchain mempools operate through gossip protocols, where transactions propagate randomly across the network in peer-to-peer fashion. Ethereum and Bitcoin nodes construct bloom filters representing their local mempool state, then request missing transactions from other nodes. This propagation takes at least log(N) steps, consuming bandwidth, memory, and computational resources at each hop^[3].

During network congestion, these mempools can balloon to 50,000-200,000 unconfirmed transactions. The CryptoKitties phenomenon in 2017 demonstrated this vulnerability when game-related transactions flooded Ethereum’s mempool, causing delays and fee spikes across the entire network. Solana’s designers recognized that mempool size directly limits blockchain functionality^[4].

How Gulf Stream Eliminates the Mempool

Gulf Stream leverages Solana’s deterministic leader schedule to forward transactions directly to expected leaders ahead of time. Since every validator knows the upcoming leader sequence—which alternates every four slots—clients and current leaders can push pending transactions toward future leaders without network-wide broadcasting^[5].

This enables validators to execute transactions ahead of time, reduce confirmation latency, switch leaders faster, and minimize memory pressure from unconfirmed transaction pools.

The leader schedule operates predictably because Solana’s Proof of History provides a verifiable source of time. Each slot lasts approximately 400 milliseconds, and the schedule is known in advance by all active network nodes. Transactions must include a recent blockhash valid for up to 150 slots (roughly 60 seconds), ensuring transaction freshness while preventing double-spend attempts^[6].

Gulf Stream Technical Implementation

Gulf Stream underwent significant upgrades in 2022 and 2024 to handle Solana’s unprecedented transaction volumes. The protocol now operates through QUIC networking and implements Stake-weighted Quality of Service to manage validator connections.

QUIC Protocol Integration

In late 2022, Solana adopted QUIC (Quick UDP Internet Connections) to replace UDP connections. This change primarily addressed spam filtering capabilities, as QUIC provides better connection management and allows leaders to prioritize legitimate traffic more effectively^[7].

When a validator becomes the leader, inbound traffic can spike to over one gigabyte per second as the entire network directs transaction packets toward them. QUIC’s multiplexed streams and improved congestion control help leaders handle this intense data ingress without dropping valid transactions.

Stake-Weighted Quality of Service

Introduced in early 2024, Stake-weighted QoS (SWQoS) fundamentally changed how transactions reach leaders. Previously, all nodes had equal access to leaders’ connection capacity. Now, leaders prioritize transaction messages proxied through staked validators, reserving 80 percent of capacity (2,000 connections) for staked peers while allocating 20 percent (500 connections) to non-staked nodes^[8].

A validator with 0.5 percent of network stake can transmit up to 0.5 percent of packets to the leader. This stake-weighted approach provides Sybil resistance, preventing attackers from flooding leaders with transaction spam from numerous low-quality nodes. Validators with higher stakes receive guaranteed service levels proportional to their network commitment^[9].

Solana vs Traditional Mempool Architectures

This table highlights the core architectural differences between Solana’s Gulf Stream and traditional blockchain mempool systems. The deterministic leader schedule enables Gulf Stream’s direct forwarding approach, which traditional proof-of-work or randomized leader selection cannot replicate^[10].

Transaction Processing Unit Pipeline

When transactions reach the leader through Gulf Stream, they enter the Transaction Processing Unit (TPU) pipeline. The TPU processes transactions through five distinct phases: Fetch, SigVerify, Banking, Proof of History Service, and Broadcast^[11].

The Fetch stage receives transaction packets from the network through the leader’s QUIC connections. SigVerify validates transaction signatures in parallel across multiple cores, discarding invalid transactions before they consume further resources. The Banking stage executes valid transactions against the current blockchain state using Sealevel’s parallel runtime^[12].

After execution, the PoH Service records transaction order in the cryptographic clock, and the Broadcast stage propagates completed blocks to other validators through Turbine—Solana’s block propagation protocol. This pipeline allows leaders to process thousands of transactions per slot while maintaining strict ordering guarantees.

Proof of History: Solana’s Cryptographic Clock

Proof of History functions as a Verifiable Delay Function that establishes a verifiable record of time before consensus occurs. Unlike traditional blockchains where validators must communicate extensively to agree on transaction ordering, PoH creates a trustless source of time that all validators can independently verify^[13].

How Proof of History Works

PoH operates as a sequential SHA-256 hash function running as fast as possible. Each output becomes the next input, creating an unbreakable chain where computing the Nth hash requires computing all N-1 previous hashes. The system periodically samples this hash chain, recording the iteration count and state^[14].

Messages referencing these samples prove they were created after the sample timestamp, establishing a cryptographic ordering of events without peer-to-peer communication.

This design provides two critical capabilities: validators can process transactions in parallel because ordering is pre-determined, and vote verification becomes efficient without requiring validators to synchronize clocks through network communication. The PoH output uniquely identifies each ledger fork, and validation votes reference specific PoH hashes present in the ledger^[15].

Slots and Leader Rotation

Solana divides time into slots of approximately 400 milliseconds each. Every slot has a designated leader who can produce a block. The leader schedule is deterministic and stake-weighted, with validators receiving leader slots proportional to their delegated stake^[16].

The leader rotates every four slots to prevent single points of failure and distribute block production across the validator set. During their slot, leaders process transactions from their Gulf Stream queue, execute them through the TPU, and produce a block containing the transaction outcomes and PoH timestamps.

Tower BFT Consensus Mechanism

While Proof of History provides transaction ordering, Tower BFT determines which blocks become finalized and canonical. Tower BFT is Solana’s custom implementation of Practical Byzantine Fault Tolerance (PBFT), modified to leverage PoH as a network clock and reduce consensus messaging overhead^[17].

Vote Towers and Exponential Lockouts

Each validator maintains a vote tower—a sequential stack of votes where each vote reinforces a fork and is an ancestor to the fork above it. When validators cast votes on blocks, they commit to that vote for a lockout period measured in slots. Each consecutive vote on the same chain doubles the lockout period for all previous votes^[18].

For example, a validator’s first vote might have a lockout of 2 slots, the second 4 slots, the third 8 slots, continuing exponentially up to a maximum of 2^32 slots. This exponential growth makes earlier votes progressively harder to reverse, as switching to a different fork requires waiting out the lockout period on abandoned votes^[19].

Supermajority Confirmation and Finalization

Validators broadcast their votes as standard transactions on the Solana blockchain. When two-thirds of stake-weighted validators vote on a block, it achieves confirmed status—providing strong assurance the transaction is on the canonical chain. This optimistic confirmation typically occurs within 500-600 milliseconds under normal network conditions, though actual time to confirmed status is usually 1-2 seconds from initial transaction submission^[20].

Finalization requires 32 confirmed blocks built atop the target block. At this maximum lockout depth, validators attempting to vote for conflicting forks would violate consensus rules and risk slashing penalties. Finality typically takes approximately 12.8 seconds (32 slots at ~400ms each), representing the tradeoff between speed and irreversibility guarantees^[21].

Every participant in the network can compute timeouts for every other participant without peer-to-peer communication, making Tower BFT asynchronous. When validators detect multiple forks, they calculate the effective stake-weighted timeout of each fork and select the heaviest one. Validator rewards only generate for votes reaching the 2^32 timeout, creating incentive compatibility for voting on the heaviest fork^[22].

Solana Node Types Explained

Solana’s network operates through two primary node types: validator nodes that participate in consensus and RPC nodes that serve blockchain data. Understanding these roles helps operators choose infrastructure that matches their business requirements and technical capabilities. Blockchain networks like Chia and Algorand have similar node distinctions that serve different infrastructure purposes.

Validator Nodes (Consensus Nodes)

Validator nodes secure the Solana network by producing blocks and voting on block validity. These nodes maintain the complete blockchain state, tracking every state transition as it occurs. Their primary functions include block production during assigned leader slots and continuous voting on blocks produced by other leaders^[23].

Running a validator requires significant stake delegation to remain economically viable. Validators earn rewards through two mechanisms: vote credits for successful votes on finalized blocks, and transaction fees plus storage rent when serving as block leader. Each vote incurs approximately 0.000005 SOL in transaction costs, accumulating to roughly 2-3 SOL per epoch, representing approximately 300-400 SOL in annual operating costs^[24].

Running a profitable Solana validator requires significant delegated stake. Validators need approximately 50,000 SOL in delegated stake at 10% commission to break even, though validators self-staking may achieve profitability with around 5,000 SOL. This threshold exists because validators incur approximately 2-3 SOL per epoch in vote transaction costs (~394 SOL annually) plus hardware and infrastructure expenses^[61,62].

Validator hardware requirements emphasize computational power and fast storage. Minimum specifications include 12-16 CPU cores, 128-256GB RAM, high-endurance NVMe SSDs totaling 1.5TB or more for accounts and ledger storage, and robust network connectivity capable of sustained gigabit throughput. These requirements support the intense processing demands during leader slots^[25].

RPC Nodes (Non-Voting Validators)

RPC nodes perform all validator functions except voting on blocks. They maintain blockchain state and respond to data requests from applications, wallets, and services. RPC nodes enable external applications to query blockchain data, submit transactions, and interact with on-chain programs^[26].

Unlike validators, RPC nodes do not receive vote credits or block rewards. Operators typically run RPC infrastructure for three reasons: providing services to users who need blockchain access, supporting their own applications’ infrastructure needs, or operating as specialized service providers offering dedicated RPC access to development teams^[27].

RPC node hardware requirements often exceed validator specifications because these nodes handle larger data volumes from decentralized applications. They require similar CPU and storage specifications but may need additional RAM (256GB+) and optimized database indexing for rapid query responses. Installation costs range from $2,000-$4,000, with monthly maintenance expenses of $500-$700^[28].

Setting Up RPC Node Infrastructure

RPC nodes run the same Agave client software as validators but configure it with specific flags: –no-voting disables consensus participation, –full-rpc-api enables complete RPC functionality, and –private-rpc hides the node’s RPC port from public discovery^[29].

The –limit-ledger-size parameter is critical for RPC operations. Given Solana’s high transaction throughput, storing the complete blockchain history on a single machine becomes impractical. RPC operators specify how many blocks to retain locally, accessing older historical data through BigTable instances when users require transaction history^[30].

Account indexing significantly impacts RPC performance. The –account-index parameter activates in-memory indexes that accelerate account-scanning requests like getProgramAccounts. Available indexes include program-id (indexing by owning program) and spl-token-mint (indexing SPL token accounts by Mint). Without these indexes, queries scanning the entire account set perform poorly as the network grows^[31].

Transaction Commitment Levels

Solana defines three commitment levels that indicate how finalized a transaction is, allowing developers to balance responsiveness against certainty. These levels—processed, confirmed, and finalized—represent increasing degrees of confidence that a transaction will not be rolled back.

Processed Commitment

A transaction reaches processed status when a leader has received it, executed it, and voted on it in their most recent block. However, this block may not yet have any cluster-wide votes and could potentially belong to a dropped fork^[32].

Processed provides the fastest possible feedback, typically occurring within the same 400ms slot. Approximately 5 percent of blocks don’t achieve finalization due to forking in the consensus protocol. Transactions using blockhashes from dropped forks won’t be considered recent by blocks in the finalized chain, causing those transactions to expire^[33].

Most applications avoid relying on processed commitment except during testing and development. The risk of fork-related rollbacks makes it unsuitable for production environments where transaction certainty matters. However, processed commitment helps developers detect transaction formatting errors quickly during development cycles.

Confirmed Commitment (Optimistic Confirmation)

Confirmed status occurs when a supermajority (66 percent or more) of stake-weighted validators vote on a block containing the transaction. This provides strong assurance the block is on the canonical chain and unlikely to be reversed through standard consensus mechanisms^[34].

No confirmed block has experienced reversion in Solana’s operational history. The consensus requires such broad validator agreement that overturning a confirmed block would necessitate coordinated action by major stake holders. Confirmed confirmation typically occurs within 1-2 seconds of a transaction’s initial processing^[35].

Many applications treat confirmed transactions as essentially final for user experience purposes. The balance between speed (1-2 second feedback) and security (66 percent consensus) makes confirmed the recommended commitment level for most RPC operations. When fetching recent blockhashes, using confirmed commitment provides an extended 13-second window compared to finalized, reducing transaction expiration risk^[36].

Finalized Commitment

Finalized represents the highest certainty level, indicating the block has been confirmed by a supermajority and at least 31 additional confirmed blocks have been built on top of it. At this 32-block depth, the block achieves maximum lockout in Tower BFT’s voting mechanism^[37].

Finalized transactions are effectively irreversible—validators attempting to vote for conflicting forks would violate consensus rules and face potential slashing.

Finalization typically requires approximately 12.8 seconds under normal conditions (32 slots at approximately 400ms each). This represents the tradeoff for absolute certainty: applications waiting for finalized status introduce noticeable latency but eliminate all rollback risk. Exchanges moving large fund amounts and critical infrastructure typically require finalized confirmation before considering transactions complete^[38].

Commitment Levels Comparison

This comparison helps developers select appropriate commitment levels based on their application’s security requirements and user experience goals^[39].

The Future: Alpenglow Upgrade

Solana’s development roadmap includes the Alpenglow upgrade, which represents the largest protocol change since the network’s launch. Alpenglow was formally approved by validators in September 2025 with 98.94% support, with testnet deployment scheduled for December 2025 at the Breakpoint conference and mainnet rollout planned for Q1 2026^[40,41].

Votor and Rotor: New Consensus Components

Alpenglow replaces both Proof of History and Tower BFT with two new systems: Votor for consensus voting and Rotor for data propagation. These components work together to reduce finality from approximately 12.8 seconds to 100-150 milliseconds—nearly 100 times faster than current performance^[42].

Votor achieves rapid finality through a dual-path approach: when 80 percent of validators participate, blocks finalize in a single voting round. When participation drops to 60 percent, finalization requires two rounds. This “20+20” resilience model tolerates up to 20 percent adversarial stake and 20 percent non-responsive stake simultaneously^[43].

Rotor optimizes how validators communicate block data, reducing network bottlenecks that currently limit throughput. Together with Votor, these changes enable Solana to compete with Web2 infrastructure in responsiveness—critical for applications like decentralized exchanges where milliseconds matter^[44].

Off-Chain Voting Mechanism

Unlike Tower BFT’s on-chain votes, Alpenglow moves voting off-chain entirely. Validators communicate votes directly to each other rather than broadcasting them as transactions. This eliminates millions of daily vote transactions from the ledger, dramatically reducing storage requirements and freeing bandwidth for user transactions^[45].

Off-chain voting also significantly lowers operational costs for validators. Currently, vote transaction fees total approximately 2-3 SOL per epoch. The Alpenglow upgrade introduces a Validator Admission Ticket (VAT) system that reduces validator costs by approximately 98%—from roughly $60,000 annually to about $1,000 annually through a fixed fee of 1.6 SOL per epoch. This dramatic cost reduction will lower the profitability threshold for smaller validators and encourage greater network decentralization^[46,63].

The simplified ledger also makes running archival nodes more practical for new infrastructure providers. With governance approval secured and specific deployment dates confirmed, Alpenglow positions Solana as one of the only blockchains fast enough for true real-time applications where even one-second delays create UX problems^[47].

MEV and Private Mempools on Solana

Although Solana lacks a traditional public mempool, Maximal Extractable Value opportunities still exist through private infrastructure. The Jito protocol previously operated a canonical out-of-protocol mempool service allowing searchers to submit transaction bundles for MEV strategies like arbitrage and liquidations^[48].

How Jito-Solana Validators Handle MEV

When Jito-Solana validators serve as leaders, they can accept bundles—groups of atomically executed transactions submitted by specialized searchers. These bundles bypass normal transaction ordering, allowing searchers to capture value through sandwich attacks, arbitrage, and liquidation opportunities^[49].

The canonical Jito mempool has since been deprecated, but the infrastructure demonstrated that Gulf Stream’s mempool-less design doesn’t eliminate MEV—it just changes how value extraction occurs. Without a public mempool, MEV opportunities concentrate among validators running specialized software and searchers with direct validator relationships.

Bundle Auctions and Validator Revenue

Jito introduced bundle auctions where searchers compete to have their transaction bundles included in blocks. Validators earn additional revenue beyond standard transaction fees by accepting the highest-paying bundles. This creates a parallel priority market operating alongside Solana’s standard transaction fee mechanism^[50].

For crypto miners transitioning to Solana validation, understanding MEV infrastructure is critical. Validators running Jito-compatible software can potentially earn significantly more than base rewards through bundle auction participation. However, this requires technical sophistication in maintaining relationships with searchers and operating specialized validator configurations.

Practical Considerations for Validators and Miners

Mining professionals evaluating Solana infrastructure face different economic and technical considerations than traditional proof-of-work systems. The shift from computational power to staked capital fundamentally changes the investment calculus and operational requirements.

Validator Economics and Break-Even Analysis

Solana validation economics center on stake delegation amounts. With approximately 1,400 consensus validators as of mid-2025—down from a peak of over 2,500 in early 2023—the competitive landscape requires substantial delegated stake to earn consistent rewards. Large validators like Helius operate with over 13 million SOL in delegated stake, representing over $2 billion in capital at mid-2024 prices^[51].

Operating costs include hardware (approximately $2,000-$4,000 initial investment), monthly infrastructure expenses ($500-$700 for self-hosted setups), vote transaction fees (approximately 300-400 SOL annually, or roughly 2-3 SOL per epoch), and opportunity cost of staked capital. Validators must attract enough delegation to offset these costs through vote credits and transaction fee earnings^[52].

The profitability threshold remains challenging for smaller operators. Validators need approximately 50,000 SOL in delegated stake at 10% commission to break even with current network economics. Validators self-staking their own SOL may achieve profitability with around 5,000 SOL depending on commission rates and MEV capture, though entry barriers remain substantially higher than small-scale proof-of-work mining operations. These economics will shift dramatically with the Alpenglow upgrade in Q1 2026, which will reduce validator operational costs by approximately 98%^[62,63].

Cloud vs Self-Hosted Infrastructure

Validators choose between self-hosted hardware and cloud providers like AWS, GCP, or specialized blockchain infrastructure services. Self-hosting provides maximum control over configuration, potential for lower long-term costs, and direct management of security. Cloud hosting offers easier scaling, redundancy options, and outsourced infrastructure management^[53].

For validators handling leader slots, co-location with major network hubs can provide latency advantages. Every millisecond matters when processing thousands of transactions during 400ms slots. Cloud providers’ data center locations in network exchange points offer connectivity benefits that offset higher operational expenses for some validators.

Monitoring and Maintenance Requirements

Solana validators require 24/7 monitoring for missed signage points, vote transaction status, and network participation. Missing too many leader slots or falling behind in voting can result in lower reward earnings and degraded network standing. Validators typically use Grafana and Prometheus for metrics collection, tracking parameters like disk I/O, network bandwidth utilization, and CPU load during leader slots^[54].

Software updates happen frequently on Solana, with validators needing to coordinate upgrades to avoid falling out of consensus. The network’s rapid development pace means operators must stay engaged with Solana’s Discord, GitHub, and announcement channels. Unlike set-it-and-forget-it proof-of-work mining, Solana validation demands active technical management.

Case Studies: Infrastructure Decisions in Practice

Helius operates one of Solana’s largest validator operations with over 13 million SOL delegated stake. Their infrastructure specializes in RPC provision, running multiple RPC nodes distributed globally to serve development teams building on Solana. By combining validator rewards with RPC service revenue, Helius created a sustainable business model that doesn’t rely solely on stake delegation^[55].

GenesysGo took a different approach, offering completely free RPC access funded by profits from their validator node and NFT sales. The Shadowy Super Coder DAO (SSC-DAO) Validator generates sufficient revenue to subsidize public RPC infrastructure. This demonstrates how validators can leverage complementary revenue streams—NFT communities, MEV capture, or specialized services—to support network participation^[56].

“Gulf Stream is not just a technical optimization—it’s a fundamental rethinking of how blockchain networks handle transaction flow. By pushing state to the network’s edge and leveraging deterministic leader schedules, Solana achieves throughput levels impossible with traditional mempool architectures.” – Anatoly Yakovenko, Solana Co-Founder^[57]

Conclusion

Solana’s architecture represents a systematic reimagining of blockchain infrastructure, eliminating traditional mempools through Gulf Stream, leveraging Proof of History for trustless time-keeping, and using Tower BFT for rapid consensus. The network’s three commitment levels let developers choose appropriate trade-offs between speed and finality, while distinct node types (RPC and validator) serve different infrastructure needs. Understanding these systems helps miners evaluate whether Solana validation aligns with their operational capabilities and economic requirements. The approved Alpenglow upgrade, launching on testnet in December 2025 and mainnet in Q1 2026, promises to push finality below 150 milliseconds while dramatically reducing validator costs, potentially opening real-time application categories previously impossible on decentralized infrastructure.

Solana Finality Mempool FAQs

Does Solana have a mempool like Ethereum and Bitcoin?

No, Solana does not use a traditional public mempool. Instead, it uses Gulf Stream, which forwards transactions directly to upcoming block leaders based on the deterministic leader schedule. This eliminates network-wide transaction broadcasting and the memory pools that other blockchains maintain. Unlike Ethereum’s mempool system, Solana’s approach reduces latency and memory pressure on validators^[58].

What is Solana finality and how long does it take?

Solana finality refers to when a transaction becomes irreversible after a supermajority of validators vote on it and 32 additional blocks are built on top. Finalized commitment typically takes approximately 12.8 seconds, while optimistic confirmed commitment occurs in 1-2 seconds with negligible rollback risk^[59].

What commitment level should I use for Solana transactions?

Use confirmed commitment for most production applications, as it provides strong security (66 percent validator agreement) with fast feedback (1-2 seconds). Use finalized only for high-value transfers where you need absolute certainty. Never use processed commitment in production, as it carries approximately 5 percent fork risk^[60].

What’s the difference between Solana RPC nodes and validator nodes?

Validator nodes participate in consensus by voting on blocks and producing blocks during their leader slots, earning vote credits and transaction fees. RPC nodes maintain blockchain state and serve data to applications but don’t vote or earn rewards. RPC nodes are run to provide services rather than for direct economic returns^[61].

How much SOL do I need to run a profitable validator?

Running a profitable Solana validator requires significant delegated stake. Validators need approximately 50,000 SOL in delegated stake at 10% commission to break even, though validators self-staking may achieve profitability with around 5,000 SOL. This threshold exists because validators incur approximately 300-400 SOL annually in vote transaction costs plus hardware and infrastructure expenses. These economics will improve dramatically with the Alpenglow upgrade in Q1 2026, which will reduce validator operational costs by approximately 98%^[62,63].

How will Alpenglow affect validator profitability?

The Alpenglow upgrade (testnet December 2025, mainnet Q1 2026) will significantly improve validator economics by reducing vote-related operational costs by approximately 98%. Instead of paying ~2-3 SOL per epoch (~$60,000 annually based on 2025 prices) in on-chain vote costs, validators will pay a fixed Validator Admission Ticket (VAT) of 1.6 SOL per epoch (~$1,000 annually). This reduction will lower the profitability threshold for smaller validators and encourage greater network decentralization^[63].

Solana Finality Mempool Citations

[1] Helius Dev Blog, “Solana’s Gulf Stream: Mo Mempool, Mo Problems” (2025)

[2] Anatoly Yakovenko, “Gulf Stream: Solana’s Mempool-less Transaction Forwarding Protocol” (2020)

[3] Parallel Research, “Solana Gulf Stream” (2025)

[4] The Web3 Hub, “How Solana’s Gulf Stream Mempool-less Protocol Works” (2024)

[5] Solana Official, “Gulf Stream: Solana’s Mempool-less Transaction Forwarding Protocol” (2020)

[6] Solana Handbook, “Gulf Stream” (Ackee.xyz)

[7] Helius Dev Blog, “Solana’s Gulf Stream: Mo Mempool, Mo Problems” (2025)

[8] Parallel Research, “Solana Gulf Stream” (2025)

[9] Helius Dev Blog, “Solana’s Gulf Stream: Mo Mempool, Mo Problems” (2025)

[10] Mert Mumtaz, “Solana Gulf Stream: How Solana Transactions Work” (2024)

[11] Helius Dev Blog, “How to Land Transactions on Solana” (2024)

[12] JitoLabs, “Overview of Transaction Processing Unit”

[13] Agave Documentation, “Tower BFT” (Anza.xyz)

[14] Anatoly Yakovenko, “Tower BFT: Solana’s High Performance Implementation of PBFT” (2020)

[15] GridPlus Documentation, “Tower BFT”

[16] Solana Official Documentation, “Tower BFT”

[17] Anatoly Yakovenko, “Tower BFT: Solana’s High Performance Implementation of PBFT” (2020)

[18] Helius Dev Blog, “Consensus on Solana” (2025)

[19] GridPlus Documentation, “Tower BFT”

[20] Visa, “A deep dive on Solana” (2024); The Defiant, “Solana Seeks 150ms Finality with Alpenglow Upgrade” (May 2025)

[21] Chainspect, “Solana TPS, Max TPS, Block Time & TTF” (December 2025)

[22] GridPlus Documentation, “Tower BFT”

[23] Helius Dev Blog, “Solana Nodes — A Primer on Solana RPCs, Validators, and RPC providers” (2025)

[24] Solana Official Documentation, “Consensus Validator or RPC Node”

[25] Alchemy, “Solana Nodes – The Complete Guide” (2023)

[26] InstantNodes, “Solana RPC Node for Validators”

[27] Helius Dev Blog, “Solana Nodes — A Primer on Solana RPCs, Validators, and RPC providers” (2025)

[28] GetBlock.io, “Difference Between Solana RPC and Validator Node” (2025)

[29] Solana Official Documentation, “Setup a Solana RPC Node”

[30] RPC Fast, “Solana RPC Nodes—The Complete Guide” (2025)

[31] Solana Official Documentation, “Setup a Solana RPC Node”

[32] Helius Dev Blog, “What are Solana Commitment Levels?” (2025)

[33] Solana Official Documentation, “Transaction Confirmation & Expiration“

[34] Helius Dev Blog, “What are Solana Commitment Levels?” (2025)

[35] Mirror World, “Transaction commitment levels on Solana Explained”

[36] Solana Official Documentation, “Transaction Confirmation & Expiration”

[37] Chainstack Blog, “Solana: What is the right transaction commitment level?” (2025)

[38] Chainstack Blog, “Solana: What is the right transaction commitment level?” (2025)

[39] Solana Official Documentation, “RPC”

[40] CoinTelegraph, “Solana’s Alpenglow Upgrade: Sub-Second Finality, Faster Than Google” (September 2025)

[41] CryptoRank, “Solana’s Roadmap: Key Upgrades and What They Mean for Adoption” (November 2025)

[42] Stake.fish Blog, “Alpenglow: Solana’s Leap Toward Real-Time Consensus” (2025)

[43] Helius Dev Blog, “Consensus on Solana” (2025)

[44] QuickNode Blog, “Alpenglow Consensus: Solana’s Biggest Protocol Upgrade” (2025)

[45] CoinDesk, “What is Solana Alpenglow? Developer Anza Proposes ‘Largest’ Consensus Change to SOL Network” (2025)

[46] QuickNode Blog, “Alpenglow Consensus: Solana’s Biggest Protocol Upgrade” (2025)

[47] Stake.fish Blog, “Alpenglow: Solana’s Leap Toward Real-Time Consensus” (2025)

[48] Helius Dev Blog, “Solana’s Gulf Stream: Mo Mempool, Mo Problems” (2025)

[49] Helius Dev Blog, “Solana’s Gulf Stream: Mo Mempool, Mo Problems” (2025)

[50] Helius Dev Blog, “Solana’s Gulf Stream: Mo Mempool, Mo Problems” (2025)

[51] GetBlock.io, “Difference Between Solana RPC and Validator Node” (2025)

[52] RPC Fast, “Solana RPC Nodes—The Complete Guide” (2025)

[53] RPC Fast, “Solana RPC Nodes—The Complete Guide” (2025)

[54] Alchemy, “Solana Nodes – The Complete Guide” (2023)

[55] Alchemy, “Top 11 Solana RPC Node Providers” (2024)

[56] Anatoly Yakovenko, “Gulf Stream: Solana’s Mempool-less Transaction Forwarding Protocol” (2020)

[57] Helius Dev Blog, “Solana’s Gulf Stream: Mo Mempool, Mo Problems” (2025)

[58] Helius Dev Blog, “What are Solana Commitment Levels?” (2025)

[59] Chainstack Blog, “Solana: What is the right transaction commitment level?” (2025)

[60] Helius Dev Blog, “Solana Nodes — A Primer on Solana RPCs, Validators, and RPC providers” (2025)

[61] GetBlock.io, “Difference Between Solana RPC and Validator Node” (2025)

[62] Solana Compass, “How Much Do Solana Validators Make?” (2024-2025); Hivelocity, “Is Running a Solana Validator Profitable? The Economics Explained” (September 2025)

[63] Placeholder VC, “Leveling the Stakes on Solana” (September 2025); The Coin Republic, “What is Alpenglow Upgrade, and Why is it Bullish for Solana?” (September 2025)