Skip to content
Solana · First Principles

The TPU: The Leader's Assembly Line

The previous page, Gulf Stream: Life Without a Mempool, answered where transactions go: not into a shared pool, but forwarded straight to the validator that the leader schedule says will produce the next few blocks. This page answers what that validator does with them once they arrive. It is where the throughput bet of this whole book — a single global state machine running at hardware speed — is either won or lost, because for its slots, this one machine is the entire network’s bottleneck.

The answer is a pipeline. Solana calls the leader’s pipeline the TPU — the Transaction Processing Unit — and the name is a deliberate borrow from CPU design. A CPU does not fetch, decode, and execute one instruction to completion before touching the next; it runs those stages at the same time on different instructions, so the silicon is never idle. The TPU does the same thing with transactions. This page walks the assembly line stage by stage and shows why decoupling the stages is the whole trick.

The TPU runs only when you are the leader

Section titled “The TPU runs only when you are the leader”

A Solana validator is always doing one of two jobs, and it switches between them on the slot boundary dictated by the leader schedule:

  • Leader (its assigned slots, a few in a row): it produces the block. It ingests transactions, orders and executes them, and broadcasts the result. That production pipeline is the TPU.
  • Not the leader (the vast majority of the time): it validates blocks other leaders produced. It receives the broadcast, replays the transactions to check them, and votes. That validation pipeline is the TVU — the Transaction Validation Unit — and it gets its own page, The TVU: Validating on the Receiving Side.
   one validator, over time:


   slot:   ... 431   432   433   434   435   436   437 ...
   role:   TVU   TVU   TPU   TPU   TPU   TVU   TVU
                       └──── you are leader ────┘
                       produce blocks           back to validating

The distinction matters because the two paths have opposite shapes. The TVU is reactive — a block arrives, you check it. The TPU is generative — you are the one deciding what goes in the block and in what order, so you own the hard problems: filtering spam, ordering fairly, executing in parallel, and getting the block out to everyone before your slots run out. The rest of this page is the TPU; keep the TVU in your pocket as the mirror image we return to later in the part.

The stages, in order

Section titled “The stages, in order”

The TPU is four stages in a line, each handing its output to the next. Follow one transaction all the way through:

   packets over          batches of              executed txs,          shreds to the
   QUIC                  signed txs              ordered by PoH         rest of network
     │                     │                        │                      │
     ▼                     ▼                        ▼                      ▼
   ┌───────┐   chan   ┌────────────┐   chan   ┌──────────────┐   chan   ┌───────────┐
   │ FETCH │ ───────► │ SIG-VERIFY │ ───────► │   BANKING    │ ───────► │ BROADCAST │
   └───────┘          └────────────┘          └──────────────┘          └───────────┘
   receive UDP/       batch-verify            execute against            split block into
   QUIC packets       ed25519 sigs,           accounts (Sealevel         shreds, send via
   coalesce into      drop invalid            parallel scheduler),       Turbine tree
   batches            (GPU-accelerated)       stamp order into PoH

Fetch — receive packets, now over QUIC

Section titled “Fetch — receive packets, now over QUIC”

The first stage does the least glamorous but most exposed job: pull raw packets off the network and coalesce them into batches. Historically this was raw UDP — cheap and fast, but connectionless, which means anyone could spray packets at a leader with a spoofed source address and no accountability. As of the 2022–2023 client work, the transaction-ingest path moved to QUIC (the same transport that backs HTTP/3). QUIC is connection-oriented over UDP: a sender must complete a handshake, which gives the leader a connection identity to rate-limit against, and lets it apply stake-weighted quality of service (more on that below). Fetch’s product is a stream of packet batches — grouping matters, because the next stage is dramatically cheaper per-transaction when it works on batches.

Sig-verify — batch-verify signatures, drop the invalid

Section titled “Sig-verify — batch-verify signatures, drop the invalid”

Every transaction carries one or more ed25519 signatures proving the accounts that must authorize it actually did. Before the leader spends any effort executing a transaction, it must check those signatures — an unsigned or badly-signed transaction is garbage and must never reach execution. Signature verification is expensive (elliptic-curve math, one verification per signature) and embarrassingly parallel (each signature is independent), which is exactly the profile that suits batching and often a GPU: hand a few thousand signatures to hundreds of GPU cores and verify them all at once.

This stage is also, for free, the network’s first real spam filter. A firehose of invalid transactions dies here, never touching the account database. That is why sig-verify sits early and why it is the natural place to shed load: if more valid-looking traffic arrives than the leader can execute, it is cheaper to drop low-priority packets before verifying them than after. This is where stake-weighted QoS earns its keep — connections from high-stake peers get proportionally more of the leader’s scarce verification budget, so an attacker with little stake cannot crowd out real users.

Banking — execute against the accounts

Section titled “Banking — execute against the accounts”

The surviving, verified transactions reach the banking stage, the heart of the pipeline. This is where two ideas you have already met come together:

  • Proof of History stamps the order. As transactions are accepted into the block, they are woven into the PoH hash chain — the verifiable clock — which fixes their relative order in a way every other validator can later check without trusting the leader. The next page, Banking and PoH: Stamping Order Into the Stream, is entirely about this coupling; here it is enough to know banking and PoH run together.
  • Sealevel executes them in parallel. Because every transaction declared the accounts it reads and writes up front, the banking stage can apply the conflict rule, group non-conflicting transactions into batches, and run each batch across cores. The banking stage is where Solana’s parallel-execution model actually runs on live traffic. Everything the Sealevel part taught in the abstract happens right here, inside one stage of the TPU, on a real 64-core leader.

Banking’s output is a stream of executed transactions with their PoH ordering fixed and their effects applied to the leader’s copy of the account state — in other words, the makings of a block.

Broadcast — get the block out

Section titled “Broadcast — get the block out”

A block nobody else has is worthless: the point of producing it is for the rest of the network to adopt it. The broadcast stage takes the executed, PoH-ordered transactions, splits the block into small packets called shreds, and sends them out — not to every validator directly (that would make the leader’s uplink the bottleneck) but through a tree, so each node forwards to a few others. That tree is Turbine, and it gets its own page, Turbine: Propagating Blocks as a Tree of Shreds. For now, broadcast is simply the last stage of the assembly line: banking makes the block, broadcast ships it.

Why the stages are decoupled by channels

Section titled “Why the stages are decoupled by channels”

Here is the part that makes it a pipeline and not just four functions called in sequence. The stages do not call each other. Each stage is its own thread (or pool of threads), and they are wired together by channels — queues that one stage writes and the next stage reads. Fetch drops packet batches into a channel; sig-verify pulls from it. Sig-verify drops verified batches into another channel; banking pulls from that.

This decoupling is the entire reason the pipeline is fast. Because the stages are independent, they run at the same time on different work:

   time ──────────────────────────────────────────────►


   FETCH:       [batch N]  [batch N+1]  [batch N+2]  [batch N+3]
   SIG-VERIFY:             [batch N]    [batch N+1]  [batch N+2]
   BANKING:                             [batch N]    [batch N+1]
   BROADCAST:                                        [batch N]
                          ▲
                          │ at this instant: fetch is pulling N+3,
                          │ sig-verify is checking N+2, banking is
                          │ executing N+1, broadcast is shipping N

At any given instant all four stages are busy on different batches. While sig-verify is grinding through the signatures of batch N, fetch has already moved on to receiving batch N+1 off the wire — it did not sit idle waiting for sig-verify to finish. This is exactly a CPU’s instruction pipeline: the throughput of the whole line is set by its slowest single stage, not by the sum of all stages. If each stage takes 1 unit of time, four transactions processed sequentially would take 4 units each end-to-end; pipelined, once the line is full it emits one completed batch every 1 unit. The stages overlap, so the machine’s cores, GPU, and network card are all working simultaneously instead of taking turns.

The channels also absorb bursts. If fetch suddenly receives a spike of packets, they queue in the channel rather than forcing the whole pipeline to stall or drop everything — and if a downstream stage falls permanently behind, the growing queue is the signal to shed load (drop low-priority packets), which is why the load-shedding logic lives near these channel boundaries.

Under the hood — why sig-verify is the stage that shapes the pipeline

Section titled “Under the hood — why sig-verify is the stage that shapes the pipeline”

Of the four stages, sig-verify is usually the one that decides the pipeline’s behavior under stress, and it is worth understanding why. Fetch is cheap (copy bytes off a NIC). Banking is bounded by the block’s compute budget and by real account contention (the hot-account ceiling from the Sealevel part). Broadcast is bounded by uplink bandwidth, which Turbine spreads out. But sig-verify sits on the widest input — it must look at every packet that arrives, including all the invalid and spammy ones, because it is the stage that decides which packets are even worth executing.

That combination — the widest input and per-item elliptic-curve cost — makes sig-verify both the natural spam filter and the natural load-shedding point:

   arriving packets  ──►  [ sig-verify ]  ──►  valid, prioritized txs  ──►  banking
        (huge, dirty)          │                    (smaller, clean)
                               ├─ invalid signature? drop here, never execute
                               └─ over budget? drop lowest-stake / lowest-priority first

Because this stage is where the network’s raw, adversarial traffic first meets a real cost, it is where Solana spends its cleverness: batch verification to amortize setup cost, GPU offload to raise the ceiling, and stake-weighted QoS to make sure that when something must be dropped, it is the traffic with the least skin in the game. A validator that let unauthenticated spam sail past sig-verify into banking would be burning its scarcest resource — execution time during its own leader slots — on garbage.

Connecting it back: the TPU is the throughput bet, made concrete

Section titled “Connecting it back: the TPU is the throughput bet, made concrete”

Step back and notice what the TPU is. Every big idea from the earlier parts of this book turns out to be one stage of this pipeline:

   idea (earlier part)                     ─►  its home in the TPU
   ────────────────────────────────────       ──────────────────────
   Gulf Stream forwarding to the leader    ─►  feeds FETCH
   ed25519 signatures (Cryptography)       ─►  checked in SIG-VERIFY
   Proof of History clock                  ─►  stamped in BANKING
   Sealevel parallel execution             ─►  run in BANKING
   Turbine tree propagation                ─►  driven by BROADCAST

The TPU is not a new mechanism to memorize; it is the place where the mechanisms you already learned are wired together into an assembly line. That is the answer to the book’s throughline for the production side: you build a single global state machine that runs at hardware speed by refusing to do the work serially — you pipeline the independent stages so the machine is never idle, and you parallelize the one stage (execution) that would otherwise dominate. The leader’s slot is a hard deadline, and every design choice in the TPU exists to fit a block inside it.

The architect’s lens

Section titled “The architect’s lens”
  • Why does it exist? Because for the slots it is leader, one validator is the whole network’s throughput bottleneck. The TPU exists to let that single machine ingest, filter, order, execute, and broadcast a block within a ~400 ms slot — by pipelining the work instead of doing it one transaction at a time.
  • What problem does it solve? Keeping every part of the machine busy at once. Naively, fetch waits for sig-verify, which waits for banking; the CPU, GPU, and NIC take turns and mostly sit idle. Decoupling the stages with channels lets them all run simultaneously on different batches, so throughput is set by the slowest stage, not the sum.
  • What are the trade-offs? Pipelining adds latency per transaction (it flows through four stages) and complexity (threads, channels, back-pressure, load-shedding rules). It also concentrates responsibility: during its slots the leader is a single point of both throughput and censorship, which is why the leader schedule rotates it constantly.
  • When should I avoid it? A pipeline this elaborate only pays off at high, bursty transaction volume on a machine with cores and a GPU to spare. A low-throughput chain gains nothing from four decoupled stages and would be simpler running transactions serially — the TPU is a direct consequence of Solana’s throughput-at-any-cost bet, not a universal design.
  • What breaks if I remove it? Collapse the stages back into one serial loop and a single heavy stage (sig-verify) can consume the entire slot, so the leader produces tiny blocks or misses its slots entirely — the chain’s throughput craters. Remove sig-verify’s spam filtering specifically and unauthenticated garbage reaches banking, letting a cheap flood exhaust the leader’s execution budget.

Check your understanding

Section titled “Check your understanding”
  1. The TPU and the TVU are two code paths in the same validator. Which one runs when, and what is the fundamental difference in their shape (generative vs reactive)?
  2. Name the four TPU stages in order and give the one-line job of each.
  3. The stages are wired together with channels rather than calling each other directly. Explain, using the fetch/sig-verify/banking/broadcast timeline, why this makes the pipeline faster — and what sets the pipeline’s throughput.
  4. Why is sig-verify the natural place to filter spam and shed load? What two techniques (one about the heavy math, one about whose traffic to keep) does Solana apply there, and what is stake-weighted QoS protecting?
  5. The banking stage is where an idea from an earlier part “actually runs.” Which idea, and what specific property of every transaction lets the banking stage do it?
Show answers
  1. The TPU runs during a validator’s own leader slots (a few slots in a row, per the leader schedule); the TVU runs the rest of the time. The TPU is generative — the leader decides what goes in the block and in what order, so it owns spam-filtering, ordering, parallel execution, and broadcast. The TVU is reactive — a block arrives and the validator checks and votes on it.
  2. Fetch — receive packets off the network (now over QUIC) and coalesce them into batches. Sig-verify — batch-verify the ed25519 signatures (often on a GPU) and drop invalid transactions. Banking — execute the verified transactions against the accounts (Sealevel parallel scheduler) and stamp their order into Proof of History. Broadcast — split the block into shreds and send them out through the Turbine tree.
  3. Because each stage is an independent thread reading from and writing to channels, the stages run at the same time on different batches: while sig-verify checks batch N, fetch is already pulling batch N+1, banking is executing N-1, and so on. Once the pipeline is full it emits one completed batch per unit of the slowest stage’s time, so pipeline throughput is set by the slowest single stage, not the sum of all stages. The channels also buffer bursts and provide the back-pressure signal for load-shedding.
  4. Sig-verify sees the widest, dirtiest input — every arriving packet, including spam — and paying its per-signature elliptic-curve cost is exactly when it can cheaply reject garbage before it reaches execution, so it is both the first spam filter and the natural load-shedding point. Solana applies batch/GPU-accelerated verification to amortize the heavy math, and stake-weighted quality of service to decide whose traffic to keep when it must drop some. Stake-weighted QoS protects real users from being crowded out: a low-stake attacker gets proportionally little of the leader’s verification budget, so it cannot drown out high-stake (legitimate) traffic.
  5. Sealevel parallel execution. It works because every transaction declares up front the accounts it reads and writes, so the banking stage can apply the conflict rule, group non-conflicting transactions into batches, and run each batch across cores — turning the abstract Sealevel model into execution on live traffic inside one TPU stage.