Monad: a familiar EVM surface with a new high-throughput core.

Same contracts, wallets, and RPC. Underneath: MonadBFT, RaptorCast, async and parallel execution, and MonadDB.

MonadBFT

pipelined consensus roundsTproposedNvotedN-1finalizedN-2T+1proposedN+1votedNfinalizedN-1T+2proposedN+2votedN+1finalizedNblock N finalized after two rounds

Build like EVM. Deploy to Monad.

Monad keeps the developer-facing Ethereum surface: Fusaka EVM bytecode, Ethereum-style transactions and accounts, familiar wallets, and full Ethereum RPC compatibility[1],[8],[16]. For most workflows, it feels like adding another EVM network: chain ID 143, MON, and a Monad RPC endpoint[13].

Ethereum-shaped tools and contracts

Solidity
EVM bytecode
20-byte addresses
typed transactions
wallets
JSON-RPC
Monad Foundry
Hardhat

Chain ID

143

Currency

MON

RPC

https://rpc.monad.xyz

Explorer

monadvision.com · monadscan.com

MonadBFT makes fast blocks safe to trust

MonadBFT is Monad's consensus protocol: validators agree on a single block order quickly, while the protocol prevents a leader from forking away its predecessor's block[1],[2].

That gives applications a practical confidence ladder: Proposed for fast feedback, speculative finality after one round, Finalized for irreversible app logic, and Verified when state-root assurance matters[6],[14].

Tail-fork resistance

N−2
→
N−1
→
N
→
N+1
↳
fork attempt
rejected by MonadBFT

block time

400 ms

speculative finality

1 round

full finality

800 ms

Block confidence states

T1

Proposed

UI feedback

T+12

Voted

stronger confidence

T+23

Finalized

canonical app logic

T+54

Verified

state-root assurance

Move big blocks without making the leader the bottleneck

RaptorCast breaks a block proposal into erasure-coded chunks and sends those chunks through two-hop broadcast trees, using the upload bandwidth of the validator network instead of relying on one leader to upload the full block to everyone[3].

originatorfirst-hopsecond-hopV1V3V4V6V2c0-c2V5c3-c5V7c6-c8every validator collects chunks from every range, enough to decodeblock

01

Block proposals become erasure-coded chunks.

02

Each chunk range fans out through a two-hop tree to every validator.

03

Validators share upload work by stake weight.

Order first. Execute the ordered block locally.

Monad reaches consensus on transaction order before execution completes. Once order is fixed, every full node can execute locally and deterministically[4].

Execution gets the full block time instead of a sliver of it, and each proposal carries a state root from three blocks back, so any node that diverges is caught within about 1.2 seconds[4].

traditional interleavedexec ≈ 1% of the 12 s slot (~100 ms)
propose
vote
exec slivers drawn at 2% for visibility
↓ Monad: separate swim-lanes, full block time for each
consensus
N−1
N
N+1
N+2
execution
N−1
N
verify
N−3
3-block delay · ~1.2 s
time →one slot ≈ 400 ms

State roots are verified after a three-block delay, catching divergence quickly.

Run transactions in parallel. Commit them in order.

Execution does not crawl through the block one transaction at a time. Many executors run transactions optimistically in parallel, and the results commit one by one in the original block order[5].

If a commit changes state that a later transaction already read, that transaction re-executes with most of its inputs cached. Contracts always see serial EVM semantics[5].

before block N

Alice: 100 USDC

Bob: 100 USDC

Charlie: 100 USDC

ordertxinputsoutputs
1

Alice -> Bob: 5 USDC

Alice: 100

Bob: 100

reserved

Alice: 95

Bob: 105

reserved

2

unrelated tx

slot X

reserved

slot X*

reserved

3

Bob -> Charlie: 10 USDC

Bob: 100

Charlie: 100

reserved

Bob: 90

Charlie: 110

reserved

4

unrelated tx

slot Y

reserved

slot Y*

reserved

committed state

Alice: 100 USDC

Bob: 100 USDC

Charlie: 100 USDC

commit order: 1 -> 2 -> 3 -> 4

1/7

Block N has a fixed order. tx 1 and tx 3 both touch Bob's USDC balance; tx 2 is unrelated.

01

Optimistic: every executor starts immediately instead of waiting for earlier transactions.

02

At commit time a result's inputs must still match state; stale results re-execute.

03

Re-runs are cheap because inputs are mostly cached, and block order never changes.

Compile hot contracts without changing EVM behavior

Monad executes EVM bytecode with an optimized interpreter and a native-code compiler. Frequently used contracts are compiled once, cached, and reused by later calls while preserving exact EVM gas and error semantics[11].

The compiler removes redundant per-instruction work, folds simple constants, and specializes code for where stack values live on the machine[11].

bytecode

EVM contract version

interpreter

runs immediately

hotness

cumulative gas crosses threshold

compiler

async native-code generation

cache

native code reused later

single gas check

JUMPDEST · PUSH1 · ADD · PUSH0 · JUMP

=> one straight-line block check

constant folding

PUSH1 0x2 · PUSH1 0x3 · ADD

=> internal value: PUSH1 0x5

operand locations

stack word in memory/register/vector

=> specialized native sequence

1/5

Cold or rarely used contracts run on the optimized interpreter immediately.

Store Ethereum state for SSD-speed execution

MonadDB stores authenticated Ethereum state in a database designed around Merkle Patricia Trie data, async I/O, versioned reads, and SSD write patterns. It keeps the EVM state model familiar while making the storage layer match Monad's execution rate[9].

persistent state trieMonadDBSSDrootacctslot=5root*acct*slot*=9MonadDBasync I/Oversioned writessequential blocksreaders: consensus + RPCwriter: executionA read walks the trie top down: root, account, slot.

Readers and the writer never block each other

Execution is the only writer. While it builds the next version, consensus and RPC keep reading the previous one. No locks, no half written state, no torn reads.

Every read sees a complete, consistent snapshot

Old versions stay whole until they age out, so a reader always gets a full picture of state at one point in time, never a mix of old and in flight values.

Writes are sequential, which is what SSDs want

New node versions append in order instead of overwriting scattered locations. That means cheaper garbage collection, less write amplification, and longer SSD life than the random writes a generic key value store produces.

From user click to verified state

A Monad transaction starts like an Ethereum transaction, then moves through leader forwarding, fast ordered consensus, local execution, parallel commit, and delayed state-root verification[17],[8],[6].

The practical app question is not just "did it land?" It is which confidence level your product needs: submitted, proposed, finalized, or verified[4],[5],[9].

User + RPC01

Submit

  • Wallet signs tx
  • RPC accepts the transaction
  • RPC forwards to next 3 leaders
Leader + BFT02

Order

  • Leader proposes block N
  • Validators vote on one order
  • Block moves toward finality
Full nodes03

Execute

  • Order is fixed first
  • Nodes execute locally
  • Parallel results commit serially
State04

Verify

  • MonadDB writes a new version
  • Delayed root checks state
  • Block N becomes Verified

App confidence rail

choose per workflow

Submitted

RPC accepted

Proposed

fast feedback

Voted

higher confidence

Finalized

app logic

Verified

root assurance

Inside execution

tx 11
tx 22
tx 33
tx 44

Parallel work, serial commit: 1 → 2 → 3 → 4.

Reserve balance keeps async execution safe

Consensus validates new blocks against a delayed state view, so it needs a lightweight way to know included transactions can still pay for gas. Monad uses a 10 MON reserve budget for EOA gas spend across inflight transactions[10].

At execution time, value-spending transactions can revert if an account's ending balance dips below the reserve. Undelegated accounts get an emptying exception for normal low-balance usage[10].

block N-3

known state

block N-2

inflight

block N-1

inflight

block N

validating

Lagged balance

Alice: 110 MON

consensus knows N-3

Unknown recent spend

blocks N-2 / N-1

execution may not be caught up

Gas budget

min(10, 110) = 10 MON

inflight gas spend must fit

consensus-time check

Include transactions only while Alice's inflight gas spend stays within the reserve budget.

execution-time check

Revert value spend that leaves the ending balance below the reserve, unless the emptying exception applies.

Builder meaning

10 MON

default reserve

D = 3

same async delay window

gas limit

gas spend budget

included

can still revert

1/5

Consensus validates block N using the state from N-3, because execution intentionally lags.

Most app code ports. Recheck the runtime assumptions.

The EVM interface is familiar, but high throughput and asynchronous execution change a few assumptions around timing, gas limits, state reads, mempool behavior, and real-time infrastructure[8],[14],[15].

Throughput

10,000 tx/s

More onchain interactions fit inside one product flow.

Block frequency

400 ms

Fast enough for subsecond feedback instead of loading screens.

Finality

800 ms

Irreversible product decisions can settle quickly.

Gas throughput

500M gas/s

More contract work can happen without hiding chain latency.

What feels the same

  • 1Solidity contracts and EVM bytecode stay familiar[1]
  • 2Wallets, accounts, signatures, and addresses look like Ethereum[1]
  • 3Standard JSON-RPC remains the main app interface[1],[15]
  • 4Hardhat works with Monad settings; for Foundry, use the Monad Foundry fork[16]

What deserves a second pass

  • 1Treat block states as confidence levels: Proposed, Voted, Finalized, Verified[6]
  • 2Transactions are charged by gas limit, not gas used[7]
  • 3latest reads can include proposed state; pick tags deliberately[15]
  • 4There is no global mempool; RPC nodes forward to upcoming leaders[8]
  • 5Reserve balance rules matter for edge cases like delegated EOAs[10]
  • 6Blob transactions are unsupported, and max contract size is 128 KB[8],[14]
  • 7Indexers and explorers may use WebSockets or execution events instead of polling[12],[14]

Start building on Monad

Same contracts, wallets, and RPC, on a new high-throughput core. You have the mental model. Here is where to go next.

Read the docs

Monad for developers

Chain ID 143, MON, a Monad RPC endpoint, and a quickstart for your first deploy.

What is different from Ethereum

Gas charged by limit, finality tags, no global mempool, and real-time infra patterns.

Architecture deep dives

MonadBFT, RaptorCast, async and parallel execution, and MonadDB in full detail.

References

  1. 1.Monad for Developers — performance overview (10k tps, 400 ms blocks, 800 ms finality)docs.monad.xyz
  2. 2.MonadBFT — pipelined consensus and the tail-forking problemdocs.monad.xyz
  3. 3.RaptorCast — erasure-coded block propagationdocs.monad.xyz
  4. 4.Asynchronous Execution — pipelining consensus with executiondocs.monad.xyz
  5. 5.Parallel Execution — optimistic concurrent transaction processingdocs.monad.xyz
  6. 6.Block States — Proposed, Voted, Finalized, Verifieddocs.monad.xyz
  7. 7.Gas Pricing — gas charged by limit, not usagedocs.monad.xyz
  8. 8.Differences between Monad and Ethereumdocs.monad.xyz
  9. 9.MonadDb — authenticated state storagedocs.monad.xyz
  10. 10.Reserve Balance — 10 MON reserve rulesdocs.monad.xyz
  11. 11.JIT Compilation — native-code compilation of hot EVM contractsdocs.monad.xyz
  12. 12.Real-Time Data Sources — WebSocket feeds and execution events SDKdocs.monad.xyz
  13. 13.Network Information — mainnet chain ID and RPC endpointsdocs.monad.xyz
  14. 14.Deployment Summary — gas limits, timing, WebSockets, and execution eventsdocs.monad.xyz
  15. 15.JSON-RPC overview — WebSocket subscriptions and Monad-specific fieldsdocs.monad.xyz
  16. 16.Toolkits — Monad Foundry and Hardhat compatibilitydocs.monad.xyz
  17. 17.Transaction Lifecycle in Monaddocs.monad.xyz