Monad — a high-performance EVM L1, explained

00Intro

Monad is an L1 blockchain with full EVM bytecode compatibility, designed for high throughput, sub-second finality and low operator cost. It uses its own consensus protocol (MonadBFT), an optimistic parallel execution engine, and a purpose-built state database (MonadDB / TrieDB). The first production client is written by Category Labs in C++ and Rust.

This page is a concentrated technical reference for anyone who wants to know what the chain actually does at the protocol level — and the exact coordinates of the live testnet and mainnet for developers and node operators.

01What is Monad

Monad is an EVM-compatible L1 that keeps Ethereum's state model, bytecode semantics and block structure, but replaces the underlying execution engine, consensus protocol and storage layer with designs tuned for modern hardware and modern throughput targets. The explicit goal is:

• Sub-second time-to-finality.
• 10,000+ transactions per second on mainnet hardware.
• Fully identical block semantics to Ethereum — any valid Ethereum transaction runs on Monad and produces the same state transitions.
• A validator set large enough to remain meaningfully decentralized.

If you already know Ethereum, the short version is: Monad is Ethereum without the bottlenecks. The observable contract semantics are the same; the throughput and latency envelope is not.

02MonadBFT — the consensus protocol

Consensus on Monad is driven by MonadBFT, a pipelined, leader-based Byzantine Fault Tolerant protocol in the HotStuff family — with a new twist called tail-fork resistance which prior pipelined BFT protocols don't have.

Finality in two rounds

From the docs: "Speculative finality in a single consensus round, and full finality in two rounds." The happy path spans three overlapping rounds, K, K+1, K+2:

• Round K: leader Alice proposes a block → validators vote → the next leader aggregates a Quorum Certificate (QC).
• Round K+1: leader Bob proposes a new payload plus the prior QC → validators vote → Alice's block achieves speculative finality.
• Round K+2: leader Charlie proposes with a QC-squared → Alice's block achieves full finality.

Because the protocol is pipelined, new blocks are being proposed and voted on continuously — there is no idle gap between rounds.

Key parameters

Fault tolerance

Standard BFT: n = 3f + 1, tolerating up to f Byzantine faulty validators. Two-thirds of the active set must remain honest for the chain to progress.

Leaders & stake weighting

Leadership rotates every round according to a schedule derived from stake weights, computed in advance. No single validator dominates block production — influence scales with stake, but every validator in the active set eventually gets turns.

Tail-fork resistance (the novel bit)

In classical pipelined BFT protocols, a malicious leader can sometimes fork away from their predecessor's block — effectively orphaning it. MonadBFT closes this by making leaders obligated to re-propose the previous block referenced in high_tip of the Timeout Certificate, unless they can get a supermajority attestation that the prior block was not seen. This forces eventual inclusion of honest proposals.

RaptorCast

Because Monad blocks can be large (10k+ transactions) and need to reach the full validator set within a 400 ms round, naive broadcast does not fit in the budget. Monad uses a RaptorCast layer built on Raptor fountain codes — the leader encodes the block into redundant packets that validators can reassemble from any sufficient fraction, allowing propagation to scale to large validator sets without each validator needing the entire block from the leader directly.

03Parallel execution

Monad executes transactions optimistically and in parallel, while preserving exactly the same block semantics as Ethereum. The docs put it bluntly: "Monad blocks are the same as Ethereum blocks — a linearly ordered set of transactions. The result of executing the transactions in a block is identical between Monad and Ethereum."

Instead of processing transactions one at a time, the client speculatively runs multiple transactions in parallel and reconciles them afterwards:

• Start executing transaction 2 before transaction 1 has completed.
• Track the inputs used by transaction 2 and compare them to the outputs of transaction 1.
• If the inputs of 2 intersect the outputs of 1, the speculation was wrong — re-execute 2 with the correct post-state of 1.
• If they don't intersect, the speculation was correct — commit both.

This is software transactional memory / optimistic concurrency control applied to block execution. Conflict-free transactions run truly in parallel; only conflicts pay the re-execution cost. For typical real-world blockspace (where most transactions touch independent contract state) the speedup is substantial while the observable semantics remain bit-for-bit identical to Ethereum.

04Storage — MonadDB & TrieDB

Monad stores state in a purpose-built database called MonadDB (sometimes referred to as TrieDB in client configuration). It's a Merkle-Patricia Trie store that lives on a raw block device — not on a filesystem, not on a generic key-value store like RocksDB. The point is to eliminate filesystem overhead from the hot path and to match the access patterns a consensus-driven execution engine actually produces.

This is why Monad node operators dedicate a whole NVMe drive to the TrieDB — the database mounts it directly via a stable symlink (/dev/triedb), partitioned but unformatted. Any other workload on the same device would compete for the I/O queue and degrade consensus-critical latency.

05MON token & staking

MON is Monad's native token. It pays for gas, it's the unit of staking, and it's what validators earn as block rewards. It's also the unit delegators use when bonding to a validator.

06Mainnet vs Testnet — side by side

Both networks are live. Both run the same client and the same protocol. They differ only in chain identity, endpoints, token realism and the consequences of failure.

07Testnet

The Monad testnet is the primary sandbox where developers deploy contracts, where wallets and dApps integrate, and where aspiring validators build operational history before applying to the Validator Delegation Program. It's fully live and accepting traffic today.

Quick start — add to wallet

Faucet

Test MON is distributed through the official faucet at faucet.monad.xyz. Amounts per request are modest — enough for gas and normal interaction, not enough to register a validator on-chain. For the latter, operators typically wait for a VDP decision and receive onboarding guidance directly from the team.

What testnet is used for

• Developers: deploying Solidity contracts, dApp integration, stress-testing applications against real Monad consensus.
• Validators: accumulating the 4+ week operational history required by VDP, proving 98%+ uptime, demonstrating monitoring and incident response capability.
• Ecosystem: wallets, indexers, block explorers, oracles, bridges — everything that needs to talk to Monad is validated here first.
• Protocol teams: trialling staking, governance and delegation flows before touching real MON.

08Mainnet

Monad mainnet is live and running monad v0.13.1 / MONAD_NINE. Block production is real, MON is the production token, and validator participation is gated through the Validator Delegation Program during the bootstrap period.

Quick start — add to wallet

RPC provider options

• rpc.monad.xyz — QuickNode, 25 rps, primary
• rpc1.monad.xyz — Alchemy, 15 rps (debug/trace disabled)
• rpc2.monad.xyz — Goldsky Edge, 300 per 10s, historical lookups supported
• rpc3.monad.xyz — Ankr, 300 per 10s (debug disabled)
• rpc-mainnet.monadinfra.com — Monad Foundation, 20 rps, historical lookups supported

09How to participate

There are three ways to meaningfully participate in the Monad network. Each one has its own entry cost and its own operational discipline.

As a full-node operator

The lowest barrier. You run the client, you sync the chain, you get a local RPC endpoint. You don't earn rewards, but you also don't need stake — and you get to verify the chain independently, run private services against it, and accumulate the operational history that feeds the next tier. I've written a practical install guide for exactly this path.

As a validator via the Validator Delegation Program

The realistic path to the active validator set for independent operators. The Validator Delegation Program (VDP) is the Monad Foundation's mechanism for extending stake to qualified third-party operators so they can meet the 10,000,000 MON active threshold without needing to source that much stake themselves.

VDP selection criteria

• Testnet operational history — minimum 4 weeks of active operation before you can be considered
• Uptime discipline — 98%+ SLA, tracked from your own monitoring and audited during review
• Industry experience — track record on other protocols is a plus, especially at operator level
• Monitoring & security — you must be able to describe your monitoring stack, alert pipeline, incident runbook and backup strategy
• Geographic decentralization — the Foundation explicitly weighs operators outside over-saturated regions
• Ecosystem contribution — write docs, help other operators, publish tooling
• KYC / KYB — mandatory before receiving delegation
• Commission cap — VDP participants are capped at 20% (normal is 10%)
• Mandatory testnet operation — even after receiving mainnet delegation, the testnet node must keep running at all times

The application form is at tally.so/r/81N1KO. Wave 2 is open at the time of writing.

As a delegator

If you hold MON and want to earn staking rewards without running infrastructure yourself, you can delegate to any existing validator using Monad's staking CLI or any wallet integration that supports it. Delegation is permissionless. Rewards accumulate automatically as the validator produces blocks, and you can either claim them (withdraw to your account) or compound them (auto-restake). The withdrawal delay after undelegate is one epoch (~5.5 hours).

10Resources

Official

• docs.monad.xyz — official documentation index
• docs.monad.xyz/monad-arch — architecture deep-dive
• MonadBFT specification
• Parallel execution overview
• Staking reference
• Full node install
• VDP program

Client & tooling

• Category Labs GitHub — first Monad client (C++ & Rust)
• staking-sdk-cli — CLI for on-chain validator registration, delegation, rewards
• pkg.category.xyz — APT repository for the monad package
• bucket.monadinfra.com — testnet config, snapshots, forkpoint, validators files

This site

• shadowoftime profile — who I am, what I run
• Monad full node install guide — the practical walkthrough, including the rakes the docs step around