The EVM (Ethereum Virtual Machine) is the runtime environment that executes smart-contract code on Ethereum, as specified in developer documentation published by the Ethereum Foundation. Every full node runs an identical copy of the EVM, so the same bytecode produces the same result on every computer in the network, keeping the ledger consistent without a central server.
Key Takeaways
- The EVM, per Gavin Wood’s Ethereum Yellow Paper, is a quasi-Turing-complete, stack-based virtual machine with a maximum stack depth of 1024 items and a 256-bit word size.
- Per Ethereum Foundation developer documentation, the EVM executes code consistently and securely across all Ethereum nodes, using the state transition function Y(S, T) = S’, where a valid state S and transactions T produce a new valid state S’.
- Smart contracts, per Vitalik Buterin’s Ethereum Whitepaper, compile to a low-level, stack-based bytecode language referred to as “Ethereum virtual machine code” or “EVM code”, typically written first in Solidity or Vyper.
- Every operation costs gas, with a standard ETH transfer requiring 21,000 units of gas and prices quoted in gwei, equal to 10^-9 ETH.
- Leading EVM-compatible Layer 2 rollups by value secured include Arbitrum One at $15.95 billion, Base Chain at $11.84 billion, and OP Mainnet at $1.57 billion as of April 2026, per L2Beat data.
How Does the EVM Work?
The EVM runs as a deterministic state machine on every Ethereum node at once, per the Ethereum Foundation documentation. Its design breaks down into four parts: stack-based architecture, bytecode and opcodes, three distinct storage locations, and gas metering.
1. Stack-Based Architecture
Per the Ethereum Yellow Paper, the EVM specification is a narrow, well-defined machine. The EVM is a simple stack-based architecture; the word size of the machine is 256-bit, chosen to facilitate the Keccak-256 hash scheme and elliptic-curve computations. The stack has a maximum size of 1024, and the memory model is a simple word-addressed byte array. Operations pop operands off the top of the stack, do arithmetic, and push results back, the same pattern an old HP calculator uses.
That design choice is worth pausing on. A 256-bit word is wasteful for storing a boolean but exactly right for holding a 256-bit hash or elliptic-curve point, so every opcode ends up native to cryptography. The entire contract language is shaped by this one number.
2. Bytecode and Opcodes
Smart contracts never run Solidity directly. Per Ethereum Foundation developer documentation, smart contracts must be compiled before they can be deployed so that Ethereum’s virtual machine can interpret and store the contract. The compiler turns human-readable code into a byte string, where each byte represents an operation. Code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter, and then incrementing the program counter by one, until the end of the code is reached or an error, STOP or RETURN instruction is detected.
A tiny example makes this concrete. Say a contract wants to compute 5 + 3 and save the result to storage slot 0. The bytecode reads:
PUSH1 0x05 // push 5 onto the stack
PUSH1 0x03 // push 3 onto the stack
ADD // pop both, push 8
PUSH1 0x00 // push storage slot index 0
SSTORE // pop slot, pop value, write 8 to storage[0]
Five opcodes. The stack goes from empty, to [5], to [5,3], to [8], to [8,0], to empty. Slot 0 now holds the value 8 forever, replicated across every node that processed this transaction. The EVM instruction set features arithmetic opcodes like XOR, AND, ADD, SUB, as well as blockchain-specific opcodes like ADDRESS, BALANCE, and BLOCKHASH, and the full set covers roughly 140 instructions.
3. Three Storage Locations (the Three-Shelf Model)
Every EVM program juggles data across three places with very different rules. The simplest way to picture them is a kitchen.
| Memory Type | Lifetime | Analogy | Cost Profile |
| Stack | Single opcode sequence | Countertop where you do the arithmetic | Cheap (3 gas per push or pop) |
| Memory | Single transaction | Whiteboard wiped after each meal | Moderate, grows quadratically |
| Storage | Forever | Notebook the whole neighbourhood can read | Expensive (20,000 gas to write a new slot) |
Source: Ethereum Yellow Paper, Ethereum Foundation developer documentation
There are three main types of storage locations in the EVM: transient storage, storage, and memory. Stack is a last-in-first-out container to which values can be pushed and popped, memory is an infinitely expandable byte array, and the contract’s long-term storage is a key/value store. Transient storage, added more recently via the TSTORE and TLOAD opcodes, sits between memory and storage, cleared at the end of each transaction instead of each call frame.
The three-shelf model matters because gas costs scale with persistence. Anything written to storage lives on every node forever, so the protocol prices it punishingly to keep state bloat in check.
4. Gas Metering
Gas is how the EVM charges for computation and prevents infinite loops. Gas refers to the unit that measures the amount of computational effort required to execute specific operations on the Ethereum network. Usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state.
Users pay in gwei. Gas prices are denoted in gwei, which itself is a denomination of ETH; each gwei is equal to one-billionth of an ETH (0.000000001 ETH or 10^-9 ETH). Under the current fee market, the total fee paid is units of gas used multiplied by the sum of the base fee and the priority fee; the base fee is set by the protocol and is burnt. A standard ETH transfer requires 21,000 units of gas, while complex DeFi interactions can require several hundred thousand. The full mechanics of how prices move block by block are covered in our Ethereum gas fees coverage.
Why Does the EVM Matter?
The EVM turned Ethereum from a second Bitcoin into a programmable settlement layer. Bitcoin’s scripting language is intentionally limited; Ethereum made the opposite bet. The EVM is a quasi-Turing-complete machine, with the quasi qualification coming from the fact that computation is intrinsically bounded through a parameter, gas. That combination, any computation plus a hard economic brake, is what allows smart contracts to do real work without ever running forever.
Rather than merely tracking transactions like Bitcoin, Ethereum maintains a large data structure which holds not only all accounts and balances but a machine state, which can change from block to block according to a pre-defined set of rules. That machine state is the EVM’s shared memory, and the DeFi economy is built entirely on top of it. Lending markets, decentralized exchanges, stablecoins, prediction markets, and on-chain governance all reduce to “deploy some EVM bytecode and let the world use it.”
Our coverage of Layer-1 and Layer-2 platforms since 2024 shows one recurring pattern: every non-Ethereum chain that gained real developer traction either adopted the EVM (BNB Chain, Polygon, Avalanche C-Chain, Base, Arbitrum) or built its own toolchain from scratch and spent years catching up. EVM compatibility is the single largest developer mindshare moat in smart-contract platforms. The crypto ecosystem now runs mostly on EVM bytecode, even when the chain settling the transactions is not Ethereum.
Advantages and Trade-offs of the EVM
The EVM’s design is deliberate. Its strengths and its limits come from the same root decisions.
Advantages
- Deterministic execution: Identical bytecode produces identical results on every node, so the network always agrees on state.
- Sandboxed: Contracts cannot reach outside the EVM. No filesystem, no network calls, no random numbers. This removes whole classes of bugs.
- Composable: Contracts are public on Ethereum and can be thought of as open APIs, so any contract can call any other, which is the basis of DeFi “money legos”.
- Portable: Any chain that runs an EVM can execute Ethereum bytecode, which is why the two main contract languages, Solidity and Vyper, now target dozens of networks, not just the Ethereum mainnet.
- Gas-metered: The fee for every opcode is fixed in the protocol, so attackers cannot DoS the chain with cheap infinite loops.
Trade-offs and Risks
- Small contract size: A smart contract can be a maximum of 24KB, or it will run out of gas; this can be circumvented by using the Diamond Pattern, which splits logic across multiple contracts but adds complexity.
- Expensive storage: Writing a new 32-byte storage slot costs 20,000 gas, the single most expensive common opcode. This pushes developers toward off-chain data and Merkle proofs.
- Limited native types: The 256-bit word forces everything into a single size class. Strings, structs, and dynamic arrays need extra encoding, which means extra gas.
- Irreversible mistakes: Once deployed, contract code cannot be changed unless the developer built in an upgrade pattern from day one. Bugs become permanent on-chain exploits.
- No randomness: The EVM is deterministic by design, so “random” values have to come from oracles or commit-reveal schemes, both of which have their own failure modes.
EVM-Compatible vs EVM-Equivalent Chains
Two terms get used interchangeably in the press but mean different things. An EVM-equivalent chain runs exactly the same bytecode, opcodes, and precompiles as the Ethereum mainnet, so developers can redeploy contracts without changing a line of code. An EVM-compatible chain runs the EVM specification with some modifications, often in gas pricing, precompiles, or consensus hooks, so most contracts work, but some need adjustment.
The top Layer 2 rollups sit at the equivalence end of the spectrum.
| Chain | Type | Value Secured (April 2026) | Category |
| Arbitrum One | Optimistic Rollup (L2) | $15.95 billion | EVM-equivalent |
| Base Chain | Optimistic Rollup (L2) | $11.84 billion | EVM-equivalent |
| OP Mainnet | Optimistic Rollup (L2) | $1.57 billion | EVM-equivalent |
| BNB Chain | Independent L1 | Not tracked by L2Beat | EVM-compatible (modified gas model) |
| Polygon PoS | Sidechain / L1 | Not tracked by L2Beat | EVM-compatible |
| Avalanche C-Chain | Subnet | Not tracked by L2Beat | EVM-compatible |
Source: L2Beat scaling summary, Ethereum Foundation developer documentation
L2Beat’s summary on April 16, 2026, showed Arbitrum One at $15.95 billion, Base Chain at $11.84 billion, and OP Mainnet at $1.57 billion in value secured, all EVM-compatible optimistic rollups executing the same EVM bytecode as Ethereum mainnet. For a developer, that distinction is practical money. An EVM-equivalent rollup lets the same Solidity repository deploy to five chains from one command; a compatible chain may need precompile tweaks or gas-cost audits.
Real-World Applications of the EVM
Almost every on-chain application outside the Bitcoin and Solana ecosystems is an EVM program.
DeFi Protocols
Uniswap, Aave, Compound, Curve, and MakerDAO all run as sets of EVM contracts. Every swap, loan, and liquidation is a transaction that pushes inputs onto the stack, runs through a few thousand opcodes, and writes updated balances to storage. The DeFi market has consolidated around EVM chains because forking a successful protocol to a new EVM network takes days, not months.
Tokens and NFTs
ERC-20 tokens and ERC-721 NFTs are just standardized EVM contracts. Because every EVM node speaks the same opcodes, a wallet like MetaMask or Rabby can show a user’s balance on Arbitrum, Base, and the Ethereum mainnet from a single piece of wallet software.
Scenario: A Uniswap Swap on Base
A user swaps 100 USDC for ETH on Base. Their wallet builds a transaction calling Uniswap’s router contract. The Base sequencer orders it, runs the EVM for that contract (hundreds of opcodes, several storage reads, two SSTORE writes to update token balances), charges gas in Base’s ETH, and posts the resulting state root back to the Ethereum mainnet. Hours later, the same bytecode path could be exercised on Arbitrum with identical results because both chains run the same EVM.
Frequently Asked Questions (FAQs)
EVM stands for Ethereum Virtual Machine. It is the runtime environment that executes smart-contract bytecode on the Ethereum network. The Yellow Paper formally defines it as a quasi-Turing-complete, stack-based virtual machine with a 256-bit word size and a maximum stack depth of 1024 items, run by every Ethereum full node to keep the ledger in sync.
Gas is the unit that measures the computational effort needed to execute EVM operations. Users pay gas fees denominated in gwei, one-billionth of an ETH, to compensate validators and prevent spam. A basic ETH transfer costs 21,000 gas, while complex DeFi transactions can run into the hundreds of thousands.
Solidity is the dominant language, used for most of the top DeFi and NFT contracts on Ethereum. Vyper is a smaller Python-style alternative favoured for security-critical contracts such as Curve Finance pools. Both compile down to the same EVM opcodes, which means the EVM itself does not care which language a contract was written in.
An EVM-equivalent chain runs the exact same bytecode, opcodes, and gas costs as the Ethereum mainnet, so any Ethereum contract can be redeployed without modification. An EVM-compatible chain runs the EVM specification with deviations in gas pricing, precompiles, or consensus, so most contracts work, but some need audits or tweaks before they behave identically.
Conclusion
The EVM is a small specification doing a large job. Its 256-bit word size, 1024-deep stack, and gas-bounded execution model are the narrow rails on which the entire smart-contract economy runs. Thousands of identical EVM instances on thousands of nodes, plus a few dozen EVM-compatible chains feeding into the same toolchain, produce a single shared computing environment that no other smart-contract platform has matched.
The next phase of EVM development sits mostly at the edges of the virtual machine rather than its core. Rollup-centric scaling pushes most transactions onto EVM-equivalent Layer 2s, while account abstraction and pre-compiles for zero-knowledge proofs slowly expand what EVM bytecode can express. The core design from 2014 keeps surviving because every scaling path still assumes you want to run Solidity code on top of it.
