Faster consensus.
ms vote pace −25%
MIP-12 proposes a 25% shorter vote pace, dropping from 400ms to 300ms. Related per-block parameters scale down to match, so blocks arrive sooner while each one carries a little less.
The information on this page should not be quoted. Please refer to MIP-12 for the authoritative spec.
What actually changes
Vote pace leads the change (above). Four more parameters scale down with it. Here's what each one means in plain terms.
Transactions per block
tx_limit
The most transactions that can be packed into a single block.
Compute per block
proposal_gas_limit
200,000,000 → 150,000,000
The total computation a block is allowed to do. “Gas” is the EVM's unit for compute.
Data per block
proposal_byte_limit
2,000,000 → 1,500,000 bytes
The largest a single block can get, measured in bytes.
Block reward
block_reward
The MON paid to the validator that proposes a block.
Why turn down every dial?
A block every 300ms instead of every 400ms means about 33% more blocks each second. Since each block now holds 25% fewer transactions, less gas, and fewer bytes, the network's per-second capacity stays roughly the same. You're not getting a bigger pipe, just a faster one. The block reward shrinks for the same reason: smaller, more frequent blocks.
400 ms · 3 blocks
300 ms · 4 blocks
same 1.2s window · more blocks, each 25% smaller
What it touches
This is a consensus-layer change only. The execution layer is unaffected and existing contracts behave exactly as before. Activating it requires a hard fork on the consensus client.
Continue the discussion on Monad Forum
Questions, feedback, or a better idea? Weigh in on the forum thread.
Open forum thread