Anatomy of an Ethereum Transaction

Anatomy of an Ethereum Transaction

Intermediate
Smart Contracts
• ~12 min read
• Updated: 08/08/2025

1) Transaction basics (types & lifecycle)

A transaction is a signed instruction from an account. It can transfer ETH, deploy a contract, or call a contract function. Once broadcast, it enters the mempool, gets selected and ordered into a block, and becomes part of the chain.

Typed transactions:

  • Legacy (type 0x00): gasPrice only (pre-EIP-1559).
  • Access list (0x01, EIP-2930): legacy fees + access list hint.
  • EIP-1559 (0x02): maxFeePerGas, maxPriorityFeePerGas, dynamic base fee burn.

2) Nonce

The nonce is the sender’s outbound transaction count. It enforces ordering and uniqueness. If your last confirmed nonce is 12, the next valid tx must use 13.

  • Replacement: A pending tx can be replaced by sending another tx with the same nonce and a higher effective fee.
  • Stuck queue: A low-fee tx with nonce n blocks later nonces until it’s mined or replaced.

3) Gas limit, base fee & tips (EIP-1559)

Gas limit is the max work you’re willing to pay for. With EIP-1559, you specify:

  • maxFeePerGas — cap you’ll pay per gas (base fee + tip).
  • maxPriorityFeePerGas — your tip to the block proposer.
Effective fee paid
effectiveGasPrice = min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas)
totalFee = gasUsed × effectiveGasPrice
Base fee is burned; the tip goes to the proposer/builder.
  • Intrinsic gas: Every tx has a base cost (e.g., 21,000 for a simple ETH transfer).
  • Refunds: Clearing storage can yield partial gas refunds (reduced by EIP-3529).
  • Out of gas: If execution exceeds the gas limit, the tx reverts but you still pay for the used gas.

4) Recipient (to) & value

  • to: An EOA or a contract. For contract creation, this field is empty and the calldata carries init code.
  • value: ETH amount in wei (1 ETH = 1018 wei). ERC-20 transfers are not ETH; they’re function calls in calldata.
  • CREATE2: Contracts can be deployed at a deterministic address derived from deployer, salt, and bytecode.

5) Calldata & ABI encoding

Calldata is read-only bytes passed to a contract. ABI-encoded calls begin with a 4-byte function selector (keccak-256 of the signature), followed by encoded arguments.

Example: ERC-20 transfer(address,uint256)
selector = keccak256("transfer(address,uint256)")[0:4]
calldata = selector || padLeft(recipient, 32) || padLeft(amount, 32)
  • Static vs dynamic types: Static (e.g., uint256, address) inline; dynamic (bytes, string, arrays) use offsets and tail data.
  • receive()/fallback(): Contracts may accept plain ETH (no calldata) or handle unknown selectors.

6) Signatures (v,r,s) & chain ID

Transactions are authorized via ECDSA over secp256k1. The signature splits into v (recovery id / parity), r, and s.

  • EIP-155: Includes chainId in the signed payload to prevent cross-chain replays.
  • EIP-2: Enforces low-s values; malformed signatures are rejected.
  • Typed txs: With 0x02 (EIP-1559), v is simply the parity (0/1); the chainId is a field in the payload.

7) Receipts, logs & blooms

After inclusion, you get a receipt with:

  • status: 1 (success) or 0 (revert)
  • gasUsed and cumulativeGasUsed
  • effectiveGasPrice (EIP-1559)
  • contractAddress (if creation)
  • logs: events with topics & data; logsBloom accelerates filtering
Revert data: Standard error encoding includes Error(string), Panic(uint256), or custom errors (cheaper). Good wallets surface these messages.

8) Lifecycle: mempool, ordering & cancellation

  • Broadcast → mempool: Validators/builders see pending txs. Public mempools enable MEV (reordering, sandwiching).
  • Private order flow: Some RPCs route privately to reduce MEV risk for sensitive swaps.
  • Cancel/replace: Send a new tx with the same nonce and higher effective fee (often a 10–15% bump) to override a stuck tx.
  • Confirmations: More blocks on top = higher finality confidence (especially on L1s without instant finality).

9) Common failures & debugging tips

  • Out of gas: Raise gas limit; simulate the call (many wallets/dApps support simulation).
  • Revert (require failed): Check the revert string/custom error; verify inputs, approvals, or slippage.
  • Nonce too low/high: Your local wallet is out of sync; fetch the on-chain nonce and resend.
  • Insufficient funds for gas: Top up ETH on the sending chain/network; ERC-20s can’t pay gas.
  • Wrong chain: Match RPC/network to the contract’s chain ID; addresses differ across chains.
  • Approval issues (ERC-20): Ensure approve(spender, amount) has been mined before transferFrom.

10) Further learning & resources

← ERC-20 vs ERC-721 vs ERC-1155
DeFi & Staking Overview →