EVM vs non-EVM — cp0x learn

概念： EVM Compatibility, Non-EVM Chains, Move, Rust, Solidity, Contract Portability

:::section{mins=2} What "EVM-Compatible" Means :::

:::lead The phrase "[[gloss:evm|EVM]]-compatible" gets thrown around like it has one meaning, and it doesn't. It's a spectrum that runs from "byte-identical to [[gloss:ethereum|Ethereum]]" to "[[gloss:solidity|Solidity]] compiles, but everything else is different." Three contracts that all claim [[gloss:evm|EVM]]-compatibility can give you three completely different deployment experiences. Knowing where on the spectrum a chain actually sits is what separates a five-minute redeploy from three weeks of unexpected bugs in production. :::

:::p{html} The [[gloss:evm|EVM]] — [[gloss:ethereum|Ethereum]] Virtual Machine — is the [[gloss:bytecode|bytecode]] interpreter that every [[gloss:ethereum|Ethereum]] [[gloss:node|node]] runs. When you write a [[gloss:smart contract|smart contract]] in [[gloss:solidity|Solidity]] and deploy it, the compiler turns your code into a string of [[gloss:evm|EVM]] [[gloss:bytecode|bytecode]], and every [[gloss:node|node]] on the network runs that [[gloss:bytecode|bytecode]] [[gloss:opcode|opcode]]-by-[[gloss:opcode|opcode]] against its own copy of network state — and arrives at the same final result. The [[gloss:evm|EVM]] is what gives [[gloss:ethereum|Ethereum]] its rules: 256-bit stack machine, [[gloss:gas|gas]] metering, deterministic state transitions, no syscalls. It's not a clever VM by modern standards — it's a 2014-era design that won by being there first. :::

:::p{html} An [[gloss:evm|EVM]]-compatible chain is one where [[gloss:ethereum|Ethereum]]-style [[gloss:smart contract|smart contracts]] run. The phrase is doing a lot of work in that sentence. At one end of the spectrum, a chain like Scroll runs the exact same [[gloss:evm|EVM]] [[gloss:bytecode|bytecode]] as [[gloss:ethereum|Ethereum]], [[gloss:opcode|opcode]] for [[gloss:opcode|opcode]], with the same [[gloss:gas|gas]] costs and the same precompiled contracts — your audited [[gloss:ethereum|Ethereum]] deployment can [[gloss:move|move]] to it without a single line of code change. At the other end, a chain like Polygon [[gloss:zkevm|zkEVM]] (Type 4) takes your [[gloss:solidity|Solidity]] source and recompiles it into something else entirely, which means most things work but a contract that relies on specific [[gloss:opcode|opcode]] behavior may quietly break. We covered the four-tier classification for ZK [[gloss:rollup|rollups]] in → 2.5 §4; the same spectrum applies to every chain that calls itself [[gloss:evm|EVM]]-compatible, not just [[gloss:rollup|rollups]]. :::

:::p{html} The practical question for a user is much simpler. [[gloss:evm|EVM]]-compatible means: same [[gloss:wallet|wallet]] (MetaMask, Rabby), same address format (the 0x... hex string you already know), same token standards (ERC-20, ERC-721, ERC-1155), same approval and signature patterns. The familiar mental model transfers. Non-[[gloss:evm|EVM]] means: different [[gloss:wallet|wallet]], different address format, different [[gloss:transaction|transaction]] signing scheme, different mental model. A token bridged from [[gloss:ethereum|Ethereum]] to [[gloss:solana|Solana]] isn't the same token — it's a wrapped version represented in a different account model and signed by a different curve. :::

:::p{html} By May 2026 there are dozens of [[gloss:evm|EVM]]-compatible chains live in production — [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]], every major [[gloss:layer 2|L2]] (Arbitrum, OP [[gloss:mainnet|Mainnet]], Base, Linea, Scroll, zkSync Era, Polygon [[gloss:zkevm|zkEVM]]), a long tail of [[gloss:l1|L1s]] and sidechains (BNB Chain, [[gloss:avalanche|Avalanche]] C-Chain, Polygon [[gloss:proof of stake|PoS]], Sonic, Mantle), and a fresh wave of high-throughput [[gloss:evm|EVM]] [[gloss:l1|L1s]] led by [[gloss:monad|Monad]], which launched [[gloss:mainnet|mainnet]] on November 24, 2025. Against this stands a much smaller but architecturally distinct group of non-[[gloss:evm|EVM]] chains: [[gloss:solana|Solana]] with its [[gloss:sealevel|Sealevel]] runtime, Starknet with [[gloss:cairo|Cairo]], [[gloss:aptos|Aptos]] and [[gloss:sui|Sui]] with [[gloss:move|Move]], [[gloss:ton|TON]] with its own TVM, and the [[gloss:cosmos|Cosmos]] chains with CosmWasm. These two groups have been competing for the same developers and the same liquidity for years, and as of 2026 they look less like rivals and more like two converging traditions — but we'll get to that in §6. :::

:::callout{icon=💡} Think of [[gloss:evm|EVM]]-compatibility the way operating-system compatibility worked in the desktop era. A Windows application doesn't just have a file format — it has an entire stack of expectations about how memory is managed, how the GUI is drawn, what filesystem looks like, what system calls are available. When someone says a program is "Windows-compatible," they usually mean it runs on Windows. But "Windows-compatible" inside a Wine emulator on Linux isn't the same as running on real Windows: most things work, edge cases break, performance is different, and a tool that depends on specific Windows internals will quietly fail. macOS is the other extreme — it doesn't try to be Windows-compatible at all, it has its own application format, its own development tools, its own design language. Some programs are released on both, recompiled for each. Most aren't. [[gloss:evm|EVM]]-compatibility is the same kind of spectrum: byte-identical execution at one end, source-level compilation at the other, and a completely different OS over in the non-[[gloss:evm|EVM]] world. :::

:::keypoints{label="Key Points"}

"[[gloss:evm|EVM]]-compatible" is not a binary property — it's a sliding scale. Treating it as a yes/no question is what makes teams ship contracts that pass tests on [[gloss:ethereum|Ethereum]] and fail on a target chain that "supports" the same code
For end users, the distinction is concrete: [[gloss:evm|EVM]]-compatible means the [[gloss:wallet|wallet]] you already use will work; non-[[gloss:evm|EVM]] means a separate [[gloss:wallet|wallet]], a separate seed-derivation path, and a separate mental model for what owning a token even means on that chain
Counting chains and counting activity give very different pictures. The [[gloss:evm|EVM]] world has dozens of chains with activity spread across them; the non-[[gloss:evm|EVM]] world is essentially a handful of concentrated islands. The right comparison isn't '40 [[gloss:evm|EVM]] chains vs 4 non-[[gloss:evm|EVM]] chains' — it's 'one [[gloss:evm|EVM]] stack with many deployments vs three or four independent ecosystems each large enough to matter.'
The two camps are no longer cleanly opposed. [[gloss:evm|EVM]] chains are getting [[gloss:wasm|WASM]] ([[gloss:stylus|Stylus]] on Arbitrum), parallel execution ([[gloss:monad|Monad]]), and a credible [[gloss:risc-v|RISC-V]] replacement proposal from Vitalik himself; non-[[gloss:evm|EVM]] chains are adding [[gloss:evm|EVM]] bridges and compatibility layers. The competition is converging, not diverging :::

:::details{badge=Advanced title="Levels of EVM compatibility"} :::p{html} The most useful taxonomy of [[gloss:evm|EVM]] compatibility has five tiers, and the gap between them is what trips up most teams. :::

:::p{html} Tier 1: byte-identical. The chain runs the exact [[gloss:evm|EVM]] [[gloss:bytecode|bytecode]] produced by solc, with the same [[gloss:gas|gas]] costs, the same [[gloss:precompile|precompiles]], and the same [[gloss:opcode|opcode]] semantics. Examples: Taiko, [[gloss:ethereum classic|Ethereum classic]] chains. A contract audited on [[gloss:ethereum|Ethereum]] needs no re-audit. The trade-off: no room to optimize, so the chain inherits [[gloss:ethereum|Ethereum]]'s performance ceiling. :::

:::p{html} Tier 2: [[gloss:evm|EVM]]-equivalent (with footnotes). The chain runs [[gloss:evm|EVM]] [[gloss:bytecode|bytecode]] but with documented deviations — different [[gloss:block|block]] timestamps, different randomness sources, sometimes different [[gloss:precompile|precompile]] lists. Examples: Arbitrum, Base, OP [[gloss:mainnet|Mainnet]], Scroll. Most contracts [[gloss:move|move]] over untouched, but contracts that depend on [[gloss:block|block]].timestamp granularity, blockhash, or chain-specific [[gloss:precompile|precompiles]] need testing. The deviations are documented and well-known. :::

:::p{html} Tier 3: [[gloss:evm|EVM]]-compatible at the source level. [[gloss:solidity|Solidity]] compiles, but the underlying VM is different. [[gloss:storage layout|Storage layout]] may not match, [[gloss:gas|gas]] costs are completely different, some [[gloss:opcode|opcodes]] are missing or behave differently. Examples: zkSync Era, Polygon [[gloss:zkevm|zkEVM]]. Most [[gloss:solidity|Solidity]] works; assembly [[gloss:block|blocks]], deep optimizations, and storage-layout-dependent code don't. Re-auditing is usually required. :::

:::p{html} Tier 4: [[gloss:solidity|Solidity]]-transpiled. [[gloss:solidity|Solidity]] is recompiled into a non-[[gloss:evm|EVM]] [[gloss:bytecode|bytecode]] for execution on a non-[[gloss:evm|EVM]] VM. Examples: [[gloss:neon evm|Neon EVM]] on [[gloss:solana|Solana]]. The promise is "deploy your [[gloss:ethereum|Ethereum]] contract on [[gloss:solana|Solana]]"; the reality is closer to "we accept your [[gloss:solidity|Solidity]] but run it inside a sandbox that bridges to [[gloss:svm|SVM]]." Works for many contracts, fails for anything that touches [[gloss:ethereum|Ethereum]]-specific behavior. :::

:::p{html} Tier 5: not [[gloss:evm|EVM]] at all. Different language, different VM, different account model. Examples: native [[gloss:solana|Solana]] programs, [[gloss:move|Move]] on [[gloss:aptos|Aptos]]/[[gloss:sui|Sui]], [[gloss:cairo|Cairo]] on Starknet. No path to deploy a [[gloss:solidity|Solidity]] contract directly. You rewrite, or you don't ship on this chain. :::

:::p{html} Bottom line. The marketing page is always Tier 1 or 2 by implication. The reality is often Tier 3. The difference between Tier 2 and Tier 3 can cost a team weeks of porting work and an entire re-audit cycle. The earliest place a project should pin down which tier its target chain belongs to is the chain-selection phase, not after the contract is already half-rewritten. ::: :::

:::quiz{id=q-2-6-s1 correct=1 explanation="Correct. zkSync Era is a Tier 3 chain — [[gloss:solidity|Solidity]] compiles, but the underlying VM is different enough that [[gloss:storage layout|storage layout]], [[gloss:gas|gas]] costs, and [[gloss:opcode|opcode]]-level details can break in non-obvious ways. Most production teams treat zkSync deployment as a re-audit event."} A team has a [[gloss:solidity|Solidity]] contract audited on [[gloss:ethereum|Ethereum]] and wants to deploy it to zkSync Era. What should they expect?

Drop-in deployment — zkSync runs the same [[gloss:evm|EVM]] [[gloss:bytecode|bytecode]], so the audit transfers directly
Most [[gloss:solidity|Solidity]] will work, but [[gloss:storage layout|storage layout]], assembly [[gloss:block|blocks]], and [[gloss:gas|gas]]-cost-dependent logic need re-testing and likely a fresh audit
The contract must be rewritten entirely in Rust because zkSync is a non-[[gloss:evm|EVM]] chain
zkSync only accepts Yul, so the team needs to extract Yul intermediate representation from solc :::

:::section{mins=2} EVM World: One Solidity, Dozens of Chains :::

:::lead The [[gloss:evm|EVM]]'s biggest moat isn't technical excellence — it's the accumulated stack of tooling, audits, conventions, and shared mental models that grew on top of it over a decade. Every new [[gloss:evm|EVM]] chain inherits the entire stack for free; every non-[[gloss:evm|EVM]] chain has to rebuild a version of it from scratch. By 2026 the [[gloss:evm|EVM]] stack still has more developers than any single competitor, but its share has been collapsing for six years, and one of every three crypto developers now works across multiple chains in different VMs simultaneously. :::

:::p{html} The numbers explain the gravity well. Electric Capital's 2024 developer report counted 8,925 active developers on the broad [[gloss:evm|EVM]] stack — [[gloss:solidity|Solidity]], Foundry, Hardhat, OpenZeppelin, Etherscan-family explorers, the whole ecosystem. The next-largest stack, [[gloss:solana|Solana]]'s [[gloss:svm|SVM]], had 2,499. Add up every non-[[gloss:evm|EVM]] chain, including [[gloss:cosmos|Cosmos]], [[gloss:aptos|Aptos]], [[gloss:sui|Sui]], Starknet, [[gloss:ton|TON]], Near, and the long tail, and the [[gloss:evm|EVM]] stack was still roughly four times larger. By the 2025 report [[gloss:ethereum|Ethereum]] alone reported 31,869 total active developers; [[gloss:solana|Solana]], the second-largest single ecosystem, reported 17,708. :::

:::p{html} What this number obscures, though, is the trend. [[gloss:ethereum|Ethereum]]'s share of all active [[gloss:blockchain|blockchain]] developers was about 82% in 2020. By 2025 it sat at 31% — a 51-percentage-point drop over six years. The decline is not because developers left crypto; total active [[gloss:blockchain|blockchain]] developers grew. It's that new developers increasingly start somewhere other than [[gloss:ethereum|Ethereum]]. Among professional developers, [[gloss:solana|Solana]]'s share rose from 5% to 20% over the same window. And roughly one in three crypto developers now contributes to projects on multiple chains, which means the question "which stack do you work in" has a less and less binary answer. :::

:::p{html} For a working developer the [[gloss:evm|EVM]] advantage is concrete. [[gloss:solidity|Solidity]] compiles once and the same artifact deploys to dozens of chains. The same [[gloss:wallet|wallet]] integrations work everywhere. The same auditing firms have seen the same patterns thousands of times — there are hundreds of [[gloss:evm|EVM]]-specialist audit firms; for [[gloss:move|Move]] there are a few dozen, for [[gloss:cairo|Cairo]] a handful. OpenZeppelin's contract library is battle-tested across every major [[gloss:evm|EVM]] chain. Etherscan-style [[gloss:block|block]] explorers exist for every [[gloss:evm|EVM]] chain in some form. The same Foundry test suite that catches a bug on [[gloss:ethereum|Ethereum]] catches it on Base. None of this is true outside the [[gloss:evm|EVM]] world. :::

:::p{html} The trade-off is that the [[gloss:evm|EVM]] itself hasn't improved much. The [[gloss:bytecode|bytecode]] that runs on Base in May 2026 is fundamentally the same instruction set that ran on [[gloss:ethereum|Ethereum]] in 2015, with a few new [[gloss:opcode|opcodes]] added at the edges. 256-bit words are wasteful for almost everything that isn't a [[gloss:hash|hash]] or a signature. [[gloss:gas|Gas]] accounting is verbose and brittle. The biggest practical limitation — strict sequential execution — is what motivated [[gloss:monad|Monad]] to spend three years engineering an [[gloss:evm|EVM]]-compatible chain that runs [[gloss:transaction|transactions]] in parallel, and what motivates the entire push to replace the [[gloss:evm|EVM]] with [[gloss:risc-v|RISC-V]] (more on that in §6). The same network effect that lets a thousand chains share a single audit ecosystem also locks them all to a decade-old design. :::

:::callout{icon=💡} English in international aviation works the same way. It's not the best language for the job — it's full of idioms, ambiguities, and homophones that have caused real accidents. There are languages with cleaner phonetic structure, better tense systems, less ambiguity. None of that matters. By the 1950s English was already the default for air traffic control, and once an entire generation of pilots, controllers, manuals, training programs, regulatory documents, and emergency-response protocols had standardized on it, switching was no longer an option. New pilots in every country learn English not because it's superior but because everyone else already speaks it. Better languages exist; nobody flies in them. The [[gloss:evm|EVM]] is in exactly that position: the technical limitations are real, the network effect is much larger, and the cost of switching grows every year the rest of the stack accumulates on top. :::

:::keypoints{label="Key Points"}

[[gloss:evm|EVM]]'s network effect rests not on [[gloss:solidity|Solidity]] itself but on the infrastructure around it — what every new [[gloss:evm|EVM]] chain inherits for free, a competing VM has to build from scratch with no realistic chance of catching up.
[[gloss:evm|EVM]] dominance is real but not permanent: its share has fallen for six straight years, and multi-chain work has shifted from exception to norm.
[[gloss:evm|EVM]] wins on inertia, not design. Technically it's worse than most newer VMs, but the accumulated stack makes any replacement uneconomical unless you hit a critical bottleneck.
Sequential execution is the specific bottleneck that justifies leaving [[gloss:evm|EVM]]. If your application doesn't hit it, losing the [[gloss:evm|EVM]] stack almost always costs more than gaining the alternative VM buys you. :::

:::details{badge=Advanced title="The fragmentation problem inside EVM"} :::p{html} The [[gloss:evm|EVM]] network effect makes any individual chain easier to launch, but it makes the resulting ecosystem economically harder to use. By May 2026 there are roughly 40 active [[gloss:layer 2|L2s]] alone in addition to the [[gloss:evm|EVM]] [[gloss:l1|L1s]], and the same token — USDC, USDT, [[gloss:ethereum|ETH]] — exists as a different on-chain object on each one of them. Native USDC on [[gloss:ethereum|Ethereum]], native USDC on Base, and wrapped USDC on Polygon are three different ERC-20 contracts with three different addresses, and ledgers don't auto-reconcile across them. :::

:::p{html} The practical effect is split liquidity. The deepest USDC/[[gloss:ethereum|ETH]] pool on Uniswap V3 lives on [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]] — that's where the institutional pricing comes from. A second-tier pool lives on Base. A third tier on Arbitrum. The same token, the same protocol, three separate pools with separate fee tiers, separate ranges, separate market makers. A trade for $50 million has to go to [[gloss:l1|L1]]; a trade for $50 can go anywhere. Anything in between has to think about routing. :::

:::p{html} The standard remedies for this are [[gloss:intent-based|intent-based]] bridges (Across, Eco Portal — covered in → 2.5 §7), unified liquidity layers (Stargate), [[gloss:chain abstraction|chain abstraction]] protocols (NEAR Intents, Particle, Connext), and increasingly [[gloss:account abstraction|account abstraction]] layered on top so the user doesn't see the routing at all. The [[gloss:superchain|Superchain]]'s [[gloss:native interop|native interop]] — when it ships — is the bet that the answer is shared protocol-level infrastructure, not application-level workarounds. None of these solutions exists at the [[gloss:l1|L1]] layer of the [[gloss:evm|EVM]] monoculture; they're patches on top. :::

:::p{html} The non-[[gloss:evm|EVM]] world doesn't have this specific problem. [[gloss:solana|Solana]] has one chain. [[gloss:aptos|Aptos]] has one chain. [[gloss:sui|Sui]] has one chain. Liquidity is concentrated by default because there's nowhere else for it to fragment to. The cost of this concentration is that [[gloss:solana|Solana]] cannot be sharded into [[gloss:solana|Solana]]-[[gloss:layer 2|L2]] + [[gloss:solana|Solana]]-[[gloss:l3|L3]] + [[gloss:solana|Solana]]-L4 the way [[gloss:ethereum|Ethereum]] was — there's no [[gloss:layer 2|L2]] story for non-[[gloss:evm|EVM]] monoliths, except for the few like [[gloss:eclipse|Eclipse]] that are trying to put [[gloss:svm|SVM]] on top of [[gloss:ethereum|Ethereum]] [[gloss:data availability|DA]]. :::

:::p{html} Bottom line. The [[gloss:evm|EVM]]'s network-effect victory was also the [[gloss:evm|EVM]]'s fragmentation problem. Monolithic non-[[gloss:evm|EVM]] chains keep everything in one place — but their auditor pool, tooling, and developer base are all much smaller. The [[gloss:evm|EVM]] stack has the larger ecosystem of tools and people — but liquidity is spread across dozens of chains, and every [[gloss:move|move]] between them costs a bridge [[gloss:transaction|transaction]]. As of 2026, neither side has fully solved this trade-off. ::: :::

:::quiz{id=q-2-6-s2 correct=2 explanation="Correct. The [[gloss:evm|EVM]]'s network effect is not the VM itself — it's the accumulated stack of audit firms, OpenZeppelin contracts, Foundry tests, Etherscan-style explorers, [[gloss:wallet|wallets]], and developer conventions. A new chain can [[gloss:fork|fork]] the [[gloss:evm|EVM]] in a weekend; replicating the stack takes a decade. D is actually the opposite of true — [[gloss:evm|EVM]] is one of the worst formats for ZK proving, which is exactly what motivates the [[gloss:risc-v|RISC-V]] proposal in §6."} Why does the [[gloss:evm|EVM]] remain dominant even though its technical design is widely considered dated?

[[gloss:solidity|Solidity]] is a uniquely well-designed language that competitors cannot replicate
[[gloss:ethereum|Ethereum]]'s market cap forces other chains to copy its VM for regulatory reasons
The [[gloss:evm|EVM]] ecosystem of audit firms, libraries, tooling, and conventions accumulated over a decade is irreplaceable — the [[gloss:bytecode|bytecode]] is dated, but the stack on top of it is not
[[gloss:evm|EVM]] [[gloss:bytecode|bytecode]] is the only format that ZK [[gloss:rollup|rollups]] can prove efficiently :::

:::section{mins=2} Non-EVM: SVM, Cairo, Move, and Why They Exist :::

:::lead Every non-[[gloss:evm|EVM]] virtual machine in production exists because one specific property of the [[gloss:evm|EVM]] was wrong for what the chain wanted to do. [[gloss:solana|Solana]]'s [[gloss:svm|SVM]] was designed to run thousands of [[gloss:transaction|transactions]] in parallel; the [[gloss:evm|EVM]] cannot. Starknet's [[gloss:cairo|Cairo]] was designed to be cheap to prove with ZK; the [[gloss:evm|EVM]] is expensive. [[gloss:move|Move]] was designed to make whole categories of bugs impossible at the type level; the [[gloss:evm|EVM]] cannot do this. The chains each made a different bet about which property mattered enough to give up the [[gloss:evm|EVM]] stack for. :::

:::p{html} [[gloss:svm|SVM]] ([[gloss:solana|Solana]] Virtual Machine) is the most architecturally distant from [[gloss:evm|EVM]], and the most successful non-[[gloss:evm|EVM]] bet by every metric except age. The defining choice is parallelism: every [[gloss:solana|Solana]] [[gloss:transaction|transaction]] declares up front which accounts it will read and write, and the [[gloss:sealevel|Sealevel]] runtime uses that declaration to schedule non-conflicting [[gloss:transaction|transactions]] in parallel across all available CPU cores. The [[gloss:evm|EVM]] cannot do this because [[gloss:solidity|Solidity]] contracts don't declare their state access in advance — a transfer might touch one account or it might touch a hundred, and you only find out by running it. We covered this design choice in → 2.3; what matters for the VM comparison is that the entire programming model is different from the [[gloss:evm|EVM]]'s. There's no "contract address with storage slots"; there's a program (immutable code) and a separate account (mutable state), and a single program can act on many accounts. This is why a [[gloss:solidity|Solidity]] developer can't just "deploy on [[gloss:solana|Solana]]" without learning a new mental model. :::

:::p{html} [[gloss:cairo|Cairo]] (Starknet) took the opposite approach: design the VM around the constraint that everything it executes will eventually be proved correct with a [[gloss:stark|STARK]]. The [[gloss:evm|EVM]] is brutal to prove — its 256-bit operations, dynamic [[gloss:gas|gas]] costs, and stateful [[gloss:opcode|opcodes]] generate huge proving circuits, and Succinct's measurements show that ~59% of [[gloss:zkevm|zkEVM]] proving time is spent simulating [[gloss:evm|EVM]] execution. [[gloss:cairo|Cairo]] was built from scratch around algebraic field operations that map cleanly to [[gloss:stark|STARK]] constraints. The cost: there's no [[gloss:solidity|Solidity]], no OpenZeppelin equivalent of the same maturity, and [[gloss:cairo|Cairo]] developers number in the thousands rather than the tens of thousands. The benefit: Starknet's proving infrastructure is several years ahead of any [[gloss:zkevm|zkEVM]] in efficiency, and Starknet was the first major [[gloss:layer 2|L2]] to decentralize its [[gloss:sequencer|sequencer]] (we covered this in → 2.5 §4). :::

:::p{html} [[gloss:move|Move]] ([[gloss:aptos|Aptos]], [[gloss:sui|Sui]], [[gloss:movement|Movement]]) made a different choice again: design the language around resource safety. In [[gloss:solidity|Solidity]], a token balance is just a number in a mapping — nothing in the language prevents you from copying it, sending the same balance twice, or losing track of who owns what; these properties must be enforced by careful coding and audit. In [[gloss:move|Move]], a token is a resource — a value with linear type semantics that the compiler refuses to copy or discard. You can [[gloss:move|move]] it, you can store it, you can destroy it explicitly, but you cannot accidentally duplicate it. Whole categories of bugs that have cost the [[gloss:evm|EVM]] world hundreds of millions of dollars — [[gloss:reentrancy|reentrancy]], double-spend through [[gloss:reentrancy|reentrancy]], integer overflow in balance arithmetic — are impossible to write in [[gloss:move|Move]]. The cost is the smallest developer pool of the three: [[gloss:sui|Sui]] had 954 monthly active developers in Q1 2026, [[gloss:aptos|Aptos]] 465, against tens of thousands on the [[gloss:evm|EVM]] stack. :::

:::p{html} Two other non-[[gloss:evm|EVM]] bets are worth mentioning because they illustrate the same pattern from different angles. [[gloss:ton|TON]] (the Telegram [[gloss:blockchain|blockchain]]) made an asynchronous-message-passing bet — contracts on [[gloss:ton|TON]] don't call each other synchronously; they send messages that are processed in subsequent [[gloss:block|blocks]]. This makes parallelism easier but makes the developer model much less familiar, and [[gloss:ton|TON]]'s economics (covered in → 2.4 §5) lean heavily on Telegram-native distribution rather than the [[gloss:evm|EVM]] toolchain. CosmWasm (Osmosis, Injective, and most other [[gloss:cosmos|Cosmos]] chains) took a different approach: pick an existing well-engineered VM ([[gloss:wasm|WebAssembly]]), wrap it with the right host functions, and lean on the [[gloss:cosmos|Cosmos]] SDK's modularity for the rest. The trade-off is roughly the same in every case — gain a property the [[gloss:evm|EVM]] doesn't have, lose access to the [[gloss:evm|EVM]] stack. :::

:::callout{icon=💡} Think about the knife [[gloss:block|block]] in a serious kitchen. There's always a chef's knife — the big general-purpose blade that handles 80% of the work. You can dice an onion with it, you can carve a chicken with it, you can chop herbs. It's not optimal for any single task, but it's adequate for almost everything, which is why every kitchen has one and every cook learns on it. The [[gloss:evm|EVM]] is the chef's knife of smart-contract VMs. Then there are the specialized blades: a yanagi for slicing raw fish in single clean strokes that a chef's knife would tear; a cleaver for splitting bone that would chip a normal edge; a paring knife for peeling fruit that a chef's knife is too big for. Each is dramatically better than the chef's knife at its specific task and useless for anything else. [[gloss:svm|SVM]] is built for parallelism the way a yanagi is built for one decisive cut. [[gloss:move|Move]] is built for resource safety the way a cleaver is built for one specific force. [[gloss:cairo|Cairo]] is built for ZK proving the way a paring knife is built for fine work. A professional kitchen has all of them; a home cook has the chef's knife and nothing else. Most [[gloss:blockchain|blockchain]] teams are home cooks. :::

:::keypoints{label="Key Points"}

The three non-[[gloss:evm|EVM]] bets in production aren't competing with each other — they occupy distinct niches: [[gloss:svm|SVM]] owns parallelism, [[gloss:cairo|Cairo]] owns ZK efficiency, [[gloss:move|Move]] owns type-level safety. It's market segmentation, not three attempts to replace [[gloss:evm|EVM]].
[[gloss:move|Move]] shifts contract safety from auditor work to compiler work. Whole categories of [[gloss:evm|EVM]] vulnerabilities don't exist in [[gloss:move|Move]] not because nobody wrote them, but because the type system refuses to compile them.
The more specialized a VM, the smaller its developer pool. This isn't a bug; it's a direct consequence of the strategy — a narrow community around one specific advantage beats a wide community around a compromise.
The right question when picking a VM is not 'which is best' but 'which [[gloss:evm|EVM]] bottleneck [[gloss:block|blocks]] my specific application.' If none of the three (parallelism, ZK efficiency, type safety) applies — leaving the [[gloss:evm|EVM]] stack costs more than it returns. :::

:::details{badge=Advanced title="Move resource types in depth"} :::p{html} [[gloss:move|Move]]'s resource model deserves a closer look because it's the cleanest example of language-level safety in any production smart-contract platform. :::

:::p{html} In [[gloss:solidity|Solidity]], an ERC-20 balance is a number stored in a mapping. The contract defines the rules: balances[from] -= amount; balances[to] += amount; for a transfer. If a developer forgets to check that balances[from] >= amount first, [[gloss:integer underflow|integer underflow]] can mint tokens out of nothing. If a developer's transfer function calls an external contract before updating the balance, a [[gloss:reentrancy|reentrancy]] attack can drain the contract. These bugs are caught by audit, by Slither, by careful code review — but they are syntactically legal [[gloss:solidity|Solidity]]. The compiler is fine with them. :::

:::p{html} In [[gloss:move|Move]], a token isn't a number in a table — it's an object in memory that the language treats like a physical thing. If your [[gloss:wallet|wallet]] holds a Coin with value 100, that's the actual Coin, not a record about it in someone's ledger. When you transfer it to someone else, you don't have it anymore — just as if you'd handed a physical coin across a table. At the syntax level, it looks like this: :::

:::p{html} Here Coin is the object's type, value: u64 is its internal field (a number up to 2⁶⁴), and the has store marker tells the compiler that objects of this type are allowed to be saved into the [[gloss:blockchain|blockchain]]'s permanent storage. :::

:::p{html} Then comes the part everything was built for — linear typing: every such object must be used exactly once. This gives three guarantees the compiler checks automatically: :::

:::p{html}

No duplication. You cannot have two variables that point to the same Coin. An attempt to copy it is a compile error, not a runtime bug.
No loss. A Coin cannot quietly fall out of a function's scope without an explicit decision about what to do with it — store it in an account, or explicitly destroy it. Forgetting about it isn't an option.
No forgery. Only the module that defined Coin can create a new one. Other code doesn't have that capability.

:::

:::p{html} The compiler refuses to build a program that violates any of these rules. :::

:::p{html} The practical effect is dramatic for the bugs the [[gloss:evm|EVM]] world has spent a decade fighting. [[gloss:reentrancy|Reentrancy]] works in [[gloss:solidity|Solidity]] because state can be inconsistent between the start and end of a function — the balance can be 100 when you enter and 0 when you leave, and an external call mid-function can run while the balance is still 100. In [[gloss:move|Move]], the act of transferring a resource removes it from the sender atomically, at the type level; there's no "balance variable" that can be inconsistent. Double-spend through [[gloss:reentrancy|reentrancy]] is not just hard to write in [[gloss:move|Move]] — it's not expressible. :::

:::p{html} The cost of this safety is two things. First, the mental model is foreign to [[gloss:solidity|Solidity]] developers: you stop thinking about "balances" and start thinking about "objects that [[gloss:move|move]]." Second, the ecosystem is much smaller. [[gloss:move|Move]] has formal verification tools (the [[gloss:move prover|Move Prover]]) that the [[gloss:evm|EVM]] doesn't, and [[gloss:aptos|Aptos]] contracts can be machine-checked for safety properties, but the number of contracts that have been formally verified is in the dozens. The number of audited [[gloss:evm|EVM]] contracts is in the hundreds of thousands. :::

:::p{html} Bottom line. [[gloss:move|Move]] proves that whole bug categories can be eliminated at the language level — it isn't a marketing claim, it's a type system property. Whether that property is worth giving up the [[gloss:evm|EVM]] ecosystem depends on what you're building. For high-value [[gloss:defi|DeFi]] primitives where a single [[gloss:reentrancy|reentrancy]] bug can lose millions, the case is strongest. For everything else, the trade is harder to justify. ::: :::

:::quiz{id=q-2-6-s3 correct=3 explanation="Correct. [[gloss:reentrancy|Reentrancy]] in [[gloss:solidity|Solidity]] exploits the gap between "balance was 100" and "balance is now 0" — an external call mid-function can run with the old value. In [[gloss:move|Move]] the act of transferring a resource removes it from the sender atomically at the type level, so the inconsistent state never exists. A and B are wrong ([[gloss:move|Move]] does allow external calls and has no special "guard"); C is wrong because the Prover is optional, not the structural defense."} What is the structural reason a [[gloss:reentrancy|reentrancy]] attack cannot be written in [[gloss:move|Move]]?

[[gloss:move|Move]] has a built-in [[gloss:reentrancy|reentrancy]] guard that auto-locks every function
[[gloss:move|Move]] doesn't allow external contract calls, so no callback can re-enter
The [[gloss:move prover|Move Prover]] automatically detects all [[gloss:reentrancy|reentrancy]] patterns and rejects the deployment
There is no "balance variable" that can be inconsistent — a token is a resource that moves atomically at the type level, so there's no mid-function inconsistent state to exploit :::

:::section{mins=1} What This Means for Users :::

:::lead For someone who just holds crypto and uses dApps, the [[gloss:evm|EVM]] vs non-[[gloss:evm|EVM]] distinction shows up in three concrete places: which [[gloss:wallet|wallet]] you install, what your address looks like, and what happens when you try to [[gloss:move|move]] a token between the two worlds. The first two are minor friction. The third is where most of the real money has been lost to bridge exploits over the past four years. :::

:::p{html} Within the [[gloss:evm|EVM]] world, the user experience is genuinely unified. Install Rabby or MetaMask once and you can use [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]], all major [[gloss:layer 2|L2s]], every [[gloss:evm|EVM]] [[gloss:l1|L1]], and any sidechain with the same [[gloss:seed phrase|seed phrase]], the same [[gloss:private key|private key]], and the same address. Your [[gloss:wallet|wallet]] on Arbitrum is the same address as your [[gloss:wallet|wallet]] on Base, on BNB Chain, on [[gloss:avalanche|Avalanche]]. You sign [[gloss:transaction|transactions]] with the same [[gloss:secp256k1|secp256k1]] [[gloss:ecdsa|ECDSA]] signature regardless of which [[gloss:evm|EVM]] network the [[gloss:transaction|transaction]] targets. You see your balances in the same Etherscan-style [[gloss:block|block]] explorer (Arbiscan, BaseScan, BscScan, Snowtrace) with the same layout and the same fields. :::

:::p{html} Stepping into non-[[gloss:evm|EVM]] means a separate [[gloss:wallet|wallet]] for each ecosystem. Phantom for [[gloss:solana|Solana]]. Argent or Braavos for Starknet. Petra or Pontem for [[gloss:aptos|Aptos]]. Suiet or Surf for [[gloss:sui|Sui]]. Keplr for [[gloss:cosmos|Cosmos]]. Tonkeeper for [[gloss:ton|TON]]. Each has its own address format — [[gloss:solana|Solana]] uses 32-byte base58 strings (around 44 characters, no "0x"), [[gloss:cosmos|Cosmos]] uses bech32 with chain-specific prefixes (cosmos1..., osmo1..., inj1...), [[gloss:aptos|Aptos]] and [[gloss:sui|Sui]] use 32-byte hex (0x with 64 characters, twice as long as [[gloss:evm|EVM]]), [[gloss:ton|TON]] uses base64-encoded EQ/UQ prefixed strings. And each uses a different signature scheme: [[gloss:secp256k1|secp256k1]] [[gloss:ecdsa|ECDSA]] for [[gloss:evm|EVM]], [[gloss:ed25519|Ed25519]] for [[gloss:solana|Solana]] and [[gloss:aptos|Aptos]] and [[gloss:sui|Sui]], [[gloss:secp256k1|secp256k1]] again for [[gloss:cosmos|Cosmos]] but on a different derivation path, [[gloss:ed25519|Ed25519]] for [[gloss:ton|TON]]. :::

:::p{html} The address-format thing is more than aesthetic. A single [[gloss:seed phrase|seed phrase]] generates different addresses on each chain because the derivation path is different — [[gloss:bip-44|BIP-44]] specifies "purpose / coin type / account / change / address index", and the coin-type field is what differentiates [[gloss:evm|EVM]] (60) from [[gloss:solana|Solana]] (501), from [[gloss:cosmos|Cosmos]] (118), from [[gloss:aptos|Aptos]] (637). One mnemonic, twelve different addresses across twelve different chains. The same [[gloss:private key|private key]] cannot sign [[gloss:transaction|transactions]] for both [[gloss:evm|EVM]] and [[gloss:solana|Solana]], because the [[gloss:elliptic curve|elliptic curve]] is different ([[gloss:secp256k1|secp256k1]] vs [[gloss:ed25519|Ed25519]]), and the addresses derived from the same seed on the two chains have no on-chain relationship. Multichain [[gloss:wallet|wallets]] like Backpack, OKX, or Trust [[gloss:wallet|Wallet]] present a unified UI on top of these separate derivations, which is helpful but doesn't change the underlying fact that you have multiple distinct on-chain identities. :::

:::p{html} The real cost shows up at the boundary. Moving USDC from [[gloss:ethereum|Ethereum]] to [[gloss:solana|Solana]] isn't "send to address" — there's no [[gloss:ethereum|Ethereum]] [[gloss:transaction|transaction]] that produces native USDC on [[gloss:solana|Solana]], because the two chains share no state. Either you go through Circle's [[gloss:cctp|CCTP]] (burn USDC on [[gloss:ethereum|Ethereum]], mint native USDC on [[gloss:solana|Solana]] — covered in → 2.5 §7), or you trust a third-party bridge to lock USDC on one side and mint a wrapped version on the other. The wrapped version is not native USDC — it's a token that depends on the bridge contract continuing to honor it. As of 2026 roughly $2.8 billion has been lost to bridge exploits, about 40% of all cumulative crypto exploit losses, and the bridges that failed worst were generally the ones connecting [[gloss:evm|EVM]] to non-[[gloss:evm|EVM]] ecosystems where no canonical native path existed. :::

:::callout{icon=💡} Imagine the [[gloss:evm|EVM]] world as the Schengen area: one passport, one currency, one set of road signs, free [[gloss:movement|movement]] between member countries. You travel from Germany to France to Italy with the same ID in your pocket, the same euros in your [[gloss:wallet|wallet]], the same driver's license. Non-[[gloss:evm|EVM]] ecosystems are like separate sovereign countries outside Schengen — each has its own passport requirements, its own currency, its own border control. [[gloss:solana|Solana]] is one country, [[gloss:aptos|Aptos]] another, Starknet a third. You can visit all of them, but each requires getting a fresh travel document and changing money at the border. The friction of crossing borders is the friction of bridging tokens. The reason bridges have been hacked so many times is the same reason currency exchange offices at borders have been robbery targets for centuries: large amounts of value sit in one place, waiting to be moved across a boundary that no single authority controls. :::

:::keypoints{label="Key Points"}

[[gloss:evm|EVM]] created the illusion of a universal crypto [[gloss:wallet|wallet]]. The illusion ends exactly at the VM boundary: one address works on thirty [[gloss:evm|EVM]] chains and on zero non-[[gloss:evm|EVM]] chains.
Different addresses don't come from design choices — they come from [[gloss:cryptography|cryptography]]. Different chains use different elliptic curves ([[gloss:secp256k1|secp256k1]] vs [[gloss:ed25519|Ed25519]]) and different derivation paths. No [[gloss:wallet|wallet]] can 'fix' this without losing security — it's math, not UI.
A multi-chain [[gloss:wallet|wallet]] unifies the interface, not the identities. Underneath, you still have N cryptographically independent accounts — which gives you attack isolation (compromising one doesn't expose the others) but also means separate backups and separate recoveries.
$2.8B lost in bridges is not a bridge bug — it's the price of separating VMs. As long as chains don't share state, bridges are inevitable; as long as bridges are inevitable, they're a permanent attack surface. The fix isn't 'better bridges' but canonical paths like [[gloss:cctp|CCTP]], where the issuer burns on one side and mints on the other. :::

:::details{badge=Advanced title="Cryptographic curves and why seeds don't transfer"} :::p{html} Why does a single [[gloss:private key|private key]] generate different public keys on [[gloss:evm|EVM]] versus [[gloss:solana|Solana]], and why isn't this just a UX problem that could be fixed? The answer is in the [[gloss:elliptic curve|elliptic curve]]. :::

:::p{html} [[gloss:evm|EVM]] chains use [[gloss:secp256k1|secp256k1]], the same curve [[gloss:bitcoin|Bitcoin]] uses, with [[gloss:ecdsa|ECDSA]] signatures. [[gloss:solana|Solana]], [[gloss:aptos|Aptos]], [[gloss:sui|Sui]], and [[gloss:ton|TON]] use [[gloss:ed25519|Ed25519]], a different curve with EdDSA signatures. [[gloss:cosmos|Cosmos]] chains use [[gloss:secp256k1|secp256k1]] like [[gloss:evm|EVM]] but with a different derivation path under [[gloss:bip-44|BIP-44]]. The curves are not interchangeable — a [[gloss:private key|private key]] valid on [[gloss:secp256k1|secp256k1]] cannot be used to produce an [[gloss:ed25519|Ed25519]] signature, and vice versa. They aren't even mathematically related in any useful way; they're just two different mathematical objects. :::

:::p{html} [[gloss:bip-44|BIP-44]] papers over this by treating the mnemonic as the entropy source for deriving separate private keys for each chain. The [[gloss:seed phrase|seed phrase]] encodes 128 or 256 bits of entropy. The derivation path m / purpose' / coin_type' / account' / change / address_index uses HMAC-SHA512 to deterministically produce a chain of child keys from that entropy. The coin_type field is what makes the [[gloss:evm|EVM]] key different from the [[gloss:solana|Solana]] key. Coin types come from a registry (SLIP-44): [[gloss:bitcoin|Bitcoin]] is 0, [[gloss:ethereum|Ethereum]] is 60, [[gloss:solana|Solana]] is 501, [[gloss:cosmos|Cosmos]] is 118, [[gloss:aptos|Aptos]] is 637, [[gloss:sui|Sui]] is 784, [[gloss:ton|TON]] is 607. :::

:::p{html} The practical implication is that "one [[gloss:seed phrase|seed phrase]], all chains" is true only because the derivation path differs across them, not because the underlying [[gloss:cryptography|cryptography]] unifies them. If you lose your seed, you lose your [[gloss:wallet|wallet]] on every chain. If someone gets your seed, they get your [[gloss:wallet|wallet]] on every chain. But you cannot, by signing a [[gloss:transaction|transaction]] with your [[gloss:ethereum|Ethereum]] [[gloss:private key|private key]], prove ownership of your [[gloss:solana|Solana]] address — they are independent identities, derived from the same root. :::

:::p{html} [[gloss:account abstraction|Account abstraction]] (ERC-4337 on [[gloss:evm|EVM]], native AA on Starknet and [[gloss:aptos|Aptos]], smart accounts on [[gloss:solana|Solana]]) starts to chip away at this. With AA, a "[[gloss:wallet|wallet]]" is a contract, and the contract decides which signatures it accepts. A single AA [[gloss:wallet|wallet]] could accept signatures from both an [[gloss:ed25519|Ed25519]] key and a [[gloss:secp256k1|secp256k1]] key, effectively letting one user identity span both worlds. As of 2026 this is real but not widespread; most users still juggle separate identities. :::

:::p{html} Bottom line. The fragmentation of identity across VMs isn't a UX bug to be fixed — it's a consequence of the underlying [[gloss:cryptography|cryptography]]. AA can paper over it at the application level; the chains themselves remain distinct. ::: :::

:::quiz{id=q-2-6-s4 correct=2 explanation="Correct. The two chains use mathematically different cryptographic curves: [[gloss:secp256k1|secp256k1]] ([[gloss:ethereum|Ethereum]], [[gloss:bitcoin|Bitcoin]], [[gloss:cosmos|Cosmos]]) versus [[gloss:ed25519|Ed25519]] ([[gloss:solana|Solana]], [[gloss:aptos|Aptos]], [[gloss:sui|Sui]], [[gloss:ton|TON]]). On top of that, [[gloss:bip-44|BIP-44]] mandates a different "coin type" field in the derivation path for each chain (60 for [[gloss:ethereum|Ethereum]], 501 for [[gloss:solana|Solana]]), producing different keys from the same entropy. The [[gloss:seed phrase|seed phrase]] is shared; the resulting on-chain identities are mathematically independent."} Why does one [[gloss:seed phrase|seed phrase]] generate different addresses on [[gloss:ethereum|Ethereum]] and [[gloss:solana|Solana]]?

A [[gloss:wallet|wallet]] bug — modern multichain [[gloss:wallet|wallets]] are gradually moving toward unified addresses
[[gloss:solana|Solana]] intentionally uses a [[gloss:hash|hash]] of the [[gloss:ethereum|Ethereum]] address to enable cross-chain linking
The two chains use different elliptic curves ([[gloss:secp256k1|secp256k1]] vs [[gloss:ed25519|Ed25519]]) and different [[gloss:bip-44|BIP-44]] derivation paths, so the same seed deterministically produces unrelated key pairs on each
It's randomness — even from the same seed, key generation is non-deterministic across chains :::

:::section{mins=2} What This Means for Developers :::

:::lead Choosing a VM is not choosing a language. It's choosing the audit firms, libraries, tooling, conventions, and a decade of accumulated tribal knowledge that comes attached. A [[gloss:solidity|Solidity]] developer can deploy to dozens of [[gloss:evm|EVM]] chains in a weekend, but adding even one non-[[gloss:evm|EVM]] target multiplies the operational surface by something between three and ten — the gain has to be worth it. :::

:::p{html} The [[gloss:solidity|Solidity]] ecosystem in 2026 is the largest, most boring, and most well-paved path in smart-contract development. The language has roughly 20,000 active developers; the supporting Rust pool (used by [[gloss:solana|Solana]], [[gloss:stylus|Stylus]], some [[gloss:cosmos|Cosmos]] chains) draws from a much larger general population of Rust developers, though only a small fraction has crypto experience. [[gloss:solidity|Solidity]] has Foundry and Hardhat (mature test frameworks), OpenZeppelin (battle-tested contract library), Slither and Mythril (static analyzers), Tenderly ([[gloss:transaction|transaction]] simulation), Etherscan and its clones (verification and exploration), the ABI standard for talking to contracts from any client. Almost all of this is free, open-source, and works the same way across every major [[gloss:evm|EVM]] chain. :::

:::p{html} The non-[[gloss:evm|EVM]] equivalents exist but the maturity gap is real. [[gloss:solana|Solana]] has Anchor (the Rust framework for [[gloss:svm|SVM]] programs), [[gloss:bankrun|Bankrun]] (test framework), [[gloss:solana|Solana]] Explorer, and a growing pool of Rust auditors. Starknet has [[gloss:scarb|Scarb]] (build tool), Starknet-foundry (test framework), the [[gloss:cairo|Cairo]] standard library. [[gloss:aptos|Aptos]] and [[gloss:sui|Sui]] have the [[gloss:move|Move]] CLI plus their respective frameworks, and [[gloss:aptos|Aptos]] has the [[gloss:move prover|Move Prover]] for formal verification. [[gloss:cosmos|Cosmos]] has CosmWasm tooling that builds on standard Rust. None of these are missing key pieces; they're all just younger and smaller. An [[gloss:evm|EVM]] auditor sees the same pattern thousands of times; a [[gloss:cairo|Cairo]] auditor sees it for the tenth time. The bugs are caught, but slower. :::

:::p{html} The biggest practical question for a team is multichain deployment. Deploying the same [[gloss:solidity|Solidity]] contract to [[gloss:ethereum|Ethereum]], Arbitrum, Base, and Optimism sounds like four-times-the-work, but is closer to "one deploy plus three configuration files" — the [[gloss:evm|EVM]] ecosystem has tooling for exactly this. Adding [[gloss:solana|Solana]] to that set is not "five-times-the-work"; it's something closer to "a parallel project that shares an idea with the [[gloss:evm|EVM]] deployment but rebuilds everything." Different language, different framework, different test setup, different deployment tooling, different oracle integrations (Pyth on [[gloss:solana|Solana]] vs Chainlink on [[gloss:evm|EVM]], though both now span multiple chains), different [[gloss:wallet|wallet]] integrations. The protocols that have done this — Uniswap (DEX on [[gloss:solana|Solana]] via UniV4), Aave (lending on [[gloss:aptos|Aptos]]), Jupiter and Drift ([[gloss:solana|Solana]]-native [[gloss:defi|DeFi]]) — each built effectively a second team to handle the second VM. :::

:::p{html} [[gloss:stylus|Stylus]] is the most interesting compromise in this picture. Arbitrum's [[gloss:wasm|WASM]] VM, in production on Arbitrum One since June 2024, lets Rust and C and C++ contracts run alongside [[gloss:solidity|Solidity]] on the same chain, with cross-call interop between the two. RedStone reported 30%+ [[gloss:gas|gas]] savings on their [[gloss:stylus|Stylus]] oracle versus heavily optimized [[gloss:evm|EVM]] [[gloss:solidity|Solidity]]. Computational benchmarks show 10–70× speedups on heavy operations. By February 2026 there's even a [[gloss:move|Move]]-to-[[gloss:stylus|Stylus]] compiler in beta from Rather Labs, which means [[gloss:move|Move]] contracts can be deployed on Arbitrum without leaving the [[gloss:evm|EVM]] ecosystem. This kind of multi-VM coexistence is the direction §6 will explore in more detail. :::

:::callout{icon=💡} Think of it the way a hospital network thinks about staffing across regions. If you run a [[gloss:solidity|Solidity]] practice, you're operating in a country with thousands of trained physicians, a national accreditation system, standardized continuing-education programs, and decades of malpractice case law. Opening a new clinic in another city in the same country is administrative work — same regulations, same training, same insurance carriers. Now imagine you decide to open a clinic in a different country with its own medical system, its own accreditation board, its own language, and its own pharmaceutical regulations. The doctors you already employ cannot just relocate; you have to recruit local specialists, retrain them on your protocols, and rebuild the same trust networks from scratch. Some hospital systems do this and the new branches are excellent, but nobody pretends it's the same operational lift as opening another clinic at home. [[gloss:evm|EVM]]-to-non-[[gloss:evm|EVM]] deployment is exactly that kind of expansion. :::

:::keypoints{label="Key Points"}

"Deploy to 10 chains" inside the [[gloss:evm|EVM]] ecosystem is one configuration file per chain. Adding the first non-[[gloss:evm|EVM]] chain is closer to standing up a parallel project — different team, different timeline, different audit budget
Audit maturity is the most undercounted [[gloss:evm|EVM]] advantage. The same firms have audited the same patterns thousands of times, with response time measured in days. Non-[[gloss:evm|EVM]] audits exist but the bench is small, slow, and expensive per contract
When a project does go multi-VM, it usually pays the cost by separating teams. Uniswap, Aave, and the major [[gloss:solana|Solana]]-native DEXes don't share contract code between their [[gloss:evm|EVM]] and non-[[gloss:evm|EVM]] presences — they share product strategy and brand
[[gloss:stylus|Stylus]] is the working counter-example: [[gloss:wasm|WASM]] contracts (Rust, C, C++, and now [[gloss:move|Move]]) running on Arbitrum alongside [[gloss:solidity|Solidity]], with cross-call interop. The cost of leaving [[gloss:solidity|Solidity]] drops dramatically when you don't have to leave the [[gloss:evm|EVM]] stack at the same time :::

:::details{badge=Advanced title="Replay attacks and chain-specific opcode behavior"} :::p{html} The dangerous bugs in multichain deployment aren't usually missing features — they're features that exist on every chain but behave subtly differently. Three categories matter in practice. :::

:::p{html} [[gloss:chain id|Chain ID]] and replay attacks. Imagine a user signs a [[gloss:permit|permit]] — an offchain authorization saying "contract X may withdraw 100 USDC from my address" — on [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]]. If the contract correctly commits [[gloss:block|block]].[[gloss:chainid|chainid]] into the signature, that signature is valid only on [[gloss:ethereum|Ethereum]]. If it doesn't, the same signature can be submitted on any [[gloss:evm|EVM]] chain where the user has the same address and balance, and 100 USDC is debited a second time. [[gloss:eip|EIP]]-155 introduced [[gloss:chainid|chainid]] exactly to make these replays impossible: every [[gloss:evm|EVM]] chain has its own [[gloss:chain id|chain ID]] ([[gloss:ethereum|Ethereum]] = 1, Arbitrum = 42161, Base = 8453, Optimism = 10), and a signature commits to a specific one. But the protection works only when the contract itself checks [[gloss:chainid|chainid]] in its signature-verification logic. Permits, governance voting, meta-[[gloss:transaction|transactions]] — anywhere [[gloss:eip-712|EIP-712]] typed-data is used — can be vulnerable. The bug is invisible on a single-chain deployment; it appears the moment the same contract address exists on two chains. :::

:::p{html} [[gloss:block|Block]] timestamp and randomness. The [[gloss:block|block]].timestamp [[gloss:opcode|opcode]] returns Unix time (seconds since January 1, 1970), but [[gloss:block|block]] frequency varies dramatically across chains. Arbitrum produces a [[gloss:block|block]] roughly every 250ms; [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]] every 12 seconds; Polygon [[gloss:proof of stake|PoS]] every 2 seconds. A contract using [[gloss:block|block]].timestamp as a randomness source (for a lottery, say) or as a fine-grained time gate ("allow withdrawal only one hour after deposit") behaves completely differently on different chains. Worse: on chains with a centralized [[gloss:sequencer|sequencer]] (Arbitrum, Optimism, Base — all run through a single operator), the timestamp can be nudged by the [[gloss:sequencer|sequencer]] within a small window. "Randomness from timestamp" then becomes "randomness the chain operator can influence." :::

:::p{html} [[gloss:precompile|Precompile]] availability. [[gloss:ethereum|Ethereum]] has a fixed set of precompiled contracts (ecrecover, sha256, blake2f, the [[gloss:bn254|bn254]] [[gloss:pairing|pairing]] operations, etc.). Most [[gloss:evm|EVM]] chains support the same set, but a few add or omit. Arbitrum has its own ArbOS [[gloss:precompile|precompiles]] for [[gloss:l1|L1]]-[[gloss:layer 2|L2]] communication that don't exist on [[gloss:ethereum|Ethereum]]. Optimism has [[gloss:l1|L1]]-[[gloss:block|block]]-info [[gloss:precompile|precompiles]]. A contract that calls an unknown [[gloss:precompile|precompile]] gets unexpected behavior (often: returns no data, fails silently). :::

:::p{html} Practical countermeasure. Real multichain deployments treat each target chain as an independent audit subject. The chain-specific test suite must include: [[gloss:chain id|chain ID]] verification, timestamp-dependence tests, [[gloss:precompile|precompile]]-availability tests, [[gloss:fork|fork]]-test reproduction of any signature-based interaction. Deployment scripts must read chain-specific configuration. The tooling for this exists (Foundry's [[gloss:fork|fork]] testing, Tenderly's multichain simulations), but the team has to use it deliberately. :::

:::p{html} Bottom line. The same [[gloss:solidity|Solidity]] source compiled to the same [[gloss:bytecode|bytecode]] produces different observable behavior on different [[gloss:evm|EVM]] chains. The bigger the deployment surface, the more chain-specific edge cases need explicit handling. Multichain isn't "free" inside the [[gloss:evm|EVM]] world either — it's just much cheaper than crossing into non-[[gloss:evm|EVM]]. ::: :::

:::quiz{id=q-2-6-s5 correct=1 explanation="Correct. Adding a non-[[gloss:evm|EVM]] chain is structurally different from adding another [[gloss:evm|EVM]] chain. Within [[gloss:evm|EVM]], a deployment is a configuration file plus a re-test pass. Crossing into [[gloss:solana|Solana]] means rewriting in Rust against Anchor, finding [[gloss:solana|Solana]]-specialist auditors, integrating Phantom rather than Rabby, and using Pyth or Switchboard rather than Chainlink. The protocols that have actually done this — Uniswap, Aave — operate effectively two parallel codebases held together by product strategy."} A [[gloss:solidity|Solidity]] team has shipped on [[gloss:ethereum|Ethereum]], Arbitrum, and Base. The team is considering adding [[gloss:solana|Solana]]. What's the realistic cost?

Roughly the same as adding another [[gloss:evm|EVM]] [[gloss:layer 2|L2]] — Foundry now supports cross-VM deployment
Essentially a parallel project: different language (Rust), different framework (Anchor), different audit firms, different [[gloss:wallet|wallet]] integrations, different oracle providers, and a separate team to maintain it long-term
Slightly more than another [[gloss:evm|EVM]], mainly to translate [[gloss:solidity|Solidity]] to Rust — the rest of the tooling transfers
Impossible without a [[gloss:chain abstraction|chain abstraction]] protocol like NEAR Intents :::

:::section{mins=2} Convergence: Worlds Merging :::

:::lead The most interesting story in VMs in 2025–2026 is not which one wins. It's that the two camps have started looking at each other's choices and absorbing them. [[gloss:evm|EVM]] chains are getting parallel execution and [[gloss:wasm|WASM]] coexistence; Vitalik himself has proposed replacing the [[gloss:evm|EVM]] with [[gloss:risc-v|RISC-V]] at the [[gloss:l1|L1]] protocol level. Non-[[gloss:evm|EVM]] chains are getting [[gloss:evm|EVM]] compatibility layers and bridges. By 2026 the question "which VM does this chain use" is becoming the wrong frame — many of them use more than one. :::

:::p{html} The [[gloss:evm|EVM]] is getting parallel execution. [[gloss:monad|Monad]], an [[gloss:evm|EVM]]-[[gloss:bytecode|bytecode]]-compatible [[gloss:l1|L1]] founded by ex-Jump Trading engineers, launched [[gloss:mainnet|mainnet]] on November 24, 2025 after three years of testnet. Architecturally [[gloss:monad|Monad]] does what the [[gloss:evm|EVM]] was never designed for: optimistic parallel execution. [[gloss:transaction|Transactions]] are run in parallel by default; if two of them end up touching the same state slot, the conflicting one is re-executed sequentially. The result is the same final state [[gloss:ethereum|Ethereum]] would reach, just much faster. [[gloss:monad|Monad]] targets 10,000 TPS with 400ms [[gloss:block|blocks]] and 800ms [[gloss:finality|finality]], and as of April 2026 the chain holds about $400.9 million in [[gloss:tvl|TVL]]. [[gloss:solidity|Solidity]] contracts deploy unchanged; OpenZeppelin, Foundry, and every standard tool work. The [[gloss:evm|EVM]] stack stays; the sequential constraint goes away. :::

:::p{html} The [[gloss:evm|EVM]] is also getting [[gloss:wasm|WASM]] coexistence. Arbitrum [[gloss:stylus|Stylus]], live on Arbitrum One since June 2024, lets Rust, C, and C++ contracts run alongside [[gloss:solidity|Solidity]] in a second VM bolted onto the same chain. Cross-call interop between [[gloss:stylus|Stylus]] and [[gloss:solidity|Solidity]] is native — a [[gloss:stylus|Stylus]] contract can be called from a [[gloss:solidity|Solidity]] contract and vice versa. RedStone's oracle, deployed on [[gloss:stylus|Stylus]] in November 2025, reported 30%+ [[gloss:gas|gas]] savings on real workloads against heavily optimized [[gloss:evm|EVM]] code; on heavy computational operations [[gloss:stylus|Stylus]] benchmarks at 10–70× faster execution. In February 2026 Rather Labs released a [[gloss:move|Move]]-to-[[gloss:stylus|Stylus]] compiler in beta — meaning [[gloss:move|Move]] contracts can now run on Arbitrum without leaving the [[gloss:ethereum|Ethereum]] ecosystem at all. The line between "[[gloss:evm|EVM]] chain" and "non-[[gloss:evm|EVM]] chain" is the boundary [[gloss:stylus|Stylus]] is dissolving. :::

:::p{html} The most ambitious [[gloss:move|move]] is from [[gloss:ethereum|Ethereum]] itself. On April 20, 2025, Vitalik posted a proposal on the [[gloss:ethereum|Ethereum]] Magicians forum to replace the [[gloss:evm|EVM]] with [[gloss:risc-v|RISC-V]] at the [[gloss:l1|L1]] protocol level — the same open-source instruction set used in modern CPUs and in most ZK provers internally. The argument: roughly 59% of [[gloss:zkevm|zkEVM]] proving time is spent simulating [[gloss:evm|EVM]] execution, and switching to [[gloss:risc-v|RISC-V]] natively could improve proving efficiency by 50–100×. The proposal lays out a three-stage deployment: [[gloss:precompile|precompiles]] for select operations first, then user-deployable [[gloss:risc-v|RISC-V]] contracts alongside [[gloss:evm|EVM]], and eventually retiring the [[gloss:evm|EVM]] entirely by running it as an interpreter inside the new VM. In a March 2026 follow-up, Vitalik described state-tree changes plus the VM change as together representing "more than 80% of the proving bottleneck" — and called both "basically mandatory" for client-side proving. Offchain Labs (the team behind Arbitrum and [[gloss:stylus|Stylus]]) responded in November 2025 with their own rebuttal arguing [[gloss:wasm|WASM]] is the better long-term choice. The debate is live; nothing is decided. :::

:::p{html} From the non-[[gloss:evm|EVM]] side, the convergence is also moving. [[gloss:eclipse|Eclipse]] runs the [[gloss:svm|SVM]] on top of [[gloss:ethereum|Ethereum]] [[gloss:data availability|data availability]], putting [[gloss:solana|Solana]]'s runtime inside [[gloss:ethereum|Ethereum]]'s security model. [[gloss:sei|Sei]] V2 shipped [[gloss:evm|EVM]] compatibility alongside its native CosmWasm. [[gloss:movement|Movement]] runs [[gloss:move|Move VM]] as an [[gloss:ethereum|Ethereum]] [[gloss:layer 2|L2]] with a settlement on [[gloss:l1|L1]] and execution on [[gloss:move|Move]]. [[gloss:neon evm|Neon EVM]] deploys [[gloss:solidity|Solidity]]-compatible [[gloss:evm|EVM]] on [[gloss:solana|Solana]]. None of these are dominant; all of them exist and have product-market signal. The pattern is consistent: instead of one VM winning, ecosystems are increasingly building multi-VM chains where the same chain can host both [[gloss:evm|EVM]] and non-[[gloss:evm|EVM]] contracts, and the choice moves from "which chain" to "which VM on this chain." :::

:::callout{icon=💡} It's similar to what happened to charging connectors over the last decade. In 2010 every phone manufacturer had its own port: Apple had the 30-pin, Samsung had micro-USB-A, Nokia had its barrel connector, the cheap brands each had something proprietary. A guest at your house could not borrow your charger; an airport seating area had four different docks taped to a kiosk. The differences had real technical reasons — different signaling, different voltages, different intellectual property — but to the user they were just friction. Then USB-C arrived, and step by step every camp moved toward it: Android first, laptops next, even Apple eventually under EU pressure. The connectors didn't merge by anyone winning. They merged because the value of the network — being able to plug anything into anything — exceeded the value of any one company's design. The VM convergence is following the same path: [[gloss:stylus|Stylus]] is a hybrid port ([[gloss:solidity|Solidity]]-USB and Rust-USB on the same chain); [[gloss:eclipse|Eclipse]] is an [[gloss:svm|SVM]] device running on [[gloss:ethereum|Ethereum]]-shaped power; the [[gloss:risc-v|RISC-V]] proposal is the new universal standard trying to replace the old socket entirely. :::

:::keypoints{label="Key Points"}

The [[gloss:evm|EVM]] is no longer the [[gloss:evm|EVM]] of 2018. [[gloss:monad|Monad]] ships parallel execution while keeping byte-identical compatibility. [[gloss:stylus|Stylus]] puts [[gloss:wasm|WASM]] next to [[gloss:solidity|Solidity]] on the same chain. Both keep the [[gloss:evm|EVM]] stack and remove the constraints that made it look dated
Vitalik's April 2025 [[gloss:risc-v|RISC-V]] proposal is the loudest signal yet that [[gloss:ethereum|Ethereum]] may retire the [[gloss:evm|EVM]] itself. The three-stage path — [[gloss:precompile|precompiles]], then user contracts, then full retirement via interpreter — is concrete enough to act on but slow enough to take years
The non-[[gloss:evm|EVM]] side mirrors the [[gloss:move|move]]: [[gloss:eclipse|Eclipse]] puts [[gloss:svm|SVM]] on [[gloss:ethereum|Ethereum]] [[gloss:data availability|DA]], [[gloss:movement|Movement]] puts [[gloss:move|Move]] as an [[gloss:ethereum|Ethereum]] [[gloss:layer 2|L2]], [[gloss:sei|Sei]] adds [[gloss:evm|EVM]] next to CosmWasm. The architectural distance between camps is shrinking from both directions
The frame "which VM does this chain use" is increasingly the wrong question. The new frame is "which VMs does this chain host, and how do they interoperate." Multi-VM is the design pattern most likely to define 2027 and beyond :::

:::details{badge=Advanced title="RISC-V vs WASM as the next execution layer"} :::p{html} If the [[gloss:evm|EVM]] is being slowly replaced, the question of what replaces it matters more than the question of whether. Two candidates have serious backing: [[gloss:risc-v|RISC-V]] and [[gloss:wasm|WASM]]. :::

:::p{html} [[gloss:risc-v|RISC-V]] (Vitalik's position). [[gloss:risc-v|RISC-V]] is an open-source CPU instruction set originally designed at Berkeley for academic use. It has a small core spec, modular extensions, and growing hardware support. For blockchains its biggest advantage is ZK proving: zkVMs like Succinct's SP1, RISC Zero, and Polygon's Miden already use [[gloss:risc-v|RISC-V]] internally because its instruction set is closer to the algebra of [[gloss:snark|SNARK]] constraints than [[gloss:evm|EVM]] [[gloss:bytecode|bytecode]] is. Vitalik's argument: if [[gloss:zkevm|zkEVMs]] are already translating [[gloss:evm|EVM]] [[gloss:bytecode|bytecode]] to [[gloss:risc-v|RISC-V]] internally to prove it, just standardize on [[gloss:risc-v|RISC-V]] at the protocol level and skip the translation step. Estimated efficiency gain: 50–100× for proving. [[gloss:polkadot|Polkadot]]'s [[gloss:polkavm|PolkaVM]] has been using [[gloss:risc-v|RISC-V]] since August 2023, so the design has production validation outside [[gloss:ethereum|Ethereum]]. :::

:::p{html} [[gloss:wasm|WASM]] (Offchain Labs' position). [[gloss:wasm|WebAssembly]] is a different open-source [[gloss:bytecode|bytecode]] format, originally designed for browsers but now used as a general-purpose target for systems languages. It's already in production on Arbitrum ([[gloss:stylus|Stylus]]), on most [[gloss:cosmos|Cosmos]] chains (CosmWasm), on [[gloss:polkadot|Polkadot]]'s contracts pallet, on Near, on Internet Computer. The argument from Offchain Labs in their November 2025 rebuttal: [[gloss:wasm|WASM]] has a much larger existing developer base than [[gloss:risc-v|RISC-V]], mature toolchains (Rust, C++, Go, AssemblyScript all compile to [[gloss:wasm|WASM]]), and an active standards process. Their core claim: the delivery ISA (what developers write code in) and the proving ISA (what the ZK prover translates to) don't need to be the same — [[gloss:wasm|WASM]] for delivery, [[gloss:risc-v|RISC-V]] for proving. :::

:::p{html} The technical difference. [[gloss:risc-v|RISC-V]] is closer to bare-metal hardware: 32-bit instructions, register-based, easy to map to ZK circuits. [[gloss:wasm|WASM]] is a stack-based VM with structured control flow, designed for safe sandboxing in browsers. Both are deterministic; both can be made [[gloss:gas|gas]]-metered. The implementation cost of either at the [[gloss:l1|L1]] level is comparable; the ecosystem cost is very different. :::

:::p{html} What's actually likely. The most plausible outcome is not a winner but a coexistence. [[gloss:ethereum|Ethereum]]'s roadmap, as Vitalik laid it out, is gradual: keep the [[gloss:evm|EVM]] for legacy contracts, add the new VM (whichever it is) alongside, let developers choose. [[gloss:glamsterdam|Glamsterdam]] ([[gloss:ethereum|Ethereum]]'s next major upgrade, scheduled for first half of 2026) is focused on state-tree changes — [[gloss:eip|EIP]]-7864 binary tree replacement — rather than VM changes. The VM transition is a 2027-and-later question. [[gloss:hegota|Hegota]], the upgrade after [[gloss:glamsterdam|Glamsterdam]], is expected later in 2026 and may begin the VM transition more seriously. :::

:::p{html} Bottom line. The [[gloss:risc-v|RISC-V]] vs [[gloss:wasm|WASM]] debate is the most important architectural debate in [[gloss:ethereum|Ethereum]]'s medium-term future. Both proposals are credible; neither is committed to. What's already certain is that the [[gloss:evm|EVM]] in its current form is not the long-term execution layer, and the people who designed it agree. ::: :::

:::quiz{id=q-2-6-s6 correct=3 explanation="Correct. The core argument is ZK proving efficiency. Around 59% of [[gloss:zkevm|zkEVM]] proving time is spent simulating [[gloss:evm|EVM]] execution, and modern zkVMs like Succinct SP1, RISC Zero, and Polygon Miden already use [[gloss:risc-v|RISC-V]] internally. Switching at the protocol level removes the translation overhead. In Vitalik's March 2026 follow-up he described the VM change plus the state-tree change as collectively the source of "more than 80% of the proving bottleneck.""} Vitalik proposed replacing the [[gloss:evm|EVM]] with [[gloss:risc-v|RISC-V]] in April 2025. What's the main technical motivation?

[[gloss:solidity|Solidity]] will compile much faster against a simpler instruction set
[[gloss:risc-v|RISC-V]] will enable [[gloss:ethereum|Ethereum]] to run on consumer-grade hardware without [[gloss:node|nodes]]
It's a marketing [[gloss:move|move]] to align [[gloss:ethereum|Ethereum]] with the open hardware [[gloss:movement|movement]]
ZK provers already translate [[gloss:evm|EVM]] [[gloss:bytecode|bytecode]] to [[gloss:risc-v|RISC-V]] internally to prove it, and the translation step accounts for most of the proving overhead — switching to [[gloss:risc-v|RISC-V]] natively could improve proving efficiency by 50–100× :::

:::section{mins=2} Where the Industry Goes in 2026 :::

:::lead Three trajectories are visible at the same time, and they're not mutually exclusive: the [[gloss:evm|EVM]] stack adapts and absorbs ([[gloss:monad|Monad]], [[gloss:stylus|Stylus]], eventual [[gloss:risc-v|RISC-V]]), the strongest non-[[gloss:evm|EVM]] bets keep growing into their own niches ([[gloss:solana|Solana]] for throughput, Starknet for ZK-native, [[gloss:move|Move]] ecosystem for high-value [[gloss:defi|DeFi]]), and a third layer rises above them that abstracts the underlying VM away from users entirely ([[gloss:account abstraction|account abstraction]], [[gloss:chain abstraction|chain abstraction]], [[gloss:intent-based|intent-based]] UX). By 2028 the question "[[gloss:evm|EVM]] or non-[[gloss:evm|EVM]]" may be one the average user simply doesn't have to ask. :::

:::p{html} The first trajectory is the one [[gloss:ethereum|Ethereum]] has been working on the longest and is least dramatic. The [[gloss:evm|EVM]] stays the dominant smart-contract platform; it absorbs improvements that compensate for its design weaknesses. [[gloss:monad|Monad]] demonstrates that parallel execution can be added without breaking compatibility. [[gloss:stylus|Stylus]] demonstrates that [[gloss:wasm|WASM]] coexistence can be added without breaking compatibility. The 2025–2026 wave of [[gloss:evm|EVM]] [[gloss:l1|L1s]] ([[gloss:monad|Monad]] and competitors like MegaETH) is the proof that "fast [[gloss:evm|EVM]]" is technically possible. If [[gloss:risc-v|RISC-V]] or [[gloss:wasm|WASM]] lands at the [[gloss:ethereum|Ethereum]] protocol level in the [[gloss:glamsterdam|Glamsterdam]]-or-[[gloss:hegota|Hegota]] timeframe, the [[gloss:evm|EVM]] gets effectively retired as a separate concept — what replaces it will still run all existing contracts via interpreter, but the new execution model will look more like a modern instruction set than a 2014 stack machine. :::

:::p{html} The second trajectory is more interesting precisely because the non-[[gloss:evm|EVM]] camp has been growing faster from a smaller base. [[gloss:solana|Solana]]'s developer count grew 83% year-over-year in the 2024 Electric Capital report; [[gloss:sui|Sui]]'s monthly active developers grew faster than any other major chain into 2026. The non-[[gloss:evm|EVM]] bets that have succeeded — [[gloss:solana|Solana]]'s parallelism, [[gloss:move|Move]]'s safety, [[gloss:cairo|Cairo]]'s ZK efficiency — aren't being replaced; they're being made deeper. [[gloss:aptos|Aptos]] shipped a major tokenomics overhaul in March 2026. [[gloss:sui|Sui]] launched its native [[gloss:usdsui|USDsui]] [[gloss:stablecoin|stablecoin]] and the [[gloss:sui|Sui]] Stack (S2) platform transition. [[gloss:solana|Solana]] saw [[gloss:stablecoin|stablecoin]] transfers cross $1 trillion in cumulative volume by 2026. These are not chains losing relevance; they're chains finding their categories. :::

:::p{html} The third trajectory, the one most likely to actually change user experience, is abstraction. [[gloss:account abstraction|Account abstraction]] (ERC-4337 on [[gloss:evm|EVM]], native AA on Starknet and [[gloss:aptos|Aptos]], smart accounts on [[gloss:solana|Solana]]) decouples "[[gloss:wallet|wallet]]" from "[[gloss:private key|private key]]," so a single user identity can present itself across multiple VMs through a contract that decides which signatures it accepts. [[gloss:chain abstraction|Chain abstraction]] (NEAR Intents, Particle, Connext, plus the [[gloss:superchain|Superchain]]'s [[gloss:native interop|native interop]] work) decouples "where my money is" from "where I'm using it." [[gloss:intent-based|Intent-based]] protocols like Across, Eco Portal, and UniswapX let a user declare an outcome and let solvers handle the routing — the user might never know whether the solver settled it on [[gloss:evm|EVM]], on [[gloss:solana|Solana]], or both. Combined, these abstractions [[gloss:move|move]] the "which VM" decision from the user's plane to the infrastructure plane. :::

:::p{html} What all three trajectories share is that they make the original binary frame — [[gloss:evm|EVM]] vs non-[[gloss:evm|EVM]] — less useful over time. By the late 2020s the relevant questions are likely to be different: how does this chain handle [[gloss:data availability|data availability]], how does it handle [[gloss:finality|finality]], how does it handle [[gloss:mev|MEV]], what's its trust model. The VM will still matter to developers writing the contracts, but it will matter less to users using them and less to capital allocators choosing where to deploy. That's the convergence story §6 set up — and that's the note Part 2 closes on, because Part 3 starts with the practical question of which [[gloss:wallet|wallet]] to actually install, and that question used to depend entirely on which VM you cared about. :::

:::callout{icon=💡} Think about how the question "which camera should I buy" lost most of its meaning over the past fifteen years. In 2005 it was a serious decision: a full-frame DSLR did something a phone camera could not, a compact zoom did something a DSLR could not, a film camera did something digital could not. People learned the trade-offs, joined forums, debated brands. By 2020 the question had folded into the phone in their pocket. A flagship phone took photos most people couldn't distinguish from a 2010 DSLR, the editing tools ran on the same phone, the sharing happened on the same phone, and the question "which camera" was replaced by "which app." Photographers who needed a real camera still bought one; everyone else stopped asking. The VM question in crypto is at the early stage of the same collapse. By 2028 most users won't pick a chain — their [[gloss:wallet|wallet]] will pick one for them, their app will pick one for them, the underlying VM will be the file format the camera saves to, not the decision the user makes. :::

:::keypoints{label="Key Points"}

Three trajectories run in parallel: [[gloss:evm|EVM]] absorbing improvements (parallel execution, [[gloss:wasm|WASM]] coexistence, eventual [[gloss:risc-v|RISC-V]]), non-[[gloss:evm|EVM]] deepening its niches ([[gloss:solana|Solana]] throughput, [[gloss:move|Move]] [[gloss:defi|DeFi]], Starknet ZK), and abstraction layers making the underlying VM less visible to end users
[[gloss:account abstraction|Account abstraction]], [[gloss:chain abstraction|chain abstraction]], and [[gloss:intent-based|intent-based]] protocols compose to push the VM selection into infrastructure code. The user declares "swap X for Y"; whatever combination of chains and solvers achieves it is invisible
The medium-term questions for ecosystem evaluators are shifting: not "[[gloss:evm|EVM]] or non-[[gloss:evm|EVM]]" but "what's the [[gloss:data availability|DA]] layer, what's the [[gloss:finality|finality]] model, what's the [[gloss:mev|MEV]] story, what's the trust assumption." The VM remains one input among several rather than the defining one
This convergence is the bridge to Part 3 of the project. [[gloss:wallet|Wallets]], the first chapter of the next part, used to be a strict VM-by-VM decision; in 2026 multichain [[gloss:wallet|wallets]] and AA-enabled solutions begin to dissolve that constraint :::

:::details{badge=Advanced title="Timelines and what to watch in 2026–2027"} :::p{html} For a reader trying to track this space, here's what's worth watching and what timeline it's on. :::

:::p{html} [[gloss:ethereum|Ethereum]]'s [[gloss:glamsterdam|Glamsterdam]] upgrade. Scheduled for first half of 2026. The headline item is [[gloss:eip|EIP]]-7864 — replacing [[gloss:ethereum|Ethereum]]'s hexary Merkle Patricia state tree with a binary tree, which Vitalik described in March 2026 as half of the proving bottleneck. State tree changes don't change the VM; they change how state proofs are constructed. This is the prerequisite work for the VM transition, not the VM transition itself. :::

:::p{html} [[gloss:ethereum|Ethereum]]'s [[gloss:hegota|Hegota]] upgrade. Scheduled for later in 2026. Developers haven't finalized the headline EIPs yet, but execution-layer changes are central to ongoing planning. This is the earliest realistic window for protocol-level [[gloss:risc-v|RISC-V]] or [[gloss:wasm|WASM]] [[gloss:precompile|precompiles]] to land. :::

:::p{html} [[gloss:superchain|Superchain]] [[gloss:native interop|native interop]]. On devnet as of April 2026; [[gloss:mainnet|mainnet]] planned for later in 2026 (we covered this in → 2.5 §5). This is the [[gloss:evm|EVM]]-side answer to chain fragmentation, and it'll be a useful test of whether protocol-level interop can replace bridge-level interop in the [[gloss:evm|EVM]] [[gloss:rollup|rollup]] ecosystem. :::

:::p{html} [[gloss:monad|Monad]]'s first year. [[gloss:mainnet|Mainnet]] launched November 24, 2025; by April 2026 it held $400.9M in [[gloss:tvl|TVL]]. The question through 2026 is whether parallel-[[gloss:evm|EVM]] economics actually attract [[gloss:defi|DeFi]] applications away from incumbent [[gloss:layer 2|L2s]] or just provide a second tier. The [[gloss:mev|MEV]] dynamics on a 400ms-[[gloss:block|block]] parallel [[gloss:evm|EVM]] are untested at scale. :::

:::p{html} The [[gloss:move|Move]] ecosystem. [[gloss:sui|Sui]]'s 954 active developers in Q1 2026 versus [[gloss:aptos|Aptos]]'s 465 is the largest gap in developer activity between two technically similar chains in the industry. [[gloss:sui|Sui]]'s [[gloss:usdsui|USDsui]] [[gloss:stablecoin|stablecoin]] launch and [[gloss:aptos|Aptos]]'s institutional RWA strategy are diverging bets. [[gloss:movement|Movement]] and Initia continue to expand [[gloss:move|Move]] into [[gloss:ethereum|Ethereum]] [[gloss:layer 2|L2]] and [[gloss:cosmos|Cosmos]] territory respectively. :::

:::p{html} [[gloss:account abstraction|Account abstraction]] deployment. ERC-4337 has been live on [[gloss:ethereum|Ethereum]] since March 2023, but real-world usage has been slow. [[gloss:eip-7702|EIP-7702]] ([[gloss:pectra|Pectra]], May 2025) reduced the friction by letting EOAs delegate to contracts without permanent migration. Watch for AA usage to compound as [[gloss:wallet|wallets]] ship better defaults — this is the practical mechanism by which "which VM" becomes invisible to users. :::

:::p{html} Bottom line. The most likely 2026–2027 outcome is no single dramatic event, but a slow compounding of changes that, taken together, make the [[gloss:evm|EVM]]-vs-non-[[gloss:evm|EVM]] question less crisp than it was in 2024. None of the bets above is guaranteed. All of them are happening. ::: :::

:::quiz{id=q-2-6-s7 correct=0 explanation="Correct. The most credible 2028 outcome isn't one VM winning — it's the question fading from the user-facing layer entirely. [[gloss:account abstraction|Account abstraction]], [[gloss:chain abstraction|chain abstraction]], and [[gloss:intent-based|intent-based]] protocols compose to make the VM decision an infrastructure detail. B, C, and D are all plausible-sounding overreaches: [[gloss:evm|EVM]] doesn't "win" because non-[[gloss:evm|EVM]] keeps growing; [[gloss:ethereum|Ethereum]]'s VM transition is a multi-year process; [[gloss:solana|Solana]] hasn't displaced [[gloss:ethereum|Ethereum]] on most metrics by April 2026 and there's no concrete path showing it will by 2028."} By 2028, what is the most likely state of the "[[gloss:evm|EVM]] vs non-[[gloss:evm|EVM]]" question for an end user?

The question fades in importance for users because [[gloss:account abstraction|account abstraction]], [[gloss:chain abstraction|chain abstraction]], and intent protocols increasingly [[gloss:move|move]] the VM choice from the user's plane to the infrastructure's. The VM still matters to developers, just much less to the people using their applications
[[gloss:evm|EVM]] wins decisively because of network effects, and non-[[gloss:evm|EVM]] chains stop being relevant
[[gloss:ethereum|Ethereum]]'s [[gloss:risc-v|RISC-V]] transition fully replaces the [[gloss:evm|EVM]] and renders the distinction meaningless
[[gloss:solana|Solana]] overtakes [[gloss:ethereum|Ethereum]] by every metric and the [[gloss:evm|EVM]] becomes a legacy stack :::