The parallel EVM, for people who run agents rather than consensus

The docs name a handful of changes, and the count depends on which page you opened. MonadBFT orders transactions. Asynchronous execution lets consensus move on while execution of an earlier block is still finishing, which is what buys the execution engine its time budget. Optimistic parallel execution runs transactions together and re-runs any that touched the same state. MonadDb is the state database built for that access pattern. RaptorCast gets a block to the validator set inside the slot. You can trade on this chain without reciting the list. You cannot write an agent that assumes Ethereum’s timing and expect the list to save you. The list is the reason the timing assumptions are false.

A block, in transfers and in swaps

The why-Monad page calls 150 million gas a block an observed mainnet budget, about 500 million gas a second, with a protocol limit of 30 million gas on a single transaction. A transfer at 21,000 gas means the block can hold 150 million divided by 21,000, about 7,100 transfers, if the block were nothing but transfers. The capacity slogan of a few thousand typical transactions a second is in this neighbourhood once you remember a slot is a third of a second. A swap at 250,000 gas is 600 of them in the block, and 180 of them in the 30 million single-transaction ceiling. Your close should not be anywhere near that ceiling. A limit of a few hundred thousand is a ceiling for the fee you are willing to burn, priced as gas used times the base fee. It is not a bid for block space. The block is large. Your transaction should still be small. Confusing the two is how people set a gas limit of millions and learn nothing except that the wallet displayed a frightening maximum.

What parallel means when you are the conflict

Two transactions that touch different state can be executed together. Two that touch the same pool cannot, not finally. One of them will be re-run against the other’s result. From the outside this looks like ordinary slippage, or like a revert if your minimum was tight. It is not the chain failing to be parallel. It is the chain keeping a sequential meaning while doing the independent work at the same time. An agent that fires ten swaps into the same WETH pool in one burst should expect them to serialize on that pool. The first pays the price it simulated, if nothing else landed. The tenth pays the price after nine fills. An agent that fires ten transfers to ten recipients should expect them to run together, because they do not share a storage slot that matters. The gas budget is what makes the burst fit. The conflict is what decides whether the burst was one price or ten.

This is also why “the pool was parallel so my sandwich should be impossible” is a confused sentence. Parallelism widens the set of transactions that do not wait for you. It does not widen the set of transactions that may ignore you. Anyone who touches the same ticks is in your sequence. The builder still orders that sequence. Your floor is how you bound the result. The protocol does not bound it for you.

Parallel means the unrelated work did not wait. It does not mean the other swap in your pool pretended you were not there.

What asynchronous means for a read

Consensus can order a new block while execution of an earlier block is still being written. A node that answers a call from the latest agreed head, and a node that answers from the latest executed state, can disagree for a moment. On a twelve-second chain that moment hides inside the block. Here it is a noticeable fraction of an agent loop that is already slower than a slot. The practical rule is dull. If a balance did not move in the same instant as the hash, read it again after the next slot before you send a second transaction that depends on it. If a mark and a quoter disagree, prefer the pool’s slot0 for the mark and a simulation for the call you are about to sign. Do not average them. An average of a stale quote and a fresh slot is a price nobody can fill.

Clocks and oracles

The block timestamp steps with the slot. A contract that used the timestamp as a minute-scale clock, copied from a chain where the block was twelve seconds and the author thought in minutes, is now a sub-second clock whether the author meant it. Anything that unlocks, accrues, or expires on a timestamp should be read again on this chain before you trust the interval you remember. An oracle that updates once a minute is a different problem. The chain will trade through two hundred slots while that oracle is still. An agent that wants the pool’s price should read the pool. An agent that wants the oracle’s price should know it is choosing to be late, on purpose, because a particular lending contract will believe the oracle and will liquidate against it. Using the pool price to predict a liquidation that uses the oracle is how a position looks safe until the minute ticks.

What to stop doing

Stop padding every wait to a number learned on Ethereum. Stop assuming a successful eth_call is a fill. Stop firing a burst into one pool and booking ten times the first quote. Stop treating a gas limit as a priority fee. Stop reading “parallel EVM” as a promise that inclusion order does not matter. The architecture pages will not tell you the minimum output on a 50 MON close, or which key may sign it. They will tell you why the close can be included quickly and why a colliding close in the same pool will see you. That is the whole gift. Inclusion is cheap and fast. Conflict is still serial. Your floor refuses a bad serial outcome. Your nonce refuses a second copy. The machinery is why those two tools are enough, most of the time, without a twelve-second cushion to hide a third mistake.