Every redistribution mechanism you’ve met so far had a quiet asterisk. Order-flow auctions (lesson 2) refunded your backrun — but you trusted the OFA operator to run the auction honestly and to route to the highest bidder. Intents and solvers (lesson 3) had you sign a goal and trust a solver to fulfill it well. CoW’s batch auctions (lesson 4) trusted the protocol’s solver competition to find the best clearing price. In every case, two things were taken for granted: the user revealed their order, and someone trusted ran the auction.
This lesson sharpens both frontiers. First, how much should you reveal? MEV-Share lets you turn that into a dial — trade a little exposure for a bigger refund, on your terms. Second, can we delete the trusted operator entirely? SUAVE is Flashbots’ attempt to make the whole auction layer credibly neutral, run by a decentralized network instead of one company’s relay. One is shipping today; the other is the endgame.
Before you read — take a guess
You're about to swap through an order-flow auction. Compared with hiding your transaction completely, revealing MORE about your order to searchers tends to do what to your refund?
MEV-Share: programmable privacy
MEV-Share is a Flashbots order-flow auction with a twist: instead of handing over your full transaction, you send it to a matchmaker and choose hints — selective scraps of information about your order that the matchmaker broadcasts to searchers.
- A hint is a deliberately partial disclosure: maybe just the function selector (which contract method you’re calling), maybe the pool you’re touching, maybe a fragment of calldata — but not the whole transaction. You decide which scraps to leak.
- The matchmaker is the operator that receives your private transaction, publishes only your chosen hints, runs the auction among searchers who want to back-run you based on those hints, and returns a refund of the matched value.
The analogy: you’re posting a redacted job ad. Reveal “senior Solidity role, remote, equity” and you attract the right applicants; black out the salary and the client name so competitors can’t reverse-engineer your hand. Reveal too little and nobody applies; reveal too much and you’ve handed away leverage. Hints are the redaction marker.
Concrete example: you’re selling 12.4 ETH for USDC. Reveal only “ETH/USDC pool, selling ETH” and a searcher knows the price will tick down, so they can profitably back-run the move and bid for the right to do so — you collect a refund. But because your size stays hidden, they can’t tell whether you sold 0.1 ETH or 100, so they can’t build the precise sandwich that needs your exact amount.
Pitfall: hints are not magic anonymity. Leak enough correlated scraps — the pool, the direction, a calldata fragment that pins down the amount — and a determined searcher can reconstruct your order anyway. Programmable privacy is a budget you can overspend.
Searchers see everything: maximum back-run value found, maximum refund — but maximum exposure.
Fill in the core MEV-Share tradeoff.
Pick the right option for each blank, then check.
In MEV-Share, revealing more hints about your order generally your refund, because searchers can find more value to bid on — but it also your exposure to attacks. Revealing nothing makes you fully private and leaves your refund at .
Remember lesson 2’s open question — OFAs refund backruns but don’t, by themselves, stop sandwiches. MEV-Share’s hints are a direct answer. A sandwich needs your exact size and price to size the front-run and back-run optimally. Hide the amount (and the precise swap) and the attacker simply can’t construct the optimal sandwich — yet a benign back-runner can still act on the direction and refund you for it. You keep the good MEV (refunded) and starve the bad MEV (under-informed).
The privacy–value frontier
Think of disclosure as a slider along a curve. At one end, fully private: perfectly safe, zero refund, because no searcher can act on what they can’t see. At the other end, fully public: maximum refund, because searchers compete hardest when they see everything — and maximum sandwich risk for exactly the same reason. Hints are the bowed middle of the curve: the sweet spot where you keep most of the refund while shedding most of the risk.
The analogy: a poker player who never shows a card wins no side bets but never gets read; one who plays face-up gets read constantly. The pros telegraph just enough — a hint — to get action without getting exploited.
| Reveal level | What searchers can do | Refund | Sandwich risk |
|---|---|---|---|
| Fully private | Nothing — they can’t see your order | None | None |
| Pool + direction only | Back-run the price move | Solid | Low (size hidden) |
| Pool + direction + size | Back-run and size an attack precisely | Higher | High |
| Full transaction | Everything, including front-run + back-run | Highest | Highest |
Definition recap: the frontier is just the set of “best achievable” points — for any level of risk you’re willing to take, the most refund you can extract, and vice versa. Your job is to pick a point on it, not to pretend you can have max refund and zero risk at once.
Pitfall: more refund is not automatically better. A whale revealing full size to squeeze out an extra few basis points of refund can lose far more to the sandwich that disclosure enabled. On the frontier, the optimal point depends on your trade size — small orders can afford to reveal more; large ones should stay shy.
Sort each outcome by whether it points you toward MORE PRIVACY or MORE REFUND on the frontier.
Place each item in the right group.
- Withhold the pool you're touching
- Leak only the function selector, nothing else
- Hide your exact swap size
- Broadcast extra hints so more searchers can bid
- Reveal the full transaction to all searchers
- Let searchers see the precise price impact of your trade
SUAVE: decentralizing the auction itself
MEV-Share fixes how much you reveal. It does not fix who runs the auction — there’s still a Flashbots matchmaker in the loop you have to trust. SUAVE — the Single Unifying Auction for Value Expression — is the attempt to fix that: a separate, decentralized, chain-agnostic sequencing layer where the auction operator is replaced by a network.
The shape of it, at a high level:
- An encrypted mempool: a decentralized pool where users submit their preferences/intents in encrypted form, so no single party (and no front-runner) can read them while they wait to be matched.
- A programmable execution environment — Flashbots calls it the MEVM (an MEV-flavored EVM) — where solvers and executors run logic to discover the best way to fulfill those encrypted orders, with the rules enforced by code rather than by a trusted operator’s good behavior.
- Decentralized block building / ordering: a network of competing builders assembles blocks and computes orderings on credibly-neutral infrastructure, rather than the whole thing happening inside one company’s relay.
The analogy: lessons 2–4 ran the auction through a single trusted auctioneer standing at the front of the room — fast and effective, but you have to take their word for it. SUAVE is the move to an open, rules-enforced exchange anyone can join and anyone can verify: no single auctioneer to bribe, mislead, or shut down. It’s the literal “democratize” verb from lesson 1, applied to the auction machinery itself.
Concrete example: instead of sending your swap intent to one OFA operator who promises to route it to the best searcher, you publish an encrypted preference to SUAVE’s mempool; a decentralized set of executors competes inside the MEVM to fulfill it; and the winning result settles through decentralized block building — with each step verifiable rather than vouched-for.
Pitfall: “decentralized” doesn’t automatically mean “trustless.” The encrypted mempool only stays private if the decryption scheme holds (more on that below), and a poorly designed executor market can re-centralize around whoever has the fastest hardware — the same gravity that pulls builders toward dominance everywhere else in the stack.
Match each piece of the MEV-Share → SUAVE picture to what it is.
Pick a term, then click its definition.
Why decentralize the operator
So why bother? MEV-Share already refunds you and shields your size — isn’t a single fast operator good enough? It is, until you ask the uncomfortable questions that lesson 6 will weigh in full. A single OFA or solver operator:
- can censor — quietly drop transactions it dislikes, or from addresses it’d rather not serve;
- can underpay — route to a friendly searcher instead of the genuine highest bidder, and you’d never know;
- can extract rents — sit in the middle and skim, because there’s no competitor watching;
- is a single point of trust and failure — one subpoena, one hack, one outage, and the whole redistribution pipeline stops.
The analogy: a benevolent monopoly is still a monopoly. It might hand out fair refunds today, but “trust me” is not a property you can verify, and incentives drift. Decentralizing the auction turns “trust the operator” into “verify the network” — which is the only way redistribution stays honest once the numbers get large enough to be worth gaming.
Pitfall / honest framing: this is precisely the tension lesson 6 unpacks — the convenience and price-improvement of a slick centralized operator versus the censorship-resistance and verifiability of a decentralized one. They’re not free to combine.
Keep your skeptic’s hat on. SUAVE is early and ambitious — a research direction and evolving set of components, not a finished, battle-tested product you can route mainnet flow through today. And the privacy story has limits: MEV-Share’s programmable privacy is partial, not perfect (leak enough correlated hints and your order is reconstructable), while SUAVE’s “encrypted” mempool ultimately rests on assumptions that can fail — threshold decryption (enough operators stay honest), trusted hardware (the enclave isn’t compromised), or similar. “Encrypted” is a promise backed by a threat model, not a law of physics.
Recap
Big picture
- MEV-Share & SUAVE
- MEV-Share (programmable privacy)
- Send tx to a matchmaker, not a full broadcast
- Hints = partial disclosure (pool, selector, direction)
- Searchers back-run the hints → you get a refund
- Hides size → defuses sandwiches, keeps benign backruns
- Privacy–value frontier
- Fully private = safe, zero refund
- Fully public = max refund, max sandwich risk
- Hints = the sweet spot in the middle
- Optimal point depends on trade size
- SUAVE (decentralize the operator)
- Encrypted mempool for orders
- MEVM execution environment
- Decentralized block building / ordering
- Replaces trusted auctioneer with a network
- Why & caveats
- Operator can censor, underpay, extract rents, fail
- Verify the network instead of trusting the operator
- SUAVE is early; privacy is partial; encryption has assumptions
- MEV-Share (programmable privacy)
Check yourself: privacy and decentralization
What is a 'hint' in MEV-Share?
Check your answer to continue.
Where this leaves us
You now have the full toolkit of MEV redistribution: order-flow auctions that refund your backrun, intents and solvers that compete to fulfill your goal, batch auctions that share a uniform clearing price, programmable privacy that lets you tune exposure against refund, and a decentralization vision that aims to delete the trusted operator altogether.
But notice we’ve been collecting promises faster than we’ve been auditing them. A slick centralized operator delivers better price improvement because it’s centralized; a decentralized one resists censorship at the cost of speed and simplicity. Hiding your order protects you but starves the auction of the very information that produces a refund. These tensions don’t cancel — they trade off. Lesson 6 puts all of it on the scale honestly: price improvement vs. solver centralization, censorship-resistance vs. convenience, trust vs. verifiability — the mechanism-design tradeoffs that decide which of these ideas actually survive contact with the real, adversarial world.