With Monad mainnet around the corner, let’s dive into what makes Monad different from other EVM chains, why it chose the hard path in designing its protocol since 2023, after raising over $200M to build a new EVM architecture, a full ecosystem of dApps, and a strong community.

Tech Differentiators: What Makes Monad Different?

Monad focuses on performance while keeping full Ethereum compatibility.

• Optimistic Parallel execution. Instead of processing transactions one by one like Ethereum, Monad runs independent transactions at the same time, like opening more tollbooth lanes.

• Asynchronous execution. The system pipelines work so nothing sits idle, similar to running the washer and dryer together.

• MonadBFT. A consensus design that targets faster finality and resilience against tail forking.

• MonadDB. A storage engine tuned for blockchain workloads that allows thousands of simultaneous reads and writes.

• RaptorCast. A block propagation approach designed for efficient bandwidth use across many validators.

Together, these improvement are made to create a decentralized network, with 150-200 mainnet validator participating in the consensus, without geographic centralisation or too expensive hardware. And with this achieve fast performance with 400ms block time and sub second finality without sharding and without breaking EVM compatibility.

MonadBFT and RaptorCast: Scaling Consensus with Reliable Block Propagation

When people talk about scaling blockchains, the focus is usually on consensus the process by which a network of validators decides which block to add next. But there’s another equally critical challenge: getting that block to everyone quickly and reliably.

Imagine a group of validators like a team working on a shared document. Consensus is the decision-making process: “What’s the next version we all agree on?” But before they can even vote, every validator first needs a full copy of that version. If distribution is slow or unreliable, consensus grinds to a halt.

Monad solves both problems with two tightly integrated components:

• MonadBFT, a modern consensus protocol designed for speed, responsiveness, and stability.

• RaptorCast, a network layer optimized for distributing large blocks efficiently — even when some participants misbehave.

This post will briefly introduce MonadBFT, then focus on how RaptorCast works and why it matters.

1. MonadBFT: Consensus Without Dropped Blocks

Most modern high-performance blockchains use protocols derived from HotStuff. These designs are efficient, but they suffer from a subtle failure mode called tail-forking.

The Tail-Forking Problem

Imagine a relay race:

• Alice runs the first leg and successfully hands off the baton (a block).

• Bob, the next runner, drops it or refuses to run.

• Instead of continuing from Alice’s progress, the team discards Alice’s effort and restarts from an earlier point.

This punishes honest participants and creates instability. In blockchain terms, a block that already had majority approval can still be abandoned, delaying finality and wasting work.

MonadBFT fixes this issue.

If a block has enough votes, it cannot be skipped.

Any future leader must first include that block before proposing new ones.

This makes the chain more stable and predictable, while also enabling:

• Faster finality: In good conditions, a block can be considered “almost final” after just one voting round.

• Adaptive speed: The protocol moves as fast as the network allows, instead of waiting for fixed timers.

• Scalability: Communication overhead grows predictably as more validators join, rather than exploding.

However, even the best consensus algorithm needs a way to get the data to all validators fast , that’s where RaptorCast comes in.

2. RaptorCast: Fast, Reliable Block Distribution

Before validators can vote on a block, they need to receive the entire block. When blocks are hundreds of kilobytes or even megabytes, distributing them to dozens or hundreds of validators quickly and securely is a serious networking challenge.

Traditional solutions aren’t good enough:

• Naive broadcast: The leader sends a full copy to each validator.

  Simple, but uses enormous bandwidth and doesn’t scale.

• Pure gossip: Validators forward blocks randomly to each other.

  Reliable but unpredictable, with uneven latency.

RaptorCast combines the structure of broadcast with the resilience of redundancy:

A two-step distribution protocol that spreads blocks quickly and securely, even when some validators are slow, offline, or actively malicious.

How RaptorCast Works

Split and Encode the Block

Instead of sending the block as a single file, the leader splits it into chunks and then encodes those chunks using a technique called erasure coding.

• Say the block is divided into k chunks.

• It’s then encoded into n > k chunks, adding redundancy.

• Any validator can reconstruct the full block once they’ve received any k chunks.

Analogy: It’s like sending a puzzle with extra pieces. Even if a few pieces are missing, you can still complete the puzzle.

This design naturally tolerates packet loss or missing data without needing retransmissions.

Two-Level Broadcast Tree

Once chunks are prepared, RaptorCast distributes them in two phases:

• Phase 1 – Leader to first-level validators:

  The leader sends different subsets of chunks to a small group of validators.

  Assignments are proportional to validator stake, so more reliable or higher-stake nodes take on more responsibility.

  
  

• Phase 2 – Validators to the whole network:

  These first-level validators forward their chunks to everyone else.

  Each validator combines pieces from multiple peers and reconstructs the block once they have enough valid chunks.

This structure ensures:

• Load balancing: The leader isn’t overwhelmed with outgoing traffic.

• Low latency: Block distribution completes in roughly two network hops.

• Fault tolerance: Even if some validators fail or misbehave, the redundancy ensures success.

Resilience Against Failures and Malicious Behavior

Because blockchains operate in adversarial environments, RaptorCast is designed to handle bad actors and network problems:

• Extra chunks: More chunks are created than strictly needed, so even if some are withheld or lost, reconstruction still works.

• Chunk authentication: Each chunk includes cryptographic proofs, allowing recipients to verify its integrity immediately.

• Deterministic responsibility: Validators know exactly which peers were supposed to forward which chunks, making misbehavior visible.

This ensures reliable delivery even if up to one-third of validators are malicious.

3. The Lifecycle: From Proposal to Voting

Here’s how it all fits together in a typical consensus round:

1. Leader creates a block of transactions.

2. RaptorCast encodes and distributes the block to validators in two steps.

3. Validators reconstruct the block, verify it, and ensure it’s valid.

4. Validators vote on the block using MonadBFT’s consensus rules.

5. If the block reaches the required support, it is locked in place and cannot be abandoned.

This process repeats continuously, with new leaders and new blocks, keeping the network moving smoothly.

4. Why This Matters

By pairing MonadBFT with RaptorCast, Monad achieves something rare: consensus and networking designed together, not in isolation.

The benefits include:

• High throughput: Large blocks spread quickly without bottlenecks.

• Strong safety: Once a block is supported, it stays in the chain — no surprise reverts.

• Resilience: The network keeps working even if some validators fail or attack the system.

• Low latency: Decisions happen quickly, improving user experience for apps and wallets.

In short, RaptorCast gives MonadBFT the foundation it needs to perform at scale in real-world conditions.

In high-performance blockchain systems, consensus is a two-part challenge: agreeing on blocks and delivering those blocks efficiently. MonadBFT addresses the first with a protocol resistant to common liveness pitfalls like tail-forking. RaptorCast addresses the second with a novel erasure-coded, two-level multicast system built for Byzantine environments.

The combination allows Monad to:

• Finalize blocks faster,

• Scale to many validators,

• Tolerate failures and adversarial behavior without sacrificing speed.

In short, RaptorCast turns the often-overlooked networking layer into a competitive advantage, making MonadBFT not just theoretically sound but practically high-performing with testnet 1 and 2 already running, and mainnet around the corner.

Sources :

• https://blog.monad.xyz/blog/how-monad-works

• https://www.category.xyz/blogs/monadbft-fast-responsive-fork-resistant-streamlined-consensus

• https://docs.monad.xyz/monad-arch/consensus/raptorcast

• https://www.category.xyz/blogs/raptorcast-designing-a-messaging-layer