Lesson 04: Monad Architecture

This lesson explains how Monad is built, layer by layer.

Every blockchain has roughly the same architecture: six layers that handle different jobs. Ethereum has them. Bitcoin has them. Monad has them. The difference isn't the layers themselves: it's how each blockchain implements them.

Think of it like this: both human eyes and butterfly eyes exist to see, but they accomplish sight in completely different ways because they're built from different parts. Once you understand what each layer does, you can understand any blockchain that comes out.

The six layers are:

1. Hardware Layer: the physical machines
2. Network Layer: how nodes find and talk to each other
3. Data Layer: how data is stored locally
4. Consensus Layer: how nodes agree on what happened
5. Execution Layer: how transactions are processed
6. App Layer: what users actually interact with

We'll go through each one. For every layer, we'll briefly explain how Ethereum implemented it, then how Monad does it differently. This isn't to pit them against each other. Ethereum proved that this architecture works. Monad reimplements it for performance.

Important: This lesson covers what each layer does and why it matters, not the deep technical details of how they work. In later tracks, we'll get into the internals of MonadBFT, parallel execution, MonadDB, and more. For now, the goal is to build a clear mental model of the full architecture.

---

1. Hardware Layer

Every blockchain runs on physical computers. The hardware layer is simply the machines that power the network.

Ethereum runs on a wide range of hardware. You can operate an Ethereum node on a cloud VM (like AWS), a consumer laptop, or dedicated server hardware. The barrier to entry is low, which is one reason Ethereum has thousands of nodes.

Monad requires bare metal servers: no cloud VMs. Cloud virtualization adds latency that breaks Monad's sub-second timing. The hardware specs are modest compared to other high-performance chains, but stricter than Ethereum's: 16-core CPU with 4.5 GHz+ base clock speed, 32GB+ RAM, 2TB NVMe SSD for state data plus a 500GB disk for consensus, and 100 Mbit/s bandwidth for full nodes (300 Mbit/s for validators).

Why does this matter? Lower hardware requirements mean more people can afford to run nodes. More nodes means more decentralization. Monad's specs are a deliberate tradeoff: strict enough for performance, accessible enough for decentralization.

---

2. Network Layer

Your node exists. Now it needs to find other nodes and start communicating. That's the network layer. Without it, transactions can't flow and the blockchain can't function.

Every blockchain's network layer does the same two jobs: peer discovery (finding other nodes) and node communication (talking to them). The implementations differ, but the jobs are the same.

Ethereum uses several components to accomplish this. Discv5 finds other nodes. DevP2P establishes communication channels. Wire protocols send block headers and transaction announcements. GossipSub broadcasts updates between synced nodes. Ethereum has roughly 13,000+ full nodes and around 1 million active validator keys, all coordinated through these protocols.

Monad accomplishes the same two jobs but with a different approach:

• Node setup: Your node starts with a configuration file and preset seed addresses provided by the MonadBFT algorithm. These are your initial connection points.
• Peer discovery: Your node contacts the seed addresses, receives the validator contact list (IP addresses + cryptographic signatures), verifies their authenticity, and connects directly to validators.
• Node communication: Nodes communicate on a dedicated port. Every message includes a digital signature proving the sender's identity. Block headers start arriving immediately, but your node buffers them until it's fully synced.
• State sync: Your node downloads state snapshots from synced peers (account balances, contract storage, bytecode) to catch up with the network.
• Block sync: After state sync completes, if your node is only a few blocks away from the tip, block sync is used to finish catching up. Requesting a few individual blocks is faster and lighter than running a full state sync again. Block sync can also recover a missed block due to packet loss.

You don't need to memorize these steps. The takeaway is that all blockchains have a network layer that handles peer discovery and communication. Monad implements it with a fast sync process designed to get your node caught up quickly.

---

3. Data Layer

Your node is now connected to the network and receiving data. Where does that data go? The data layer stores it locally on your machine.

This layer is critical for trustlessness. If your node couldn't store blockchain data locally, it would need to ask an external source every time it wanted to verify something. That would kill decentralization.

Ethereum stores data using generic databases (LevelDB or RocksDB) that weren't originally designed for blockchains. Incoming data is organized into Merkle Patricia Tries: tree structures that hold account balances, transactions, and event logs. These tries are then converted into key-value pairs and stored in the database.

Monad uses MonadDB, a custom-built database designed specifically for blockchain data. The key difference: where Ethereum has to convert its tree structures into key-value pairs for a generic database, MonadDB stores Merkle Patricia Tries directly, without conversion. It also uses asynchronous I/O (a technology called io_uring) to read from and write to your SSD at high speed.

The data is the same. The structure is the same. The difference is that MonadDB was purpose-built for blockchains, while Ethereum adapts general-purpose databases to do a job they weren't designed for.

---

4. Consensus Layer

Your node is online and synced. When someone sends a transaction, the network needs to decide: is this valid? And in what order should it be recorded? That's the consensus layer.

Consensus is how thousands of independent computers agree on a single version of truth. If someone proposes a fraudulent block, honest nodes reject it. If two validators propose blocks at the same time, the network picks one. Without consensus, there's no shared reality.

Ethereum uses a consensus mechanism called Gasper, which combines two algorithms:

• LMD-GHOST keeps the chain moving by choosing which fork to follow when multiple blocks are proposed at the same time. It picks the side with the most validator votes.
• Casper FFG locks in history. It finalizes blocks through a two-phase voting process on special checkpoint blocks. Once a block is finalized, it can never be reverted.

Together, LMD-GHOST + Casper FFG = Gasper. This process works through 32-slot epochs and checkpoint voting, which takes time. Ethereum's block time is 12 seconds, and finality takes roughly 13 minutes (2 epochs of 32 slots each).

Ethereum proved that proof-of-stake consensus works at scale. It secured hundreds of billions of dollars in value using this system. That achievement is foundational.

Monad uses MonadBFT, which achieves the same goal (agreeing on valid blocks) but much faster:

• MonadBFT has validators take turns as "leader." The leader rotates every 400 milliseconds. The leader proposes a block, and other validators vote on it in two rounds of voting. After two rounds, the block is finalized. Monad does have epochs, but unlike Ethereum, epochs are not used for block finality — finality happens at the individual block level, every 800 milliseconds.
• Tailforking resistance prevents malicious leaders from skipping the previous leader's block to steal rewards or enable MEV exploitation. MonadBFT forces leaders to include (or prove they cannot recover) the previous leader's blocks.
• RaptorCast solves a bandwidth problem. If a leader had to send a full 2MB block directly to every validator, the bandwidth requirements would be enormous, far too slow for 400ms block times. RaptorCast breaks the block into thousands of small chunks using erasure coding, where the full block can be reconstructed from any sufficiently large subset of those chunks. Chunks are distributed in a two-level fan-out: the leader sends chunks to first-level validators, who forward them to everyone else. This spreads the bandwidth load across the entire network instead of bottlenecking at the leader.

The result: 400 millisecond block times and 800 millisecond finality. Ethereum takes minutes. Monad takes less than a second.

---

5. Execution Layer

Consensus decided which blocks are valid and in what order. But the blockchain's state hasn't actually been updated yet. The execution layer processes the transactions inside those blocks and updates account balances, contract storage, and everything else.

Ethereum executes transactions using the EVM (Ethereum Virtual Machine), a global computer that runs smart contract code identically on every node. When a transaction arrives, the EVM runs the smart contract's bytecode step by step, one instruction at a time, one transaction at a time.

That last part is the bottleneck. Ethereum processes transactions sequentially. Transaction 1 finishes, then Transaction 2 starts, then Transaction 3. One at a time. This limits Ethereum to around 15-25 transactions per second on average.

There's another constraint. In Ethereum, consensus and execution are interleaved, meaning a block must be fully executed before consensus can move to the next block. Ethereum's block time is 12 seconds, but most of that time is consumed by consensus and block propagation, leaving a limited window for actual execution. This is one reason Ethereum blocks typically contain only around 150-250 transactions.

Ethereum established the EVM as the global standard for smart contract execution. Every Solidity developer, every tool, every dApp was built around it. That's the foundation Monad inherits.

Monad runs the same EVM (apps written for Ethereum work on Monad without code changes) but reimplements how transactions are processed:

• Optimistic parallel execution: Instead of processing transactions one at a time, Monad runs them simultaneously across multiple CPU cores. It optimistically assumes transactions won't conflict. If two transactions do conflict (e.g., both trying to spend from the same balance), the affected transaction is re-executed. The final state is always applied in the correct order, matching exactly what sequential execution would have produced.
• Asynchronous execution (decoupled from consensus): In Ethereum, execution has to finish before consensus moves on. Monad separates them. While consensus agrees on Block N's transaction ordering, execution processes Block N-1 in the background. This means execution gets to use the full block time instead of a tiny fraction, dramatically expanding throughput.
• MonadDB: The custom database from the data layer also plays a role here. Traditional databases force transactions to wait in line even when they're just reading data. MonadDB allows thousands of parallel state reads, so many transactions can access account balances simultaneously without bottlenecking.

The combination of parallel execution, decoupled consensus, and MonadDB enables Monad to achieve approximately 10,000 transactions per second, hundreds of times faster than Ethereum, while remaining fully EVM-compatible.

---

6. App Layer

The blockchain is now fully operational. Transactions are being processed and the state is updating. The app layer is where users actually experience all of this, through wallets, DEXs, games, lending protocols, and every other application built on the chain.

Ethereum established the app layer as we know it. MetaMask, Uniswap, Aave, OpenSea. These applications defined what it means to use a blockchain. They proved that decentralized applications could work, that users would adopt them, and that an entire economy could run on smart contracts.

Monad inherits all of it. Because Monad is fully EVM-compatible, Ethereum applications work on Monad without code changes. Developers just redeploy the same contract to Monad using Monad's chain ID. Same Solidity. Same tools. Same wallet connections. From a developer's perspective, deploying to Monad feels identical to deploying to Ethereum. From a user's perspective, the apps work the same way, just faster and cheaper.

This is the layer where everything comes together. Users don't need to understand MonadBFT, parallel execution, or MonadDB. They just experience fast, cheap transactions when swapping tokens, placing bets, or interacting with any on-chain application.

---

Putting It All Together

Each layer builds on the previous one:

1. Hardware provides the computing power
2. Network connects nodes together
3. Data stores blockchain state locally
4. Consensus agrees on valid blocks
5. Execution processes transactions and updates state
6. App delivers services to users

Ethereum built this architecture and proved it works. Monad reimplements it for performance: MonadBFT for fast consensus, parallel execution for high throughput, and MonadDB for efficient storage. The result is 10,000 TPS with 800ms finality, while maintaining full compatibility with everything Ethereum developers already know.

---

What's Next

You've got the layered map of how Monad is built. Next, What Becomes Possible at 10,000 TPS looks at what that speed and sub-second finality actually change for the kinds of apps you can build — and how to separate the honest claims from the hype.