500ms Batch Auctions for MEV-Resistant Prediction Markets on Monad

Protocol
1

Hey everyone :waving_hand:

I’m Gianluca, building Predik, a decentralized prediction market that I want to launch natively on Monad.

I wrote a paper called:

“Temporal Discretization in Decentralized Prediction Markets: Mitigating LVR via 500ms Frequent Batch Auctions on Monad L1”

tl;dr

Design: ~500ms Frequent Batch Auctions (FBA) on top of Monad’s low-latency, pipelined execution.

Goal: Reduce LVR/MEV and make prediction markets fairer for LPs and traders.

Plan: Use an off-chain solver + on-chain settlement, potentially with encrypted/TEE-backed orderflow.

What I’m proposing

  • App-level 500ms auctions that clear all orders at a uniform price.

  • Settlement on Monad using a contract that updates balances/positions per batch.

  • Architecture tuned to Monad’s block time / finality and speculative execution.

What I’d love feedback on

  1. Protocol fit:
    Does this architecture make sense given Monad’s execution & consensus model (pipelined BFT, local mempools, speculative execution)?

  2. Testing it properly:
    Any recommendations for:

    • How to structure infra for a latency-sensitive app on testnet (own node vs provider, use of Execution Events/WebSockets)?
    • Gotchas around local mempools / ordering that matter for fair auctions?

  3. Realism check:
    From people thinking about MEV on Monad, does FBA + Monad’s performance realistically move the needle on LVR/latency arbitrage, or are there obvious pitfalls?

My plan is to actually ship this as a live prediction market on Monad, not just publish a paper.
If anyone from the team or community is open to a quick chat or async review, I’d love to share the draft + prototype.

You can also reach me on X or Telegram: @gianlucapanz

Thanks!
Gianluca

2

How important is composability to you? If the batching via backend is mandatory for successful execution then you disrupt atomic on-chain composability. If it isn’t, then there’s no MEV protection because others could frontrun / censor / backrun you.

Furthermore, if the batching is a prerequisite, then you can add an inventory escrow / lockup period to then deterministically issue ‘preconfirmations’ by virtue of having what’s effectively a permanent write lock on the prediction market state. Doing this means that you could issue results / outcomes to users prior to their batch’s tx landing on chain or being confirmed. Monad’s fast finality would help with cross-chain interactions but it wouldn’t help with getting confirms to users faster because you could already do that. Note also that having a write lock on the execution in absence of escrowing the inventory would subject you to giving all of your FBA participants a ‘free look’ and worse. They could write large tickets and then cancel them later by simply transfering their tokens before the batch lands.. so typically with a batch solver you want to either escrow the inventory or add some other disincentive for spoof orders, especially on a low gas cost chain like Monad. Relevant paper (without batching, but could be modified to include batching) here: https://arxiv.org/pdf/2503.05338

1 Like