Skip to content

Account-Based State Model

Understand Ethereum's account-based model through account fields, state and storage roots, ordered transaction execution, gas and reverts, token storage, EIP-7702 delegation, access lists, traces, and finality.

Updated

For educational purposes only; not investment advice. Investing may result in loss.

Direct answer

An account-based model represents the execution state as data keyed by address. In Ethereum’s execution layer, an account leaf contains [nonce, balance, storageRoot, codeHash]. The native balance is denominated in wei; contract data lives behind that account’s storageRoot; and the block’s post-execution stateRoot commits to the resulting world state. A wallet, RPC provider, or explorer reads and interprets this state but does not store the canonical balance on the user’s behalf.

ERC-20 balances, allowances, lending debt, and collateral are normally values in contract storage, not extra fields in the holder’s protocol account. Likewise, an explorer’s “internal transaction” is usually a traced EVM message call, not a separately signed Ethereum transaction with its own transaction hash and sender nonce.

The traditional externally owned account (EOA) versus contract-account distinction remains useful, but “an EOA always has empty code” is no longer absolute on a chain that activates EIP-7702. An EOA can carry a delegation indicator 0xef0100 || address and execute the delegate’s code while retaining EOA transaction authority. Classification must therefore use the chain rules and actual account code, not an old UI label.

Seven-step state-transition audit

  1. Pin the observation: network, chainId, fork rules, block number and hash, timestamp, and block tag such as pending, latest, safe, or finalized. Near-head state can change after a reorganization; never merge facts from different blocks without labeling them.
  2. Read the protocol account fields: nonce, native balance, storageRoot, and codeHash. If code is an EIP-7702 delegation indicator, resolve the delegate under that fork’s rules. For proxies and delegated accounts, separately identify implementation code, upgrade control, and storage layout.
  3. Locate application balances. ETH changes the native balance; an ERC-20 balance usually changes a mapping in the token contract’s storage; allowances, debt, collateral, and rewards may occupy other contracts and slots. Token decimals and logs are interpretation aids, not additional account-leaf fields.
  4. Decode and precheck the top-level transaction: type, chain domain, signature, sender nonce, recipient or creation, value, input, gas limit, fee caps, and optional access list or EIP-7702 authorizations. The sender must cover the value and maximum fee commitment. A rejected transaction is not included and consumes no on-chain gas.
  5. Execute transactions in block order from the prior state. The EVM processes nested message calls and contract creation frames, each with its own caller, callee, value, calldata, gas, and return status. Shared reads and writes make results order-dependent. An EIP-2930 access list prewarms named accounts and slots and changes gas accounting; it neither prohibits undeclared access nor proves safe parallelism.
  6. Apply commit and rollback boundaries. A successful frame commits its state and logs unless a parent later reverts. REVERT rolls back that failed frame’s writes, value transfers, and logs while returning unused gas; an outer contract can catch a child failure and still succeed. An included top-level failure has receipt status = 0, but the sender transaction nonce increments and consumed gas is paid. EIP-7702 authorization processing has its own persistence rules even if later execution reverts.
  7. Reconcile the post-state. Match native and token balance deltas, storage changes, receipt status, gas used, effective gas price, logs, and provider traces to the block’s committed roots. Treat traces as provider reconstructions rather than separate consensus transactions. Wait for the required finality, then handle replacements, reorgs, indexer revisions, bridges, rollups, and accounting reversals explicitly.

Four worked examples

  • EIP-1559 ETH transfer. A starts with 5 ETH and nonce 12; B starts with 1 ETH. A sends 1 ETH using 21,000 gas, with base fee 20 gwei, priority cap 3 gwei, and max fee 40 gwei. Effective gas price is min(40, 20 + 3) = 23 gwei; total fee is 21,000 × 23 gwei = 0.000483 ETH, of which 0.000420 ETH is base-fee burn and 0.000063 ETH is priority fee. Maximum signing-time requirement is 1 ETH + 21,000 × 40 gwei = 1.000840 ETH. Final balances are A 3.999517 ETH, B 2 ETH, and A’s nonce is 13.
  • Included transaction that reverts. A starts with 2 ETH and nonce 7. A calls a contract with 0.50 ETH; the top-level execution reverts after 80,000 gas at an effective 25 gwei, so fee is 80,000 × 25 gwei = 0.002000 ETH. Contract storage writes, logs, and the 0.50 ETH transfer roll back, while A ends with 1.998000 ETH, nonce 8, and receipt status = 0. A caught child-call failure could instead coexist with outer receipt status = 1.
  • Token balance is contract storage. A token contract records Alice 1,000 units and Bob 200 units. A successful transfer of 250 units produces Alice 750 units and Bob 450 units, preserving 1,200 units. If Alice’s top-level transaction uses 60,000 gas × 20 gwei = 0.001200 ETH, her native ETH balance separately falls by that fee. The token account’s storageRoot and the global stateRoot change; the token principal never became Alice’s native account balance.
  • EIP-7702 persistence boundary. A sponsor submits a set-code transaction containing an authorization from account A at nonce 5 to delegate to implementation D. The protocol writes the 23-byte indicator 0xef0100 || 20-byte address and increments A’s authority nonce to 6. If later execution in that outer transaction reverts, the already processed delegation indicator and authorization nonce remain. This is not the same rollback boundary as ordinary EVM storage written by the failed call.

Risks and controls

  • Reading the wrong chain, fork, block hash, or block tag produces an internally inconsistent state snapshot.
  • A stale or untrusted RPC can omit, lag, or misreport head state.
  • Pending nonce races, gaps, and replacements can invalidate queued assumptions.
  • A wallet’s “cancel” is usually a replacement transaction, not a protocol-level deletion.
  • Insufficient balance for value plus maximum fees prevents transaction inclusion.
  • Base-fee movement or fee-cap errors can delay inclusion or change cost.
  • EIP-7702 code can cause an EOA to be misclassified by old account heuristics.
  • A malicious delegate, initialization flaw, or authorization replay can compromise an EIP-7702 account.
  • Proxy upgrades and delegate calls can make code and storage interpretation change over time.
  • Key, signature-domain, or chain-ID errors can authorize theft or replay.
  • Reentrancy and shared-state ordering can alter balances within one execution.
  • A child call can fail and be caught while the outer transaction still reports success.
  • A top-level revert or out-of-gas failure still consumes gas and increments the sender nonce.
  • Token decimals, fee-on-transfer behavior, rebasing, and hooks can invalidate simple balance arithmetic.
  • Allowances, debt, collateral, and rewards can be omitted when only wallet balances are reconciled.
  • Logs can be absent, reverted, misleading, or insufficient to prove final state.
  • Explorer “internal transactions” and provider traces can differ because they are reconstructed views.
  • An access list can be incomplete, duplicated, or uneconomic and does not lock a read/write set.
  • Shared-state ordering, priority fees, and MEV can change execution outcomes.
  • Reorgs, pruning, unavailable proofs, L2 system transitions, and bridge finality can reverse or obscure accounting.

Common misconceptions

  • “The wallet stores the on-chain balance.” The wallet holds credentials and presents state obtained from the network.
  • “Every address is permanently either a code-free EOA or an ordinary contract.” EIP-7702 delegation changes that code heuristic.
  • “Every displayed transfer is a separate Ethereum transaction.” Token events and internal message-call traces are not top-level signed transactions.
  • “A failed transaction changes nothing and costs nothing.” Included failure can consume gas and advance the sender nonce.
  • “The account model or an access list guarantees faster parallel execution than UTXO.” Performance and conflicts depend on the full protocol and workload.

Sources

Navigation

Search the wiki...