A research idea for new members: can a swap prove it was treated fairly?

Most research starts with a question that sounds simple and turns out not to be. Here is one we keep coming back to in the lab:

When my swap lands on-chain, how do I know it was treated fairly, and could someone prove it to me?

Today the honest answer is "you can't, not really". You can look at the block afterwards and guess whether a bot traded around you. You can trust a private RPC that promises not to leak your transaction. But you get no receipt, nothing you could hand to a third party that says "this order was handled according to the rules". This post is an invitation to work on that gap. It is written for new members, so it assumes only that you have read our posts on zero-knowledge proofs and sandwich attacks, or are happy to.

None of this is a finished plan. It is a map with several roads marked on it, and we expect you to find roads we have not drawn.

Why this question is worth your time

Three things make it a good starting point for a student.

It matters to real people. Sandwich attacks on Ethereum alone took millions of dollars a month from ordinary traders in 2025, and on chains with public mempools and low fees they are still part of daily life. Every improvement in how orders are protected, or how protection is verified, has users waiting for it.

The data is free. Every block, every swap and every bot transaction is public. You do not need a lab partnership or a dataset licence to start measuring.

It sits where two strong areas meet. MEV research is mostly game theory and systems; ZK research is mostly cryptography. Very few people are fluent in both, so there is room for a student to become useful quickly by connecting them.

The idea in one picture

Imagine that the party who orders transactions (a builder, a sequencer on a rollup, or a solver in a batch auction) publishes a promise, such as "within each block I order transactions by the time I first saw them" or "every order in a batch gets the same clearing price". Alongside each block it publishes a short proof that it kept the promise. Any user, or a smart contract acting for them, can check the proof without trusting the builder and without the builder revealing everything it saw.

We call this a fair-order receipt. It is not a new primitive; it combines ideas that already exist in pieces. The research is in making it precise, cheap and hard to game.

Three ways in

You do not need to do all three. Pick the one that matches what you enjoy, and you will meet the others along the way.

Door 1: Measure (good if you like data)

Before building a defence, find out how big the problem is where you are. Pick one chain and one month, and answer:

• How many swaps were sandwiched, and how much did victims lose in total and per trade?
• How does the loss depend on slippage setting, trade size and pool depth? (Our MEV post predicts "loss ≈ slippage". Is that true in the data?)
• How much of the order flow already goes through private RPCs or batch auctions, and do those users really get sandwiched less?

There is plenty of published work for Ethereum, much less for other EVM chains and rollups, and very little that looks at how sandwiching changes when a chain changes its sequencer or fee rules. A careful, reproducible measurement on a less-studied chain is a real contribution and a natural first paper.

Door 2: Design (good if you like mechanisms and games)

Write down exactly what "fair" should mean. This is harder than it sounds, and it is where the interesting theory lives:

• First-seen order is intuitive, but "seen" by whom? Different nodes see transactions in different orders, which is the problem fair-ordering protocols such as Aequitas and Themis study.
• Uniform-price batches (as in CoW Swap) remove the before/after advantage inside a batch, but someone still chooses which orders go into which batch.
• Encrypted or commit-reveal ordering fixes the order before anyone can read the content, but adds latency and a key-management problem.

For each definition, ask what an attacker who controls ordering can still do, and what it costs honest users. A clear comparison, with small simulations, is also publishable, and it gives Door 3 something precise to prove.

Door 3: Prove (good if you like cryptography and code)

Take one definition from Door 2 and try to prove compliance in zero knowledge. A first prototype could be very modest:

1. Model a toy sequencer that receives timestamped, signed transactions and produces an ordered batch.
2. Write the rule "the batch is sorted by receive-time" as a circuit in Noir or Circom, or as a Rust program in a zkVM such as SP1 or RISC Zero.
3. Generate a proof per batch, and verify it in a Solidity contract on a testnet.

Then ask the questions that make it research: How does proving time scale with batch size? What stops the sequencer from lying about receive-times in the first place? Can a user check that their own transaction was included at the right place without learning about everyone else's?

Open questions nobody has fully answered

These are deliberately broad. Any one of them could become a thesis.

• Where does the trusted input come from? A proof can show a rule was followed on the inputs, but not that the inputs were honest. Can trusted hardware, threshold timestamping or multiple independent observers close that gap, and at what cost?
• What is the cheapest fairness worth proving? Full order-fairness may be too expensive. Is there a weaker property, such as "no transaction from the builder's own addresses surrounds any user swap in the same pool", that captures most of the harm and is easy to prove?
• Who pays for the proof? If proving costs a few cents per block, who should pay, and does that change who can afford to be a builder or sequencer?
• Can it work on today's chains? On a rollup with a single sequencer, a receipt could be added without changing Ethereum. What would it take, and would users or wallets actually check it?
• What do attackers do next? If sandwiches inside a block become provably impossible, does extraction move across blocks, across chains, or into the choice of which transactions get in at all?

A first month, in small steps

If you are new and want to try this, here is a realistic plan. Each step ends in something you can show at a lab meeting.

• Week 1. Read. Flash Boys 2.0 for the origin of MEV, and the SoK on transaction-reordering defences for the landscape. Write half a page in your own words on each, and post it as a paper review on this site.
• Week 2. Reproduce. Fork a mainnet block in Foundry or Anvil and replay one real sandwich: the front-run, the victim and the back-run. Recompute the victim's loss yourself.
• Week 3. Measure a little. Write a script that scans one day of swaps on one pool and flags candidate sandwiches (same pool, same bot address before and after a user swap, opposite directions). Compare your list with a public MEV explorer.
• Week 4. Prove a little. Write the smallest possible circuit that checks "this list of numbers is sorted", generate a proof, and verify it on-chain. Then think about what list a sequencer would need to sort, and what it would need to prove about it.

At the end of the month you will have a measurement, a working proof, and a much sharper version of the question than the one at the top of this page. That sharper question is the real deliverable.

How to get involved

If any part of this caught your interest, bring it to the next lab meeting or write to the group. You do not need to commit to the whole idea; a careful week-2 reproduction is already useful to everyone. And if you think the question itself is wrong, or that a better one is hiding behind it, that is exactly the kind of answer we are hoping for.