What Is Monad: Complete Parallelized EVM Layer 1 Guide (2026)

For years, Ethereum has been the undisputed home of smart contracts, but it has carried a fundamental limitation: every transaction in a block must execute one after another, like cars stuck in single-file traffic on a one-lane road. The result is a network that processes roughly 15 transactions per second, charges high gas fees during peak demand, and forces developers to push activity to sharding alternatives, rollups, or entirely separate chains. Monad arrives in 2026 with a bold claim: keep full EVM bytecode compatibility, change nothing for developers, and push throughput to roughly 10,000 transactions per second by re-engineering how the execution engine itself works.

Monad is a Layer 1 blockchain designed from scratch by former Jump Trading high-frequency engineers who concluded that the EVM specification was not the bottleneck. Instead, they argued, the bottleneck was the way every existing EVM client implemented consensus, execution, and storage as a synchronous, single-threaded pipeline. By rewriting those layers using parallel EVM execution, deferred execution, a pipelined consensus called MonadBFT, and a custom database called MonadDB, the team has produced a chain that runs unmodified Solidity contracts at speeds that previously belonged to non-EVM networks like Solana.

This guide is the deepest English-language breakdown of what Monad actually is, what makes it different from every other parallel EVM project, how the four pillars of its architecture work together, what the MON token does, how its mainnet ecosystem looks in 2026, and how Monad compares against Sei v2, MegaETH, and Solana. By the end you will understand not just the headline numbers but the engineering decisions behind them.

What Is Monad

Monad is a Layer 1 proof-of-stake blockchain that executes Ethereum smart contracts in parallel. It was founded in 2022 by Keone Hon, James Hunsaker, and Eunice Giarta, all former engineers at Jump Trading and Jump Crypto. Jump is one of the largest high-frequency trading firms in the world, and the team brought a low-latency engineering mindset to a problem that the broader crypto industry had been treating as an inherent constraint of the EVM model.

The thesis is simple but counterintuitive. Most scaling efforts in the last five years have either moved execution off-chain (rollups), changed the virtual machine entirely (Solana, Aptos, Sui), or split state across multiple chains (sharding, app-chains). Monad does none of those things. It keeps the EVM specification untouched at the bytecode level. Any Solidity contract that runs on Ethereum runs on Monad without recompilation. The same Hardhat scripts, Foundry tests, MetaMask connections, ethers.js code, and Etherscan-style explorers work out of the box. The difference is entirely beneath the surface.

What changes is the implementation of the four heavy components that turn ordered transactions into committed state: consensus, transaction ordering, execution, and persistent storage. Each of these layers has been redesigned to take advantage of modern hardware: many CPU cores, NVMe SSDs, and high-bandwidth networks. The result is a chain that targets 10,000 transactions per second, one-second block times, and a single-slot finality of around one second, while charging gas fees that are several orders of magnitude lower than mainnet Ethereum.

Monad raised one of the largest crypto rounds of 2024, a $225 million investment led by Paradigm with participation from Electric Capital, Coinbase Ventures, GSR, Wintermute, and others. That funding bankrolled the long testnet phase, the public devnet, the developer outreach program, and ultimately the mainnet launch and MON token generation event in early 2026.

The Problem: The EVM Throughput Ceiling

To understand why Monad exists, you have to understand why Ethereum is slow. The EVM was designed in 2014 and 2015 with the goal of being deterministic, simple to reason about, and easy to verify across thousands of independent nodes. Those goals were achieved, but they came with a structural cost: every transaction in a block is executed sequentially, one after another, in the order chosen by the proposer. There is no concurrency. There is no speculation. Every state read and write happens through a Merkle Patricia Trie that was optimized for cryptographic verifiability, not for throughput.

That design made sense for a network whose primary job was to host a few thousand decentralized applications and process a million transactions per day. It does not make sense for a network that wants to host order books, perpetual exchanges, on-chain games, social graphs, and AI inference markets. Even with rollups absorbing most of the load, the underlying execution engine on any individual EVM chain remains a bottleneck. A single complex transaction can occupy an entire block. A burst of NFT minting can push gas to triple digits. A high-volume on-chain order book is, on Ethereum mainnet, simply not feasible.

Several teams have tried to break this ceiling. Some, like Solana and Aptos, chose to abandon the EVM entirely and write a new virtual machine optimized for parallelism. Others, like Sei v2, retrofitted parallel execution onto a Cosmos-based EVM. Monad's path is to keep the EVM at the bytecode level while rebuilding everything around it. The bet is that developer mindshare, tooling, and audited libraries are the EVM's greatest asset, and that throwing them away to gain performance is a bad trade if you can keep the performance and the ecosystem at the same time.

Monad's Four Key Innovations

Monad's performance comes from four engineering bets that are layered on top of each other. Each one alone is a meaningful improvement; together, they unlock the order-of-magnitude jump from 15 TPS to 10,000 TPS.

The crucial insight is that no single layer can deliver 10,000 TPS on its own. Parallel execution is useless if storage cannot keep up. Storage is useless if consensus blocks execution. Consensus is useless if it has to wait for execution to finish before voting. Monad's architecture is a chain of optimizations where each layer feeds the next, and removing any one of them collapses the throughput back toward the Ethereum baseline.

MonadBFT: Pipelined HotStuff Consensus

The first layer is consensus. Monad uses a custom protocol called MonadBFT, which is a variant of the HotStuff family of Byzantine Fault Tolerant consensus algorithms. HotStuff was the basis for Diem's consensus and has since been adapted by Aptos, Sui, and several other modern chains. Monad's variant introduces two important modifications: pipelining and a tight integration with deferred execution.

In classical BFT consensus, a leader proposes a block, validators vote on it, the votes are aggregated, and the block is committed. Each of those phases is a round trip, and the chain cannot move to the next block until the current one is finalized. Pipelined HotStuff overlaps these phases. While the network is voting on block N, the leader can already be proposing block N+1, and validators can be pre-validating signatures for block N+2. The pipeline keeps every part of the protocol busy at all times, like a CPU pipeline keeps fetch, decode, and execute units all active on different instructions simultaneously.

Monad uses a proof-of-stake validator set bonded by the MON token. Validators run high-spec hardware. The launch validator set is around 100 nodes, with plans to expand over time as the protocol stabilizes. Single-slot finality means a transaction is irreversible within roughly one second of being included, compared to twelve to fifteen minutes on Ethereum, which makes Monad usable for applications like trading and gaming where waiting tens of minutes for finality is not acceptable. For more on consensus models, our guide on proof-of-stake goes deeper.

Deferred Execution Optimization

The second layer is the most counterintuitive of the four: deferred execution. In every traditional blockchain, the proposer of a block has to execute every transaction in it before it can propose the block. This is because the block header contains the resulting state root, and you cannot compute the state root without running every transaction. Validators then re-execute every transaction to verify that the proposer's claimed state root is correct. Execution and consensus are tightly coupled, and that coupling is one of the main reasons throughput is capped.

Monad decouples them. The block produced by consensus contains the ordered list of transactions and a commitment to the previous block's state root, but it does not contain the resulting state root of the current block. The current block's state root is computed asynchronously, several blocks later, when execution catches up. This sounds dangerous at first, but it is mathematically sound: since the order of transactions is fixed by consensus, every validator deterministically computes the same future state root, and any disagreement is provable after the fact.

The practical effect is enormous. Consensus runs at the speed of network round trips, which is the actual physical limit. Execution runs in parallel with consensus, on a separate pipeline. The two no longer block each other. A validator that votes on block N is already preparing block N+1, executing block N-3, persisting block N-5, and finalizing block N-10, all simultaneously. This is the same trick that modern CPUs use to run far faster than a naive implementation would allow, and it works for the same reason.

Parallel EVM Execution

The third layer is what most people associate with the word "Monad": parallel EVM execution. The naive way to run an EVM is one transaction at a time, in the order chosen by the block proposer. Monad runs many transactions at once, on many CPU cores, and resolves any conflicts after the fact. The technical name for this strategy is optimistic concurrency, and it has been used in databases for decades.

The way it works is simple to describe. The execution engine takes the ordered list of transactions from the consensus layer and dispatches them to a pool of worker threads. Each thread executes its assigned transaction speculatively, recording every state read and every state write into a transaction-local read set and write set. Once all transactions in a batch have been executed, the engine walks the original order and commits transactions one by one. If transaction N's read set does not overlap with the write sets of any earlier transaction it has not yet seen committed, the result is accepted. If there is a conflict, the transaction is re-executed against the committed state.

Consider a concrete example. Imagine a block contains 500 transactions. 100 of them swap USDC for ETH on Uniswap-style pool A. 100 of them swap USDC for ETH on pool B. 100 are NFT transfers. 100 are simple ETH transfers between unrelated wallets. 100 are calls to a perpetual exchange. Of these, the only group that has serious conflicts is the swaps on pool A, because they all read and write the same liquidity reserves. The same applies to pool B. Everything else can run completely in parallel. On Monad, the engine identifies these independent groups dynamically and runs them concurrently. On Ethereum, all 500 transactions wait in a queue.

Importantly, because the EVM bytecode itself is untouched, the developer writing the smart contract does not need to mark transactions as parallel or annotate state. The chain figures it out at runtime. This is a major difference from chains like Sui or Aptos, which require developers to declare which objects a transaction will touch in advance.

MonadDB: The Custom Storage Layer

The fourth and final layer is MonadDB, a purpose-built database for blockchain state. Most existing EVM clients store state in a Merkle Patricia Trie backed by a generic key-value store like LevelDB or Pebble. Those databases were designed for general workloads and do a perfectly fine job on most things, but they were not designed for the specific pattern that a blockchain produces: many small random reads and writes, organized by a deep trie structure, with append-only semantics at the bottom.

The team measured the actual bottleneck during testnet and discovered that even with parallel execution, the chain spent more time waiting for disk reads than executing EVM opcodes. The standard databases were not asynchronous in a way that would let many parallel transactions issue reads simultaneously. So Monad wrote its own. MonadDB is built on direct asynchronous I/O against NVMe SSDs. It stores the trie natively, without going through a key-value abstraction. It allows thousands of concurrent reads to be issued and completed in parallel, which matches the access pattern of the parallel execution layer.

The benefit is that the storage layer no longer caps throughput. With MonadDB, every parallel worker thread can issue its disk reads in parallel, and the operating system schedules them efficiently against the SSD's hardware queues. A standard EVM client, by contrast, has its execution thread block waiting for a single read at a time. The combination of parallel execution plus parallel storage I/O is what unlocks the 10,000 TPS figure.

Performance Benchmarks: The 10,000 TPS Claim

Numbers matter. The headline claim from the Monad team is 10,000 transactions per second on mainnet hardware. To put that in context, Ethereum mainnet handles around 15 TPS, BNB Chain handles around 100 TPS sustained, Solana handles between 1,500 and 4,000 TPS of meaningful user transactions, and Sei v2 has reported around 5,000 TPS in optimal conditions. If Monad delivers 10,000 TPS consistently, it will be in the top tier of all production chains.

The caveat is that benchmark numbers vary enormously depending on the transaction mix. 10,000 simple ETH transfers per second is one thing; 10,000 complex Uniswap swaps with deep state contention is another. The Monad team has consistently published benchmarks against realistic workloads sampled from Ethereum mainnet history, which is the right thing to do, but it still represents a best case under controlled conditions. Real mainnet workloads with adversarial transaction patterns, high state contention, and validator misbehavior will see lower numbers. A reasonable expectation is that Monad delivers a five to twenty times improvement over Ethereum on most realistic workloads, with the headline 10,000 TPS reachable for favorable mixes.

Block time is one second, and finality is one second. These numbers are not theoretical; they are visible to anyone running a Monad node or checking the explorer. The user experience difference is dramatic. On Monad, a swap confirms before you can blink. On Ethereum, you watch a spinner for fifteen seconds. The product implications are significant, especially for trading and gaming.

EVM Bytecode Compatibility: Why It Matters for Developers

Monad's most strategic decision is to be EVM bytecode compatible, not just EVM compatible at the language level. The distinction matters enormously. A chain that is "EVM compatible" typically means you can write Solidity and deploy it, but the compiled bytecode runs on a different VM, sometimes with subtle differences in opcode behavior or gas accounting. A chain that is bytecode compatible runs the exact same compiled artifacts as Ethereum, with the same gas costs and the same opcode semantics.

For developers, this is the difference between "easy port" and "no port at all." On Monad, you can take a contract that has been deployed to Ethereum mainnet for years, redeploy the same bytecode to Monad, and it will behave identically. Your audited Aave fork works. Your Uniswap V3 deployment works. Your ERC-20 tokens work. Your multisig wallets work. You do not need to re-audit anything, because the execution semantics are the same.

This also means the entire EVM tooling ecosystem works. Foundry, Hardhat, Remix, ethers.js, viem, web3.js, OpenZeppelin contracts, MetaMask, WalletConnect, Etherscan-style block explorers, Tenderly, Defender, and every other tool a Solidity developer uses. Monad ships with an RPC endpoint that is fully compatible with Ethereum JSON-RPC, so you simply change the chain ID and the RPC URL and your application works.

The MON Token: Distribution and Airdrop History

The MON token is the native asset of the Monad blockchain. It is used to pay gas fees, to stake with validators, to vote in governance, and as the unit of account for the protocol's incentive programs. The total supply at genesis is 100 billion MON, with future inflation governed by a low staking-yield schedule that targets long-term sustainability.

The distribution at launch reflects the team's view that long-term ecosystem investment matters more than short-term hype. Community-related allocations make up the majority of the supply, with team and investor allocations vested over multi-year cliffs to align incentives with sustained network growth. Understanding tokenomics is critical for evaluating any new L1, and Monad's design has been one of the more debated in the 2026 launch cohort.

The Monad airdrop was one of the most heavily campaigned-for events of the 2025 testnet season. Eligibility was based on a combination of testnet activity, participation in the public devnet, contributions to ecosystem projects, and presence in early Discord and developer programs. A retroactive snapshot rewarded users who had been active across multiple testnet phases rather than only at the final snapshot moment, which is an attempt to filter out airdrop farmers. The genesis airdrop distributed around 6% of total supply to verified testnet users and early builders, with subsequent ecosystem incentive rounds planned over the first two to three years of mainnet.

Mainnet Launch Timeline and Ecosystem

The Monad story has played out across four phases. The first was the private testnet phase in 2023 and early 2024, during which the team built the consensus, execution, and storage layers in isolation. The second was the public devnet in mid-2024, which allowed developers to deploy contracts and iterate on tooling. The third was the public testnet that ran throughout 2025, attracting hundreds of projects and tens of millions of test transactions. The fourth was mainnet launch and the MON token generation event in early 2026, which is the moment Monad became a production network with real economic activity.

Since launch, the ecosystem has grown faster than most expected. The combination of full EVM compatibility and dramatically lower fees made it easy for existing Ethereum and Layer 2 protocols to deploy a Monad version with minimal engineering. By mid-2026, Monad hosts hundreds of live applications across DEXes, lending markets, perpetual exchanges, NFT marketplaces, on-chain games, prediction markets, and infrastructure tools. The chain's TVL has grown into the multi-billion-dollar range, and daily active addresses regularly exceed those of mid-tier Layer 2s.

Top Monad dApps in 2026

The Monad ecosystem in 2026 is built around a handful of flagship applications, each of which leverages the chain's speed for use cases that were not feasible on traditional EVMs.

Beyond these flagships, the ecosystem includes a rapidly expanding tail of NFT marketplaces, on-chain games that update every block, AI inference markets, social graphs, and infrastructure providers like indexers, oracles, and bridges. The pattern is consistent: applications that depend on speed and low fees migrate first, while applications that primarily depend on Ethereum's settlement assurances stay where they are.

Comparison with Other Parallel EVMs

Monad is not the only project pursuing parallel EVM execution. The category has become one of the most competitive in crypto, with several serious teams shipping different approaches. Understanding the differences is critical for anyone deciding where to build or invest.

The clearest competitor is Sei v2, which uses a similar optimistic concurrency approach on a Cosmos-based stack with an EVM module. Sei shipped earlier than Monad but has a smaller validator footprint, a different consensus model, and a fundamentally different chain identity. Both deliver real performance improvements; Monad's bet is that purpose-built consensus, deferred execution, and a custom database deliver more headroom than retrofitting parallel execution onto an existing chain.

MegaETH is a different beast. It is a Layer 2 that compresses transactions back to Ethereum, with a centralized but specialized sequencer node delivering extreme performance. The trade-off is centralization in the short term in exchange for theoretical throughput well beyond 100,000 TPS. Monad and MegaETH are not directly competing in the same category; one is a decentralized L1, the other is a high-performance L2. Many applications may run on both for different purposes.

Solana, Aptos, and Sui are non-EVM. They offer real parallelism and high TPS, but they require developers to learn a new language or VM. Monad's argument against them is the developer flywheel: if you can have Solana-grade speed and Ethereum-grade compatibility at the same time, the new-language penalty becomes hard to justify.

Monad vs Solana: The Parallel L1 Battle

The most interesting strategic question for the next few years is Monad versus Solana. Both are general-purpose L1s, both rely on parallel execution, both target single-digit-second finality, and both want to be the chain where high-frequency on-chain applications live. The differences are philosophical and ecosystemic.

Solana abandoned the EVM and built Sealevel, a parallel VM where transactions explicitly declare which accounts they will read and write. This declaration-based approach is more efficient when developers do it correctly, because there is no need to detect conflicts at runtime. The downside is that developers must reason about parallelism, and bugs in account declaration can lead to surprising behaviors. Solana also has a much longer history of validator client diversity issues and network outages, although these have improved substantially.

Monad takes the opposite approach: keep the EVM, do the conflict detection at runtime, and let developers stay ignorant of parallelism. The downside is that runtime conflict detection has overhead and occasional re-executions. The upside is that every existing Solidity contract works, and every existing developer is already trained. This is a long-term distribution bet. If the EVM remains the dominant smart contract standard for the next decade, Monad's strategy pays off enormously. If a new VM emerges and overtakes the EVM, Solana's strategy looks more prescient.

In 2026, both chains coexist and serve different audiences. Solana dominates memecoins, consumer apps, and many trading flows. Monad is rapidly becoming the home for DeFi protocols that want EVM-tier composability without Ethereum-tier costs. The two are likely to remain leaders in the high-performance L1 segment for years.

Risks: What Could Go Wrong

Monad is not without risks. A serious investor or developer should consider them.

Centralization at launch. The validator set at mainnet launch is around 100 nodes, mostly run by professional operators. This is similar to other modern PoS chains but is far from the thousands of validators on Ethereum. Decentralization will grow over time, but the early years will require trust in a relatively small set of operators.

Untested at scale. Testnet results are encouraging, but no chain truly knows its limits until it has run under adversarial mainnet conditions for years. The parallel execution layer in particular has many edge cases where adversarial transaction patterns could cause high re-execution rates and degrade throughput.

Competition from other parallel EVMs. The space is crowded. Sei is already live with a different but viable approach. MegaETH offers a different value proposition. New entrants will keep emerging. Monad needs to maintain a clear technical lead and a thriving ecosystem to justify the premium attention it currently enjoys.

Token unlocks. Like every new L1, Monad has significant insider allocations that vest over years. As cliffs pass and tokens unlock, supply pressure will hit the market. Smart token holders watch unlock schedules carefully.

The trilemma trade-offs. Optimizing for throughput typically comes at the cost of decentralization or security. Monad's design is careful, but no chain has fully solved the trilemma, and it is worth understanding which trade-offs the design accepts. Compared to Celestia-style modular designs that separate execution from consensus across distinct chains, Monad is monolithic by choice, which gives performance but concentrates more responsibility in a single network.

How to Connect to Monad and Use dApps Step-by-Step

Connecting to Monad is essentially identical to connecting to any other EVM chain, which is one of the main user-experience advantages.

Step 1: Add the Monad network to your wallet. In MetaMask, Rabby, or any EVM wallet, add a new network with Monad's RPC URL, chain ID, native currency (MON), and block explorer URL. These details are published on the official Monad documentation site, and many wallets will auto-detect Monad once you visit a dApp on it.

Step 2: Acquire MON for gas. Bridge tokens from Ethereum or a Layer 2 using the official bridge or a third-party bridge that supports Monad. Alternatively, withdraw MON directly from a centralized exchange that has listed it. You only need a small amount to cover gas, since fees are extremely low compared to Ethereum mainnet.

Step 3: Visit a Monad dApp. Open a flagship application like Kuru Exchange, Bean Exchange, or Apriori. Connect your wallet using the same flow you would on Ethereum. Sign the connection message. The dApp will detect that you are on Monad and load the Monad-specific deployment.

Step 4: Interact and confirm. Perform whatever action the dApp supports: swap, deposit, stake, mint, or trade. Sign the transaction in your wallet. The transaction confirms in roughly one second. You will likely double-take the first time you see how fast it is.

Step 5: Verify on the explorer. Copy your transaction hash and open it in the Monad block explorer, which works identically to Etherscan. You will see the transaction details, gas usage, internal calls, and event logs in the same format Ethereum developers are used to.

FAQs

Is Monad a Layer 1 or a Layer 2?

Monad is a Layer 1 blockchain. It is not a rollup and does not settle to Ethereum. It runs its own consensus, has its own validator set, and produces its own blocks. It is fully independent of Ethereum, which is also one of the criticisms its competitors level at it: by being an L1, it does not inherit Ethereum's security.

Do I need to rewrite my Solidity contracts to deploy on Monad?

No. Monad is bytecode compatible with the EVM. The same compiled contract you deploy to Ethereum runs unmodified on Monad. Tooling, libraries, and audits all carry over. The only thing that changes is the chain ID and the RPC endpoint your tools point at.

How is Monad different from Sei v2?

Both use optimistic concurrency to parallelize EVM execution, but the underlying chain architectures differ. Sei v2 is a Cosmos-based chain with an EVM module added on top. Monad is a from-scratch design with custom consensus (MonadBFT), deferred execution, and a custom database (MonadDB). In practice, Monad targets higher headline throughput and faster finality, while Sei has a head start on adoption in some segments.

What is the MON token used for?

MON is used to pay gas fees on Monad, to stake with validators for network security, and to vote in governance. It is also a unit of account for ecosystem incentive programs and a key asset across DeFi applications on the chain.

Can Monad really hit 10,000 TPS in practice?

Under realistic mainnet conditions, Monad has demonstrated benchmarks in the thousands of TPS range, with peaks approaching the 10,000 TPS headline figure for favorable transaction mixes. As with all blockchain throughput claims, actual numbers depend heavily on the mix of transactions, the level of state contention, and validator behavior. The order-of-magnitude improvement over Ethereum is real; the exact ceiling on any given day depends on workload.

Will Monad replace Ethereum?

No, and that is not the goal. Ethereum continues to function as the most secure and decentralized smart contract platform, and many use cases benefit from those properties. Monad is best understood as a complementary chain in the EVM ecosystem, optimized for applications where speed and low fees matter more than maximum decentralization.

Conclusion

Monad represents one of the more ambitious engineering bets in the current crypto landscape. By refusing to abandon the EVM while simultaneously rebuilding consensus, execution, and storage from scratch, the team has produced a chain that delivers a step change in throughput without forcing developers to learn anything new. The four pillars of MonadBFT, deferred execution, parallel EVM, and MonadDB work together as a layered system in which each optimization unblocks the next, and the result is a network that runs unmodified Solidity at speeds that previously belonged to non-EVM chains.

That said, Monad is still early. Mainnet launched in 2026, the validator set is concentrated, the ecosystem is growing fast but still maturing, and competing parallel EVMs are pushing their own designs aggressively. Anyone evaluating Monad as a developer, user, or token holder should weigh the genuine engineering merits against the risks of a young L1 that has not yet seen years of adversarial mainnet conditions.

For developers shipping today, Monad is one of the easiest new chains to support, because the deployment process is identical to Ethereum. For users, it offers a glimpse at what a future EVM might feel like, where confirmations are instant and fees are not a tax on every interaction. For the broader industry, it is a test of whether parallelizing the EVM at the implementation layer can really deliver the holy grail of speed plus compatibility. The next two to three years will reveal the answer.

Related Guides

• What Is Sei? Parallelized EVM and Trading Focus (2026)
• zkEVM Types Compared: Polygon vs zkSync vs Scroll 2026
• What Is wagmi: React Hooks, Wallet Connectors and EVM State (2026)
• What Is Taiko? Type 1 ZK EVM Ethereum Equivalent L2 Guide 2026
• What Is RainbowKit: Wallet Connection UI for EVM Apps (2026)

Frequently Asked Questions

What is a parallelized EVM?

A parallelized EVM is an Ethereum-compatible execution environment that can process independent transactions at the same time instead of strictly one after another. This is intended to increase throughput while keeping compatibility with existing Ethereum tooling.

How does parallel execution improve performance?

By running transactions that do not touch the same data simultaneously, a parallel system can use more of the hardware's capacity and confirm more transactions per second. Transactions that conflict still need careful ordering to stay correct.

What does EVM compatibility mean?

EVM compatibility means a chain can run smart contracts written for Ethereum and work with familiar tools and wallets. This makes it easier for developers to deploy existing applications with little or no rewriting.

What is a Layer 1 blockchain?

A Layer 1 is a base blockchain that settles its own transactions and provides its own security, as opposed to a Layer 2 that builds on top of another chain. Examples of Layer 1 features include consensus, native tokens, and validators.