What Is the EVM? The Ethereum Virtual Machine Explained
The Ethereum Virtual Machine is the engine that runs every smart contract on Ethereum. Here's what it does, what 'EVM compatible' means, and why one wallet address works on Base, Arbitrum, and Polygon.
The Ethereum Virtual Machine, almost always shortened to EVM, is the part of Ethereum that actually runs code. Every smart contract, every token transfer, every swap on a decentralized exchange is the EVM executing instructions.
You will run into the term in two very different places. Developers use it to mean the execution engine at Ethereum’s core. Everyone else meets it in phrases like “EVM compatible chain” or “EVM network” on a wallet screen, usually while trying to work out why their address seems to exist on six blockchains at once.
Both meanings come from the same idea. This guide explains the engine first, then the practical consequences that affect where your funds land.
What the EVM Actually Is
Start with what Ethereum is not. It is not only a list of who owns what.
The ethereum.org developer documentation describes Ethereum as “a distributed state machine” whose state 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.”
Those pre-defined rules are the EVM. It is the rulebook that decides how the network moves from its current state to the next one.
A useful comparison: Bitcoin’s ledger mostly records transfers. Ethereum’s ledger records the results of arbitrary computation. The EVM is what makes that second thing possible, which is where the “world computer” nickname comes from.
One detail matters for trust. The EVM is deterministic. Given the same starting state and the same transaction, every node on Earth computes the identical result. That is why thousands of independent machines can agree on the outcome without trusting each other.
What Happens When You Send a Transaction
The abstraction gets concrete fast. Say you swap ETH for USDC on Uniswap.
- Your wallet signs a transaction addressed to the Uniswap contract and broadcasts it.
- A validator picks it up and hands it to its EVM.
- The EVM loads the dapp’s contract code and runs it instruction by instruction, checking balances, calculating the exchange rate, and updating the liquidity pool.
- The resulting state changes get written into a block.
- Every other node re-runs the same code and confirms it reaches the same answer.
Step 5 is the expensive part and the whole point. Redundant execution across the network is what makes the result trustworthy without a company standing behind it.
This also explains a detail that confuses beginners about failed transactions. A transaction that reverts still consumed real computation before it failed, so it still costs gas. The work happened; it just did not produce the outcome you wanted.
Gas: Why the EVM Charges for Computation
An open computer anyone can run code on has an obvious problem. Someone will write an infinite loop.
Gas is the answer. Every EVM operation has a fixed gas price attached: arithmetic is cheap, writing to permanent storage is expensive. Your transaction carries a gas limit, and if execution exceeds it, the EVM halts and reverts everything while keeping the fee.
That turns denial of service into a pricing problem. Attacking the network with heavy computation means paying for every step, and no one can afford to loop forever.
It also explains why writing data on-chain costs so much more than reading it. Storage has to be kept by every node indefinitely. Our gas fees guide covers what you actually pay in practice.
Solidity, Bytecode, and Opcodes
The EVM does not understand Solidity, the language most Ethereum contracts are written in. It understands roughly 140 low-level instructions called opcodes.
The pipeline runs in one direction:
| Stage | What it is | Who reads it |
|---|---|---|
| Solidity source | Human-readable contract code | Developers and auditors |
| Bytecode | Compiled hexadecimal instructions | The EVM |
| Opcodes | Individual operations like ADD, SUB, and SSTORE | The EVM, one step at a time |
Per ethereum.org, the EVM runs as “a stack machine with a depth of 1024 items,” pushing and popping values as it works through those opcodes.
Only the bytecode goes on-chain. The original Solidity does not, which is exactly why contract verification matters. When Etherscan shows a contract as verified, it has confirmed that published source code compiles to the bytecode actually deployed. An unverified contract is a black box you are being asked to trust, and that is a genuine red flag.
Who Created the EVM?
The EVM was specified by Gavin Wood in the Ethereum Yellow Paper, the formal technical definition of the protocol, and shipped with Ethereum’s launch in 2015. Wood was a co-founder of Ethereum alongside Vitalik Buterin, who wrote the original 2013 whitepaper describing the broader concept.
The Yellow Paper still functions as the reference specification. When a chain claims to be “EVM equivalent,” compliance with that document is the claim being made.
What “EVM Compatible” Means
Here is the part that shows up on your wallet screen.
Because the EVM is a specification rather than a product, any blockchain can implement it. A chain that does is EVM compatible, and three things follow immediately:
- Contracts port over. A developer can deploy the same Solidity code on Ethereum, Polygon, or Base with little or no modification.
- Tools work everywhere. MetaMask, Etherscan-style explorers, and standard developer libraries all speak the same language.
- Addresses are identical in format. Every EVM chain derives wallet addresses the same way, so your
0xaddress is the same string on all of them.
That last point is the practical answer to why your one address appears to work on many networks. It is not being copied anywhere. Each chain independently arrives at the same address from the same public key.
For a new chain, EVM compatibility is a shortcut to an ecosystem. Instead of persuading developers to learn a new language, you inherit Ethereum’s existing contracts, tooling, and audited code.
EVM Compatible vs EVM Equivalent
These two phrases get used interchangeably in marketing. They mean different things.
| EVM compatible | EVM equivalent | |
|---|---|---|
| Goal | Run Solidity contracts | Replicate Ethereum’s execution environment exactly |
| Yellow Paper compliance | Partial | Full |
| Under the hood | Modified execution, different consensus or fee rules | Matches Ethereum’s behavior |
| Standard Ethereum clients | May need custom nodes | Can run clients like Geth |
| Porting a contract | Usually works, sometimes needs changes | Any bytecode that runs on Ethereum runs here |
As Chainlink’s explainer puts it, equivalence is the stricter promise: not just running the same code, but reproducing the same environment.
Most Layer 2 networks aim for equivalence, because their whole pitch is being Ethereum with cheaper fees. Independent Layer 1 chains more often settle for compatibility, since they have deliberately changed consensus or block times to hit other goals.
Which Chains Are EVM Chains?
The EVM is now the default programming environment for smart contracts well beyond Ethereum itself, spanning dozens of networks.
| Chain | EVM? | Notes |
|---|---|---|
| Ethereum | Yes, the original | The reference implementation |
| Arbitrum, Base, Optimism | Yes | Layer 2 rollups targeting EVM equivalence |
| Polygon, BNB Chain, Avalanche C-Chain | Yes | Independent chains, EVM compatible |
| Solana | No | Uses its own Solana Virtual Machine, which runs transactions in parallel |
| Bitcoin | No | No general smart contract engine by design |
| XRP Ledger | Not natively | Added a separate EVM sidechain in June 2025 |
The Solana contrast is the instructive one. Where the EVM processes transactions sequentially, Solana’s SVM executes many at once across multiple CPU cores. That is a real speed advantage and the reason Solana contracts cannot simply be moved to Ethereum: different engine, different language, different assumptions.
XRP answers a common question in a way worth stating precisely. The XRP Ledger itself is not an EVM chain. Ripple launched an Ethereum-compatible sidechain that runs alongside it, live on mainnet since June 30, 2025 per CoinDesk. The mainnet architecture did not change.
Is the EVM the Same as an Ethereum Wallet?
No, and the confusion is understandable given how often “EVM wallet” appears in app interfaces.
The EVM is the execution engine inside the network. A wallet is software on your device that holds keys and signs messages. They never occupy the same place.
When a service advertises an “EVM wallet,” it means a wallet that works with EVM-format addresses and can connect to EVM chains. MetaMask is the common example. That is a statement about which networks the wallet supports, not about the wallet containing an EVM.
Why This Matters When You Send Funds
The abstraction becomes expensive at exactly one moment: choosing a network on a withdrawal screen.
Because every EVM chain accepts the same address format, a valid address tells you nothing about whether you picked the right chain. Your wallet will happily accept a correct-looking address on the wrong network, and the transaction will succeed. The funds simply arrive somewhere you were not expecting.
Sometimes you can recover them by adding the network to your wallet, since you control that address on every EVM chain. With exchange deposits, often you cannot.
Two habits cover nearly all of this risk:
- Read the network name, not just the address. Every deposit and withdrawal screen names one. Match it on both sides.
- Send a small test transaction first. On a Layer 2 the gas cost is a fraction of a cent, and it converts an unrecoverable mistake into a five dollar experiment.
Sending to a non-EVM chain usually fails outright, because a Solana or Bitcoin address will not validate as an Ethereum one. That failure is protecting you.
Is the EVM Changing?
The EVM is deliberately conservative. Every change has to be adopted by the whole network, and thousands of deployed contracts depend on current behavior, so upgrades are slow by design.
The active proposal is the EVM Object Format, or EOF, tracked as EIP-7692. It restructures contract bytecode into a versioned container that separates executable code from data, letting clients validate a contract once at deployment instead of repeatedly at execution.
EOF has had a rough path. Core developers removed it from the Fusaka upgrade after community pushback and concerns about timeline risk, as The Defiant reported, leaving Fusaka to ship PeerDAS and the higher blob count that cut fees in December 2025. EOF is now a candidate for Glamsterdam, the next hard fork, targeted for Q4 2026 with enshrined proposer-builder separation (EIP-7732) and block-level access lists (EIP-7928) as its headline changes.
For anyone using Ethereum rather than building on it, none of this changes what you do. It is worth knowing that the EVM is maintained rather than frozen, and that “why is this taking so long” usually has the same answer: breaking deployed contracts is not an option.
The Short Version
The EVM is the engine that executes Ethereum’s smart contracts, priced by gas so that open access does not mean unlimited free computation. Because it is a published specification rather than a product, dozens of other chains implement it, which is what “EVM compatible” means.
The consequence you will actually feel is that your 0x address is valid across all of those chains. Convenient when you understand it, expensive when you assume a valid address means the right network.
If you take one habit from this: read the network name on every deposit screen, and send a test transaction before anything large.
This article is educational and is not financial advice.
Related Reading
- What Is Ethereum?
- What Is a Crypto Wallet Address?
- Ethereum Gas Fees Explained
- Ethereum Layer 2 Networks
- Ethereum vs Solana
- What Is Etherscan?
