Most chains that promise big throughput ask you to learn something new — a different VM, a different account model, a caveat about transaction ordering. Monad's whole thesis is the opposite: 10,000 TPS with nothing to relearn. It's a high-performance EVM Layer 1 (chain ID 143) that reaches its throughput through parallel execution and a pipelined BFT consensus — but it's fully EVM bytecode-compatible, so your existing Solidity contracts and Ethereum tooling work without modification, and the RPC surface is plain eth_*. The clever engineering is under the hood; the developer experience is deliberately boring. Here's the map, including the two things that do change.
The essentials
Monad mainnet (live since November 2025) is chain ID 143, an EVM Layer 1 with:
- MON as the native gas token (18 decimals) — used for gas and staking.
- Sub-second blocks (~0.4–0.5s) and fast single-slot finality (~0.8s) via MonadBFT, a pipelined consensus from the HotStuff family.
- Parallel transaction execution plus an optimized state database (MonadDb) — the source of the throughput.
- Full EVM bytecode compatibility — Solidity, ABIs, Foundry, Hardhat, ethers, and viem all apply directly; no recompilation, no special dialect.
Connecting is as standard as it gets:
import { createPublicClient, http, defineChain } from "viem";
const monad = defineChain({
id: 143,
name: "Monad",
nativeCurrency: { name: "Monad", symbol: "MON", decimals: 18 },
rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/monad?key=YOUR_API_KEY"] } },
});
const client = createPublicClient({ chain: monad, transport: http() });
await client.getBlockNumber(); // just works
The headline: parallel execution you don't have to think about
Here's the part that makes Monad fast, and why it doesn't leak into your code. A normal EVM executes transactions strictly one after another. Monad executes them optimistically in parallel — running independent transactions simultaneously across cores — and detects conflicts (two transactions touching the same state), re-executing those as needed to resolve them.
The crucial property: the result is identical to serial execution. Monad produces the same final state, in the same canonical transaction order, that a single-threaded EVM would — it just gets there faster by doing the independent work concurrently. So from the outside:
- Transaction ordering semantics are preserved. You don't get a "don't assume ordering between transactions" caveat. The block has a definite order and the state reflects it, exactly as on Ethereum.
-
Nothing about parallelism appears in the RPC. There's no special namespace, no parallel-aware method, no flag.
eth_call,eth_getTransactionReceipt,eth_getLogsbehave exactly as they do on any EVM chain.
This is a different approach from some other parallel-EVM chains. On Sei, for instance, parallelism is also largely transparent, but the general advice there is to be careful about assuming cross-transaction ordering; Monad's model is built to be serial-equivalent, so you reason about it just like Ethereum — only quicker. If you're porting a contract or an indexer, that's the reassuring headline: your assumptions still hold.
What actually changes: speed, in two places
If the RPC is standard and ordering is preserved, what does a developer need to do differently? Two things, both consequences of raw speed:
1. Stream, don't poll. At ~0.4–0.5s blocks, tight polling loops (eth_blockNumber every second) are both wasteful and behind. Use WebSocket subscriptions (newHeads, logs) to react to blocks as they arrive:
const unwatch = client.watchBlockNumber({
onBlockNumber: (n) => console.log("new head", n),
}); // eth_subscribe newHeads under the hood
At Monad's block rate, a subscription keeps you current without hammering the endpoint; polling always trails and multiplies request volume.
2. Confirm once — it's single-slot BFT finality. MonadBFT gives fast, single-slot finality (~0.8s): a committed block is final, no reorgs. That collapses the whole class of reorg-handling patterns to "confirm once" — you don't need deep confirmation counts or block-hash reconciliation the way you do on probabilistic chains. This puts Monad in the same fast-finality comfort zone as Sonic and Kaia: once you see it committed, trust it.
That's genuinely the whole list. High throughput plus fast finality changes your read pattern (stream) and your trust model (confirm once) — not your contract code or your method calls.
Gas and fees behave normally
MON is the 18-decimal gas token, and gas mechanics follow standard EVM rules — eth_estimateGas returns gas units, EIP-1559 fields apply, and you buffer estimates the usual way (gas estimation basics). Because Monad targets high-volume, low-cost usage, fees are designed to stay low, but the shape of fee handling is exactly what you already do on Ethereum. Likewise, reading a receipt to confirm success works identically — check status, decode logs, done.
What carries over unchanged (almost everything)
Because Monad is bytecode-compatible, treat it as a standard EVM chain:
-
eth_call,eth_getBalance,eth_getLogs,eth_getTransactionReceipt,eth_estimateGas,eth_sendRawTransaction,eth_subscribeall behave normally. - Solidity contracts deploy without recompilation for a new VM — same bytecode, same ABIs.
- The full viem/ethers/hardhat/foundry toolchain works as-is.
- MON is the 18-decimal gas token; WebSocket subscriptions work and, at sub-second blocks, are the right default.
The short version
Monad (chain ID 143) is a high-performance EVM Layer 1 that reaches 10,000 TPS through parallel execution and pipelined MonadBFT consensus — while staying fully EVM bytecode-compatible, so viem/ethers/foundry and your existing contracts work unchanged and the RPC is plain eth_*. The parallelism is serial-equivalent and invisible: transaction ordering is preserved, and no method or namespace changes. The only two things a developer does differently are consequences of speed — stream over WebSocket instead of polling (~0.4–0.5s blocks), and confirm once because single-slot BFT finality (~0.8s) means no reorgs. Everything else is the Ethereum you already know, faster.
Building high-throughput DeFi, on-chain order books, or consumer-scale apps on Monad? A flat-rate Monad RPC endpoint gives you chain 143 over HTTP and WebSocket, load-balanced across upstream nodes, alongside 75+ other chains under one key. Grab a free key and point your stack at:
https://rpc.swiftnodes.io/rpc/monad?key=YOUR_API_KEY
wss://rpc.swiftnodes.io/ws/monad?key=YOUR_API_KEY
Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.
Top comments (0)