MEV, vintages, and the price of one block
In a classic parimutuel, delaying someone's transaction by one block is economically inert. Everyone in the pool is paid the same multiple regardless of when they arrived, so ordering does not matter and there is nothing to extract from seeing flow early.
Under the vested rule, ordering is payout. That makes advance sight of order flow directly monetizable, and the paper is explicit that this is a new risk class relative to a classic parimutuel — not a pre-existing problem the mechanism inherits.
This article is about what the mechanism removes, what it prices, and what it can only mitigate.
What is removed: the intra-block game
All entries in one block share a vintage, and the batching rule is normative:
- Every entry in a vintage vests to the books as they stood at the start of the vintage — so same-vintage entries never vest to each other.
- Capacity granted by a vintage's entries becomes usable only from the next vintage.
- When joint same-vintage demand
D_wexceeds a book's headroomH_w, every entry is filled at the same book fraction⌊c_e · H_w / D_w⌋.
Rules (i) and (ii) remove the ordering game from vesting. Rule (iii) removes it from acceptance, and it is the one that completes the claim — without it, acceptance under a binding κ would fill in intra-block order, and the priority race that vesting no longer has would reappear exactly where priority is most valuable.
With all three, settlement is invariant under permutation within a vintage in both vesting and acceptance (conformance cases V1–V3). The paper's claim is narrow and, after the rationing rule, actually true:
No intra-block ordering game.
But order-free is not size-strategyproof. An entry's rationed share rises with its offered size while the refused remainder costs nothing, so under a binding κ the within-block contest becomes an oversizing game — offer more than you want, take your pro-rata slice.
This is the standard property of pro-rata matching everywhere it is used, and it is disclosed rather than solved. The mitigations, at their stated costs:
- Fee or bond the offered amount rather than the accepted one.
- Cap per-account offers (costs sybil pressure).
- Run κ large enough that headroom rarely binds.
What is priced: the inter-block game
Between blocks, the game is real, and the paper gives the capture formula rather than gesturing at it.
A party who sees a stake before inclusion — a sequencer, an RPC or API operator, a peered searcher — can take the opposing vintage one block earlier and capture that stake's vesting with little principal and little uncertainty.
Front-running a victim stake c into an opposing book of principal P with a stake of f captures:
c · f / (P + f)
of contingent claim. So the marginal value of one block of foresight on one stake is ≈ c·f/(P+f) — increasing in the victim's size and in the thinness of the book — and the front-runner's optimum trades that against (1−p)·f of event risk.
Three things to read off that formula.
Thin books are the target. As P → 0, the capture approaches the whole of c. New markets and unloved outcomes are where this is worth doing, which is exactly the long tail the mechanism is for.
The victim is indifferent. Their stake is accepted at the same size and vests to the opposing book either way. The loss falls on the honest early holders who would otherwise have shared that flow. That makes it a hard attack to complain about, because the party who notices is not the party who is hurt.
Under a binding κ there is a second surface, and there the victim is not indifferent. The same foresight steals acceptance headroom — the front-runner consumes the capacity, and the victim is refused. That one has a visible victim and a visible complaint.
The mitigations, each with its cost
The paper lists mechanical mitigations that compose, and prices each:
| mitigation | what it does | cost |
|---|---|---|
| commit–reveal entry | removes flow visibility entirely | a round trip of latency, plus a griefing-bond design for unrevealed commits |
| threshold-encrypted mempool | same, at the chain level | only available where the chain offers it |
| k-block epoch vintages | widens the batch, so foresight buys less | trades time resolution against ordering value |
| non-extraction commitment | a venue promise covering ordering and flow visibility | weaker than any of the above — it is a promise, not a property |
The epoch dial is the natural extension of what §4.4 already specifies: if a one-block vintage removes the game inside one block, a k-block vintage removes it inside k. What you lose is granularity — a market whose vintage is 12 blocks wide has a coarser notion of "when you arrived", which is the thing the mechanism pays for.
For a venue on a centralized sequencer, the paper's instruction is direct: treat flow confidentiality as a mechanism parameter, publish a non-extraction commitment covering ordering and flow visibility, and understand that a commitment is weaker than any of the mechanical options. Saying "we don't front-run" is not the same kind of object as "we cannot see the flow."
Block time is the mechanism's time resolution
This is the mechanism's one genuine chain sensitivity, and it is worth stating plainly because everything else about it is chain-agnostic. The settlement identity is one accumulator update per outcome and nothing in it prefers an execution environment.
But vintages batch per block, so block time is the mechanism's time resolution. The ordering games removed at the intra-block level reappear between blocks, and their value scales with how long a block is.
The paper's summary: "At two seconds they are small; at twelve they are not."
A practical reading:
| block time | inter-block MEV surface | posture |
|---|---|---|
| ~1–2s | small | ordinary mitigations suffice |
| ~12s | material | commit–reveal or encrypted mempool worth the cost |
| centralized sequencer, any speed | operator-controlled | flow confidentiality is a parameter you must publish |
The rest of the deployment requirements are about rails rather than consensus: settlement in a native stablecoin, per-transaction attribution, a machine-payable request standard, and agent-readable market discovery. Any chain that offers short blocks and those rails will carry this.
Why this is worse than in a classic pool, stated plainly
It would be easy to file MEV under "a general blockchain problem." The paper refuses that framing, and it is right to:
Delaying someone by one block is economically inert in a classic parimutuel and a direct transfer here.
That is the honest comparison. A venue migrating from classic pools is acquiring an extraction surface it did not previously have, and the acquisition is a direct consequence of the property that makes the mechanism worth adopting — if when you arrived determines what you are paid, then whoever controls when you arrive has something to sell.
There is no version of this design where that is not true. The mechanism's contribution is to remove the sub-block portion of it as an identity, publish the formula for the rest, and list the mitigations with their prices — rather than to claim the problem away.