Introduction to Monad

Monad is a new Layer 1 blockchain designed as a high performance, EVM-compatible platform. Founded by former Jump Trading engineers Keone Hon and James Hunsaker, Monad applies high-frequency trading (HFT) optimization principles to blockchain, aiming for hyperscaling of the Ethereum Virtual Machine (EVM). In practical terms, Monad targets 10k+ transactions per second (TPS) with 400ms block times and 800ms finality, a dramatic leap from Ethereum’s current 15-30 TPS, 12 second blocks, and 15 minute finality. Crucially, Monad achieves this without forsaking decentralization or EVM-compatibility.

Most EVM-based chains today (Ethereum L1 and various L2s) struggle with the “blockchain trilemma” of balancing throughput, decentralization, and security. A core limitation is Ethereum’s current design where consensus and execution are interdependent and sequential during block production. Each Ethereum block must be fully executed by the proposer and verified by validators within a 12-second slot, forcing conservative gas limits and leaving much of each slot’s time allocated to network communication and safety margins rather than executing transactions. This results in low throughput and high latency/fees under heavy load. The Ethereum community has been hesitant to radically alter the EVM or require powerful hardware for nodes, instead focusing on L2 scaling. While effective, L2s introduce new complexities, and baselayer performance improvements have largely stalled in recent years. Monad takes a different approach: redesign the baselayer, both the consensus protocol and the EVM execution engine, to massively increase throughput and speed, while still running ordinary Solidity smart contracts. By doing so, Monad attempts to scale the L1 itself in a way that complements L2s and provides a testbed for eventual Ethereum enhancements.

Monad’s protocol is a ground up implementation in C++/Rust that preserves EVM bytecode compatibility but introduces five key innovations: (1) a custom MonadBFT consensus (HotStuff-derived) with optimizations for fast finality, (2) a RaptorCast networking layer for efficient block propagation, (3) Asynchronous (Deferred) Execution decoupling transaction execution from consensus, (4) Optimistic Parallel Execution of EVM transactions, and (5) a specialized MonadDB state storage engine. Together, these allow Monad to achieve orders of magnitude higher throughput than Ethereum while keeping node requirements reasonable (recommended 32GB RAM, 16-core CPU). The following sections will explain each of these components and how they improve on the traditional EVM design.

MonadBFT Consensus and Pipelined Block Production

At the heart of Monad is MonadBFT, a Byzantine Fault Tolerant consensus protocol derived from HotStuff. MonadBFT finalizes blocks in two communication rounds (instead of three) by using an optimistic pipeline that progresses at actual network latency. Validators elect a leader each block; the leader proposes a block of transactions and collects attestations (votes) from validators, similar to Ethereum’s proposers and attesters, but accelerated. MonadBFT’s innovation is a “one-to-many-to-one” pipeline:

• Round 1 (Block Proposal): Leader (say Alice) broadcasts a signed block proposal to all validators. Rather than sending the full block individually to hundreds of validators (which would require enormous bandwidth), Monad uses a specialized multicast (RaptorCast, described later) to efficiently distribute the block.
   
• Round 2 (Quorum Certificate): Once validators receive Alice’s block and verify it, they send signed votes to the next scheduled leader (Bob). Bob aggregates >=2/3 of the votes into a Quorum Certificate (QC) for Alice’s block and includes this QC in his own block proposal for the next slot. 
   
• Round 3 (QC-on-QC): The third leader (Charlie) collects votes on Bob’s block+QC, forming a QC-on-QC (a certificate that the previous QC was seen by a supermajority). When Charlie broadcasts this, Alice’s block is considered finalized (by block N+2). This QC-on-QC mechanism ensures safety (no conflicting finalized blocks) and is unique to MonadBFT’s tail-fork resilience design.

Diagram of proposal to finality for blocks in MonadBFT consensus protocol | Source: Monad

Single Slot Finality: By this pipeline, every block gets finalized just two blocks later, yielding <1 second deterministic finality under normal operation. This contrasts with Ethereum’s probabilistic finality (blocks become highly unlikely to revert after ~2 epochs) and even other BFT chains that often wait multiple blocks to finalize. MonadBFT achieves linear communication complexity, avoiding the exponential messaging blowup that can come with many validators, which helps it scale to 100+ validators without slowdown.

Pipelined Consensus & Execution: A crucial aspect of Monad’s design is that consensus is reached before executing transactions in a block. This asynchronous execution (also called deferred execution) decouples block agreement from state computation. In Ethereum and most chains, a block proposer must execute all included transactions (to produce a state root and ensure validity) before proposing the block, and validators must execute them before voting - this interleaving means the time available for execution in each block is very limited. Monad instead treats block production like a transaction ordering service: validators agree on the ordered list of transactions first, then execute them after the block is finalized. By moving execution “out of the hot path” of consensus, the full block interval can be used for network consensus tasks, not execution. This allows Monad to shorten its block time to 400ms yet still accommodate a very large execution workload per block.

Diagram comparing interleaved (Ethereum) vs asynchronous (Monad) execution | Source: Monad

One side effect of decoupling execution is that Monad’s block proposals do not include a state root (since the transactions haven’t been executed yet at proposal time). To ensure validators stay in sync and detect any divergent execution results, Monad includes a “delayed Merkle root” where each block carries the state root from a few blocks back (e.g. 3 blocks ago) as a consistency check. If a node’s execution was faulty (e.g. hardware error causing a wrong state), it will notice a mismatch when the delayed root comes around and can correct or resync. This provides eventual assurance that all honest nodes have the same state, even though execution is trailing behind consensus by a few blocks.

In summary, MonadBFT and asynchronous execution allow continuous block production at network speed: every 400ms a new block is proposed and consensus moves forward, while execution of the finalized blocks happens concurrently. This greatly increases throughput by removing execution from the critical path. However, it introduces new considerations like handling transactions that might no longer be valid at execution time, which we will cover later.

RaptorCast: Efficient Block Propagation

To support 10,000 TPS throughput, not only must consensus and execution be optimized, but also the network layer. With blocks containing thousands of transactions (~2 MB or more), naively broadcasting them can bottleneck performance. RaptorCast is Monad’s custom solution for high-speed block dissemination. It is a multicast protocol that uses erasure coding (Raptor codes) and a two-tier “broadcast tree” to maximize bandwidth usage across the validator network.

In RaptorCast, when a leader has a block to send:

• The block is first erasure-coded into many smaller chunks (e.g. splitting a 2MB block into, say, 100 chunks of 24KB each, with some redundancy). Erasure coding means any subset of chunks (above a threshold) can reconstruct the full block. This adds a configurable redundancy factor to overcome packet loss or malicious drop of messages - e.g. 20% extra chunks to tolerate up to ~20% network loss.
   
• Each chunk is assigned to a specific intermediate node, which will forward it. The leader sends different chunks to different “level-1” validators, and each of those validators then rebroadcasts their chunk to all other validators (level-2). In effect, each chunk travels in a two-hop path: from leader -> one validator -> all validators. Because different validators handle different chunks, the upload bandwidth burden is spread across the network rather than all on the leader. Every validator ultimately receives all chunks (either directly from the leader for one chunk, and indirectly from peers for others) and can reconstruct the full block.

Simple view of the two-hop Raptorcast “broadcast tree” | Source: Monad

This structured pipeline ensures block propagation completes within about 2 round trip times (RTT) of the network’s diameter in the worst case. In other words, latency to get the block to everyone is roughly the time it takes for the farthest two validators to exchange two messages. RaptorCast uses UDP as the transport for efficiency (no connection overhead), with built-in redundancy instead of per packet acknowledgments. It also includes cryptographic guarantees: each chunk carries a Merkle proof and signature so validators can verify it came from the legitimate leader and hasn’t been tampered with.

By utilizing the full upload bandwidth of all nodes, RaptorCast can propagate large blocks quickly without requiring any single node to have an enormous connection. For example, if a block is 2 MB and there are 100 validators, each might only upload ~2% of that data (plus redundancy) to fulfill their part. This design is similar to Solana’s Turbine protocol (which also uses erasure-coded chunk broadcasting), but Monad’s implementation is tailored to BFT consensus needs. The result is that networking will not become a bottleneck even as Monad pushes to higher TPS; the network scales with the number of validators. RaptorCast is one reason Monad can target single-slot finality with hundreds of globally distributed validators.

Parallel Execution and MonadDB

Perhaps Monad’s most important innovations lie in its execution engine. Ethereum processes transactions strictly one-by-one, in order, on each node. Monad instead implements Optimistic Parallel Execution: it speculatively executes multiple transactions concurrently across multiple threads/VM instances, then reconciles the results to ensure the final state matches a serial execution. This approach takes advantage of the fact that many transactions do not conflict and thus can be executed in parallel without interference, greatly increasing throughput on multi-core hardware.

This design yields the same final outcome as if transactions ran one-by-one, but optimistically parallelizes as much as possible. Conflicts and re-executions are rare in practice because most transactions touch disjoint parts of state or only read/write a few common areas like ETH balances. Even when re-execution happens, it’s cheaper because needed data is likely cached from the first execution. The result is near-linear scaling of throughput with the number of CPU cores for a given workload, according to Monad’s internal tests. Notably, transactions are still committed in original order, preserving Ethereum’s predictable ordering semantics for things like nonce ordering and composability.

Example: Suppose in a block, Transaction 0 sends 100 USDC from Alice to Bob, and Transaction 1 sends 100 USDC from Alice to Charlie. If executed in parallel, both see Alice’s starting balance (1000) and each create a pending result that deducts 100 from Alice. When committing in order, Tx0 commits first (Alice = 900, Bob = +100). Tx1’s pending result is then found invalid (it assumed Alice had 1000 but she has 900 now). So Tx1 is re-run on the updated state (Alice 900, Charlie 400) and commits, ending with Alice = 800, Charlie = 500. The net effect matches serial execution, and Tx1 only had to execute twice. In a scenario with no overlapping inputs, both transactions would have committed without any re-execution.

MonadDB - Optimized State Storage: To support high throughput parallel execution, Monad engineered a custom state database called MonadDB. Like Ethereum, Monad uses a Merkle Patricia Trie to represent global state (for EVM compatibility), but typical Ethereum clients rely heavily on RAM to cache state or require expensive random reads to disk. MonadDB is designed for fast concurrent state access, allowing much of the state to reside on SSD rather than RAM with minimal slowdown. It uses techniques such as: storing trie nodes in an optimized on-disk format, opportunistic pre-fetching of state chunks, and fine grained locks or versioning to allow threads to read state in parallel without stomping on each other. This means that even as multiple transactions execute simultaneously, they can efficiently fetch and update state.

One impressive result of MonadDB’s design is that a Monad full node’s recommended specs (32GB RAM, 2TB SSD) are only moderately higher than Ethereum’s (~16GB RAM, 1TB SSD) and far lower than some other high performance chains (Solana recommends 128-256GB RAM). Monad deliberately aims to keep node hardware within consumer grade limits to maintain decentralization. By letting disk storage shoulder more of the state burden, Monad can scale state size and throughput without proportionally scaling memory usage. In short, MonadDB provides the throughput benefits of large in-memory databases but with a lower resource footprint, striking a balance between performance and decentralization.

It’s also worth noting that Monad’s EVM implementation is fully bytecode-equivalent to Ethereum’s and matches Ethereum’s gas pricing rules. The team ran extensive simulations of historical Ethereum transactions on Monad’s engine to ensure it produces identical results as geth. This means developers can deploy existing Solidity contracts on Monad without modification, and users can use Ethereum tooling (Metamask, Hardhat, Ethers.js, etc.) by just pointing to a Monad node endpoint. Monad supports the same JSON-RPC API as Ethereum, making it very familiar to integrate. By mirroring the EVM and RPC, Monad leverages the entire Ethereum ecosystem’s tools and knowledge, lowering the barrier for adoption while providing a massive performance boost.

Why Monad’s Mainnet Took Years: Development and Testing

Monad’s redesign of core blockchain components was not an overnight endeavor. The project has been in development for several years, reflecting the complexity of building a brand new execution client and consensus client from scratch. By contrast, many new L1 chains either fork an existing client or use off the shelf consensus algorithms; Monad chose the hard path of a ground up build to squeeze maximum performance. Here are key reasons it’s not live on mainnet yet and what the team has been working on:

The Monad team had to research and implement novel solutions like MonadBFT, RaptorCast, and the optimistic parallel EVM - each of which addresses difficult problems in blockchain design. For example, designing a BFT consensus that achieves 1s finality with hundreds of nodes required careful tweaks to HotStuff and rigorous testing. Similarly, the parallel execution engine needed new approaches to conflict detection and state management that traditional EVMs don’t have. Writing these in performant C++/Rust and ensuring they all work together is a huge engineering feat. This lengthy R&D phase explains much of the time investment.

Given the radical changes, Monad’s team spent a long time in internal testing before any public release. They built simulation frameworks to replay Ethereum Mainnet history on Monad to verify correctness and measure performance under real workloads. Running billions of past Ethereum transactions through Monad helped confirm that Monad’s EVM produces identical state/root outcomes and gives confidence in its capacity claims. Recent simulation data showcases the relative throughput capability of Monad relative to Ethereum. We can observe a decline in simulated throughput over Ethereum’s block history, likely due to an increase in complex transaction types and increased periods of state contention. Nevertheless, more recent blocks showcase Monad’s more than 100x throughput over Ethereum, with simulated TPS in the range of 2,000-6,000 over blocks 16 to 19 million. Furthermore, Monad’s recent testnet spec is operating at 500 million gas/s throughput, whereas Base’s observed peak throughput is roughly 35 million gas/s. Together, this test data indicates Monad may comfortably exceed the highest throughput seen on any existing EVM chain by a wide margin.

In early stages, Monad ran in a semi-centralized test environment. As it has matured, successive network stages have expanded to include more geographically distributed community-run nodes to observe real world performance scaling and uncover issues. Ensuring the network works over the open internet, with random latencies and potential Byzantine behavior, is non-trivial. 

The team also engaged in security audits of their consensus and EVM code. A novel consensus protocol like MonadBFT must undergo formal analysis to ensure no double-finality or catastrophic bug, and the EVM changes would be scrutinized for correctness under all edge cases. All this vetting adds months but is critical given the history of high performance chains hitting snags (e.g. Solana’s early outages). Monad’s goal of “speed without sacrifice” means they could not cut corners on reliability.

Another practical reason mainnet hasn’t launched yet is to allow time for an ecosystem of dApps and infrastructure to form on testnet. Monad doesn’t want to launch an empty chain; they’ve actively courted developers to build on testnet so that when mainnet goes live there are real applications and users ready. This was evident in Monad’s public testnet launched earlier this year which had 20+ apps on day one and dozens of validators participating. By spending months in testnet, the team gathered feedback from those developers, improved tooling support, and ensured that mainnet launch will be smooth for users. In essence, a longer testnet period helped Monad battle test the technology under community use.

Improvements Since Early Monad

Monad has evolved in various ways since the early development ideas from years back. In some cases entire components of the design had to be scrapped and rebuilt from scratch, and in other cases adjustments have been made after observing testnet behavior and feedback. Major areas of improvement are highlighted below:

• Building From Scratch: In the early phases of development, Monad initially explored building on top of the Tendermint consensus engine. However, the team ultimately concluded that Tendermint's codebase and architecture could not meet their performance requirements. This led the team to abandon that approach and instead develop their own stack from scratch - including MonadBFT for consensus, RaptorCast for high-throughput networking, and MonadDB for optimized state storage. These components became foundational to Monad's high-performance architecture and enabled the tightly integrated, asynchronous design that now defines the protocol.
   
• Higher Throughput Parameters: Monad has taken a measured, stepwise approach to scaling throughput. Initial parameters were set conservatively to prioritize stability, but as the network matured, the team progressively raised the block gas limit - reaching 150 million gas per 0.5-second block by February 2025 (equivalent to 300 million gas/s), and have recently pushed this limit up to 500 million gas/s. Meanwhile, block times were reduced from an initial 1 second to 500 milliseconds and then recently down to 400 milliseconds. The team has stated that throughput will continue to “increase over time,” signaling an eventual target of around 1 billion gas/s on mainnet - nearly two times the current testnet throughput.
   
• Enhanced Networking and Sync: RaptorCast and the state sync mechanisms were also proven on testnet. The team may have adjusted the default redundancy factor in RaptorCast or optimized its UDP handling after seeing it live. Similarly, state synchronization (Statesync/Blocksync) for new nodes has been tested - ensuring that a node can quickly catch up by downloading state from peers in parallel, which is crucial given the large state size a 10k TPS chain can accumulate.
   
• Tooling & Integration: Since launch, Monad has integrated with more wallets, block explorers, and dev tools. The original testnet onboarding guide highlighted native support from Phantom, OKX, Metamask, Uniswap Wallet, among others, and even an in-page Uniswap trading widget on testnet. These aren’t protocol changes, but they improve the developer/user experience.
   
• MEV and Infrastructure Additions: An interesting area of improvement is handling MEV in Monad’s unique asynchronous setting. The testnet period saw teams like aPriori and FastLane build MEV auction infrastructure tailored to Monad. While the MEV solutions are largely offchain services, the protocol could be tweaked to better support them (for instance, ensuring parallel execution doesn't interfere with MEV bundles). 

Contributing to Ethereum Research and EIPs

An intriguing aspect of Monad is that it can serve as a proving ground for what could be done to improve Ethereum L1 performance. While Ethereum’s roadmap currently prioritizes scaling via Layer 2s, the innovations in Monad suggest pathways for L1 enhancements, some of which could be considered via Ethereum Improvement Proposals:

• Asynchronous Execution: Monad demonstrates that decoupling execution from consensus can vastly increase throughput. If Ethereum were ever to adopt a pipelined execution model, it would likely require an overhaul of the protocol (perhaps in a future where hardware and network conditions permit). An Ethereum EIP could draw from Monad’s design to introduce a form of deferred execution, where block proposals carry transactions without state roots and execution happens slightly later. This would be a complex change (effectively Ethereum 1.5 or 2.0), but Monad provides a working reference implementation of how it can be done and what the benefits are.
   
• Parallel Transaction Processing: There have been discussions in the Ethereum community about parallelizing execution (e.g. “Sharded EVM” ideas or minor parallelism in clients). Monad’s optimistic parallel execution could inform an EIP to allow certain transactions to be marked as independent or to use multi-threading in execution clients. For instance, Ethereum could one day introduce a concept of non-conflicting transaction segments that execute concurrently within a block. Monad’s conflict resolution via re-execution is a concrete strategy that Ethereum researchers could consider (taking care to maintain atomicity and composability). If successful, such techniques could increase Ethereum’s TPS without altering the consensus layer.
   
• Networking Improvements: Ethereum currently uses a gossip protocol for blocks. Monad’s RaptorCast shows the advantage of structured broadcast with erasure codes. Ethereum could potentially implement an erasure-coded gossip (a bit similar to how Ethereum handles data availability sampling for danksharding, but for block propagation). An EIP could propose using something like Raptor codes or fountain codes for block propagation on Ethereum to reduce propagation time and bandwidth load per node. This would help Ethereum handle larger blocks or more validators. The trade-off is complexity in the p2p layer, but Monad’s success here provides a template.
   
• State Storage Optimizations: Ethereum is exploring Verkle trees to reduce state size and witness sizes. MonadDB’s approach of storing the Merkle trie on-disk with optimized access patterns could translate into client-level improvements for Ethereum. While not an EIP (since it doesn’t change protocol), Ethereum clients could adopt similar database structures. If Monad open-sources MonadDB, it might inspire Ethereum client teams (geth, Erigon, etc.) to incorporate those ideas to improve performance for all Ethereum nodes.

In essence, Monad shows what an Ethereum-like environment can do if you push certain design levers to the max. The Monad team has indicated that their work “can improve Ethereum as well,” by contributing these ideas upstream and potentially promoting targeted EIPs. We might see them write proposals or research papers for the Ethereum community based on Monad’s learnings (for example, a proposal for pipelined HotStuff BFT in Ethereum’s consensus, or suggestions for parallel transaction execution in a future Ethereum upgrade). Of course, Ethereum values stability and decentralization, so any changes would be weighed carefully. Higher performance often demands higher hardware capabilities, which Ethereum has historically been cautious about. Nonetheless, Monad provides a valuable reference point and could gradually shift the conversation on Ethereum L1 scaling if Monad proves its merits in production.

Risks

One major risk for Monad is technical performance and reliability. The project promises up to 10,000 transactions per second and sub-second finality, but these claims remain largely unproven in public settings. So far, there is limited concrete data from testnets or benchmarks to verify that Monad can sustain its high throughput under real world workloads. Early testnet results have been positive, but it remains to be seen if this level holds up with diverse, complex transactions on an open network. Monad’s novel architecture, including optimistic parallel execution and a pipelined BFT consensus, also introduces complexity that could yield unforeseen bugs or inefficiencies. If the network cannot deliver the expected performance or encounters instability, it could undermine Monad’s core value proposition in the short term. Additionally, the asynchronous execution model might expose new MEV attack vectors or race conditions that Ethereum’s synchronous design doesn’t face. Monad’s engineers will need to mitigate any such vulnerabilities quickly to maintain user trust. In short, until Monad’s technology is proven under production conditions, technical risk remains a concern.

A second risk area is ecosystem and adoption. No matter how fast or efficient Monad is, its success depends on attracting developers, users, and infrastructure in an extremely competitive landscape. Ethereum enjoys a massive network effect with countless existing dApps and users, and even newer high performance chains like Solana, Aptos, and Sui have established communities. Monad is entering a crowded market, and it will need to convince projects and users to migrate or build anew on its platform. This entails not just technical superiority but also effective community building and incentives to overcome the inertia of established platforms. There’s evidence that Monad is fostering a tightknit early community (e.g. through testnet engagement, hackathons, early Monad DeFi protocol funding), but broader adoption is uncertain. The timing and execution of the mainnet launch will be key: if the launch is delayed too long, interest could wane, yet launching too early without a robust ecosystem (DEXs, bridges, wallets, etc. ready on day one) could result in a barren network that fails to attract activity. To succeed, Monad must demonstrate real usage and utility shortly after launch, proving that its high performance can translate into compelling user experiences and not just theoretical advantages.

Finally, Monad faces strategic and structural risks related to its newness. Being a first-of-its-kind EVM chain with such aggressive optimizations means there is little historical precedent. The parallel execution and custom database may make debugging and maintenance more challenging than on traditional chains. There is also a decentralization tradeoff to monitor: Monad’s design strives to keep hardware requirements reasonable, but running a high TPS, high throughput chain might gradually demand more powerful nodes, potentially reducing the pool of participants over time. The team currently recommends 32 GB of RAM for validators, a midpoint between Ethereum’s lightweight nodes and Solana’s heavy duty nodes, and is using a Proof of Stake validator set to secure the network. However, governance centralization could be a concern: the project’s hefty VC funding means a large portion of tokens could be held by a few entities for several years. This concentration might influence decisions or undermine the egalitarian ethos if not managed carefully. Competition adds strategic risk as well. Even if Monad executes perfectly, rival platforms and L2 networks will continue advancing. Ethereum’s upcoming upgrades and the growth of rollups could eat into the niche Monad aims to fill. In summary, the very factors that make Monad innovative also introduce uncertainty. The team will need to navigate these unknown unknowns deftly, ensuring that early security incidents, governance missteps, or centralization concerns do not derail the project’s momentum.

Conclusion

Monad’s journey represents a bold attempt to supercharge the Ethereum experience from the ground up, introducing a new consensus algorithm, a parallel execution engine, and a custom data architecture, all while preserving a familiar EVM interface for developers. If successful, Monad would offer a developer experience nearly identical to Ethereum’s but with throughput and latency on par with the fastest modern chains. This combination of Ethereum-like usability with Solana-like speed could enable applications that were previously impractical on traditional EVM chains. Onchain perps, real time gaming, social networks, and other novel Web3 apps that demand instant finality and negligible fees, become much more feasible on a platform like Monad. In fact, teams are already experimenting with innovative dApp designs in areas like trading, social media, and even health/fitness on Monad’s testnet. Monad aims to deliver this leap in performance without sacrificing security or decentralization: it uses a robust BFT Proof of Stake consensus and keeps node requirements moderate to invite broad participation.

As the mainnet launch approaches, all eyes will be on whether Monad can translate its theoretical advantages into real world success. The coming months will test not only the technology’s resilience and throughput claims, but also the ecosystem’s response. The outcome will have implications beyond just one blockchain. A thriving Monad network would validate the approach of scaling at the base layer, potentially influencing how future blockchains (and even Ethereum itself) evolve. Monad’s founders have hinted that some innovations, such as networking improvements or minor EVM tweaks, could eventually be proposed to Ethereum, although more radical changes like fully asynchronous execution may be too large a departure for Ethereum’s roadmap. Conversely, if Monad struggles to gain traction or stability, it will underscore the challenges of pushing performance limits in a decentralized setting. Ultimately, Monad’s launch asks a pivotal question: Can we achieve a step change in blockchain performance without abandoning the paradigms that made Ethereum successful? As Monad transitions from an ambitious engineering project to a live network, it will provide new insights into what is possible for the next generation of blockchain platforms. And if it does fulfill its promise, we may witness the emergence of an Ethereum-compatible chain that truly marries speed, scale, and security to the benefit of developers and users alike.


This research report has been funded by Monad. By providing this disclosure, we aim to ensure that the research reported in this document is conducted with objectivity and transparency. Blockworks Research makes the following disclosures: 1) Research Funding: The research reported in this document has been funded by Monad. The sponsor may have input on the content of the report, but Blockworks Research maintains editorial control over the final report to retain data accuracy and objectivity. All published reports by Blockworks Research are reviewed by internal independent parties to prevent bias. 2) Researchers submit financial conflict of interest (FCOI) disclosures on a monthly basis that are reviewed by appropriate internal parties. Readers are advised to conduct their own independent research and seek the advice of a qualified financial advisor before making any investment decisions.