Monad Six Months After Launch

Key Takeaways

• Monad takes on the blockchain trilemma not by proposing a new model, but through extreme engineering. It keeps the EVM interface and redesigns consensus, execution, network propagation, and storage underneath to optimize each one. MONAD_NINE and MIP-3, MIP-4, and MIP-5 show that Monad is running a high-performance EVM variant, tuning resource pricing and execution rules to fit its own runtime.
• The price of high performance is complexity. Asynchronous execution, parallel execution, reserve balance, and the split between block states in RPC all create complexity specific to Monad. Monad works to abstract this down to a level developers and infrastructure can handle, using the MIP process, tooling, RPC specs, and precompiles. In other words, Monad's performance is the result of system engineering across execution, memory, storage, and network propagation together.
• Monad's next task is to move past the identity of "a faster EVM." The job ahead is not to be a fast chain, but to build a new identity that gives builders and users a reason to stay as blockchain demand keeps expanding, backed by a long-term vision.

0. Introduction

The blockchain trilemma, the difficulty of solving security, scalability, and decentralization at the same time, has been a long-standing problem for blockchain networks. Raising throughput usually forces you to either cut the number of validators or raise node hardware requirements, and both reduce decentralization.

Monad, a Layer 1 blockchain that pursues high performance, decentralization, and EVM compatibility together, launched its public mainnet on November 24, 2025. As of June 2026, six months after that launch, how far has Monad actually gotten toward solving the trilemma in a live environment?

This article looks at what Monad achieved in its first six months, not from the angle of token price or ecosystem, but from the protocol's technical and infrastructure side, and discusses where Monad should go next.

1. Monad's Core Hypothesis

Projects building a new Layer 1 split into two broad camps. Some, like Aptos and Sui, design a completely new execution environment unlike Ethereum's. Others try to keep EVM compatibility as intact as possible.

Monad belongs to the second camp. It aims to keep the interface that developers and users see as close to Ethereum as possible. The address scheme, transaction format, bytecode compatibility, and RPC interface all stay similar to the EVM ecosystem. Developers can reuse their existing Solidity code and EVM tooling almost as-is, and users keep their familiar wallet and application experience largely unchanged.

What Monad rebuilds instead is the internal pipeline that determines the chain's performance. Its performance improvements come down to five pieces:

• MonadBFT: fast BFT consensus based on pipelining
• RaptorCast: efficient block propagation using erasure coding
• Asynchronous Execution: separating consensus from execution so block production does not wait for execution to finish
• Optimistic Parallel Execution and JIT compilation: processing transactions in parallel and compiling frequently called contracts into native code to optimize execution
• MonadDB: a dedicated database for storing Ethereum state efficiently on NVMe SSDs

What Monad changes, then, is the implementation underneath the EVM interface, not the interface itself. Its core hypothesis is to keep the surface that developers and users see identical to Ethereum, while rebuilding consensus, execution, state access, and block propagation inside the node from scratch for performance.

For this hypothesis to succeed, three conditions have to hold at once. First, decentralization must not be sacrificed too heavily in the pursuit of high performance. Second, the newly designed consensus and execution structure must actually hit the target throughput and low latency in production. Third, EVM compatibility must hold up at the level of developer experience and tooling.

Examining the changes inside Monad over its first six months against this core hypothesis is the purpose of this article.

2. An Institutionalized Process for Protocol Changes: MIP

Source: Monad Research Forum

The first institutional mechanism Monad introduced after launch was the MIP (Monad Improvement Proposal). A MIP is the procedure for how a protocol change gets proposed, discussed, and recorded, and the discussion happens on the Monad Research Forum.

MIP-1 is the meta proposal that defines the MIP process itself. It establishes the formal framework for proposing and discussing changes to the Monad protocol, ecosystem standards, and governance process. It is modeled on Ethereum's EIP-1 but adapted to Monad's structure. Several proposals went through this procedure during the first half of 2026. Some are already live on mainnet (MIP-3, MIP-4, MIP-5), and others are still in discussion or implementation (MIP-8, MIP-9, MIP-10, and others).

A blockchain is ultimately a protocol made of code, and keeping it running and improving it means making sensitive design decisions continuously. On a chain that targets high performance like Monad, even a small change ripples across several layers. Recording these decisions and discussions in the open, as MIPs, means protocol changes no longer live inside a closed team. Anyone can track and verify them. For node operators and ecosystem builders, being able to see in advance, in writing, which change is coming and why has real value.

Monad is a centrally driven chain that started under Category Labs. Introducing an open proposal process like the MIP is a concrete, verifiable first step toward decentralizing the network. The MIP process alone does not amount to decentralized governance. The center of gravity for actual decisions still sits with the founding team, and the MIP should be read as a starting point.

3. MONAD_NINE: The First Major Upgrade

MONAD_NINE is the first case where proposals discussed through the MIP process landed as an actual mainnet upgrade. Monad v0.13.0, applied to mainnet on March 19, 2026, was the hard fork that activated MONAD_NINE, and it includes MIP-3 (linear memory cost model), MIP-4 (reserve balance precompile), and MIP-5 (Fusaka fork and CLZ opcode activation).

3.1 MIP-3: Making Memory Cost More Predictable

MIP-3 (Linear Memory) changes how Monad's EVM computes memory expansion cost, moving from a quadratic model to a linear one, and sets a maximum on how much memory each transaction can use. Ethereum's EVM is designed so cost grows quadratically as you use more memory, which discourages excessive memory use. Monad switches this to linear to make cost predictable, and pins down how much memory a single transaction can occupy with a clear 8MB cap. This matters for a chain running many transactions in parallel. The worst-case memory use of each transaction has to be bounded for parallel execution to be managed safely.

This is also a deliberate departure from Ethereum's gas cost model. For the same contract code, an operation that uses a lot of memory can cost very different gas on Ethereum versus Monad. Monad keeps EVM compatibility, but it does not try to keep things like resource pricing identical to Ethereum. It re-prices the EVM for a higher-throughput environment by re-tuning economic parameters to fit its own execution structure.

3.2 MIP-4: Detecting a Side Effect of Asynchronous Execution Inside the Contract

MIP-4 (Reserve Balance Introspection) introduces a new opcode that lets a contract check, in real time during execution, whether it has violated the reserve balance rules.

To understand the context for MIP-4, you first need to understand Monad's asynchronous execution. Monad's asynchronous execution separates consensus from execution. Rather than having nodes execute transactions first and then reach consensus the way Ethereum does, Monad reaches consensus on the order of transactions first and executes them later. This means execution is no longer the bottleneck for consensus, and the time available for execution grows significantly. Monad's asynchronous execution is covered in more detail in 4.1.

But this structure creates a new problem. Nodes have to build and agree on blocks without fully seeing the latest execution state. The reserve balance rule was introduced to handle this. In plain terms, the reserve balance keeps each externally owned account from dropping its balance below a certain level, so that consensus can judge "this account can pay the gas cost" even without fully knowing the latest state.

MIP-4 lets a smart contract check the reserve balance state during execution. It adds a new precompile at address 0x1001, and the dippedIntoReserve() method returns whether the reserve balance has been violated. With this, a contract can detect the situation mid-execution and restore the balance, take a different code path, or revert quickly while leaving a more meaningful error.

This is a Monad-specific opcode that Ethereum does not have. Rather than only following the EVM, Monad also adds custom instructions that its own architecture needs.

3.3 MIP-5: Reflecting Ethereum Upgrades

MIP-5 (Fusaka EIP Activation) applies three execution-layer EIPs from Ethereum's Fusaka hard fork to Monad.

• EIP-7823 (Set upper bounds for MODEXP): caps the input size of the MODEXP precompile (8192 bits each for base, exponent, and modulus).
• EIP-7883 (ModExp Gas Cost Increase): raises the gas cost of MODEXP to match its actual computational work.
• EIP-7939 (CLZ opcode): adds a new CLZ (Count Leading Zeros) opcode that counts the leading zero bits of a 256-bit word.

Fusaka added 13 EIPs to Ethereum in total. Monad takes only these three. The reason is that Monad's consensus (MonadBFT), data propagation (RaptorCast), and data availability are entirely its own design, unlike Ethereum's. To keep EVM bytecode compatibility, Monad only needs to follow the precompile and opcode changes that directly affect the execution layer, the EVM itself. Either way, to stay Ethereum-compatible, Monad has to keep tracking EVM changes and keep deciding which of them to adopt.

3.4 The Direction of Monad's EVM Compatibility

The three MIPs in MONAD_NINE make Monad's direction clear. The EVM compatibility Monad talks about is not simply copying the EVM. It deliberately changes the gas cost model to fit its own engine (MIP-3), adds its own opcodes when its architecture needs them (MIP-4), and selectively follows the Ethereum changes that compatibility requires (MIP-5). Monad does not take Ethereum's EVM as-is. It runs a variant reshaped to fit its own execution environment.

3.5 The Shift in RPC Semantics

The change developers and infrastructure providers feel most directly in MONAD_NINE is RPC behavior.

The latest block tag moved from a Finalized basis to a Proposed basis. As a result, state queries like eth_getBalance and eth_call can respond against a more recent block, and eth_sendRawTransactionSync was moved up from a Voted basis to a Proposed basis. The WebSocket newHeads and logs notifications also changed from Finalized to a Voted basis.

This change helps reduce latency. For developers, though, it adds the burden of distinguishing the latest state from the confirmed state. Returning latest as a Proposed state rather than a Finalized one gives low latency, but it is closer to a tentative execution state that has not yet gone through consensus. To balance this, Monad added new tags for other block conditions. safe maps to the state where voting is complete, and finalized maps to the fully confirmed state. For anything that needs real value settlement, like cross-chain asset transfers, deposit crediting, or payment settlement, querying state on a finalized basis is recommended. After MONAD_NINE, reading latest on Monad means reading the fastest state, not an irreversible confirmed one.

This change captures Monad's performance philosophy well. A frontend that wants fast UX can use latest for more timely state. But indexers, bridges, payment systems, and off-chain accounting systems have to clearly understand the difference between latest, safe, and finalized. On a high-performance chain, it is not just blocks that get faster. The way block state is interpreted gets more granular too.

4. The Reality of Asynchronous and Parallel Execution: The Hidden Cost of EVM Compatibility

MIP-3 and MIP-4 actually derive from the two pillars of Monad's execution engine: asynchronous execution and optimistic parallel execution. These are the core of what makes a high-performance EVM possible, and at the same time the biggest obstacle to EVM compatibility. This chapter looks at how those two pillars actually work, and what it costs to keep "an interface that looks like Ethereum."

4.1 Asynchronous Execution: Consensus Does Not Wait for Execution

On Ethereum, before proposing a block you have to execute every transaction in it and compute the state root. For Monad, there is not enough time to do that within a 400 to 500 ms block. So Monad separates consensus from execution, as mentioned in 3.2. The leader proposes a block by setting only the order of transactions, and execution follows afterward, against a delayed state. Consensus is reached on transaction order first, and what the resulting state is gets confirmed later. This is the core of Monad's performance. When consensus does not have to wait for execution to finish, block time can be made faster. Because of this, a Monad block does not carry the current state root. It carries the delayed state root from D blocks earlier (currently D=3). From the protocol's point of view, execution always lags consensus by three blocks.

이미지 표시

Source: Monad docs

But this structure has a cost. Consensus has to build blocks without fully knowing the latest execution state. This is exactly where the hidden cost of EVM compatibility shows up. On the surface it looks like the same transactions and the same contracts are executing, but inside there is a time gap between consensus and execution. To handle this gap safely, Monad has to design gas charging, reserve balance, and the RPC state model separately. The same transaction that processes fine on Ethereum can be reverted on Monad under the reserve balance rules, and light clients or some bridge systems have to account for the fact that a Monad block carries a state root from three blocks ago, not the current one.

4.2 Parallel Execution

Monad executes the transactions in a block optimistically in parallel. It assumes they do not conflict and runs them at the same time first, then tracks each transaction's read and write sets, and when it finds a conflict (for instance two transactions touching the same state) it re-executes only the affected transaction with the correct data. The final state matches the result of Ethereum's sequential execution, so the actual visible result does not change.

The benefit of parallel execution is largest when transactions are independent of one another. It becomes a problem in contention, when many transactions touch the same state at once. When everyone piles onto one point, such as a hot AMM pool, a memecoin mint, or an NFT drop, conflicts and re-execution go up. The catch is that on-chain crypto demand tends to cluster exactly like that. The peak moment, when throughput matters most, can be the moment parallel execution is least favorable. So the 10,000 TPS figure often cited for Monad's scalability has to be read conditionally. It is a number under ideal conditions where transactions are sufficiently parallelizable, not a measured one.

4.3 Gas Is Charged by Limit, Not by Usage

The clearest place the difference between Ethereum and Monad shows up is gas charging. A developer used to Ethereum usually assumes cost is charged based on "gas actually used." But on Monad, a transaction is charged based on the gas limit set on it, not the gas it actually used. This change comes from Monad's asynchronous execution.

The reason becomes clear once you think back through Monad's asynchronous execution. In asynchronous execution, the leader and validators build and vote on a block before executing transactions. If you charged only for gas actually used, someone could submit a transaction with a very large gas limit, take up a big chunk of the block's gas space, and then use little gas at execution time to pay a low cost. That becomes an attack vector for occupying block space far more cheaply than it should cost. Abused, it enables a DoS (Denial of Service) attack. To prevent this, Monad charges based on the submitted gas limit rather than the gas the transaction actually used.

This directly affects the developer and user experience. On Monad, setting the gas limit too high is costly. So wallets, frontends, backends, and bundlers have to handle gas limit settings more carefully.

4.4 EVM Compatibility Is Not Free

Monad works to keep the surface, the contracts and tooling, as close to the EVM as possible to maintain compatibility. But it changed the internal execution structure for performance, and there are differences that arose from solving the problems that change created. These differences are the hidden cost of EVM compatibility. The more complex an application gets, especially in areas where state freshness and finality matter (bridges, payments, derivatives, high-frequency trading, account abstraction, indexing infrastructure), the more of Monad's internals you have to understand and watch out for.

In this situation Monad needs to abstract the unavoidable complexity its high-performance execution creates down to a level developers and infrastructure can handle. Seen in this light, the past six months of updates matter: MIP-3 re-tuned resource pricing, MIP-4 let contracts detect the exceptions of asynchronous execution, and the RPC spec started to distinguish block state from tentative data more explicitly.

5. MIP-8: Bringing State Access Down to the Real Hardware Unit

Source: mipland

MIP-8 (Page-ified Storage State) is not yet a live mainnet upgrade. It is a proposal still under discussion as a MIP. Early Monad focused on fast consensus, parallel execution, and asynchronous execution. But in production, a high-performance chain is not complete just by optimizing consensus and the execution engine. Transactions ultimately read and write contract state, and that state is stored in the node's storage layer. So as the chain's throughput rises, how fast you can read and write state becomes an important bottleneck.

MIP-8 takes its cue from the gap between the EVM's abstraction and real hardware. To a smart contract, storage looks like a long list of 32-byte slots. But at the real hardware and database layer, data is read and written in much larger units. An SSD reads and writes in 4KB pages, and one page holds the equivalent of 128 32-byte slots. When a Monad node reads a single slot that is not in memory, its actual disk pulls the entire 4KB page that slot belongs to anyway. So the moment you read one slot, the adjacent 127 slots are effectively read along with it.

The problem is that the existing EVM storage model does not reflect this. The EVM handles state slot by slot, and Ethereum's Merkle trie hashes slot keys to store them. This helps keep the tree balanced, but it scatters logically nearby data across different locations on the actual disk. As a result, even reading consecutive slots within the same contract can mean repeatedly reading different pages, which is inefficient.

To solve this, Category Labs proposed MIP-8. The idea is to raise the 4KB page, the unit real hardware uses, to a first-class concept for EVM state access. The protocol groups every 128 consecutive slots into one page, and both the gas schedule and the storage layout recognize that page. The Merkle trie is reorganized to commit by page rather than by individual slot.

On the gas side, you pay the high cold access cost only the first time you touch a page, and pay the lower warm access cost for the other slots in that page within the same transaction. In other words, for data already pulled from disk inside a page, the protocol reflects the fact that it is "already in memory" and charges less. As a result, patterns that use consecutive slots (arrays, structs, packed state variables) naturally get cheaper.

Even with MIP-8 applied, the EVM's 32-byte slot model stays the same, so Monad developers still write Solidity and existing contracts keep working as they did. What changes is how state is stored and priced underneath. The EVM interface stays the same while the internal unit of state access is brought closer to real hardware.

For a developer building a Monad app, optimizing a contract expands from simply reducing the number of storage accesses to also placing state that is read together within the same page as well as possible. This takes the storage optimization problem familiar to EVM developers and reconnects it to the hardware's data access unit. You do not have to rewrite Ethereum contract code for basic compatibility, but optimizing for performance and cost may require code changes.

The way Monad pursues "performance without sacrificing decentralization" is closer to treating the blockchain as a high-performance system engineering problem than to bringing in a new model like ZK, a new VM, or sharding. From consensus and execution pipelining down to a disk-page-level gas model, it pushes techniques from CPU and distributed systems engineering all the way to fit hardware reality.

6. RaptorCast and the Network Layer

6.1 RaptorCast

A blockchain is a peer-to-peer network. No matter how well you optimize consensus and execution, it means nothing if blocks reach every node slowly. Monad's block time is 400 ms. Most of that short window is spent on communication between validators scattered around the world. On a chain targeting block times this short, block propagation itself becomes the core bottleneck for consensus. Ethereum uses libp2p (GossipSub) as the messaging infrastructure for its consensus layer. But Monad differs from Ethereum not just in block time but in consensus structure, so it uses its own block propagation protocol, RaptorCast.

RaptorCast is the dedicated multicast protocol the leader uses inside MonadBFT to propagate a block proposal to the validators. The leader splits the block proposal into many pieces using erasure coding, and each piece is delivered to validators through a two-level broadcast tree. Non-leader validators act as the first-level forwarder for a specific bundle of pieces, and the share of pieces each validator is assigned is determined by its staking weight. Since every chunk reaches the whole network in exactly two hops, propagation time converges to a single round-trip time (RTT), the one between the two most distant nodes in the network.

이미지 표시

Source: monad docs

Because block propagation mobilizes the upload bandwidth of the entire network at once, the bandwidth a single validator carries is fixed at about three times the block size, regardless of how many validators there are. Whether there are 100 validators or 500, the line required of an individual node does not grow. This is the basis for Monad's claim that it can reconcile "a large, distributed validator set on commodity uplinks" with high performance and high throughput.

RaptorCast also runs on UDP rather than TCP. Because TCP's retransmission and head-of-line blocking translate directly into latency, RaptorCast accepts packet loss as a normal condition rather than an anomaly, and absorbs it through an erasure coding redundancy level each node operator can configure. In exchange, every packet carries the leader's signature and proof, so loss is allowed but tampering is blocked. One thing to add: the first-level relay forwards the chunks it receives without re-encoding them.

RaptorCast is not used only for block propagation between validators. The leader delivering block proposals to the active validator set is Primary RaptorCast, and there is also Secondary RaptorCast, where each validator propagates blocks to its downstream full nodes. Secondary RaptorCast works on a similar principle, but it treats all participating nodes with equal weight regardless of staking. Under the recommended configuration, each validator can have a Secondary RaptorCast group of about 150 full nodes, which means a capacity of up to 30,000 full nodes for 200 validators. Accounting for the redundancy factor, the structure can support roughly 15,000 full nodes network-wide. On a high-performance blockchain, the performance of the network core matters, but so does how reliably the full nodes that users touch can receive blocks and keep up with the chain's latest state. Secondary RaptorCast is the network design that keeps full node participation stable on a high-performance chain like Monad.

Whether by intent or not, RaptorCast's structure itself eases the problems that come from geographic skew in the network. Ethereum's GossipSub is mesh-based, multi-hop propagation. Because a message spreads peer to peer across many hops, propagation delay accumulates per hop, and the hop count and a node's position in the mesh end up depending on its geography and connectivity. Peer scoring then reinforces this bias, systematically disadvantaging nodes far from the message origin. Monad's RaptorCast sidesteps this by fixing the hop count at two. Whether a node is in Asia or Africa, it no longer falls behind from accumulated hops. This does not mean Monad is technically superior to Ethereum. It is possible because the structural premise of the consensus algorithm is different. Where Ethereum's GossipSub assumes communication among peers that know nothing about each other, MonadBFT runs on a fixed validator set whose stake weights are known. So Monad can structure, at the protocol level, who relays which chunk.

But RaptorCast has not fully solved the problem of peers' geographic decentralization. The fact that Monad's propagation time converges to the RTT between the two most distant nodes means the degree to which a node is geographically far sets the floor for block time. The more widely the validator set is spread geographically, the larger the worst-case RTT, and the tighter the 400 ms block time budget. As Monad expands the validator set and moves toward being genuinely permissionless, this can become a problem.

6.2 MIP-10

The proposal to improve RaptorCast after mainnet launch is MIP-10 (Deterministic RaptorCast). MIP-10 fixes RaptorCast's encoding to a publicly computable seed. With this, a validator can vote on the Merkle root the moment it receives a single verified piece, even before reconstructing the whole block. The goal is to take full block decoding off the critical path of consensus. Then the next leader can gather votes to build a QC (Quorum Certificate) and start producing the next block while the previous block's pieces are still propagating, so block time is no longer tied to the time it takes to propagate the entire block.

To explain MIP-10 a bit further: in the existing approach, the leader can freely choose the erasure coding seed, and the commitment to the encoding is split into one Merkle root per batch of 32 packets. This freedom gives performance flexibility, but it leaves room for a malicious leader to send only the pieces that are unfavorable for reconstruction to a specific validator, or to create ambiguity where one Merkle root could be tied to several different payloads. MIP-10 makes the encoding seed deterministic, and has each round record the first valid Merkle-root-and-leader-signature pair it sees, which is a security hardening that reduces this attack surface.

The network layer for peer-to-peer communication is a very important area that strongly affects both a blockchain's performance and its decentralization. Rather than leaving block propagation to a plain gossip approach, Monad redesigned it at the protocol level to fit MonadBFT's structure. But RaptorCast does not solve everything. The larger the validator set grows and the more widely it spreads across regions, the harder it is to hold a 400 ms block time. The network layer has to keep changing as Monad evolves.

7. The Direction Toward Decentralization

So far we have looked at how Monad refined its technical premises, a high-performance blockchain and EVM compatibility, in a live environment over the six months since mainnet launch. But Monad is not a chain that pursues high performance alone. The identity it set out with from the start is the simultaneous achievement of high performance, EVM compatibility, and decentralization.

Decentralization is an especially tricky problem on a high-performance chain. As block time gets shorter, the demands on a node's network quality, hardware performance, and operational stability rise, which naturally narrows the range of validators that can participate. Performance optimization raises throughput technically, but it can put pressure on decentralization operationally. This chapter looks at the reality of decentralization on Monad since mainnet launch, and how Monad is handling this challenge.

7.1 The Current State of Monad's Decentralization

Monad is a Delegated Proof of Stake (DPoS) chain. Registering as a validator is itself permissionless. But to actually take part in consensus, a validator has to meet conditions and be included in the active validator set.

Becoming an active validator requires three conditions. First, the validator's auth address must self-delegate at least 100K MON. Second, the total delegation the validator has received must be at least 10M MON. Third, it has to rank within the top ACTIVE_VALSET_SIZE by stake weight. The current ACTIVE_VALSET_SIZE is 200. A validator that does not meet the conditions is dropped from the active set in the next epoch. The door is open to anyone, but crossing the threshold is decided by capital.

Source: Monadvision

Where did the capital delegated to Monad's validators come from? Looking at that source makes the decentralization story a bit more complicated. The Monad Foundation has been delegating its own holdings to validators through the VDP (Validator Delegation Program). In the first wave, the foundation delegated about 9.3 billion MON, roughly 9.3% of total supply, across 170 validators. It also provided the minimum self-staking requirement of 100K MON to selected validators as a one-time grant. This is a structure where the foundation's choices strongly shape who makes the active validator set. In a second VDP wave, the foundation reduced its delegation by 25%, showing a direction of gradually lowering reliance on the foundation, but whether a Monad validator gets in still depends heavily on foundation delegation.

This is a classic dilemma for DPoS chains. In a structure where stake is consensus power and consensus power determines the chain's security, you need a trustworthy validator set and enough delegation from early on. So most foundations pre-mint their own coins and delegate them to stable validators. It is the most practical way to raise a young chain's security and stability at launch, but it concentrates the power to select network participants in the foundation.

Most blockchains expect this problem to resolve on its own over time, as the foundation's stake dilutes and as technology improves enough to raise the number of active validators needed for the same performance, lowering the barrier to entry. But that is a hopeful expectation, not a systemic guarantee. Above all, performance has to hold even if the number of active validators grows well beyond today's. Monad's early-stage decentralization sits in tension between two directions: running the early network stably at the expected performance, and reducing foundation reliance to take in more external delegation and validators.

7.2 MIP-9 and Raising the Active Validator Count

On top of this tension, the first proposal pulling toward decentralization after six months of a stable launch is MIP-9 (Active Set Increase). MIP-9 proposes raising the active validator count ACTIVE_VALSET_SIZE from 200 to 300, and is currently in Draft. Raising the active validator count does not directly affect the execution daemon, but it does affect the consensus layer, MonadBFT, because the size of the active validator set directly determines how many nodes take part in each consensus round. According to the MIP-9 proposal, raising the count by 100 is a meaningful 50% expansion, but not enough to dramatically change the message complexity of a MonadBFT voting round.

Even if MIP-9 lands on mainnet and active validators grow from 200 to 300, that does not mean decentralization has dramatically increased. The barrier to participation has to come down further, and the influence of foundation delegation has to shrink further. If Monad aims to be a general-purpose blockchain and claims to have solved the trilemma, there is no room for compromise here. MIP-9 shows that Monad's aim is not performance alone, but it is not the destination of Monad's decentralization.

7.3 The Absence of Automated Slashing

Monad has no automated slashing. Slashing is the strongest security tool in a proof-of-stake blockchain for making the cost of attack higher than the cost of defense. For actions like double-signing or violating consensus rules, the protocol has to automatically slash that validator's stake so the expected cost of malicious behavior exceeds the expected gain.

Monad tracks malicious validator behavior through logging to keep a record of responsibility, but automated in-protocol slashing is not currently implemented. Detection is possible, but enforcing the economic penalty is left to the social layer outside the protocol. Whether and when slashing is introduced is a marker for whether Monad's security moves from a bootstrap stage to self-sustaining security.

8. Closing: The Monad Ahead

As we have seen, the way Monad solves the problems it faces is to push each system bottleneck to its limit, one at a time. It rebuilds the physical foundation that runs the EVM, makes consensus stop waiting on execution, and tunes memory, storage, and the network to make verification faster. The way Monad resolves the trade-off between decentralization and performance is thorough system engineering.

This shows the strength of Monad's engineering team. But it is also a limit and a risk. Monad still sits on the basic grammar of existing blockchains. It does not fundamentally break out of the existing structure of "verification through re-execution." Someday a project may show up that solves the same problem more simply with an entirely different model. In that case the performance bottlenecks Monad worked so hard to optimize and resolve could be replaced by another approach.

EVM compatibility is also a double-edged sword. It is Monad's strongest advantage. Developers can use their existing Solidity code and tooling, and users keep their familiar wallet and application experience. For the ecosystem, the barrier to entry is low, and it is easy to absorb the liquidity and developer experience of Ethereum and the broader EVM world. But for the same reason, leaving is easy too. The fact that builders can move to Monad easily means that if Monad fails to provide enough performance, liquidity, users, and revenue opportunity, they can leave just as easily for another EVM chain. An EVM-compatible chain has to create a reason to stay on it. Being merely a faster EVM is not enough.

Over the past six months, Monad succeeded in showing the potential of a high-performance EVM with some degree of decentralization. But the era when being fast alone wins a blockchain is over. Blockchain users are expanding from the early adopters who preached cypherpunk ideals to a broader user base and to institutions, and what the network is asked for is changing with them. As the user base expands, so does the nature of demand.

In step with this shift, Monad has to redefine the problem it is solving. The starting point is already in place. As we saw in chapter 2, Monad set up the MIP process after launch, and most of the major improvements over the past six months happened on top of it. The fact that protocol-change discussions are formalized and recorded in the open means Monad is no longer a project designed only inside a closed team. But the MIPs today are still mostly proposed and led by the core development team and the foundation.

Going forward, Monad has to move past solving engineering bottlenecks and present a concrete vision of what kind of network it intends to become over the long term. And the various ecosystem participants who share that vision have to be able to raise the problems they find from their own vantage points through MIPs. The set of people taking part in the MIP process has to widen beyond the foundation and core team to the ecosystem as a whole.

What Monad needs now is a new problem definition and a shift in model that goes past solving technical bottlenecks through system engineering. If the first six months were the time that showed what Monad can do, the time ahead is for showing what Monad intends to become over the long run.