The EVM Is Where Code Moves Money

Traditional backend software runs on infrastructure controlled by a single organization. It processes private application state, reads and writes databases, calls external APIs, depends on supporting services, and can be patched, migrated, or rolled back. Failures are usually limited to that organization's context.

Smart contracts use a different execution model. They run against shared state replicated across the network, where execution can move money, collateral, debt, ownership, and liquidity.

That is what makes the EVM more than a runtime: it is the layer where code directly changes economic reality.

Ethereum Is More Than a Ledger

Ethereum is commonly described as a ledger, but more precisely it is a replicated state machine whose transitions are executed by the EVM.

Each node processes the same ordered transaction history according to the same rules and derives the same global state. Each state transition takes the prior state, applies an ordered set of transactions under the EVM rules and gas constraints, and produces the next state.

At a high level, Ethereum execution is ordered state transition:

for block in canonical_chain:
    for tx in block:
        state = EVM.execute(state, tx)

Transaction order affects state: the consensus layer selects the canonical block sequence, and the execution layer applies each block's transactions in order, producing the same result from the same starting state.

Ethereum state is composed of accounts. Conceptually, the global state is a giant key-value database:

address -> account data

Each account contains fields such as an ETH balance, nonce, contract code, and contract storage.

A DeFi protocol is not merely deployed on Ethereum; it is part of Ethereum’s shared state machine. Its economically meaningful data lives inside global state: DEX reserves, swap rules, vault shares, lending positions, pool balances, oracle values, and governance parameters.

Unlike a conventional transaction database, Ethereum does not only store transactions. It re-executes a deterministic economic history and materializes the resulting state.

Transactions Are Entry Points

Those state transitions begin with transactions, the external inputs that start EVM execution. For a contract call, it is a signed request to execute against Ethereum state, with a target address, optional ETH value, calldata, fee parameters, and a gas limit.

Once execution starts, the target contract can expand that single entry point into a full execution trace across multiple contracts. These internal calls are triggered by the original transaction; they are not separate transactions.

tx
└── Vault.deposit(...)
    ├── Token.transferFrom(...)
    ├── Strategy.allocate(...)
    └── emit Deposit(...)

Contracts do not initiate execution on their own but run only when invoked during a transaction and may then call other contracts.

Money Requires Deterministic Execution

Because every node must produce the same result from the same transaction, EVM execution cannot directly depend on off-chain or nondeterministic inputs.

That excludes common software features such as uncontrolled randomness, external API calls, wall-clock time, hidden local state, and nondeterministic system behavior. Any of these could make the same transaction produce different results on different nodes.

The EVM excludes nondeterministic operations from its instruction set. Contracts can only depend on data available in the execution context: calldata, storage, balances, transaction metadata, block metadata, and existing on-chain state.

This constraint shapes core blockchain patterns:

• External data must be brought on-chain before contracts can use it, which is why oracles exist.
• Time is not direct wall-clock time. Contracts use block metadata such as block.timestamp.
• Randomness cannot come from a local node. It must be generated in a way that can be verified on-chain.

Determinism is not a design preference; it is what allows independent nodes to agree on money.

Atomicity Enables DeFi Composition

A transaction is one atomic EVM execution. It may contain many internal calls and state changes, but those changes do not commit independently.

If the transaction succeeds, its state changes persist. If it reverts, they are discarded.

This all-or-nothing property enables multi-step DeFi workflows such as flash loans:

tx
└── ArbitrageContract.execute()
    ├── borrow USDC from a flash loan provider
    ├── swap USDC for ETH on DEX A
    ├── swap ETH for USDC on DEX B
    ├── repay the flash loan plus fee
    ├── send remaining USDC as profit
    └── revert if profit is below the required threshold

The lending contract transfers the assets, invokes the borrower's logic, and reverts the entire transaction unless the principal and fee are repaid before execution completes.

Atomicity is local to a single transaction. It does not extend across separate transactions, off-chain systems, cross-chain messages, or asynchronous oracle updates.

Composability Creates Protocol Dependency Graphs

Because contract calls execute atomically within one transaction, DeFi protocols can compose directly at execution time and become building blocks for one another. For example, a liquidation contract can borrow from one protocol, repay debt in another, and sell collateral through a third.

Composability increases the risk surface. A protocol can be correct in isolation but still fail because a contract it depends on reverts, returns stale data, changes behavior, or loses liquidity. Each dependency becomes part of the protocol's effective execution environment.

The risk is amplified by permissionless execution: public functions are not called only by honest users through the intended interface. Any actor can call them directly, route through other contracts or prepare state beforehand. Protocol design is therefore about constraining reachable state transitions, not only implementing expected user flows.

Gas Bounds Execution

Composability can expand a transaction across many contracts, but gas keeps the total execution finite by charging each operation against the transaction's gas limit. Every node that validates execution must run the transaction, so the EVM measures computational work in gas rather than elapsed time or CPU cycles. The sender pays for the gas consumed, and when blockspace is scarce, users compete for transaction inclusion by offering higher fees.

Gas serves several roles at once:

• DoS and spam resistance: execution is metered and transaction submission has a cost.
• Execution budget enforcement: each transaction has a maximum amount of work it can consume.
• Resource pricing: costly resources, especially persistent storage, cost more gas.
• Blockspace allocation: each block has a finite gas budget.
• Economic prioritization: higher-fee transactions are more likely to be included when demand is high.

Each EVM operation has a gas cost. During execution, the EVM subtracts these costs from the transaction's gas limit. If execution exhausts the available gas before completing, execution reverts. The state changes are discarded, but the gas spent is still paid.

Gas is charged across the full execution trace, including every internal call.

Gas constraints shape code as well as protocol architecture, favoring fewer storage writes, compact data structures, and implementation choices that may trade readability or flexibility for lower execution cost. A profitable or necessary action may fail in practice if it is too expensive to execute.

Economic Memory Is Expensive

Most EVM data, including stack values and memory, is discarded when the transaction ends, while storage writes modify Ethereum's persistent global state. Values written to storage can be read by future transactions and must be carried forward by nodes, making storage one of the EVM's most expensive resources.

For DeFi protocols, storage is where economic state lives: ownership, balances, debt, collateral, liquidity, configuration, and accounting variables. It is the durable state that lets a protocol operate across transactions, blocks, and users.

Storage cost shapes protocol architecture. Protocols must minimize unnecessary writes, avoid unbounded state growth, and keep persistent state compact.

On-Chain State, Off-Chain Views

Not every execution detail belongs in expensive persistent storage, so contracts expose activity through events that are recorded as logs for off-chain consumption.

The source of truth stays on-chain: storage, balances, and the rules enforced by contract code. Events only describe what happened during execution.

This creates a boundary between on-chain state and off-chain read models. Raw logs from canonical blocks are deterministic; the systems that consume and index them are not. Off-chain systems reconstruct views of the chain from logs, RPC calls, traces, and historical data. These views are useful, but derived: they can lag, miss data, drop subscription updates, mishandle reorgs, or differ depending on the data source and indexing pipeline.

Ethereum applies ordered transactions to shared state under deterministic, atomic, and gas-bounded rules. In the EVM, code changes the financial state that users and protocols depend on.