Who gets which piece of the block
1 root
per proposal. v0 signs a separate root for every batch of up to 32 chunks.
Public seed
Round, a 2,048 ms time bucket and the leader's key decide which validator gets each chunk.
1 commitment
per round. A validator drops chunks that carry a different one.
MIP-10 is a Draft from Category Labs. It changes how the round's leader (the spec calls it the author) splits a block proposal into chunks and sends them to the other validators. Since v0.16.2, Monad testnet and mainnet publish proposals in this format and still accept the old one.
The information on this page should not be quoted. Please refer to MIP-10 for the authoritative spec.
One root for the whole block
The same 70 chunks under each format. Chunk counts are illustrative.
128 leaves · one tree, root in the signed header · R
58 zero leaves
ESI (encoding symbol ID) is the number of a Raptor-encoded symbol. Leaves past the last chunk hold 20 zero bytes, so the tree always has 2^(d-1) slots.
Who gets which chunk
Eight validators plus the leader. Change the block size, the stakes or the timestamp. Every validator runs these steps and gets the same answer.
K = 21 · N = 53 · n = 57 · depth 7 · 64 leaf slots · 1,199 bytes per symbol
1 · Seed
c034ce050000000003b226340000000098d497e194b312f05bc5170d6a2983b2
round · time bucket 874,951,171 · leader key, bytes 1-16
2 · Sorted by key, then shuffled
Click a validator to highlight its chunks.
3 · Leaf slots, colored by first recipient
7 × zero leaf
Chunks are dealt one at a time down the shuffled list, skipping validators that have their share.
Each validator gets ceil(stake × N / total stake) chunks. Rounding up is why n can exceed N by up to one chunk per validator, and why the depth leaves room for N + 8.
What the leader can still choose
The timestamp is the only input the leader controls, and validators drop it if it is more than 10 s from their clock. That allows 10 or 11 buckets, so at most 11 assignments. The leader can pick one of them but cannot place a chunk with a chosen validator.
A timestamp change inside one bucket keeps the assignment. It still counts as a different commitment.
At full scale
The active set is capped at 200 validators. Pick a block size and a set size.
Tree depth
12
Proof per chunk
220 B
Block bytes per chunk
1,099 B
Chunks sent (equal stakes)
995
Leader uploads
1.37 MiB
K = 350 · N = 875 · K source symbols, N = ceil(2.5 × K)
Every packet is exactly 1,440 bytes: a 117-byte header, a 4-byte chunk header, the Merkle proof, and the symbol. A deeper tree means a longer proof and less block data per packet.
monad-bft caps a proposal at 3 MiB.
What a validator rejects
Pick a proposal. Each chunk goes through the per-chunk checks; the decoded block goes through one more.
Per chunk
- Timestamp within 10 s of local clockpass
- Header in canonical form (depth, version, epoch, reserved bits)pass
- Signed by the round's leaderpass
- Merkle proof of leaf i verifies against the rootpass
- Same commitment as the first one seen this roundpass
- Chunk index below npass
After decoding
- Re-encoding the block gives the same rootpass
Every chunk is accepted and the block decodes. Re-encoding it gives the committed root.
Rollout in four stages
Each stage has to be fully adopted before the next one starts. Votes and timeouts stay on v0.
- Stage 1
accepts v0
publishes v0
The format before MIP-10.
- Stage 2
accepts v0 and v1
publishes v0
v0.15.2, on testnet July 27, 2026. The release notes call this "stage 1".
- Stage 3Monad today
accepts v0 and v1
publishes v1
v0.16.2, on testnet September 3 and mainnet September 10, 2026.
- Stage 4
accepts v1
publishes v1
Not in any release yet.
Can two nodes talk?
Nodes one stage apart work together. Two or more stages apart, one of them drops the other's proposals.
| 1 | 2 | 3 | 4 | |
|---|---|---|---|---|
| 1 | yes | yes | no | no |
| 2 | yes | yes | yes | no |
| 3 | no | yes | yes | yes |
| 4 | no | no | yes | yes |
Two spec rules, canonical depth and reserved bits (monad-bft #3247) and the commitment fix (#3248), merged on October 5, 2026 and are not in v0.16.2.
Who this affects
Validators and node operators
Upgrade with each stage
A node two stages behind the network can't read its proposals. Each decoded block is also re-encoded once to check the root.
Apps and users
Nothing to change
MIP-10 changes how proposals travel between validators. Transactions, RPC, gas, consensus voting, the quorum certificate format and execution stay the same.
Protocol work
Groundwork for later changes
One root per block would let validators vote after one verified chunk (a forthcoming MIP), let nodes sync old blocks as chunks from many peers, and turn two signed headers for one round into proof of equivocation. None of these are part of MIP-10.
MIP-10 is still a Draft and can change. Secondary RaptorCast, which carries proposals on to full nodes, uses the same encoding, but its routing is outside this MIP.
Continue the discussion on Monad Forum
Questions, feedback, or a better idea? Weigh in on the forum thread.
Open forum thread