This page is being reworked and is not live yet. Content may not reflect the current Monad design.
Monad architecture
Consensus first.
Execution alongside.
Monad nodes agree on transaction ordering without executing the block first. Execution moves into a separate, slightly lagged lane, so it can use the full block time instead of fighting consensus for a small slice.
Same ordered transactions, same deterministic result. The pipeline changes when the work is done.
live pipeline
Consensus lane
orders blocks
one block every ~400ms
N
Proposed
N+1
Voted
N+2
Finalized
N+3
Next
Execution lane
catches up
one block every ~400ms
N-1
Verified
N
Executing
N+1
Queued
N+2
Queued
0
extra executions before proposal
D=3
delayed root check
1.2s
new funding delay
block-time budget
Interleaved execution wastes the clock
In the interleaved model, execution sits on the consensus hot path: the leader executes before proposing, then validators execute before voting. Monad removes that dependency, so consensus and execution both occupy the block interval in separate lanes.
Interleaved
execution blocks consensus
one block interval
Execution must fit into a small, conservative slice of the block time.
Asynchronous
execution runs beside consensus
Consensus agrees on ordering; execution catches up with a full interval of budget.
Ordering only
Consensus chooses the official transaction sequence.
Execution later
Nodes execute the same sequence locally, slightly behind.
State check
Delayed roots keep execution divergence detectable.
delayed Merkle root
The pipeline still checks state
Monad block proposals do not need the state root for the block being proposed. Instead, a proposal includes the Merkle root from three blocks earlier.
With D = 3, block N carries the root for N-3. If execution diverged, validators can reject the proposal and the bad node can roll back and re-execute from the last good state.
N-3
executed
state root known
N-2
executing
local execution
N-1
queued
not checked yet
N
proposal
includes root for N-3
root(N-3)
checked inside block N
deterministic state
Once ordering is fixed, the truth is fixed
Execution can lag consensus without changing semantics because a Monad block is still an ordered list of transactions. Every node executes that list and commits results in the same order.
canonical transaction order
execution view
selected: tx 02
reads
A balance
writes
C balance +8
outcome
depends on tx 01
ordered
Consensus fixes the sequence.
executed
Local EVM work can run later.
merged
Results commit in original order.
developer effects
Most apps just need to know the edges
Asynchronous execution preserves EVM transaction semantics, but the delayed state view leaks into a few app-level workflows around funding, simulation, and low-balance accounts.
selected edge case
A zero-balance account needs a short delay
Consensus validates gas budgets using a 3-block delayed view. If account B had zero MON and account A just funded it, B's transaction should wait until that funding transfer is old enough to appear in the delayed state.
~1.2s
typical wait after inclusion
watch for
Account flows that assume a just-funded zero-balance account can immediately pay for another transaction.
use this mental model
Consensus is ahead, execution catches up, and delayed roots prove the pipeline stayed aligned.