How Ethereum Transactions Work

The Account Model: How Ethereum Tracks State

Bitcoin tracks ownership using unspent transaction outputs — a model where "your balance" is really a collection of coins you haven't spent yet. Ethereum takes a different approach entirely.

Ethereum maintains a global state: a massive database mapping every address on the network to a set of values — its ether balance, a nonce (a transaction counter), some storage data, and optionally a piece of executable code. This is called the account model.

There are two types of accounts in Ethereum:

• Externally Owned Accounts (EOAs): Controlled by a private key. This is your wallet. It has a balance and a nonce; it has no code.
• Contract Accounts: Controlled by code, not a private key. These are smart contracts. They also have a balance, a nonce, storage, and bytecode that executes when called.

Only EOAs can initiate transactions. A transaction is always triggered by a human (or a bot) holding a private key — even when the end destination is a contract.

What a Transaction Contains

Every Ethereum transaction is a signed data structure. The fields that matter:

Nonce — A counter tracking how many transactions the sender has sent. This prevents replay attacks and enforces ordering. If your nonce is 47, your next transaction must be nonce 48. A gap stalls the queue.

To — The recipient address. This is an EOA if you're sending ether, a contract address if you're calling a function, and empty (null) if you're deploying a new contract.

Value — The amount of ether to transfer, denominated in wei (1 ETH = 10^18 wei).

Data — An optional byte string. For plain ether transfers, this is empty. For contract calls, this contains the calldata: the function selector (a 4-byte hash of the function signature) plus any arguments. For contract deployments, this contains the contract bytecode.

Gas Limit — The maximum units of gas the sender is willing to consume. Gas measures computational work. Every EVM operation costs a defined amount of gas. If execution hits the limit, the transaction reverts — but the gas already consumed is still paid.

Max Fee Per Gas / Max Priority Fee Per Gas — Since EIP-1559 (August 2021), Ethereum uses a two-component gas pricing model. There's a base fee set by the protocol (burned, not paid to validators) and a priority fee (tip) that goes to the block proposer. The sender sets a max fee cap; any difference between the max fee and actual base fee is refunded.

Signature (v, r, s) — ECDSA cryptographic signature proving the sender authorized the transaction.

What Happens When a Transaction Is Broadcast

A signed transaction is broadcast to any Ethereum node. That node validates the signature, checks the nonce is correct, and verifies the sender has enough ether to cover the max possible cost (value + gas limit × max fee). Valid transactions land in the mempool — the waiting room.

Block proposers (validators, in Ethereum's current proof-of-stake design) select transactions from the mempool, typically prioritizing by priority fee. Each block has a gas limit — a cap on total computational work per block. This creates the scarcity that drives fee markets.

When a transaction is included in a block, the Ethereum Virtual Machine (EVM) executes it:

1. The sender's balance is decremented by the gas cost (reserved upfront).
2. The nonce increments.
3. If the to field is a contract, the contract's bytecode executes. The EVM processes each opcode, reading and writing to the contract's storage as instructed.
4. Any ether value moves from sender to recipient (or contract).
5. If execution completes without hitting the gas limit, unused gas is refunded.
6. If execution reverts (explicit revert, out-of-gas, or invalid opcode), state changes roll back — but gas consumed is not refunded.
7. The base fee is burned. The priority fee goes to the block proposer.

The new global state — updated balances, updated nonces, updated contract storage — is committed to the block. Every full node replays this execution independently to verify.

Where the Constraints Live

The key constraint in Ethereum's transaction system is the block gas limit, currently around 30 million gas. A simple ether transfer costs 21,000 gas. A complex DeFi interaction might cost 200,000–500,000. This means a block can hold anywhere from a handful of complex contract calls to thousands of simple transfers — but not unlimited transactions.

The base fee adjusts dynamically based on block fullness. If a block is more than 50% full, the base fee rises. If it's less than 50%, it falls. This creates a self-regulating fee market, though during high-demand periods (NFT mints, market volatility) fees can spike dramatically in short windows.

Finality — the point after which a transaction can't be reversed — is probabilistic on short time horizons. Under Ethereum's current consensus, economic finality is reached after roughly 12.8 minutes (~2 epochs).

What's Changing

Two structural shifts are reshaping Ethereum's transaction layer.

Account abstraction (ERC-4337): Currently only EOAs can initiate transactions. Account abstraction would allow contract accounts to initiate their own transactions, enabling features like transaction batching, gas payment in any token, social recovery, and more programmable signing logic. ERC-4337 implements this as an overlay on the current system; future protocol changes could make it native.

EIP-4844 (Proto-Danksharding): Introduced in 2024, this added a new transaction type carrying blobs — temporary data stores that Layer 2 rollups use to post their transaction data to Ethereum cheaply. Blobs don't execute in the EVM; they're available for a short window and then pruned. This is infrastructure for Ethereum's long-term scaling roadmap, where most user-facing transactions will happen on rollups that periodically settle to the base layer.

What Would Confirm This Direction

• Continued growth in rollup transaction volume as blobs make L2 data posting cheaper
• ERC-4337 adoption metrics — bundlers, paymasters, smart accounts as a share of active addresses
• Account abstraction proposals reaching mainnet consideration at the protocol level
• Block gas limit increases without corresponding fee spikes (would indicate efficiency gains)

What Would Break or Invalidate This Direction

• A critical vulnerability in the EVM execution environment requiring fundamental redesign
• Account abstraction proving too complex for mainstream wallet developers, leaving EOA dominance intact
• A competing L1 achieving comparable security with significantly lower execution costs
• A rollback of EIP-1559's fee burning mechanism in response to validator economics pressure

Timing Perspective

Now: The current transaction model — EIP-1559 fees, proof-of-stake validators, EVM execution — is stable and battle-tested at scale. EIP-4844 blobs are live.

Next (1–2 years): Account abstraction matures. Rollup data throughput increases as Ethereum's blob capacity expands toward full Danksharding.

Later (3+ years): Statelessness and Verkle trees change how nodes store and verify state, potentially reducing the cost of running a full node.

What This Doesn't Cover

This post explains the mechanics of how Ethereum transactions function at the protocol level. It doesn't constitute advice on gas optimization strategies, doesn't cover Ethereum's investment profile or price dynamics, and doesn't address the security considerations of specific smart contracts or DeFi protocols. Understanding the mechanism is a prerequisite for evaluating those questions — but it's not a substitute for them.