Change vs Post/Cancel on Monad

How Monad's parallel execution, 400ms blocks, and cold storage repricing interact with order book requoting strategies

Figure 1.0 : Post/Cancel Regime (3 Market Makers requoting after oracle move) SERIAL
Oracle Update
Cancel Order
Post Order
Taker Order
Block N t = 0ms
Oracle Price Update$85,000 → $85,100
MM-A
ON BOOK @ $85,000
MM-B
ON BOOK @ $84,990
MM-C
ON BOOK @ $84,980
Bid Depth
3/3 MMs quoting (stale)
Block N+1, TX1 t = 400ms
MM-A (highest priority fee)
Cancel @ $85,000free ID • update Idx16 • remove lock
NOT ON BOOK
Post @ $85,090alloc ID • update Idx16 • add lock
ON BOOK @ $85,090
MM-B
STALE @ $84,990
MM-C
STALE @ $84,980
Bid Depth
2/3 MMs quoting bids
Block N+1, TX2 re-executed (conflict)
MM-B (re-exec: Idx16 conflict)
Cancel @ $84,990free ID • update Idx16 • remove lock
NOT ON BOOK
Post @ $85,080alloc ID • update Idx16 • add lock
ON BOOK @ $85,080
MM-C
STALE @ $84,980
Bid Depth
1/3 MMs quoting bids
Block N+1, TX3 re-executed (conflict)
MM-C (re-exec: Idx16 conflict)
Cancel @ $84,980free ID • update Idx16 • remove lock
NOT ON BOOK
Post @ $85,070alloc ID • update Idx16 • add lock
ON BOOK @ $85,070
Bid Depth (final)
3/3 MMs requoted
Taker arriving mid-block (between TX1 and TX3): sees only 1-2 stale bids, wide spread, degraded depth. Each Cancel removes an MM from the book before its Post restores it at the new price. All 3 MMs serialized through Index16Bit.root and numOrders conflicts.
Figure 2.0 : Change Regime (3 Market Makers requoting after oracle move) PARALLEL
Oracle Update
Change Order
Taker Order
Block N t = 0ms
Oracle Price Update$85,000 → $85,100
MM-A
ON BOOK @ $85,000
MM-B
ON BOOK @ $84,990
MM-C
ON BOOK @ $84,980
Bid Depth
3/3 MMs quoting (stale)
Block N+1 t = 400ms : all execute in parallel
MM-A
Change$85,000 → $85,090
ON BOOK @ $85,090
MM-B
Change$84,990 → $85,080
ON BOOK @ $85,080
MM-C
Change$84,980 → $85,070
ON BOOK @ $85,070
Bid Depth (instant transition)
3/3 MMs requoted simultaneously
Block N+2 t = 800ms
Taker Buy Orderhits full depth at new prices
MM-A
ON BOOK @ $85,090
MM-B
ON BOOK @ $85,080
MM-C
ON BOOK @ $85,070
Bid Depth
3/3 MMs • full depth • fresh prices
Taker arriving at any point: sees either full old book or full new book. Never a partially-drained state. No MM is ever absent from the book. Zero Index16Bit or numOrders contention : all MMs execute in true parallel.
Figure 3.0 : State Contention Map

Post/Cancel : Shared State Conflicts

Index16Bit.root
A, B, C all write
Index16Bit.leaf[i]
A, B, C write (varies)
OrderBook.slot1 (numOrders)
A, B, C all write
idOrderMap[orderId]
per-MM (private)
orderLockMap[lockId]
per-MM (private)
priceLevelOrderIds[price]
per-price (private)
3 global conflict points → FULLY SERIAL execution

Change : No Shared State

Index16Bit.root
NOT TOUCHED
Index16Bit.leaf[i]
NOT TOUCHED
OrderBook.slot1 (numOrders)
NOT TOUCHED
idOrderMap[orderId]
per-MM (private)
account.lockedBalCNS
per-MM (private)
priceLevelOrderIds[price]
per-price (private)
0 global conflict points → FULLY PARALLEL execution
Figure 4.0 : Parallel Executor Timeline (10 MMs, 20 requotes per block)

Post/Cancel : Serial Pipeline

Each tx conflicts with previous via Index16Bit.root. Re-execution on every step.

t=0
TX1 (MM-A bid)
t=1
TX2 re-exec
t=2
TX3 re-exec
t=3
TX4 re-exec
...
TX5-TX20
Wall time
20 sequential steps
Gas used
~2.8M gas (140k each)
Parallelism
1x

Change : Parallel Pipeline

No shared slots between MMs at different prices. All execute in first pass.

t=0
TX1
TX2
TX3
TX4
t=1
TX5
TX6
TX7
TX8
t=2
TX9
TX10
TX11
TX12
t=3
TX13
TX14
TX15
TX16
t=4
TX17
TX18
TX19
TX20
Wall time
5 parallel batches
Gas used
~1.2M gas (60k each)
Parallelism
~4x
Figure 5.0 : Book Depth During Requote Storm (taker perspective)

Post/Cancel : Progressive Thinning

Before
A+B+C
stale
After TX1
B+C
67% depth
After TX2
C only
33% depth
Final
A'+B'+C'
100% depth

Change : Atomic Transition

Before
A+B+C
stale
Transition (parallel, atomic)
→
no intermediate state
always 100% depth
After
A'+B'+C'
100% depth
Figure 6.0 : MM React Pipeline (speculative execution window)

Post/Cancel : Dependency Chain

See oracle update
→ Compute new price
Build Cancel tx
→ Need: current orderId, perpId
Build Post tx
→ Need: balance AFTER cancel (unknown), new orderId (unknown)
Batch both ops
→ gas_limit must cover worst case of 2 ops
Submit
→ 1 tx, 2 ops, higher gas, fragile balance estimation

Change : No Dependencies

See oracle update
→ Compute new price
Build Change tx
→ orderId known (unchanged), balance known (unchanged)
Submit
→ 1 tx, 1 op, tight gas_limit, no speculation needed
Fewer steps, no dependency chain, lower latency
Sources: Perpl smart contracts • Monad docs (docs.monad.xyz) • Perpl docs (docs.perpl.xyz)