Does Hiding a Trade Make Ordering Fair?
Compare public and private order flow to see what searcher visibility changes—and which trust boundaries remain.
- Explain which visibility path private flow removes
- Compare public ordering with private packaging
- Recognize that protecting users does not remove ordering power
- PREVIOUSWho Back-runs the Price Gap a User Creates?
- CURRENTDoes Hiding a Trade Make Ordering Fair?
Compare public and private order flow to see what searcher visibility changes—and which trust boundaries remain.
- NEXTFree sandbox
Think about these questions first.
Choose an answer before opening the explanation. You can add anything unexpected to your review list.
Q01Does keeping an order out of the public mempool eliminate MEV?＋
It reduces observation by public searchers but hands ordering, censorship, and fallback power to private builders or relays. MEV does not disappear; the trust boundary moves.
Sending a transaction through private order flow can reduce the chance that public searchers see user intent, but it does not remove ordering power. Visibility moves to the relationship between the builder, proposer, and order-flow service—and a new trust boundary appears.
Public protection and private protection are different answers
The public path is observable and competitive, but it exposes intent to searchers. A private path may reduce public sandwiches, but you must trust the service not to censor, delay, leak, or reorder—and understand who receives payment.
Who gets to choose the order?
Put one swap into a deterministic pool, then watch visibility, ordering, slippage protection, and extraction change the result.
Repeat the user trade with public and private visibility, and name the trust boundary that remains.
- 01Mempoolintent is visible→
- 02Block orderwho goes first→
- 03Statereplayed by nodes
A mempool record is not a fill. The block order is not a payout. Only execution moves balances and pool reserves.
Searcher profit, proposer tip, pool fees, and user output live on the same ledger.
Submit one user swap first. The key question is not whether the transaction is valid, but who can see and order it before it becomes shared state.
- 01
Public pool created: 120,000 credits + 1,000 TOKEN, any public transaction can change the next quote.
Use the slider to return to an earlier step. Continuing from there replaces the later history with a new sequence.
Switch between plain public ordering and private flow with the same user swap. The lab does not label private flow “safe”; it removes one public visibility path and concentrates control among different participants.
Expand: how this step works
public: user → public mempool → many searchers → builder → proposer
private: user → private relay/builder → proposer
This is not a simple decentralized/centralized binary. Ask who can compete, who can see orders, who can censor, whether payment is verifiable, and whether a failed private submission can return to a public path.
What risk does private order flow most directly reduce?
The final systems question
MEV design is not a search for a system with no profit. Ask instead: which public rule creates the profit, can the user set an acceptable boundary, is ordering power observable, and is there a traceable fallback after failure or censorship?