Monad is a parallel EVM layer 1 with fast finality

Monad is a base blockchain, meaning it settles its own history, that runs Ethereum-style smart contracts and processes independent transactions in parallel. This EVM-compatible layer 1 combines MonadBFT consensus, asynchronous execution, and a purpose-built state database. Its design targets fast DeFi, payments, games, and onchain markets while keeping the contracts and tools Solidity developers already use.

In this guide

Public mainnet launched in 2025, and MON pays transaction fees and supports proof-of-stake security. The sections below follow one transaction through the architecture, compare alternatives, and explain the limits that matter before using the network.

Bottom line: A 30 million gas ceiling applies per transaction, while wallets pay for the gas limit they submit.

Parallel execution keeps one ordered EVM history

Parallel execution matters because Monad keeps Ethereum’s ordered transaction semantics while running independent work across multiple processor cores. Every block remains a linear list.

An optimistic scheduler starts later transactions before earlier ones finish. It records the state each task reads, then merges completed state changes in block order. If an earlier transaction changed an input used by a later one, the later task runs again with the correct state. Two swaps touching unrelated pools proceed together; many trades updating one pool create conflicts and lose part of the parallel speedup. Signature recovery and cached storage reads need not repeat, so a conflict costs less than restarting every operation from zero.

At the configured minimum slot time, Monad produces blocks every 300 milliseconds and reaches full finality after 2 slots, or 600 milliseconds. One-slot speculative finality arrives after 300 milliseconds, before the second consensus certificate completes.

Asynchronous execution separates ordering from state computation, giving execution the entire slot while consensus advances. The design target is 10,000 transactions per second, and a delayed state root checks execution 3 blocks behind the ordered tip. RaptorCast distributes block data, while MonadDb serves parallel state reads through asynchronous input and output. Together, these parts increase capacity without changing the final order contracts observe. Hot contracts still serialize around shared storage, so application state layout determines how much capacity remains usable.

Ethereum, Base, and Solana expose different settlement trade-offs

The main decision around Monad is whether a workload needs Ethereum compatibility, Ethereum settlement, or a distinct high-throughput runtime and account model.

Ethereum mainnet, chain ID 1, supplies the original EVM settlement environment and 12-second slots. Monad mainnet, chain ID 143, preserves EVM bytecode and JSON-RPC behavior while settling on its own validator set.

That difference matters more than raw speed: assets, validators, and state belong to separate layer 1 networks. Solidity code ports readily, yet liquidity and governance never migrate automatically. Teams choosing between the two weigh mature Ethereum state and integrations against shorter feedback loops and greater execution headroom on Monad.

Base, with chain ID 8453, and Arbitrum One, with chain ID 42161, are EVM layer 2 networks whose state commitments ultimately connect to Ethereum. They provide Ethereum-aligned settlement paths, although deposits, withdrawals, sequencer behavior, and data publication shape the user experience. Monad instead operates as a separate layer 1; that brings fast native finality and a different validator-security boundary.

Solana follows another path through the Solana Virtual Machine, programs commonly written in Rust, and transactions declaring accounts up front for parallel scheduling. It offers a large non-EVM ecosystem but asks Ethereum teams to change runtime assumptions and tooling. The decision rests on the settlement domain, contract compatibility, and liquidity an application actually requires.

EVM compatibility moves existing contracts into faster application loops

EVM compatibility gives Monad its clearest use case: applications needing faster feedback without replacing Solidity contracts, wallets, or Ethereum development tools. Developers retain familiar ABI conventions.

The network uses 20-byte addresses and the EIP-2718 typed transaction envelope. It accepts transaction types 0, 1, 2, and 4, covering legacy transfers, EIP-2930 access lists, EIP-1559 fees, and EIP-7702 delegation. Type 3 EIP-4844 blob transactions remain unsupported, so rollup-oriented blob workflows need another network. Foundry, Hardhat, and Remix fit the development workflow; MetaMask and Phantom handle user signing. These carryovers shorten migration work, although contracts still need testing against Monad-specific gas prices, reserve-balance rules, and opcode repricing.

The Monad EVM permits 128 KB of deployed contract code, 256 KB of init code, and up to 8 MB of transaction memory. These limits exceed Ethereum’s contract-size envelope and support larger applications, yet modular design still improves audits and upgrades.

High-throughput DeFi is the obvious fit: automated market makers, order books, lending, and liquidations benefit from short settlement loops. ERC-20 tokens, ERC-721 collections, and EIP-4337 account-abstraction components use the same broad standards families. Chainlink and Pyth supply oracle infrastructure, while indexers such as Envio turn logs into balances and trade data. Games and payment systems also gain responsive state changes, provided their contracts avoid concentrating every action on one storage location.

Monad logo and headline The Next Frontier of Crypto Is Here
Monad logo and headline The Next Frontier of Crypto Is Here

Gas limits shape fees differently from Ethereum

Fee calculation on Monad hinges on the submitted gas limit because the protocol charges reserved capacity, not only the computation a transaction consumes.

Each price uses the EIP-1559 structure: a dynamic base fee plus a user-selected priority fee, capped by the transaction’s maximum fee. The base component burns, while the priority component rewards the block producer. Charging the gas limit supports asynchronous execution because leaders order transactions before running them; reserved block capacity must therefore carry a price. Wallet estimates matter more here. A limit far above actual use costs the full reserved amount, while a limit below required work causes execution to run out of gas.

The mainnet configuration sets a 100 MON-gwei minimum base fee, a 200 million gas block limit, and a 30 million gas ceiling per transaction. Those ceilings define capacity, while block demand moves the effective gas price above its minimum.

The payable amount equals the submitted gas limit multiplied by the effective price per gas, so live demand still moves the final MON cost. Compare the wallet’s gas limit with a simulation, then judge the base and priority components separately. A transaction reaches its practical cost ceiling at the submitted gas limit and selected maximum fee.

Mainnet entry starts with chain ID 143 and MON

Mainnet access starts by selecting Monad chain ID 143 in an EVM wallet and keeping MON available for gas.

MetaMask and Phantom support the familiar 20-byte address format, so an existing EVM account represents the same public address on Monad. Balances remain chain-specific. A token held on Ethereum, Base, or Arbitrum One does not appear on Monad until a supported transfer route creates or releases the corresponding asset there. Mainnet and testnet also differ: mainnet uses chain ID 143, while testnet uses chain ID 10143 and test MON has no mainnet value. Use this short decision checklist before the first transaction.

For builders, Foundry and Hardhat supply deployment and testing paths, and standard Ethereum JSON-RPC methods expose balances, estimates, receipts, and logs. Chain ID 143 should be explicit in signed transactions. The first usable path ends once the wallet holds MON, the intended asset, and a confirmed receipt.

Reserve balance and shared state define the practical limits

Monad’s major trade-offs appear when asynchronous ordering meets account funding, shared contract state, bridge assumptions, and application-level liquidity.

This is set out in detail. The reserve-balance mechanism lets consensus include transactions before execution catches up. A delayed state root trails by 3 blocks, so a newly funded account starting from zero must wait for that funded state to age through the delay before spending. EIP-7702-delegated externally owned accounts carry another rule: their balance cannot fall below 10 MON while delegation remains active. These constraints are deterministic, but wallet software and contract flows must account for them when chaining actions across fresh accounts.

Contention imposes a separate ceiling. When many transactions read and update the same storage, optimistic conflicts trigger re-execution and reduce parallel gains.

Fast finality belongs only to Monad’s own consensus. A bridged asset inherits the bridge’s verification model, oracle-driven markets inherit data-update assumptions, and DeFi outcomes rely on available liquidity. Chainlink, Pyth, and protocol-specific safeguards provide ingredients; they do not merge these trust boundaries into MonadBFT. Likewise, a short block interval does not guarantee a favorable trade or deep market. Execution speed improves responsiveness, while economic state still controls price impact and liquidation risk.

Validator consensus requires more than two-thirds of stake for a quorum certificate, and full finality takes 2 slots. MON staking aligns block production with proof-of-stake security. MonadBFT keeps happy-path communication linear, while RaptorCast distributes block payloads. The architecture’s benefit is clearest for workloads with independent state. Its practical limit appears when activity converges on one contract, one bridge, or one thin market.

Monad: questions and answers

What was MON’s initial token supply?

MON launched with an initial supply of 100 billion tokens. It serves as the native asset for transaction fees and proof-of-stake participation. Initial supply is a historical launch figure, not a live circulating-balance claim: circulation changes as locked allocations release, validators receive protocol rewards, and base transaction fees burn. The useful distinction is between the fixed launch total and later supply or circulation, which reflect the token’s issuance, unlock, and burn mechanics.

How do staking changes activate on Monad?

Staking changes activate at epoch boundaries rather than immediately. A boundary arrives every 50,000 blocks, followed by a 5,000-round delay before the new epoch begins. An action submitted before the boundary targets the next epoch; one submitted during the delay targets the epoch after that. Undelegated stake then waits 1 epoch before withdrawal. Rounds and blocks are different counters, so contracts should read the staking precompile’s epoch state instead of inferring timing from block numbers.

Which explorers show Monad mainnet transactions?

MonadVision and Monadscan both index Monad mainnet activity. MonadVision is built by BlockVision, while Monadscan uses Etherscan infrastructure and verification conventions. JiffyScan focuses on EIP-4337 user operations. Tenderly Explorer and Blocksec Phalcon Explorer provide deeper call traces and state-change analysis. A transaction hash should resolve to the same canonical receipt across providers, although presentation, indexing delay, trace depth, and API limits differ by explorer. Use the canonical receipt status and block number for cross-checking.

What happens if a Monad leader misses its round?

MonadBFT advances through a timeout path when a scheduled leader misses its round. The next eligible leader uses protocol certificates to continue from a supported tip, and one failed leader adds one timeout delay rather than stopping later rounds. Round numbers still increase even without a proposed block, which is why rounds and block heights diverge. Finality resumes through quorum certificates once more than two-thirds of stake supports the required proposals.

Are archive-state queries available from every Monad RPC?

Archive-state queries are not available from every Monad RPC endpoint. Standard methods such as balance reads or contract calls against recent state are widely exposed, while older-state access depends on the provider’s retained history and method policy. Public endpoints also impose different request and batch limits. Applications needing reproducible historical reads should select an archive-capable provider, pin the block identifier, and handle rate limits separately from the chain’s consensus or execution behavior.

Does Monad support smart accounts and passkeys?

Monad supports smart-account building blocks through EIP-7702, EIP-4337 infrastructure, and P256 signature verification. Canonical EntryPoint deployments cover EIP-4337 versions 0.6, 0.7, and 0.8, while the P256 precompile enables onchain verification of WebAuthn-style signatures. Monad-specific reserve-balance rules still apply: an EIP-7702-delegated externally owned account cannot reduce its balance below 10 MON while delegated. Account software must also estimate and reserve gas for every transaction under Monad’s gas-limit charging model.

Which languages are the Monad clients written in?

Monad’s first execution and consensus clients are written in C++ and Rust. Category Labs develops the execution client and MonadBFT implementation, and both codebases use the GPL-3.0 open-source license. That client stack is separate from application development: smart-contract teams normally use Solidity and EVM tooling such as Foundry or Hardhat. Client language describes node software, while contract language describes programs deployed for users on the network at the application layer.

Do developers need testnet MON before deploying to mainnet?

Testnet MON is useful for rehearsing deployments, but it is separate from mainnet MON and carries no mainnet value. Testnet uses chain ID 10143, while mainnet uses chain ID 143. Developers can test contract creation, calls, indexing, and wallet prompts before repeating the workflow with real assets. A successful testnet receipt proves the transaction executed under testnet state; it does not transfer balances, contract addresses, liquidity, or deployment state onto mainnet.