EVM
Ethereum Virtual Machine
The runtime that executes smart contracts on Ethereum and the dozens of chains that copied its bytecode format.
The EVM is the execution layer Ethereum invented and that became the de-facto standard for smart-contract chains. A contract compiled to EVM bytecode runs on Ethereum mainnet, Polygon, Arbitrum, Optimism, Base, BNB Chain, Avalanche C-chain, and a long tail of L2s and sidechains.
The practical implication: write your contracts in Solidity (or Vyper), test on Ethereum testnets, and deploy to whichever EVM chain matches your cost and latency target. The portability is real. The trade-offs between chains are speed, finality, decentralisation, and which L2 framework they are built on.
Worked example of choosing a chain: a DeFi protocol that needs to compose with existing lending and DEX contracts belongs on Ethereum mainnet or a major L2, where that ecosystem lives, even at higher gas. A high-volume consumer app where users will not tolerate dollar-scale fees belongs on an L2 like Arbitrum, Optimism, or Base (same security model, a tenth to a hundredth the cost) or off the EVM entirely toward Solana. The decision is the security-versus-cost trade-off, not whichever chain has the loudest marketing this quarter.
The honest trade-off and the mistake that catches teams repeatedly: EVM-compatible is not the same as Ethereum-equivalent. Subtle differences in gas pricing, precompiles, opcode support, and consensus behaviour mean a contract that passes on mainnet can break on a sidechain. The portability is a starting point, not a guarantee; always re-test per chain before deploying. Account-level UX features like account abstraction also vary in maturity across chains, so confirm support before you promise it.
The deeper trade-off is what you give up for cheap fees. Moving off mainnet onto a cheaper EVM chain almost always means inheriting a different trust model: a sidechain like Polygon PoS runs its own validator set rather than borrowing Ethereum’s security, and a rollup adds a sequencer you now depend on and a withdrawal delay back to L1. None of that shows up in the gas-fee comparison a vendor puts in the deck. Decide what your application actually needs to guarantee before you optimise for the per-transaction cost. For web3 builds we default to Solidity over Vyper for the broader tooling and auditor familiarity, unless there is a strong reason to swim against the current.