If you have read about Base, Ethereum, or any of the dozens of other networks built around the same technology, you have probably seen the term EVM. It stands for Ethereum Virtual Machine, and it is one of those ideas that sounds abstract but explains a lot of practical things, like why the same wallet works on Base and Ethereum, and why a smart contract written for one network can often run on another with no changes at all.
A virtual machine, not a physical one
A virtual machine, in computing generally, is a program that behaves like a computer. It has its own simple instruction set, its own memory, and its own rules for what each instruction does. Code written for that virtual machine runs the same way no matter what physical hardware is underneath it, whether that is an Intel laptop, an ARM phone, or a cloud server.
The EVM is a virtual machine purpose built for blockchains. It was introduced with Ethereum in 2015 and defines exactly how smart contracts are executed: what each instruction (called an opcode) does, how much it costs in gas, how a contract reads and writes its own storage, and how it calls other contracts. Every full node on an EVM network runs this same virtual machine and gets the same result from the same input, which is what lets thousands of independent computers agree on the state of the network without trusting each other.
What actually runs inside it
When you write a smart contract in a language like Solidity or Vyper, that code is compiled down into EVM bytecode, a long string of low level instructions the virtual machine can execute directly. Things like "add these two numbers," "read this storage slot," or "send this amount of ETH to this address" are each represented by a specific opcode.
When you send a transaction, whatever node processes it loads the relevant contract's bytecode, feeds it into the EVM, and runs it step by step. Every opcode has a gas cost, which is why a transaction that touches more contract logic or storage costs more than a simple transfer. The EVM stops execution the moment it runs out of allotted gas, which is also why a transaction can fail partway through and still consume the gas that was spent up to that point.
Why Base uses it too
Base is not a separate blockchain with its own rules. It is a Layer 2 built on the OP Stack, and one of the core design choices behind the OP Stack is EVM equivalence: Base runs the exact same virtual machine as Ethereum, with the same opcodes and the same execution rules. The things that differ are the surrounding infrastructure, like how transactions get ordered and how data eventually gets posted back to Ethereum for security, not the computing environment contracts actually run in.
This is a deliberate tradeoff. A network could build a faster or cheaper virtual machine from scratch, but it would break compatibility with everything built for the EVM over the past decade: wallets, developer tools, auditing firms, and the contracts themselves. By keeping the same virtual machine, Base lets existing Ethereum contracts deploy with little to no modification, and lets existing tooling, including wallets, work without changes.
What this means in practice
A few things follow directly from Base sharing the EVM with Ethereum.
Your wallet address works the same way on both networks, and on every other EVM chain, because address generation is a function of the virtual machine's account model, not of any one network.
A contract audited and battle tested on Ethereum behaves identically when deployed on Base, assuming it does not depend on anything Ethereum specific like a particular oracle address. This is a big part of why so many established DeFi protocols were able to launch on Base quickly.
Developer tools like Hardhat, Foundry, and block explorers like Basescan work on Base the same way their Ethereum equivalents work, because they are built against the EVM's rules, not against one specific deployment of it.
It also explains why EVM compatibility is treated as a meaningful label across the industry. Chains that describe themselves as "EVM compatible" are telling developers and users that the same contracts, wallets, and mental model carry over, even if the chain is not literally a Layer 2 of Ethereum. Not every blockchain works this way. Solana, for example, uses a different execution model entirely (the Solana Virtual Machine), which is one reason tooling and contracts do not move between Solana and EVM networks without being rewritten.
The part that is easy to overlook
None of this means Base is identical to Ethereum in every respect. Block times, fee markets, and how transactions get finalized back on Ethereum are all specific to Base's own design, covered elsewhere on this blog. The EVM is the shared computing layer underneath those differences, not a guarantee that everything above it behaves the same.
For a self custody wallet, the practical takeaway is simple: the same account, the same recovery phrase, and largely the same contract code work across EVM networks because they are all speaking the same low level language. That shared language is the reason an ecosystem of independent chains, including Base, could grow around Ethereum instead of requiring the entire ecosystem to be rebuilt from scratch for each new network.