Why Robinhood Chain has no public mempool

One line in Robinhood Chain's design gets traders' attention faster than any other: there is no public mempool, and transactions are sequenced first come, first served. This post explains what that actually means at the mechanism level, what a public mempool enables on other chains, and, just as importantly, what this design does not do for you. No magic claims here, only moving parts.

What a mempool is

On many chains, a transaction does not go straight into a block. It first lands in a mempool, a public waiting room of pending transactions that every node can see. Validators or builders then choose which pending transactions to include and in what order, often guided by fees: pay more, get placed sooner or in a more favorable position.

Two properties of that arrangement matter for traders. First, visibility: anyone can watch the waiting room and see your swap, its size, and its slippage limit before it executes. Second, orderability: because inclusion order is up for grabs, someone who sees your pending trade can pay to have their own transactions placed around it.

What that setup enables elsewhere

The classic sandwich attack is built entirely from those two properties. A bot watches the public mempool and spots a pending swap, say a large buy of some token. It places its own buy immediately before the victim's transaction, letting the victim's trade push the price up, then sells immediately after. The victim's swap executes at a worse price, inside the gap they left with a loose slippage setting, and the bot pockets the difference.

Notice what the attack requires. The bot needs to see the transaction before it executes, and it needs a way to influence ordering around it. Remove either ingredient and this particular trade structure has nothing to grip.

What Robinhood Chain does instead

Robinhood Chain sequences transactions first come, first served, and pending transactions are not visible before inclusion. Blocks arrive roughly every 100 milliseconds. In practice:

• There is no public waiting room. Your transaction goes to the sequencer and comes out included in a block. Between those two moments, there is no public feed where its contents sit exposed.
• There is no ordering auction. First come, first served means arrival order decides placement. There is no mechanism for a third party to pay for the slot directly in front of your trade after learning what your trade is.

So the sandwich setup described above has nothing to watch and no auction to bid in. The pre-trade information leak that the strategy is built on does not exist here, and that is a property of the chain itself, not a feature any app adds on top.

Saying it carefully

It would be easy to compress all this into "trades here are protected from MEV", and you should distrust anyone who does. That phrasing claims an outcome. What the chain actually provides is a mechanism: no public pre-inclusion visibility, and arrival-order sequencing. The honest statement is that the specific attack structure that depends on watching pending transactions has no input to work with on this chain. That is a statement about how the pipes are built, and it is where the claim should stop.

Adversarial behavior in markets adapts to whatever surface exists; describing today's mechanism honestly is not a warranty about every strategy anyone will ever run. Mechanisms, not promises.

What still matters: your slippage floor

Here is the part that deserves equal billing. Removing the mempool does not repeal market movement, and it does not make your execution price safe by default.

• Prices move between your quote and your fill. The market keeps trading in the moment between quoting and inclusion, even a fast one. Your fill can differ from your quote for entirely ordinary reasons.
• Your own trade moves the pool. Price impact comes from your order's size relative to pool depth, not from any attacker, and no sequencing design changes it.
• The minimum-output floor is still your real defense. A slippage tolerance sets the worst fill you will accept; the transaction reverts rather than fill below it. That floor is doing the protective work on every chain, this one included. The slippage guide covers how to set it well.

A loose slippage setting is a bad idea here for the same boring reason it is a bad idea anywhere: you are declaring, on the record, the worst price you will accept, and markets have a way of finding it.

How Splitshot builds on this

Splitshot treats the chain's sequencing as the floor, not the finish line, and pairs it with execution discipline:

• Automatic slippage sized from measured impact. Instead of a one-size-fits-all default, Splitshot probes each trade's own price impact and sets the tolerance from the measurement, clamped between 0.10% and 5%. Small trades in deep pools get tight floors automatically.
• One transaction, one floor. A split-routed order settles as a single multicall with a single minimum-output floor across all legs, so there is no partially-filled middle state where some legs land and others do not.
• A receipt you can check. Every swap links its Blockscout receipt, and the explorer guide shows how to confirm what you actually paid and received.

The bottom line

Robinhood Chain's design removes a specific, well-understood attack surface: with no public mempool and first-come-first-served sequencing, the watch-the-pending-transaction setup that sandwich trading depends on elsewhere has no input here. That is genuinely valuable, and it is also strictly a mechanism, not a blanket promise about outcomes. Your slippage floor, your attention to price impact, and your habit of reading receipts still carry the load they always did. Set the floor sensibly, size trades against real pool depth, and let the chain's sequencing be what it is: one good property among the several you still have to manage yourself. The swap walkthrough shows how these pieces fit together in an actual trade.