Does Solana have a mempool? TX lifecycle and what "mempool data" means

TL;DR

• No, Solana does not have a classical mempool. Gulf Stream forwards each transaction straight to the known upcoming leader, so there is no shared pool of pending transactions to subscribe to.
• The lifecycle is: user signs, RPC forwards, Gulf Stream routes to the leader, the leader's TPU executes, the block streams out as shreds, then it gets confirmed. Visibility begins at the shred stage, not before.
• Ethereum-style mempool sniping does not port over literally. The reaction window still exists, it just moved to the shred level and shrank from seconds to milliseconds.
• "Solana mempool data" as sold by vendors means one of two things: shred-level streaming with status simulation on the read side, or staked and block-engine submission on the write side. A Solana private mempool, in practice, is that second thing.
• MEV is alive on Solana. Jito shut its public pseudo-mempool in March 2024, but sandwiches still happen through bundles, so protection is about how you submit, not about hoping nobody can see you.

‍

Short answer: Solana has no mempool. Because the leader schedule is public in advance, transactions are forwarded directly to the validator about to build the next block instead of waiting in a shared pool. What people call "Solana mempool data" is not a pending pool at all. It is shred-level streaming plus status simulation, which is the earliest observable signal the network actually produces.

Why the mempool question keeps coming up

Almost everyone building on Solana arrives with Ethereum instincts. On Ethereum, the mempool is where unconfirmed transactions sit in public, visible to anyone, competing on gas. It is where searchers watch for opportunities, where replace-by-fee happens, and where a whole industry of tooling lives. So the first question is always the same: where is the Solana mempool, and how do I subscribe to it?

The answer is that there isn't one, and this is not an omission. It is the design. But the question is not naive either, because the underlying need is real: bot operators want to see what is happening as early as possible, and they want their own transactions to land without being read and reacted to. Solana answers both needs, just not with a mempool. This article walks the real lifecycle first, then explains precisely what is being sold when a provider advertises "Solana mempool data."

The transaction lifecycle, step by step

Six stages, from signature to finality. Knowing exactly where each one sits is what makes the rest of this article make sense, because the entire question of visibility comes down to which stage you can observe.

1. The user or bot signs

A transaction is built referencing a recent blockhash and signed. That blockhash matters more than newcomers expect: it is valid for roughly 150 slots, about a minute. It is not a nonce and it is not a queue position. It is an expiry timer.

2. The RPC node receives it

Your sendTransaction call lands on an RPC node. The node does not pool the transaction, does not hold it for a fee auction, and does not gossip it to peers for storage. It forwards it onward. This is the exact point where the Ethereum mental model breaks: on Ethereum the RPC hands your transaction to a pool, on Solana it hands it toward a specific validator.

3. Gulf Stream routes it to the leader

Solana publishes its leader schedule in advance, so every participant knows which validator produces the next blocks. Gulf Stream uses that fact to push transactions to the current and upcoming leaders directly. Transport is QUIC, and how much bandwidth you get is stake-weighted, which is why the same transaction from a staked connection and from a random public endpoint does not have the same odds of arriving.

4. The leader's TPU processes it

Inside the leader, the transaction enters the Transaction Processing Unit: fetch over QUIC, signature verification and dedup, then the banking stage where it is scheduled and executed, then stamped into Proof of History. The banking stage holds a priority buffer, and this is the closest thing on the entire network to a "pending" state. It is local to one validator, it lives for milliseconds, and nothing outside that validator can query it.

5. The block streams out as shreds

Solana does not assemble a block and then publish it. It streams the block out continuously as it is built, in roughly one-kilobyte fragments called shreds, with erasure coding for recovery, distributed through the Turbine tree. This is the first moment the transaction becomes observable to anyone who is not the leader.

6. Confirmation and finality

Validators replay the block, vote, and the transaction moves through confirmed to finalized. By the time a standard RPC subscription reports it at confirmed commitment, it has been observable in the shred stream for a meaningful amount of time already. For a trading system, that gap is the whole opportunity.

Why Ethereum-style mempool sniping does not port over

The classic Ethereum play is simple: watch the public pool, spot a large pending swap, and get your own transaction in front of it. That play depends on one thing, a window of time during which someone else's intention is public but not yet executed. On Ethereum that window is seconds long and open to everybody.

On Solana there is no public pending window at all. A transaction is in flight toward one leader, and the only parties with any view of it are that leader and infrastructure sitting directly on the path. By the time anyone else can see it, it is already in a block that is streaming out. So the literal Ethereum strategy, subscribe to pending and front-run it, has nothing to subscribe to.

What replaces it is a different game with a much tighter clock. Instead of reacting to intentions, you react to landings: you observe transactions as they hit blocks, in the shred stream, and you compete on how fast you can decide and submit your own response, potentially into the same slot. Slots are around 400 milliseconds, so the whole loop of see, decide, submit has to fit inside a budget where network hops matter more than clever logic.

MEV on Solana is real. The mechanics are just different

It is worth being blunt here, because a lot of Solana marketing is not. The absence of a mempool does not mean front-running is impossible or that sandwiches do not happen. It means the extraction happens somewhere else.

For a period, Jito ran an off-protocol pseudo-mempool that let searchers see pending bundles, and sandwiching flourished on it. Jito shut that mempool down in March 2024, giving up the associated revenue, precisely because the attacks were harming ordinary users. That closed the easiest path. It did not close every path.

Today, most MEV activity routes through the Jito block engine: searchers assemble bundles of transactions that execute atomically in a chosen order, attach a tip, and win an off-chain auction for inclusion. A sandwich on Solana looks like a bundle containing a front-run, the victim's transaction, and a back-run, all landing together. Searchers with optimized infrastructure and direct validator connections can observe transaction flow and respond to it, which is exactly what the official Solana MEV guidance acknowledges.

Solana narrows the MEV surface. It does not eliminate it. Anyone claiming otherwise is selling something.

The practical consequence for a bot operator is that protection is not a property of the chain. It is a property of how you submit. If your transaction goes out over a public path where it can be observed and reacted to before landing, you carry the risk. If it goes through a protected submission route, the observation window closes.

So what is being sold as "Solana mempool data"?

When a provider advertises mempool data for Solana, they are not selling access to a pending pool, because there is none to sell. They are selling one of two things, and it is worth knowing which one you are buying.

Read side: shred streaming plus status simulation

This is the closest functional analog to watching a mempool. Instead of reading pending intentions, you decode transactions out of the shred stream as blocks are produced, before execution metadata is complete and long before a confirmed-commitment RPC query would return anything.

The catch is that shred-derived data is early but incomplete. You get the transaction message: signatures, accounts, instructions, the slot. You do not get the full post-execution picture, no balance changes, no logs, no compute usage, no final status, because none of that exists yet at the moment you are reading. A decoded transaction may still fail, never confirm, or land on a fork that does not survive.

That gap is why status simulation matters. Aperture reconstructs validator shreds into a structured gRPC stream, and its TxStream protocol pairs that early view with roughly 95% status simulation, so you get both the earliest arrival and a high-confidence read on whether the transaction is going to succeed. That combination, see it first and know what it will do, is the practical answer to "I want to look inside the mempool." We covered the underlying trade-offs in ShredStream vs Geyser vs standard RPC and the implementation detail in Aperture gRPC explained.

Write side: staked and protected submission

The other half of what people want from a mempool is not visibility at all, it is the opposite: getting their own transaction in without anyone else reading it first. On Ethereum that is a private mempool or a relay. This is also what most people are really after when they search for a Solana private mempool: not a pool to read, but a submission path nobody else can watch. On Solana the equivalent is how you route your submission.

This is what Beam does. It routes signed transactions through SWQoS-backed validator paths, the Jito block engine, and partner delivery networks at the same time, races them, and takes whichever route wins the block. Staked submission gets you priority admission to the leader rather than competing in the unstaked lane, block engine routing keeps the transaction off public paths, and multi-path delivery removes the single point of failure that kills landing rates during congestion. Beam also streams live tip percentiles, so tip sizing is based on what is actually landing rather than a hardcoded guess.

What to take away

1. There is no mempool, and no amount of tooling changes that. Gulf Stream forwards to the known leader. The nearest thing to pending is a per-leader buffer you cannot query.
2. Visibility starts at shreds. The earliest observable signal is the block streaming out, which is meaningfully ahead of confirmed-commitment RPC.
3. The reaction window shrank, it did not close. Milliseconds instead of seconds, and reacting to landings instead of intentions.
4. MEV exists here. Bundles and direct validator connections replaced the public pool. Treat sandwich risk as reduced, never zero.
5. "Mempool data" is two products wearing one name. Early streaming with simulation on the read side, protected staked submission on the write side. Know which one your problem needs.

If you came here looking for a Solana mempool endpoint, the honest conclusion is that you were asking for the wrong object but the right capability. Stream from shreds when you need to see early. Submit through staked, protected paths when you need to land without being read. That pair is what a mempool was doing for you on Ethereum, and on Solana it is simply two separate, better-scoped tools.