Skip to content
Solana · First Principles

Gulf Stream: Life Without a Mempool

The pipeline overview drew a validator as an assembly line: transactions arrive, get ordered, get executed, get shipped out as a block. This page is about the very first stage — how does a transaction even reach the machine that will put it in a block? On Bitcoin and Ethereum the answer is “it floats in a shared pool and waits.” Solana deletes that pool. Understanding why is the cleanest possible illustration of the book’s throughline: to run a global state machine at hardware speed, you have to stop making transactions wait in a room and start delivering them straight to the desk that will process them.

That trick has a name — Gulf Stream — and it only works because of the clock you met in Proof of History. The clock makes the future knowable: Solana knows, right now, which validator will be producing blocks two seconds from now. Once you know that, holding a giant pool of pending transactions and gossiping them everywhere is not just wasteful — it is the wrong design.

The thing everyone else has: a mempool

Section titled “The thing everyone else has: a mempool”

Start with what Solana is replacing. On Bitcoin and Ethereum, a submitted transaction does not go to “the next block producer,” because the network is not built around forwarding to a single known producer. On Bitcoin, block production is a lottery — whoever finds the next proof-of-work hash — so the producer is fundamentally unknowable until it happens. On Ethereum the per-slot proposer schedule is known an epoch in advance, but the network still relies on a shared mempool (transactions serve a public fee market, and proposals can shift under reorgs), so clients gossip rather than address one proposer. Either way, the transaction is broadcast to everyone rather than aimed at the next producer.

So each transaction is gossiped to the whole network. Every node keeps a mempool: a local pool of valid-but-unconfirmed transactions it has heard about. When a node finally wins the right to build a block, it reaches into its own mempool, picks the most profitable transactions, and assembles the block.

   Bitcoin / Ethereum — the shared pending pool


   client ──┐
            ├─► gossip tx to peers ─► every node stores it in its mempool
   client ──┘                              │
                                           │  (thousands of copies, network-wide)
                                           ▼
                        whoever wins the next block reaches into
                        ITS mempool and pulls transactions out

This model is robust and simple, and it costs you three things:

  • Memory, everywhere. Every node holds a copy of every pending transaction. Under load the mempool swells into hundreds of megabytes of RAM per node, network-wide, most of it duplicated.
  • Latency. A transaction has to propagate to the whole network before it can be mined, then wait in the pool until some future producer happens to pick it. You are paying for a broadcast you did not need.
  • A blind spot. Because nobody knows the next producer, a client cannot reason about when its transaction might land or cleanly give up on it. It sits in limbo, re-broadcast, until it confirms or ages out.

None of these are bugs. They are the price of not knowing who produces next. Solana’s whole move is to make that knowable.

The enabler: a leader schedule known in advance

Section titled “The enabler: a leader schedule known in advance”

Here is the pivot. Because Proof of History gives every validator the same verifiable clock, Solana divides time into fixed slots (each on the order of 400 ms), and assigns each slot a single leader — the one validator allowed to produce a block in that slot. Crucially, that assignment is not a surprise. It is computed an entire epoch ahead from stake weights and a PoH-derived seed, so at any moment the network already knows who leads not just the next slot, but the next several hundred. (The mechanics of how stake is turned into that schedule are covered in Stake and the Leader Schedule; here we only need the fact that the schedule exists and is public, in advance.)

   The leader schedule is deterministic and known ahead of time


   slot:     100      101      102      103      104      105   ...
   leader:  Val_A ─► Val_A ─► Val_B ─► Val_B ─► Val_C ─► Val_C
             ▲                  ▲                  ▲
          leading NOW      leads in ~0.8s      leads in ~1.6s
                           (already known)     (already known)

Stop and feel how strange this is next to Bitcoin. On Bitcoin the identity of the next block producer is fundamentally unknowable until the moment it happens — that unpredictability is the whole security model. On Solana the producer of a slot two seconds out is a settled fact you can look up. That single difference is what makes the mempool obsolete.

Gulf Stream: forward, don’t pool

Section titled “Gulf Stream: forward, don’t pool”

If you know who the next several leaders are, why would you broadcast a transaction to the entire network and hope? You would send it straight to them. That is Gulf Stream in one sentence: clients and validators forward each transaction directly to the current leader and the next few upcoming leaders, ahead of their slots.

Concretely: a client (or its RPC node) looks at the leader schedule, sees that Val_B leads slots 102–103, and pushes the transaction to Val_B’s transaction-ingest port now — while Val_A is still leading slot 100. By the time Val_B’s slot actually opens, the transaction is already sitting in Val_B’s local buffer, pre-fetched and ready. The leader does not have to wait for anything to propagate; the instant its slot begins, it can start stamping transactions into the PoH stream.

   Solana — forward to the upcoming leaders (no global pool)


   client / RPC ──► reads leader schedule
                        │
                        ├──► forward tx to Val_A  (leading now, slots 100–101)
                        └──► forward tx to Val_B  (upcoming, slots 102–103)
                                     │
                                     ▼
                        Val_B buffers it locally, BEFORE its slot opens.
                        Slot 102 begins ─► Val_B orders it immediately.

The transaction never joins a network-wide pending pool. It goes to a handful of specific machines — the leaders who can actually act on it — and nowhere else. The forwarding typically overshoots to two or more upcoming leaders, so if the current leader stumbles or skips its slot, the next one already holds the transaction and can pick it up. That redundancy is deliberate: it replaces the mempool’s “everyone has a copy” safety net with a much smaller “the next few producers have a copy” one.

Under the hood — where forwarding actually happens

Section titled “Under the hood — where forwarding actually happens”

Two forwarding paths run in practice, and it helps to keep them distinct:

  • Client → leader. A wallet does not usually talk to the network directly; it submits to an RPC node, which knows the leader schedule and forwards to the upcoming leaders on the client’s behalf.
  • Validator → leader. A validator that is not currently the leader but receives a transaction does not sit on it. It forwards it onward to the machines that lead the upcoming slots. This is the transaction-ingest half of a validator’s networking stack — the front door of the TPU (Transaction Processing Unit), the leader’s assembly line you will meet next.

Notice that this is addressed delivery, not broadcast. The whole design leans on the schedule being correct and public, which in turn leans on the PoH clock being trustworthy. Break the clock and you break the schedule; break the schedule and Gulf Stream has no one to forward to. The stages of the pipeline are not independent — they are stacked on the clock.

The payoff

Section titled “The payoff”

Deleting the mempool buys three concrete things, each a direct inverse of a cost from the section above:

  • Lower confirmation latency. The leader does not wait for a transaction to propagate network-wide and then wait to be selected from a pool. It receives the transaction before its slot, so ordering can begin the moment the slot opens. You cut out an entire propagation-and-wait round.
  • No giant pending pool to hold in RAM. There is no network-wide mempool to keep in memory. Pending transactions live briefly in the buffers of a few upcoming leaders, not as hundreds of duplicated megabytes on every node. That memory goes back to doing real work — executing transactions.
  • Clients can drop and retry intelligently. Because the schedule is known, a client can reason about time. A transaction carries a recent blockhash that expires after a fixed window (roughly 150 slots, about a minute). If the leaders it was forwarded to don’t include it before that blockhash expires, the client knows it will never land, can stop retrying, and can resubmit with a fresh blockhash. Contrast the mempool’s limbo, where a transaction may linger indefinitely with no clean verdict. (The blockhash-as-expiry mechanism is detailed in The Message and Recent Blockhash.)

The cost this pushes onto validators

Section titled “The cost this pushes onto validators”

Nothing is free, and Gulf Stream’s bill lands squarely on the leader. In the mempool model, the flood of incoming transactions is smeared across the whole network — every node absorbs a share of the gossip. In the Gulf Stream model, that flood is aimed. Every client and every forwarding validator points its transactions at the same handful of upcoming leaders. For its ~400 ms in the spotlight, the leader is on the receiving end of a firehose pointed straight at it.

That has hard consequences:

  • Leaders must be well-connected and powerful. A leader has to absorb, deduplicate, verify signatures on, and buffer an enormous burst of inbound traffic in real time — which is a large part of why Solana validators need serious CPUs, lots of RAM, and high-bandwidth networking. The hardware bill from the foundations part is partly Gulf Stream’s bill.
  • The firehose is a spam vector. If forwarding a transaction to the leader is nearly free for the sender, an attacker can point garbage at the leader and try to drown out real traffic — exactly the kind of load that has, historically, been able to knock the network over. Solana’s answers to that — stake-weighted Quality-of-Service on the ingest port, per-account fee markets, and the compute budget with priority fees — are all downstream of this one design decision. We are foreshadowing them here so that when you meet them you recognize the problem they solve: how does a machine survive having a firehose aimed at it on purpose?

Hold that tension. Gulf Stream trades the mempool’s diffuse, everyone-shares-the-load robustness for a concentrated, low-latency delivery straight to the producer. The upside is speed and memory; the downside is that the leader becomes a single, predictable, high-value target for load — which is precisely the problem the rest of the validator pipeline, and later Solana’s QoS machinery, has to defend against.

The architect’s lens

Section titled “The architect’s lens”
  • Why does it exist? Because a global mempool is dead weight once you know who produces the next blocks. Proof of History makes the leader schedule knowable in advance, and the moment producers are addressable, broadcasting to everyone and pooling everywhere is strictly worse than forwarding to the few machines that can act.
  • What problem does it solve? The latency and memory cost of the shared pending pool: propagate-then- wait confirmation delay, hundreds of megabytes of duplicated pending transactions per node, and a client’s inability to reason about when (or whether) its transaction will land.
  • What are the trade-offs? You swap the mempool’s diffuse, load-sharing robustness for concentrated, low-latency delivery. Latency and memory improve dramatically; in return the current leader becomes a predictable, high-value target that must absorb a firehose — pushing real cost onto validator hardware and opening a spam surface.
  • When should I avoid it? When you cannot know the next producer in advance — i.e. any chain whose security relies on the producer being unpredictable (Bitcoin’s PoW lottery). Gulf Stream is only sound because the schedule is both deterministic and public; without a trustworthy clock to seed it, there is no one to forward to.
  • What breaks if I remove it? You fall back to a global mempool: confirmation latency climbs (extra propagate-and-wait round), every node pays the RAM tax again, and the leader can no longer start ordering the instant its slot opens because transactions have not been pre-delivered. The pipeline’s first stage stalls, and hardware-speed throughput becomes unreachable.

Check your understanding

Section titled “Check your understanding”
  1. On Bitcoin and Ethereum, why must a transaction be gossiped to the whole network instead of sent straight to the next block producer? What three costs does that impose?
  2. What property of Proof of History makes Gulf Stream possible, and what exactly does that property let the network know in advance?
  3. Describe the path a transaction takes under Gulf Stream, from client to the machine that orders it. Why is the transaction forwarded to several upcoming leaders rather than just one?
  4. Name the three payoffs of deleting the mempool, and explain how “clients can drop and retry intelligently” depends on the schedule being known.
  5. What cost does Gulf Stream push onto the leader, and why does that cost foreshadow Solana’s need for stake-weighted QoS and priority fees?
Show answers
  1. Because neither network is built to address a single known producer: on Bitcoin the next producer is a PoW lottery winner that is fundamentally unknowable in advance, and on Ethereum — though the proposer schedule is known an epoch ahead — the network still relies on a shared mempool (public fee market, proposals that can shift under reorgs). So clients broadcast to everyone rather than aim at one producer. The three costs: memory (every node stores every pending transaction, duplicated network-wide), latency (a transaction must propagate everywhere and then wait to be picked from a pool), and a blind spot (a client cannot reason about when or whether its transaction will land).
  2. PoH is a verifiable clock that lets Solana divide time into deterministic slots and assign each slot a single leader, computed an epoch ahead from stake and a PoH seed. That makes the leader schedule public and known in advance — the network already knows who leads not just the next slot but the next several hundred.
  3. A client submits to an RPC node, which reads the leader schedule and forwards the transaction directly to the current and next few upcoming leaders — landing in their local ingest buffers before their slots open, so the producing leader can order it the instant its slot begins. It goes to several leaders for redundancy: if the current leader stumbles or skips its slot, the next one already holds the transaction and can include it, replacing the mempool’s “everyone has a copy” safety net with a smaller “the next few producers have a copy” one.
  4. Lower confirmation latency (no propagate-then-wait; the leader is pre-loaded), no giant pending pool in RAM (pending transactions live briefly in a few leaders’ buffers, not duplicated on every node), and intelligent drop/retry. The last one depends on the known schedule plus the transaction’s recent-blockhash expiry (~150 slots): because the client knows the timeline, if the forwarded-to leaders don’t include the transaction before its blockhash expires, it knows the transaction is dead, can stop retrying, and can resubmit with a fresh blockhash — instead of leaving it in indefinite mempool limbo.
  5. Gulf Stream aims the incoming transaction flood at the current leader, so for its ~400 ms slot the leader faces a firehose pointed straight at it — which is why leaders need powerful CPUs, ample RAM, and high-bandwidth networking. Because forwarding to the leader is cheap for the sender, an attacker can aim garbage at the leader to drown out real traffic, so Solana needs stake-weighted Quality-of-Service on the ingest port and priority fees / a compute budget to prioritize legitimate, fee-paying transactions under that load.