EVM-based smart contracts have long been the dominant development paradigm in crypto, only recently being challenged by SPL programs. While the EVM has the longest history, largest developer community, and the most tooling available, it’s historically been structurally limited in the throughput it can handle as compared with, for example, the SVM. Monad aims to address these throughput issues, providing EVM-focused teams with their own ultra-high throughput, monolithic layer 1. (See the official docs: Monad Introduction and Monad Architecture Concepts.)
While Monad is widely known for leveraging parallel execution to increase performance, this is only one of a number of significant changes the network makes to traditional EVM design to push the EVM to its performance limits. Thanks to parallel execution and a variety of other complimentary optimizations, Monad is able to scale to 10,000+ TPS, offer sub-second finality, and retain the ability to support a relatively large validator set. Read on to learn more about how Monad has reinvented the EVM to supercharge its performance. (See the dev docs: Monad for Developers and EVM Resources – Monad.)
Monad Design / Architecture
Monad Consensus
MonadBFT
MonadBFT is Monad’s custom Byzantine Fault Tolerant (BFT) consensus algorithm, built on the HotStuff family of protocols. Designed for high throughput, low latency, and scalability across a large validator set, it is capable of processing over 10,000 transactions per second with sub-second finality. (See Monad Architecture and MonadBFT summary in the docs.)
MonadBFT has linear communication complexity, rather than exponential complexity, this means the amount of coordination required grows steadily as more validators join, rather than growing at an increasing rate. Instead of every validator communicating with each other directly, each sends their vote to the leader, who then aggregates them. Because the rate of growth in coordination is relatively low as the validator set expands, Monad is able to maintain a relatively large validator set without sacrificing on speed.
The protocol also uses pipelined consensus, which enables multiple consensus rounds to progress at once, when a given block is being finalized, the next is already being proposed, ensuring the network doesn’t get held up waiting for each consensus phase to finish.
This is reinforced by optimistic responsiveness, which allows consensus to advance at the speed of real-time latency instead of fixed timeouts. Under favorable network conditions, MonadBFT can finalize blocks in a single round, offering finality on the order of hundreds of milliseconds. Together, these properties make for a consensus layer that is fast, scalable, and secure without the need to compromise on decentralization or safety. (See blog: Monad Scalability Unleashed for the EVM.)
Asynchronous Execution
Monad’s asynchronous execution model separates transaction execution from consensus, allowing both stages to take place in parallel. Most EVM-based layer 1s (e.g., Ethereum) handle execution and consensus for a given block all within the same consensus round. Because consensus requires communication between a globally-distributed set of validators, the process of reaching it can take up the majority of the block time and leave only a small portion left over for execution. As a result, the time required for consensus becomes a limiting factor for the execution budget in this more traditional “interleaved” consensus model. (See Why Blockchain? – Monad Docs.)
By contrast, Monad reaches consensus over the order of transactions in a block first, then executes them in the following round. This decoupling removes execution from the critical path of consensus so that execution is no longer blocked by consensus. As a result, validators can continue proposing and finalizing new blocks while previous ones are still being executed. This change materially increases throughput, allowing for much higher per-block gas limits supporting more complex transactions without slowing down finality. (See Monad Asynchronous Execution Overview and Monad Developer Essentials.)
It’s worth noting that even though the exact state that will result from a block of transactions is not known immediately when consensus is reached, the outcome is deterministic despite a 1 block delay in the transaction being “revealed” by execution. A finalized sequence of transactions will always result in the same end state, even if it is not immediately known. Moreover, like on Ethereum, transactions included in a block that fail are not invalid and therefore do not invalidate the correctness of the block.
RaptorCast
RaptorCast is Monad’s custom block propagation protocol, designed to efficiently distribute large blocks throughout the validator set during consensus. Rather than having the leader send an entire block directly to each validator, RaptorCast uses erasure coding and a structured relay network to spread data quickly and redundantly. (See Monad Architecture Concepts and articles on block propagation in blockchain.)
When the leader validator proposes a block, it divides that block into many small chunks and encodes them in a way that only a subset is needed for full reconstruction of the block. Each validator then forwards a portion of those chunks to other validators, forming a tree-like broadcast pattern. This approach dramatically reduces the leader’s upload burden and ensures data reaches all validators quickly, even if some nodes are slow or temporarily offline.
By distributing propagation work across multiple validators, not just the leader, RaptorCast keeps bandwidth requirements low, enabling Monad to scale to a larger validator set without compromising performance. It also makes block dissemination resilient to latency spikes or localized network failures, which helps maintain sub-second finality in real-world network conditions.
Monad Execution
Optimistic Parallel Execution
Monad’s execution layer runs transactions in parallel with others, maximizing CPU utilization. This is a departure from most other EVM-based networks, which typically execute transactions in the order they were received, one-by-one. (See Monad Parallel EVM: How Optimistic Parallel Execution Unlocks 10,000+ TPS.)
More specifically, Monad uses a process called Optimistic Parallel Execution. During the first phase of this process, transactions in a given block are executed simultaneously on the (optimistic) assumption that none of them conflict with each other. Then, during a second phase, these transactions are merged into a block. As they’re merged, if multiple transactions modify the same piece of state, the validator detects this conflict and re-executes transactions with conflicts in linear order, just as they are on Ethereum. (See EVM Behaviour – Monad.)
This way, since state-update conflicts within a given block tend to be rare, the parallel execution model nearly always offers some time savings. In most cases, it will be significant compared to linear execution. Even in the extremely rare absolute worst case, where every transaction in a block has a state conflict with its preceding transaction, the outcome is essentially the same as if Monad simply used linear execution.
This model combines the determinism of traditional sequential execution with the scalability of parallel computation. By detecting and resolving conflicts dynamically rather than preemptively serializing all computation, Monad can offer much higher throughput without compromising correctness. (See Monad Developer Guide – EVM Resources.)
MonadDB
While Monad’s Parallel Execution is widely understood to be a driver of improved performance, its full potential is only unlocked by MonadDB, a custom database optimized to be sufficiently performant not to bottleneck the potential performance parallel execution makes possible. It’s designed to support the demands of optimistic parallel execution, ensuring that multiple threads can read and write to state efficiently. (See MonadDb – Monad Docs.)
Unlike traditional key-value databases that serialize reads and writes, MonadDB is built for fine-grained concurrency control. This means different parts of the state can be accessed and updated independently, allowing thousands of operations to execute in parallel. Combined with aggressive caching and memory-optimized data structures, this architecture minimizes latency and keeps state updates in sync with the pace of execution.
Staking Mechanics
Monad is a delegated Proof of Stake (dPoS) layer 1. As on other networks, validators are responsible for proposing and finalizing blocks, with their influence in consensus determined by the amount of MON they have staked (inclusive of self stake and any delegated stake). Delegators can stake MON to a validator and earn a proportional share of rewards, minus the validator’s commission rate. Because a fixed amount of 25 MON is issued per block produced, the exact SRR will vary based on the amount of MON that’s staked. (See Developer Essentials – Staking Behavior.)
The network operates in epochs, during which the active validator set remains constant. Each epoch is 50,000 blocks (about 5.5 hours), followed by a short 5,000-round delay before the next epoch begins. Staking actions such as delegations, undelegations, or validator registration take effect only at epoch boundaries to ensure predictability in validator selection. When a user unstakes, their tokens can be withdrawn after one full epoch has elapsed — therefore, the unstaking delay on Monad can be anywhere between 6 and 12 hours, depending on when in an epoch the user initially unstakes.
To qualify for the active validator set, a node must meet the minimum self-stake requirement of 100,000 MON and have at least 10 million MON in total stake (including delegations). Only the top 200 validators by total stake are included in the active set each epoch.
Tokenomics
Monad’s TGE is scheduled for November 24th, with the following allocations:
- Ecosystem Development: 38.5%
- Team: 27%
- Investors: 19.7%
- Public Sale: 7.5%
- Category Labs Treasury: 4%
- Airdrop: 3.3%
The recently-announced Monad public sale will be available via the new Coinbase token sale platform at a price of $0.025 per token. The Monad Airdrop was allocated to early Monad community members as well as other members of the broader crypto community including developers, power users of other protocols, NFT holders, and even security-focused participants like ZachXBT and Seal 911. (See Monad Official Site and Monad Ecosystem Directory.)
Figment’s Involvement
Figment has been supporting Monad as a testnet validator from the earliest days of private testnet and will be live on mainnet on day 1. Figment has extensive experience running validator infrastructure on Monad and is deeply committed to supporting the long-term success of the network and its ecosystem. If you’re interested in staking MON with Figment, connect with our team here.
