Interview with the Founders of MegaETH and Monad: Reshaping Ethereum's Future (Full Version)
TechFlow Selected TechFlow Selected
Interview with the Founders of MegaETH and Monad: Reshaping Ethereum's Future (Full Version)
This episode of the podcast will discuss the Ethereum Virtual Machine (EVM), focusing on how Mega ETH and Monad plan to make Ethereum faster.
Navigating Web3 tides with focused insightsCompiled & Translated: TechFlow
Guests: Keone Hon, Founder of Monad; Lei Yang, Co-Founder of Mega ETH
Hosts: Ryan Sean Adams, Co-Founder of Bankless; David Hoffman, Co-Founder of Bankless
Podcast Source: Bankless
Original Title: Mega ETH vs Monad: The Battle To Shape Ethereum's Future
Release Date: August 21, 2024
Click here for the condensed podcast notes: Link
Background
In this episode, we explore the cutting edge of the EVM—two blockchains with fundamentally different architectures: Monad and Mega ETH.
Monad is a Layer 1 project aiming to achieve over 10,000 transactions per second by rearchitecting both execution and consensus layers.
Mega ETH is a Layer 2 project focused on performance optimization, targeting over 100,000 Ethereum transactions per second.
This podcast dives into the Ethereum Virtual Machine (EVM), specifically how Mega ETH and Monad plan to make Ethereum faster.
We'll answer these questions:
1. Which is faster, more decentralized, and more censorship-resistant: Monad or MegaETH?
Technical Architecture:
-
Monad improves performance through innovations like Monad DB, optimistic parallel execution, asynchronous execution, and Monad BFT.
-
Mega ETH leverages a Layer 2 architecture, specializing nodes, reducing redundant execution, and boosting performance via just-in-time compilation and parallel EVM execution.
Decentralization & Performance:
-
Monad emphasizes decentralization through low hardware requirements, enabling anyone to run a full node.
-
Mega ETH ensures censorship tolerance and execution correctness via its Layer 2 architecture and economic incentives.
2. How have Monad and MegaETH built large communities before launching testnets or mainnets?
-
Monad:
-
Monad has attracted members by creating and promoting a unique community culture. For example, they launched the "Monad Running Club," encouraging community members to run together. The community has also organically created fun mascots and stories like "Molandak" and "Salmonad."
-
Monad hosts various online and offline events, such as Molingo—a language-learning initiative—that boost engagement and belonging.
-
Community members are encouraged to contribute in diverse ways—from organizing events to creating art. This bottom-up involvement strengthens community cohesion.
-
-
Mega ETH:
-
Branding centers around the "Mega Mafia," their flagship user program and incubator. This identity successfully attracts developers and founders interested in high-performance blockchain applications.
-
By hosting technical discussions and sharing sessions, they attract engineers passionate about blockchain performance optimization. They also use social media to explain technical details and industry anecdotes, broadening their audience.
-
By incubating projects and supporting innovative apps, Mega ETH draws developers eager to build new ideas on blockchain.
-
-
Both Monad and Mega ETH actively engage their communities on platforms like Twitter and Discord, sharing updates and technical insights. This transparent communication builds trust and loyalty.
3. What do you think about the criticism that “building on EVM is like building on quicksand”? Does this affect Solana’s value proposition?
-
Keone’s View:
-
Technical Maturity & Ecosystem: Despite potential technical shortcomings, EVM has become a mature standard with strong network effects and extensive tooling support, making it easier for developers to build and deploy apps. Monad aims to enhance EVM’s performance and scalability through innovation—not replace it entirely.
-
Impact on Solana: Keone believes that while Solana excels at high throughput, EVM’s widespread adoption and ecosystem maturity keep it highly attractive to developers. Ongoing EVM improvements won’t significantly weaken Solana’s value proposition but will solidify Ethereum’s position among developers.
-
-
Lei Yang’s View:
-
Adaptability & Improvement: Lei notes that EVM’s flexibility allows it to evolve continuously. Through Layer 2 solutions, Mega ETH aims to boost EVM performance to support more complex and efficient applications.
-
Competition with Solana: While Solana is competitive in performance, EVM’s wide adoption and compatibility give it advantages in cross-chain interoperability and developer support. By enhancing EVM, Mega ETH aims to offer a more compelling development platform while staying competitive with other chains.
-
Here are the key highlights from the discussion:
Introducing Monad
David: Keone, please explain what Monad is and how it’s doing things differently in the blockchain space.
Keone:
Thanks for having me. I’m Keone Hon, co-founder and CEO of Monad Labs. We’re building Monad—a reimagined version of Ethereum, redesigned from the ground up at the execution and consensus layers. We introduce four major improvements to deliver a high-performance Ethereum capable of over 10,000 transactions per second. These include: a new database called Monad DB built from scratch; optimistic parallel execution enabling many transactions to run simultaneously; asynchronous execution allowing consensus and execution to operate on separate tracks, greatly increasing execution budget; and Monad BFT, a high-performance consensus mechanism that keeps hundreds of globally distributed nodes in sync. Overall, this is a deep systems engineering effort to reimagine a truly high-performance Ethereum.
David: There’s huge anticipation around Monad, especially after Solana and SVM. SVM’s parallelization got people excited about parallel execution—but some smart critics argue the real bottleneck isn’t parallel execution itself, but parallel read access to the database. Can you explain why VM-level parallelization is exciting, and how it ties back to the need for parallel database access—which Monad does enable?
Keone:
Great question. Intuitively, people understand that parallel execution is beneficial because modern computers have multiple processors running many tasks in parallel. I’ve got hundreds of browser tabs open—bad habit, I know—plus Spotify, Discord, all running concurrently. But Ethereum and other EVM chains are single-threaded, executing everything serially, which is kind of insane. Parallel execution uses multiple threads or processors to run workloads in parallel—one of the key improvements that unlocks real performance gains.
But when you benchmark actual costs, the biggest bottleneck isn’t CPU time or instruction execution—it’s state access. Every smart contract relies on residual state. For example, during a token swap, you need balances of two assets in a pool like Uni v2. You must look up those balances to compute the new ones. That requires reading data from disk. So the true bottleneck is state access. Simply parallelizing computation without parallelizing database reads yields only minor improvements compared to what’s possible with parallel database access.
This is exactly what our team achieved with Monad DB—a database built from scratch, optimized for efficiently storing Ethereum Merkle tree data. People always say, “Don’t write your own database”—it’s a massive undertaking. But in this case, it was necessary and impactful because Ethereum state is high-value. We need to access it as fast as possible.
How Does Monad Fit Into Ethereum?
Ryan: Keone, you mentioned bringing this tech to Ethereum, but Monad plans to launch its own alternative Layer 1—an “Alt Layer 1”—not a Layer 2. So how are you bringing this technology to Ethereum? In what ways aren’t you? You’re not scaling Ethereum as a Layer 2 or within mainnet—you’re doing it as an alternative chain, right?
Keone:
Monad is a pioneer environment meant to prove the viability of architectural improvements our team believes will eventually be needed in Ethereum L1. The Layer 1 vs Layer 2 debate has evolved over time. When we started in 2022, everyone assumed Layer 2s interacted with Ethereum the same way—using Ethereum for state commitment and data availability. That’s one model of interaction. But in 2024, how Layer 2s interact with Ethereum and how much they directly leverage Ethereum services is evolving. Our belief is there are many ways to contribute to Ethereum. By focusing on a completely orthogonal direction in Ethereum scaling research—one that’s underexplored—we can still make significant contributions to the broader Ethereum ecosystem.
What Is Mega ETH?
Ryan: Let’s now talk about Mega ETH. Lei Yang, can you tell us what this project is and what it means?
Lei Yang:
Sure. Hi everyone, I’m Lei Yang, CTO and co-founder of Mega ETH. I just finished my PhD at MIT and have spent six years working in blockchain consensus, publishing papers on blockchain security, performance, and networking.
Now I’m building Mega ETH—a performance-optimized blockchain fully compatible with Ethereum. A key difference here is that we unapologetically prioritize performance and focus on how to achieve it.
First, we chose to build as an Ethereum Layer 2 because we believe it’s the optimal architecture for performance engineering. Using the Layer 2 architecture, we’re building what we call the “first real-time blockchain.” We aim to process over 100,000 real Ethereum transactions per second—not just payments—with block times between 1 to 10 milliseconds. Our goal is for DApps to feel as responsive and functionally rich as Web 2 apps, while delivering the benefits users expect from DApps: execution correctness, censorship resistance, etc.
On the technical side, being a Layer 2 enables node specialization. In Mega, we minimize execution redundancy so that only one active sequencer executes each transaction at any time. Other nodes subscribe to state updates and stay current but don’t re-execute every transaction. This dramatically boosts performance. We can scale up the sequencer’s hardware while keeping hardware requirements low for full nodes that only care about the current state.
For the sequencer, we’ve made optimizations including a new data structure functionally equivalent to Merkle Patricia Trie but more efficient for real hardware like SSDs and RAM. We JIT-compile Ethereum smart contracts from bytecode to native assembly and execute EVM in parallel. These are the highlights—we call the final product a “real-time blockchain.”
Similarities and Differences
Ryan: What do you see as the similarities and differences between Mega ETH and Monad? To a layperson—or someone familiar with crypto—the similarity is clear: both want to scale EVM and enable parallel execution. But Mega ETH uses a Layer 2 architecture, settles to Ethereum, and uses Ethereum for data availability, correct?
Lei Yang:
Not quite accurate. We use EigenLayer for data availability and settle to Ethereum. Also, a subtle point: we don’t treat parallelization as our flagship feature or primary optimization. We value single-thread performance just as much.
Ryan: So what do you see as the key similarities and differences?
Lei Yang:
I agree with your summary of similarities. Both focus on performance and aim to unlock next-gen applications by providing abundant resources. But the difference lies in our view of parallelization. If you want to deploy 100 copies of Uniswap, Ethereum’s block space is sufficient.
But what we really need are entirely new applications. For these, we believe extremely high single-thread performance is critical—it reflects the actual performance available to a single app. In other words, we’re pushing the frontier of single-thread performance. Optimizations like new data structures, JIT compilation of smart contracts, and memory computing techniques—all target single-thread speed. We see parallelization as a second step, after achieving enough single-thread performance to support novel apps. Though in practice, we’re engineering both simultaneously.
Another distinction is our explicit focus on performance. We chose Layer 2 because we believe it’s the sole optimal architecture for performance—enabling maximum elimination of redundancy in execution and consensus. That’s a key difference.
David: Keone, what’s your take?
Keone:
One thing worth noting is that Monad’s goals and architectural improvements aim to extract maximum performance from minimal hardware requirements. From a decentralization standpoint, it’s crucial that anyone can run a node on commodity hardware. To achieve this, we need software improvements that extract higher performance from hardware—rather than relying solely on expensive hardware. So I think the foundational premise of these two projects may be very different. At Monad, we’re focused on maximizing hardware efficiency so anyone can run a full node, access all state, keep up with the network, verify directly—and not rely on trust.
Impact of Architecture
David: Both Moand and Mega ETH share the same goal: a very fast EVM. But your paths to get there are almost opposite. Mega ETH opts for a Layer 2 with a single sequencer or very few sequencers, while Monad pursues a Layer 1 with a broad validator set. Technically, your architectures align with these end goals.
Since the end goal is the same—a very fast EVM—will the applications on each chain be similar? Or will different ecosystems emerge due to architectural differences? How will underlying architecture shape application ecosystems? Or might it not matter at all?
Lei Yang:
I think they’ll be very different. First, as I mentioned, we’re singularly focused on performance—achieving lower latency and higher throughput. I want to emphasize latency because, as noted, we use a single sequencer. This allows streaming transaction execution, minimizing wait time and block packing time. We expect feedback—from transaction arrival at the sequencer to execution, packaging, and state update—in just 1 millisecond.
From my background in consensus research, I believe this is impossible in any system where consensus is on the critical path. Consensus requires messages to pass between all nodes. With global distribution, messages travel around the world. Even at light speed, this takes hundreds of milliseconds—plus at least two to three rounds of messaging, leading to 600–700ms delays. That’s the minimum latency for L1s or L2s using decentralized, consensus-based sequencers.
This low latency enables unique applications. Imagine Minecraft—you wouldn’t want your character waiting 600ms before moving. For HFT, it’s exciting—market makers and traders could collaborate with our sequencer. Real-time apps like these will define our unique ecosystem.
David: Keone, what’s your take on the same question?
Keone:
I was thinking about decentralized Minecraft—if you're far from the sequencer, you won’t get low latency.
Lei Yang:
Yes, absolutely. Let me distinguish two parameters. One is ticktime or block time—action precision or resolution, e.g., an action every 1ms. But when users receive feedback, we’re not breaking physics. Their input must go from keyboard to sequencer and back to display. But this delay is common in online MMOs or RPGs and is acceptable. The real issue is if consensus is on the critical path, causing three global message rounds and >600ms latency—far above typical delays between users and centralized sequencers.
David: Keone, what’s your vision for the app ecosystem on Monad? Are you focused on specific areas?
Keone:
I think the beauty of EVM is that it’s a dominant standard with incredible network effects. Countless libraries are built for it, many apps developed here, and much applied cryptography research done in the EVM context. As a project fully bytecode-equivalent to EVM, Monad offers developers the best combo of performance and portability for existing EVM-built apps. Monad continues this while preserving decentralization. This might be a convergence point between Monad and Mega ETH—our team believes decentralized block production is vital from censorship resistance and other values cherished in crypto. Even as you said, the consensus overhead due to light-speed limits is unavoidable—unless we figure out how to speed up light.
David: Keone, are you saying building a Layer 1 carries responsibility because it embodies crypto ideals? What’s the point of a Layer 1 without censorship resistance? What’s the point if you can’t effectively decentralize the validator set? Beyond Monad EVM and Monad DB’s strong architectural improvements, you must do certain things to qualify as a legitimate blockchain project—things our industry values. Is that what you mean?
Keone:
Yes. And this also comes from a social layer reinforcing these values. Decentralization matters in hardware requirements, number of consensus-participating nodes, stake distribution, etc.—all attributes that must be evaluated. Plus, a strong social layer to reinforce these values.
Decentralization - Monad
Ryan: “Decentralization” is a sacred word in crypto. We chose Layer 2 deployment precisely because of decentralization and censorship resistance. Keone, can you discuss Monad’s stance on decentralization? If you’re trying to maximize decentralization, why choose Layer 1 over Layer 2? For a typical Ethereum user, Ethereum has been battle-tested for years, offering strong decentralization—it excels at this. Its execution layer handles about 10–15 TPS, which is insufficient in many ways. But its decentralization properties are nearly Bitcoin-level, maybe even better. So why abandon that for a Layer 1?
Keone:
As you said, we optimize for decentralization in Monad’s design choices. First, I’d note that for any network parameter choice, we should strive to extract maximum performance. So if we have a network of 10,000 fully globally distributed nodes, with specific hardware requirements—like in Ethereum, jokingly, you should be able to run it on a Raspberry Pi. Given certain hardware specs and node counts, we should squeeze maximum performance from them. If requirements are slightly higher but still reasonable—say, 32GB RAM, 2TB SSD, 100Mbps bandwidth, and an affordable CPU in Monad’s case—we should extract as much performance as possible from that setup.
Ryan: Are these exact specs or a rough range?
Keone: These are the exact specs.
David: So roughly consumer-grade laptops—like a MacBook Pro—or typical broadband internet connections. That’s your described hardware, with 200–300 nodes.
Keone: Yes, like a laptop you could buy at Costco.
Ryan: Do you consider this sufficiently decentralized? How does it compare to Ethereum’s decentralization? Of course, it’s not just about nodes and validators—there are other participants like block builders, forming a whole supply chain. Would you say Monad’s design is more decentralized than Ethereum’s? How would you frame this discussion?
Keone:
I want to clarify: for a given parameter set, we should extract maximum performance from that configuration. The only way to achieve this is through software improvements. Some of the innovations our team pioneers in Monad will benefit other setups—like Ethereum L1 today, with ~10,000 nodes. Different node count, slightly different hardware. The new DB design isn’t tied to a specific SSD size—it works across sizes. Ultimately, it’s about extracting maximum performance with very reasonable hardware. My point is, if you limit the network to one node and remove hardware constraints—or allow unlimited RAM—you might get different performance traits, maybe even free ones like keeping all state in memory instead of SSD.
Ultimately, the engineering team’s job is to extract maximum performance from any hardware setup. Everyone picks a starting hardware point and squeezes as much performance as possible. We think this is a great anchor—hardware remains very reasonable, yet we extract substantial performance.
Decentralization - Mega
Ryan: Lei, what’s your take on the keyword “decentralization”? What’s Mega ETH’s stance? Any similarities or differences compared to what we just heard?
Lei Yang:
Absolutely. First, I want to address performance per hardware unit. Mega ETH also strives to maximize performance per hardware unit—per GB of RAM, per CPU core, per GHz of CPU frequency. But if hardware could scale infinitely, all optimizations might be irrelevant. Unfortunately, no hardware has infinite cores or memory. Even top-tier server hardware has limits, requiring hard engineering to maximize efficiency—meaning performance per unit, like compilation and new data structures.
Back to decentralization. We also have lightweight nodes. Our full nodes require 8–16GB RAM, 1TB SSD—not server-grade, but consumer CPUs with 4–8 cores. Roughly equivalent to Ethereum execution nodes or S molar nodes. But the key difference is the sequencer bears most of the load, executing all transactions. The L2 architecture allows us to maintain low hardware requirements for full nodes—so anyone who wants the latest state can run one. This actually enhances decentralization via Layer 2. Additionally, verifier nodes can run on a Raspberry Pi—no storage needed, fetching verification data dynamically in chunks. They can verify the chain piecewise.
We deeply care about decentralization. Node specialization is our response to Keone’s observation. If you require everyone to use powerful hardware, there’s no decentralization—nobody can afford servers, or want noisy machines at home. I have one nearby—when I upgrade or reboot, it’s loud. Nobody wants that at home. We take this seriously—node specialization is our solution.
Ryan: Is node specialization simply the L1/L2 divide? Is that what this is?
Lei Yang:
No—basically, you have different node types with different hardware performing distinct tasks in a Layer 2 system. Sequencers execute all transactions, full nodes subscribe to state updates, verifiers statelessly validate transaction states.
But on decentralization, while we care deeply, we view decentralization as a means to an end. What you want is execution correctness, finality, censorship resistance. I think most important figures from Web 2 entering crypto don’t seek “decentralization” per se. They want execution correctness—they don’t want to trust a single entity with critical apps. Decentralization, as we see, works well for L1s—it’s a means to an end. Now that L1—Ethereum—is established and maximally decentralized, it’s time to move forward. Ethereum handles decentralization for us—now it’s time to optimize performance, leveraging Ethereum’s decentralized foundation.
Which Is More Decentralized?
Ryan: Can we have a decentralization debate? Instead of using “decentralization” directly, let’s use it as a proxy for all the attributes you mentioned—censorship resistance, settlement assurance, etc. So which super-fast EVM is more decentralized: Mega ETH or Monad?
Lei Yang:
Great question. We can analyze from several angles, like hardware specs. I mentioned Mega ETH’s full nodes and verifiers have hardware similar to Ethereum and Monad nodes. Mega ETH’s full nodes and verifiers are actually high-end—they download info on demand. So hardware specs are comparable. You don’t need stronger hardware than existing Ethereum execution nodes to download and maintain the latest Mega ETH state.
Keone:
Sorry, you keep calling them full nodes—but is that accurate? Most in the blockchain space define a full node as one that executes all transactions and validates results. Your “full node” seems different.
Lei Yang:
I can clarify. Visit Ethereum’s site—guides show syncing a full node, with snapshot sync or fast sync as default. Terminology changes, but essentially, default is downloading the latest state snapshot. Such nodes don’t truly validate transactions initially—they start serving the downloaded state, maybe selectively verifying past transactions, but not necessarily.
I emphasize: our definition of a full node is maintaining and tracking the latest state changes. That’s crucial. Of course, terminology can be debated—industry alignment on terms would be ideal.
David: Keone, how do you define a full node? How does it differ from Lei’s view?
Keone:
I think if your node must trust a centralized entity, that’s not good. The whole point of blockchains is not needing trust—we can verify. Whether we call it a full node or not, I’m just pointing out the term’s usage relative to others. But what I care about is this: if I’m a small business owner accepting payments, I need to ensure the payment succeeded. To me, blockchain’s promise is that this business owner can run a node and verify the transaction happened—without trusting any single centralized intermediary.
Lei Yang:
I agree “don’t trust, verify” is crucial. If I may add: don’t trust, verify—but better yet, let others verify for you. That’s the case with optimistic and ZK rollups.
Take your example: I’m selling a laptop, someone pays $5,000 on Mega ETH. Before handing it over, I am trusting the single sequencer to correctly order and execute the transaction. But importantly, this sequencer operates under social and economic contracts. So the crux is cryptoeconomic security.
If the sequencer cheats—excludes a transaction or gives me an incorrect balance update—every piece of info the sequencer tells me before I hand over the laptop is signed. If they misbehave, that signature becomes proof, and they get penalized. So while the sequencer might lie to me, if the cost is 1,000 Teslas or 1,000 laptops, it’s not worth it.
I think it boils down to cryptoeconomic security. Starting from PoW in Ethereum, I found it beautiful. Over time, I learned about PoS and cryptoeconomic security—I now find them more important.
Ryan: We’re using “decentralization” as a proxy for censorship resistance, etc. Keone, what’s your view? Which is more decentralized? What’s the path to that goal?
Keone:
To me, decentralization means anyone can run a full node. I mean a node that can access all state and execute all transactions. Monad is pioneering architectural improvements so anyone can run a node, stay current with the chain, execute all transactions, and access full state—without drastically increasing hardware demands.
I think this is vital for decentralization. Other architectures may sacrifice decentralization and censorship resistance by moving execution off L1. It’s interesting, with clear benefits. But from a system perspective—hundreds of nodes in consensus, thousands of full nodes accessing full state—that’s important. Hardware must be reasonable to ensure decentralization. High-cost hardware leads to centralization—we see this in high-performance chains where small holders can’t afford to run nodes. Efficiency is crucial—software efficiency gains are essential for building decentralized networks.
Mid-Podcast Summary
David: Let me summarize so far to ensure I’m following.
-
I agree with you, Keone. In Ethereum, my definition of a full node is: I listen to the blockchain, keep a copy of the ledger, and verify incoming transactions and blocks for validity. Sometimes I receive an invalid block—I reject it and continue listening for valid blocks from other sources. I ensure only valid blocks and transactions are added. Because everyone plays this role, the blockchain stays decentralized and correct.
What you describe—listening to a trusted single source, relying on a centralized sequencer—reduces the full node’s function. Automatically trusting block validity makes you more like an incomplete full node. That’s the point of contention.
-
Lei’s response is that if the sequencer signs transactions and faces severe economic penalties for cheating, then while we may not be the full nodes I described, there’s strong economic security. That’s our new trust assumption—this summarizes the discussion so far.
Lei Yang:
Exactly. The node type you described combines Ethereum’s full node and validator roles—typically, full nodes don’t sign or mine blocks. Should a non-staking node be called a full node? I think yes. This node type goes beyond the typical full node definition.
Keone:
Just to confirm—you mentioned earlier that if the sequencer publishes an invalid state root, how are they punished?
Lei Yang:
It’s standard optimistic and zero-knowledge proofs. The sequencer posts state updates with provable trails. If state is wrong, subsequent transactions and blocks are submitted to Ethereum. For optimistic proofs, verifiers have 7 days to re-execute. If errors are found, they submit fraud proofs to automatically slash the sequencer. For ZK proofs, the sequencer must prove state transitions in real time before posting updates. As I said, it’s standard optimistic and zk rollups.
Keone:
These mechanisms differ. Have you decided which one to use?
Lei Yang:
We currently use optimistic proofs because we find ZK proofs not efficient enough for our throughput needs.
Keone:
I see. But you mentioned ZK as a future possibility.
Lei Yang:
Yes, I was just giving a high-level overview of validity proofs.
Keone: But for optimistic proofs, verification requires a lot of memory, right?
Lei Yang:
Actually, no—because, as I repeated, verifiers need only Raspberry Pi-level specs. The key is so-called stateless verification. This concept isn’t ours—it originated from Ethereum’s stateless client discussions years ago. We’ve adapted the technology.
Software Efficiency
David: Back to Monad’s software efficiency—can we understand it as minimizing computational resources consumed per transaction across all global nodes? Is that the source of your efficiency? If you optimize the total compute cost of running the Monad blockchain, what ripple effects occur? What benefits does Monad gain?
Keone:
Let me clarify: Lei mentioned efficiency as using minimal compute for a task. Reducing consensus nodes in Monad would reduce power consumption somewhat, but that’s not our team’s primary optimization. We want validation cost per full node to be as low as possible—so running a full node is cheap and keeps pace with changing global state.
David: Maybe I misunderstood how Mega ETH operates. Suppose Mega ETH achieves speed via centralized compute, while Monad is a consensus-based L1 allowing independent stakers. So your view is that due to Mega ETH’s centralized sequencer, it’s weaker in decentralization and censorship resistance, while Monad, due to its architecture, better preserves these—do you agree?
Keone: Yes, I agree.
David: Because you have independent stakers and thus independent full nodes, maintaining full blockchain integrity, ensuring decentralization and censorship resistance. Lei, your thoughts?
Lei Yang:
It’s important to recognize that our finality, correctness, and censorship resistance are based on Ethereum. Compared to hundreds of nodes, tens of thousands support these censorship-tolerant guarantees. So by your standard, I believe Mega ETH is more decentralized. I generally dislike comparing products’ decentralization without clear definitions. But by your metric—number of nodes providing finality guarantees—Mega ETH is indeed more decentralized. Because we’re built on Ethereum. That’s a conscious choice.
Ryan: Keone, how do you respond? How would you describe Monad’s decentralization claim? How do you counter that argument?
Keone:
I think we should move toward greater efficiency. Returning to Ethereum L1 discussions—how to increase execution throughput from 15 TPS to higher levels. Spikes in gas prices on L1 are frustrating. Improving Ethereum’s performance is beneficial—pushing software improvements to make Ethereum stronger is important. That’s a core principle behind Monad’s design—making architectural improvements that might one day be integrated into Ethereum L1.
Lei Yang:
If we return to Mega ETH relying on Ethereum elements, all L2s can claim greater decentralization since we all use Ethereum for settlement. Monad introduces tech to make Ethereum more efficient without increasing hardware demands—this helps improve the entire decentralized system.
Keone:
I think we’re both contributing to the Ethereum ecosystem. But let me add something about total hardware consumption. If we define total hardware consumption as the capital spent buying servers and nodes to properly generate blocks, Mega ETH has one sequencer, Monad has hundreds of full nodes. I’m not sure operating and purchasing one sequencer is cheaper than hundreds of full nodes. This argument confuses me—because if the Monad network had only two nodes instead of hundreds, costs would indeed be lower.
Lei Yang:
Yes, that’s true. But in that hypothetical, censorship tolerance, finality, and correctness depend on those two Monad nodes. Mega ETH depends on tens of thousands of Ethereum nodes—that’s a key difference. You said all L2s can claim this—we fully agree, and we chose to build on L2.
Keone:
I have a question—because you keep saying “censorship tolerance,” carefully avoiding “censorship resistance.” Is there a difference?
Lei Yang:
I usually use them interchangeably. The key difference is whether you want real-time censorship tolerance or tolerance within limited delay. Mega ETH offers time-bound censorship tolerance—users can directly submit censored transactions to Ethereum to guarantee inclusion, forcing the sequencer to include them in L2 blocks. If the sequencer fails, there are cryptoeconomic consequences. So it’s a blend of delayed censorship tolerance and cryptoeconomic security.
Keone:
That’s standard OP stack.
Lei Yang:
It’s not Mega ETH’s tech—it’s Layer 2 fundamentals.
Monolithic vs Modular Architecture
Ryan: Viewing from the Ethereum ecosystem, both projects are, in a way, responses to Solana’s innovation—especially high-throughput SVM. Ethereum hasn’t innovated much in VMs since inception, and the EF hasn’t prioritized it. But both of you are innovating on EVM, opening new possibilities.
I think Keone’s Monad approach is more monolithic—putting all state and components in one full stack, rather than splitting execution, settlement, and data availability across layers and dependencies. You support EVM and a monolithic architecture. Mega ETH also supports EVM but leans modular. Your emphasis on decentralization traits and L2 focus is solid.
Both innovate on EVM, benefiting Ethereum’s progress, especially via open-source. Monad leans monolithic integration, Mega ETH modular. I want to clarify these architectural differences—we in crypto love debating architecture.
Keone:
I think Monad is a full-stack approach—optimizing and coordinating all layers. Ethereum itself is full-stack—VM, consensus, and DA layer for others. When improving Ethereum, we must consider how parts fit. That’s what our team is solving. You mentioned Solana—Monad’s one innovation is asynchronous execution. Think of the movie *Limitless*—the idea that “you only use 10% of your brain.” If you used 100%, life would be simpler.
This analogy helps—existing blockchains alternate consensus and execution. Like Ethereum and almost all others, execution budget is tiny because consensus consumes most time. Consensus is expensive—nodes are globally distributed. So execution uses only a fraction of block time. In Ethereum’s 12-second block, execution budget is just 100ms—a tiny slice. With asynchronous execution, Monad moves execution off consensus’s critical path, running it on a separate track slightly lagging consensus. This frees the entire block time for execution—a massive boost from different software architecture.
Our team has discussed this for a long time. Recently, I’ve seen other chains—including Solana—starting to talk about asynchronous execution and how to integrate it. This is only possible when designing the entire system with consensus-execution interplay in mind, optimizing the full stack. So Monad aligns with the philosophy of optimizing the whole system for peak performance.
Ryan: When you launch Monad, it might confuse many—narratives may label you an “Ethereum killer” or “Solana killer.” We need a “killer” to drive the story. Lei, what’s your reaction to my framework? You both support EVM, your project takes a modular path, while Monad takes an integrated, monolithic approach.
Lei Yang:
We’re EVM supporters aiming to enable new apps. Our product design focuses on performance—throughput, low latency, real-time. I don’t recall discussing monolithic vs modular in our design talks. So I fully agree—we’re on the modular path. But our design isn’t guided by religious debates—it’s because we chose to build on L2.
Engineering-wise, we focus on performance. If Monad is full-stack, we focus on performance and are willing to make controversial, interesting design choices.
Community Building
David: One fascinating thing about your two blockchain projects is that despite lacking testnets, both have large communities. Your brands attract many developers—people are already building on Monad, forming partnerships. Same for Mega ETH—with the “Mega Mafia” group and a hat everyone wants. As EVM chains, what’s your process for community management and business development? There are ~50 EVM chains, but you two excel at community building and developer attraction.
Keone: Let me show you this Monad hat. Community involvement is incredible—all driven by crypto enthusiasts passionate about DeFi, constantly watching crypto Twitter memes and stories. Many aren’t crypto Twitter celebrities—they’re followers who found belonging in the Monad community, opportunities to contribute and lead—organizing events, creating art. We have fun activities like the Monad Running Club—goal was 10,000 km together, quickly achieved. Molingo—language learning, like group Duolingo. The community is vibrant, driven by individuals. It aligns with crypto’s spirit: everyone matters, everyone can make a difference.
David: When only a few are in the internal Monad testnet, how do you keep them engaged? What are they doing? Running together is cool, but are there more “crypto-native” activities?
Keone:
Our activities evolved over time. Initially, many gathered just to vent during bear markets. Much was path-dependent—those were tough times, many early members sought refuge scrolling timelines. Over time, it evolved into structured activities. Some in our community are finding jobs in the Monad ecosystem, connecting with great community managers, marketers, or those with good instincts for driving projects. It’s an emerging, growing environment full of opportunity.
David: If you’re part of the Monad story’s audience, you’ll notice not just Molandak, but other creatures like Monad fish and others I don’t understand. Where do these Monad creature stories come from?
Keone:
Great question. When we opened the community, Bill Monday and I brainstormed heavily for the right mascot. I have a Notion page listing potential mascots—all terrible. Each idea worse than the last. We overthought it, trying to link to Monad’s speed—cheetahs, cars. Ultimately, the unofficial mascots emerged from the community: someone uploads an image, community filters it, it surfaces—no formal vote, just collective memory and reuse. Now Molandak, Mocodal, Salmonad, Moyaki all have rich stories.
(TechFlow Note: The animals mentioned are meme-ified cartoon characters related to Monad.)
David: Lei, how did you start the Mega ETH apparel brand?
Lei Yang:
Our community growth is surprising—we only went public recently. Our brand is Mega Mafia—flagship user program and incubator.
We seek 0-to-1 apps only possible on a real-time blockchain like Mega. We target founders drawn to crypto—maybe read online promises of building decentralized, trustless apps. But when they arrive, they find it’s a lie—resources and infrastructure fall short. So we tell them: Mega offers new infrastructure, encouraging them to rediscover their original crypto dreams.
Examples: on-chain Minecraft, infinitely scalable VPN, orderbook-based DEX, real-time prediction markets, live game shows. I’m wearing a Mega Mafia T-shirt—central to our community. As for rabbits—if Monad is mid-curving, we’re left permanent. We chose rabbits because I genuinely like them. First chat with co-founder and CBO Shuyao, she said we need an animal mascot. I said I feed rabbits on MIT campus almost every night—so rabbit became the mascot.
I think it’s great—not community-chosen, but our community loves rabbits. Our only Discord rule: if you eat rabbits, you’re permanently banned. Otherwise, everything’s going well. More people are getting interested in the tech. Some listeners may have seen our TikTok clips—short videos explaining common misconceptions and lesser-known crypto trivia. We also do serious performance engineering—posting long-form threads and upcoming blog posts for technically inclined audiences. Driving app development is the core of our community-building efforts.
Why Choose the Ethereum Virtual Machine (EVM)?
David: In our recent podcast with Justin Drake and Anatoly, Anatoly described EVM as “building on quicksand.” You can rebuild EVM architecture for developer ease, but it’s still hard. What’s your take? You both chose EVM—why? How do you see EVM’s future role in the industry? I remember in 2021, the Ethereum community believed EVM was central—even “Ethereum killers” like Phantom, Avalanche used EVM. What’s your overall view of building on EVM? Why commit to it? How do you see it evolving?
Keone:
I think EVM is actually a very suitable bytecode standard. Sure, minor issues—like 32-byte slot size being large—but fundamentally, it’s a very reasonable, expressive standard. We have powerful high-level languages like Solidity, Viper, Huff. So much criticism of EVM is misleading, baseless, or just attention-seeking. EVM is an excellent standard—continuously improvable via new precompiles or opcodes. It’s evolving—no fundamental flaws. Combined with the network effect of countless developers already building on EVM, vast libraries, applied cryptography research—it’s an undeniable choice.
David: Lei, your thoughts?
Lei Yang:
I mostly agree. EVM has no fundamental flaws. Interestingly, at EthCC, we hosted Vitalik. A student asked him about regrets in Ethereum’s tech choices. I don’t think Vitalik mentioned EVM. He said he wouldn’t start the precompile slippery slope. But fundamentally, EVM is fine—we fully agree. Also, as engineers and researchers, there’s always an urge to scrap everything and restart. But as Keone said, the ecosystem’s tools, libraries, research—and most importantly, people—are accustomed to EVM. Intel doesn’t release a new ISA every five years for a reason—capital and knowledge accumulate in a tech ecosystem. So EVM has no fundamental issues—I’m 100% confident EVM will continue to thrive.
David: Keone, final question—Monad’s future and open-source nature. Will Monad EVM and Monad DB eventually be open-sourced?
Keone:
That’s the plan. We’ll consider timing—code will be fully open before mainnet, so people can read and verify. Critical for audits and security. No problem.
When Will Mainnet Launch?
Keone: Our team is working hard—can’t give an exact date. My answer: when Molandak emerges from this locker and starts handing things out, that’s when mainnet launches.
Lei Yang: We expect to open by year-end or early next year.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
深潮TechFlow
