Order Flow Auctions: The New Private Mempools

Over the last few months, Jito has received reports from different ecosystem stakeholders and applications about an increase in frontrunning and new forms of wide sandwiching. These reports have coincided with broader adoption of order flow auctions (OFAs) by client teams and validators. OFAs are, in practice, private mempools: they give third-party searchers privileged access to users’ transactions under a profit-sharing structure.
Opinions differ on whether these practices are acceptable, and even on whether some of the new forms of MEV appearing should be described as sandwiches or as market inefficiencies. In this post, we share our learnings from the Jito mempool and provide an update on the current state of OFAs.
Rather than debating what is acceptable using narrow technical definitions, we want to approach the subject from what we think is the critical angle: do these practices contribute to or detract from Solana’s goal of being the best place to trade any asset?
Our Learnings: The Jito Mempool
In March 2024, Jito decided to shut down its public mempool service, after running it since launch. Originally intended to help validators capture higher tips through improved arbitrage, it devolved into an untenable environment where Solana's users were being impacted by the prevalence of sandwich attacks.
In its original announcement, Jito Labs stated:

Before shutting it down, the Jito team spent countless hours trying to figure out how to classify and monitor extractive behavior, while enabling value capture from net-positive arbitrage like backrunning. After realizing this would be a never-ending cat-and-mouse game, Jito ultimately decided to shut down the mempool for the benefit of the network.
This coincided with Solana seeing unprecedented levels of retail trading adoption and validator profits. The network established itself as the best venue for spot trading in crypto during this period.
How OFAs Work
As individual validators and client teams try to differentiate themselves and generate higher rewards for stakers, we've seen the return of private mempools with accelerated adoption. We estimate 30-40% of stake is participating in some form of OFA currently.The premise is simple:
- The OFA provider establishes relationships with searchers and validators
- The validator runs the OFA provider’s custom client or sidecars
- Validators send their inbound transactions (TPU traffic) to the OFA provider during their leader slots
- Sidecars delay and hold transactions when that validator's leader slots are up
- Searchers working with the OFA provider do MEV on that order flow, with profits shared between the searchers, the OFA provider and the validator
Much has been said about whether the general concept of “privatizing” order flow is good or bad, often depending on the type of MEV it enables. That broader topic is outside the scope of this post, which focuses on the effects of the specific OFAs described above.
The OFAs’ Expected Guarantees
OFA providers market KYC and anti-frontrunning mechanisms as guardrails against extractive behavior. Even taking these efforts in good faith, there are two key problems for all involved stakeholders:
- You have to trust that the OFA providers' controls are robust, and that they will maintain them.
- There is no recourse. You can only catch a violation after the fact, when the losses have already materialized.
The above are particularly troublesome for applications and their end users, who participate in these agreements indirectly and without their consent, yet are the ones materially affected when value extraction happens: applications can lose customers, and users can lose funds.
The Question That Matters
That brings us to the most important question: are these arrangements making Solana a better execution environment for apps and users?
The early evidence we’ve gotten, from the applications themselves and from users receiving suboptimal trade execution, says no.
In several instances, a newer pattern has been raised to us, which is prevalent on validators running a specific OFA provider’s client. It consists of bots backrunning a sequence of buy transactions sent over microseconds in the same slot, effectively pushing the price of the asset in-between buys, and selling afterwards to profit from the price increase of the latter buys. Some argue it’s a consequence of bad app design, while others see it as a new form of sandwiching enabled by unique information advantages. Either way, the result is the same: applications’ execution quality is suffering, and users are losing money.
Another OFA provider enabled wide sandwiching on multiple applications in recent months. The extraction persisted for weeks until we notified them directly. The explanation was an oversight failure by the OFA provider over one of the participating searchers. Users who lost funds during that time received no recovery. This is the pattern described above: controls failing silently, violations caught only after extended losses, and nobody made whole.
Execution issues related to OFAs have become a frequent topic between Jito and leading Solana applications over the last two months. When consulted about sharing data for this piece that linked sandwiching on their applications to specific searchers and validators, all of them asked us not to share it.
Jito’s Take
When discussing these topics, it’s easy to get lost in mechanism design, game theory and individual subjective perceptions of what is right or wrong, missing the forest for the trees and forgetting what should drive how we think about this:
The most important thing is to make Solana the best place to trade any asset. That is a clear objective that we can all align behind, and it’s the only way everybody wins, be it SOL holders, validators or builders.
At Jito, that is what we work towards every day, through two of our core products: BAM and JTX. We believe this depends on users and applications trusting that their transactions will execute fairly, as every subpar outcome that comes as a result of a suspicious or ambiguous practice erodes that trust.
The end user is not thinking about whether what happened was technically a sandwich, whether it’s immoral to frontrun them, or who has a deal with whom. They will just see the quality of their fill, and if it’s not competitive with the market, they will go elsewhere, plain and simple.
Call to Action
Through its mempool, Jito found out firsthand that monitoring and controlling systems that provide privileged transaction data to third-party searchers is extremely challenging and creates an endless game of whack-a-mole. We are seeing that play out again, with a clear acceleration of reported issues as these OFAs have gone live.
On the block building side, maximizing validator rewards is an imperative for BAM, but not at the expense of applications and users. Now, as an app builder through JTX, we are even more aligned with making Solana the best place to trade any asset.
The question for everyone else is the same one: do your actions make Solana a better place to trade, or a worse one?
For validators, that means knowing whether your chosen client is giving third parties privileged access to user transaction data, to users’ detriment. For stakers, it means using execution quality as a delegation criterion alongside APY. For applications, it means knowing how you route user transactions and whether you adjust for validators with worse execution.
Solana’s stated goal is Internet Capital Markets. Every successful capital market shares a basic rule: no one with privileged visibility into customer orders gets to trade ahead of them. The arrangements described in this article have crossed that line, and the question for anyone participating in them is whether they are building ICM or selling it off one slot at a time.