Accounts, Transactions, Gas and Fees

Introduction

Ethereum is a state-transition system. The blockchain records a shared state containing accounts, contract storage, balances, code, and other protocol data. A transaction is an authenticated request that asks the Ethereum Virtual Machine (EVM) to change that state. Understanding accounts, keys, nonces, transaction execution, gas, and fees is essential for developing, testing, and operating Solidity applications.

A user may see only a wallet address and a fee estimate, but the protocol processes several distinct objects: a signed transaction, an execution attempt, a receipt, state changes, and event logs. These objects must not be confused. For example, a transaction can be included in a block and receive a receipt even though its contract execution failed and its state changes were reverted.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish externally owned accounts from contract accounts;
• explain private keys, public keys, addresses, and nonces;
• describe the transaction lifecycle from construction to finality;
• interpret transaction fields, receipts, logs, and explorer data;
• calculate gas costs under Ethereum’s current fee market;
• explain priority fees, base fees, gas limits, and transaction failure;
• estimate transaction costs and identify operational risks.

1. Ethereum Accounts

An account is an address-associated entity represented in Ethereum’s global state. The two traditional account categories are externally owned accounts (EOAs) and contract accounts.

1.1 Externally Owned Accounts

An EOA is controlled by a cryptographic private key. The private key is used to create a digital signature over a transaction. Nodes verify the signature and recover or derive the corresponding public key and address. The private key is not stored on the blockchain and must never be disclosed.

A wallet is not the account itself. It is software or hardware that manages keys and constructs signed messages. A single wallet may manage many accounts, while a multisignature wallet may represent a contract account controlled by several EOAs.

Ethereum commonly uses elliptic-curve cryptography based on secp256k1. An address is represented as 20 bytes, usually displayed as a hexadecimal string beginning with 0x. In the conventional derivation, the address is the rightmost 20 bytes of the Keccak-256 hash of the public key (excluding the public-key format prefix). The address is therefore an identifier, not a secret.

Checksummed hexadecimal addresses use capitalization to help detect typing errors. A checksum does not prove that an address is trustworthy; it only provides limited error detection.

1.2 Contract Accounts

A contract account contains bytecode. Its behavior is determined by that bytecode, the EVM execution environment, and the data supplied in a call or transaction. Contract accounts can hold Ether and tokens, maintain storage, emit events, and call other accounts.

A contract account does not spontaneously initiate a transaction. An EOA, another contract during execution, or a protocol mechanism must begin the execution path. When a contract calls another contract, the call occurs within the same transaction and shares the transaction’s execution context and gas budget.

Contract creation assigns an address to the new contract. Traditionally, the address depends on the creator address and creator nonce; deterministic deployment mechanisms such as CREATE2 use a different construction involving the creator, a salt, and the initialization code hash. Developers should therefore use the deployment mechanism’s documented address formula rather than assume that every contract address is calculated identically.

2. Keys, Addresses, and Nonces

2.1 Key Security

A private key is a high-value credential. Anyone possessing it can generally sign transactions and transfer the account’s assets. Seed phrases, hardware-wallet backups, and encrypted key files require equivalent protection. Private keys should not be placed in source code, browser storage, public repositories, chat messages, or ordinary application logs.

Key management is also an operational design problem. Production systems should consider hardware security modules, hardware wallets, multisignature approval, transaction simulation, role separation, spending limits, backups, and recovery procedures.

2.2 Nonces

For an EOA, the nonce is a sequential counter associated with transactions sent from that account. A valid transaction normally uses the next executable nonce. If a transaction with nonce 12 is pending, a later transaction with nonce 13 cannot normally be executed first.

The nonce prevents replay of an identical signed transaction on the same chain and imposes ordering for transactions from one EOA. It does not globally order all transactions in a block. Transactions from different senders may be arranged according to block-building and fee-selection policies.

A replacement transaction generally uses the same nonce as the pending transaction and offers a sufficiently different fee so that nodes and block builders prefer it. A replacement does not create an additional state transition; it competes to occupy the same nonce position.

For contract accounts, the protocol also maintains a nonce, but it is not used in the same user-facing manner as an EOA nonce. It is principally associated with contract creation operations. Smart-contract developers must not assume that an address is an EOA merely because it can receive Ether.

3. Transactions and Their Lifecycle

A transaction may transfer Ether, deploy a contract, or call a contract function. A typical EIP-1559 transaction contains fields such as:

• chainId: identifies the intended network and helps prevent cross-chain replay;
• nonce: the sender’s transaction sequence number;
• to: recipient address, or empty for contract creation;
• value: Ether transferred in wei;
• data: calldata or contract creation initialization code;
• gasLimit: maximum gas the sender authorizes for execution;
• maxFeePerGas: maximum total fee per unit of gas;
• maxPriorityFeePerGas: maximum tip per unit of gas;
• signature: cryptographic proof authorizing the transaction.

Wei is the smallest commonly used Ether denomination. One Ether equals 10¹⁸ wei. Gas prices are usually expressed in gwei, where one gwei equals 10⁹ wei.

3.1 Lifecycle Stages

1. Construction: A wallet or application selects the chain, nonce, destination, value, calldata, gas limit, and fee parameters.
2. Signing: The sender signs the transaction with the private key. The signature authenticates the transaction but does not guarantee its success.
3. Broadcast: The signed transaction is sent to an Ethereum node and propagated through the peer-to-peer network.
4. Mempool handling: Nodes check basic validity and may retain the transaction in their local mempools. Mempools are local, not a single globally synchronized queue.
5. Inclusion: A block proposer or builder selects transactions and places them in a block, subject to validity, ordering, and block resource constraints.
6. Execution: Every validating node executes the block’s transactions according to the EVM rules.
7. Receipt creation: The protocol records execution metadata, including status, gas used, logs, and the block location.
8. Confirmation and finality: Additional blocks reduce practical reorganization risk. Under Ethereum’s proof-of-stake protocol, justified and finalized checkpoints provide stronger finality than a mere first confirmation.

A transaction hash identifies a signed transaction. It is not a password and should not be treated as proof that execution succeeded. The receipt and the resulting state must also be inspected.

4. Calls, State Changes, Receipts, and Logs

A read-only JSON-RPC call, often made with eth_call, executes contract logic against a selected state without publishing a transaction. It normally consumes no user-paid on-chain gas because it does not change consensus state. It is useful for simulation but cannot prove that a later transaction will succeed: state, ordering, gas, and permissions may change.

A mined transaction produces a receipt. Important receipt fields include:

A receipt is not the complete state transition. To understand what happened, inspect decoded calldata, internal calls or traces, token-transfer events, balance changes, and contract storage where appropriate.

Events and Logs

Solidity events compile to EVM logs. An event may contain indexed parameters, called topics, and non-indexed data. Indexed values are searchable by clients and explorers; non-indexed values are ABI-encoded in the data field. The first topic commonly contains the hash of the event signature, except for anonymous events.

Events are an efficient communication mechanism for off-chain applications, but they are not a substitute for contract state. A contract should not rely on an event as its authoritative internal record. Logs produced by a reverted transaction are not retained as successful application history.

5. Gas and the EVM Resource Model

Gas is a unit of computational work and resource consumption. It protects the network from infinite loops and denial-of-service attacks and allows different operations to be priced according to protocol-defined resource costs. Gas is not itself Ether; Ether is used to pay for gas.

A transaction has a gas limit, while execution consumes gas. The sender authorizes up to the limit, but under ordinary EIP-1559 accounting the sender pays for the gas actually used, not automatically for the entire limit. Unused gas is not charged as execution cost and is returned in the accounting sense to the sender’s balance.

The general fee identity is:

Here, gas used is measured in gas units and the effective gas price is measured in wei per gas unit, producing wei. For an EIP-1559 transaction:

The priority fee paid cannot exceed the transaction’s specified maximum priority fee, and the total effective price cannot exceed maxFeePerGas. A useful expression is:

These expressions assume the transaction is included under EIP-1559 rules and that maxFeePerGas is at least the applicable base fee. The protocol burns the base-fee component. The priority-fee component is paid to the validator or block proposer under the protocol’s accounting rules. Exact explorer displays may separately show burned fees and tips.

For a transaction using G gas units, base fee B wei/gas, and priority fee paid P wei/gas:

If B = 30 gwei, P = 2 gwei, and G = 50,000 gas, then:

The sender must also have sufficient balance to cover the Ether value transferred and the maximum authorized fee exposure. A transaction with maxFeePerGas = 50 gwei and a 50,000-gas limit may require temporary balance capacity of up to 0.0025 ETH for gas, even if the eventual effective price is lower.

5.1 Gas Limit and Out-of-Gas Failure

A gas limit is not a prediction of gas usage; it is a ceiling. If it is too low, execution may run out of gas and revert. Gas already consumed is not generally refunded merely because the transaction failed. If the limit is excessively high, it does not automatically increase the fee, but it can create balance and replacement constraints.

Some operations have a fixed or predictable intrinsic cost, while contract execution adds costs for calldata, storage access, storage modification, memory expansion, hashing, logs, and external calls. Gas schedules can change through protocol upgrades. Therefore, exact estimates should be obtained using the target network, transaction data, current node simulation, and a prudent margin.

Gas refunds for certain state-clearing operations have existed in modified and limited forms, but developers should not build financial assumptions around large refunds. Current protocol rules constrain refunds and may change through upgrades.

6. Fee Markets and Practical Estimation

Under EIP-1559, the base fee is protocol-determined and adjusts in response to block gas usage relative to a target. It is not a negotiable payment to a validator. A transaction must offer a maximum fee that can cover the current base fee at inclusion time. The priority fee expresses the sender’s willingness to reward timely inclusion.

A practical estimation workflow is:

1. construct the exact calldata and transaction parameters;
2. simulate with eth_estimateGas against a recent state;
3. add a justified safety margin, avoiding arbitrary excessive limits;
4. obtain current fee suggestions from a reliable node or fee estimator;
5. select a maxFeePerGas that covers plausible base-fee movement and a maxPriorityFeePerGas appropriate to urgency;
6. check sender balance for value plus potential maximum gas exposure;
7. submit, then inspect the receipt and decoded events.

Suppose simulation estimates 82,000 gas, and the application uses a 10% operational margin:

This is an operational estimate, not a protocol formula. The margin must reflect uncertainty and should be validated by testing. If actual gas used is 83,500, the unused 6,700 gas is not charged as execution gas.

A failed simulation may indicate invalid calldata, insufficient permissions, a paused contract, an unfavorable price, or a state-dependent condition. Increasing the gas limit does not fix a logical revert. Conversely, a simulation that succeeds cannot guarantee later success because another transaction may change the state first.

7. Transaction Failure and Reversion

Failure has several forms:

• Rejected before inclusion: invalid signature, incorrect nonce, insufficient balance, fee below requirements, or malformed transaction.
• Dropped or replaced: a node removes a pending transaction, or another transaction with the same nonce supersedes it.
• Included but reverted: contract execution encounters a revert, failed assertion, failed call, or out-of-gas condition.
• Successful execution with an undesirable outcome: the transaction follows valid code but produces an economic or business result the user did not intend.

A reverted transaction normally rolls back state changes made during that transaction, including nested calls. However, the sender still pays for gas consumed up to failure. The transaction’s inclusion and receipt remain part of the blockchain history.

Solidity’s require, revert, and custom errors provide controlled failure. Custom errors are often more gas-efficient than long revert strings and improve structured error handling. Developers should distinguish error reporting from security: exposing an error reason does not make an authorization check correct.

8. Reading a Blockchain Explorer

When investigating a transaction, follow a systematic sequence:

1. Network and hash: Confirm that the explorer is showing the intended chain and transaction hash.
2. Status: Check success or failure and the block number.
3. From and to: Identify the signer and destination. A blank or creation destination may indicate deployment.
4. Value and calldata: Determine Ether transfer and decode the function selector and arguments.
5. Gas fields: Compare gas limit, gas used, base fee, priority fee, effective gas price, and total fee.
6. Nonce: Compare with neighboring transactions from the sender to identify ordering or replacement.
7. Logs: Decode events and verify token addresses, amounts, indexed participants, and event order.
8. Internal calls or traces: Where available, inspect nested calls, transfers, and the point of failure.
9. State outcome: Verify balances, allowances, ownership, and application-specific state rather than relying only on displayed labels.

Explorer interfaces are presentation layers. Their token symbols, USD values, labels, and decoded function names may be incomplete or misleading. Contract verification improves readability but does not guarantee that the verified code is safe or that a particular deployment is legitimate.

9. Applied Case: A Failed Token Purchase

The following is an illustrative case, not a report of a particular real deployment.

Background

A user attempts to purchase tokens from a crowdsale contract. The wallet displays a transaction with a 120,000-gas limit, a maximum fee of 60 gwei, and a 2 gwei maximum priority fee. The transaction is later marked “failed” by an explorer.

Problem

The user believes that no fee should have been charged because the purchase failed. They also assume that increasing the gas limit would have guaranteed success.

Analysis

The receipt shows:

• status: failure;
• gas used: 91,000;
• base fee: 28 gwei;
• priority fee paid: 2 gwei;
• effective gas price: 30 gwei.

The fee is:

The transaction failed after the contract’s price-limit check detected that the supplied maximum acceptable price was below the current sale price. Since the failure occurred after substantial execution, gas was consumed. The token transfer and purchase state changes were reverted, but the fee was not returned.

Approach and Solution

The application should simulate the exact transaction immediately before submission, display the price and slippage condition clearly, and use a deadline and user-approved maximum. The front end should distinguish a failed receipt from a pending transaction and should not claim that tokens were purchased merely because a hash exists. The user should inspect the receipt, decoded revert reason where available, and resulting balances.

Outcome

On a later attempt, the user accepts an updated price and the simulation succeeds. The resulting receipt has status success, gas used of 88,000, and the logs show the expected purchase and token-transfer events.

Learning Points

• A transaction hash is not evidence of success.
• Failed execution can still consume gas.
• More gas cannot repair a failed business-condition check.
• Simulation, clear slippage controls, and receipt verification are essential.

10. Professional, Governance, and Security Considerations

Fee estimation affects user experience, inclusion speed, treasury expenditure, and operational reliability. Applications should avoid hiding fees, should display units clearly, and should not describe a gas limit as an amount that will necessarily be spent.

Common security risks include signing on the wrong chain, sending assets to an incorrect address, approving unlimited token allowances, accepting malicious calldata, exposing private keys, and trusting unverified contract interfaces. Address poisoning and phishing exploit users’ visual assumptions; applications should obtain destinations from trusted records and use checksummed display and independent confirmation.

Organizations operating automated signers should implement nonce coordination. Multiple workers submitting transactions from one EOA can accidentally reuse a nonce or create gaps. A transaction manager should reserve nonces, track replacements, reconcile receipts, and handle dropped or reorged transactions.

Regulatory and governance obligations may apply to custody, financial products, consumer disclosures, sanctions screening, record retention, and incident response. Blockchain transparency does not eliminate privacy obligations. Addresses are pseudonymous identifiers, and transaction graphs can sometimes be linked to real-world identities. Logs and explorer data should therefore be handled with appropriate privacy and access controls.

11. Contemporary Developments

Ethereum transaction processing continues to evolve. Typed transaction envelopes support different fee and access-list behavior. Layer-2 networks generally execute transactions in a separate environment and publish data or commitments to Ethereum; their user fees may include both execution and data-publication components. Consequently, an explorer’s “gas fee” on a layer 2 should be interpreted using that network’s own accounting model.

Account abstraction systems seek to provide programmable authorization, sponsored fees, batched actions, and recovery mechanisms. These systems may introduce user operations and paymasters that are not identical to traditional EOA transactions. Nevertheless, the underlying principles remain: authenticate authorization, account for resource consumption, verify execution results, and protect against replay and malicious approval.

Artificial intelligence can assist with calldata decoding, anomaly detection, fee forecasting, and transaction simulation. It must not be treated as an authority for signing or approving transactions. Human-controlled policy limits, deterministic validation, and independent contract checks remain necessary.

Best-Practice Checklist

• Confirm the chain ID and destination address.
• Protect private keys and separate development from production credentials.
• Coordinate nonces for automated senders.
• Simulate the exact calldata and state-dependent conditions.
• Set a justified gas limit and distinguish it from gas used.
• Choose fee parameters using current network conditions.
• Ensure balance covers value and possible maximum gas exposure.
• Verify receipt status, logs, and resulting state.
• Treat explorer labels and token metadata as aids, not proof.
• Test failure paths, replacement logic, reorg handling, and recovery procedures.

Chapter Summary

Ethereum accounts are either externally owned accounts controlled by private-key signatures or contract accounts controlled by code and protocol execution. Addresses identify accounts, while private keys authorize actions; neither should be confused with a wallet application. Nonces provide replay protection and ordering for transactions from an EOA.

A transaction is constructed, signed, propagated, included, executed, and represented by a receipt. Inclusion does not imply success. Receipts report status, gas used, effective gas price, and logs, while traces and state inspection may be needed to understand nested calls and final outcomes.

Gas measures EVM resource consumption. Under EIP-1559, the effective gas price combines the base fee and the priority fee paid. The fundamental cost relationship is gas used multiplied by effective gas price. A gas limit caps authorized execution but does not determine actual consumption. Failed transactions may consume gas because execution resources were used before reversion.

Professional Ethereum work requires simulation, careful nonce management, secure key custody, transparent fee communication, receipt verification, and critical interpretation of explorer data. Layer-2 systems, typed transactions, account abstraction, and automated analysis are extending the model, but they do not remove the need for sound authorization and resource accounting.

Key Terms

Account: An address-associated entity in Ethereum state.

Externally owned account (EOA): An account controlled by a private-key signature.

Contract account: An account containing EVM bytecode and governed by that code.

Private key: Secret cryptographic material used to authorize signatures.

Public key: Cryptographic counterpart from which an address is conventionally derived.

Address: A 20-byte identifier used to designate an account or contract.

Nonce: A sequence value used to prevent replay and order transactions from an EOA.

Transaction: A signed request to transfer value, deploy code, or invoke execution.

Calldata: Input data supplied to a contract call.

Receipt: Post-execution metadata associated with an included transaction.

Log: An EVM event record emitted during execution.

Gas: A unit measuring computational and other EVM resource consumption.

Gas limit: Maximum gas authorized for a transaction.

Gas used: Amount of gas actually consumed.

Base fee: Protocol-determined fee component burned under EIP-1559.

Priority fee: Fee component offered to encourage timely inclusion.

Effective gas price: Actual per-unit gas price paid for an included transaction.

Revert: An execution failure that rolls back transaction state changes.

Mempool: A node’s collection of valid-looking pending transactions.

Finality: Protocol assurance that a block or state will not ordinarily be reverted.

Review Questions

Short Answer Questions

1. What is the principal difference between an EOA and a contract account?
2. Why is a nonce important for an EOA?
3. What information does a transaction receipt provide?
4. Distinguish gas used from gas limit.
5. Why can a failed transaction still incur a fee?

Long Answer Questions

1. Explain the complete lifecycle of an Ethereum transaction from construction to finality.
2. Describe EIP-1559 fee accounting, including base fee, priority fee, effective gas price, and maximum fee.
3. Explain how events and logs support off-chain applications and why they cannot replace contract state.
4. Develop a professional workflow for estimating and submitting a contract transaction.
5. Discuss the security and governance implications of private-key custody, nonce management, and explorer interpretation.

Analytical / Application Questions

1. A transaction uses 75,000 gas. The base fee is 24 gwei and the priority fee paid is 1.5 gwei. Calculate the transaction fee in ETH and explain each unit conversion.
2. An explorer reports status failure, gas used of 64,000, and an effective gas price of 35 gwei. The user claims that no fee should have been charged. Assess the claim and calculate the fee.
3. A transaction simulation succeeds, but the submitted transaction reverts because another transaction changes the contract state first. Explain why this occurred and propose two design or operational measures to reduce the risk.

Multiple Choice Questions with Answers

Question 1

Which entity normally signs and initiates a standard Ethereum transaction?

A. An externally owned account

B. A contract account without an external trigger

C. A transaction receipt

D. An event log

Correct Answer: A. An externally owned account

Question 2

What is the primary purpose of an EOA nonce?

A. To encode the contract ABI

B. To prevent replay and sequence transactions from the sender

C. To calculate the base fee

D. To identify the validator who produced a block

Correct Answer: B. To prevent replay and sequence transactions from the sender

Question 3

Under EIP-1559, which fee component is generally burned?

A. The gas limit

B. The priority fee

C. The base fee

D. The transaction value

Correct Answer: C. The base fee

Question 4

A transaction uses 50,000 gas at an effective gas price of 32 gwei. What fee is paid?

A. 0.00016 ETH

B. 0.0016 ETH

C. 0.016 ETH

D. 1.6 ETH

Correct Answer: B. 0.0016 ETH

Question 5

What does a successful eth_call primarily provide?

A. A mined state-changing transaction

B. A read-only simulation against a selected state

C. A guaranteed future transaction result

D. A validator signature

Correct Answer: B. A read-only simulation against a selected state

Question 6

What normally happens to state changes when a contract transaction reverts?

A. They are committed permanently

B. They are rolled back, although gas consumed is still charged

C. They are transferred to the next block

D. They are converted into event logs

Correct Answer: B. They are rolled back, although gas consumed is still charged

Question 7

Which receipt field indicates the actual amount of execution resource consumed?

A. gasUsed

B. chainId

C. nonce

D. maxFeePerGas

Correct Answer: A. gasUsed

Question 8

What is the best interpretation of a transaction hash by itself?

A. Proof that the contract call succeeded

B. A private key for recovering funds

C. An identifier for the signed transaction

D. A guarantee of finality

Correct Answer: C. An identifier for the signed transaction

Question 9

If a transaction has a gas limit that is too low, what may occur?

A. The base fee becomes zero

B. Execution may run out of gas and revert

C. The nonce is automatically cancelled

D. The transaction becomes a read-only call

Correct Answer: B. Execution may run out of gas and revert

Question 10

Why should a developer inspect logs and resulting state after a transaction is mined?

A. Because the transaction hash does not fully establish what occurred

B. Because logs determine the sender’s private key

C. Because gas limits are stored only in event topics

D. Because receipts never contain status information

Correct Answer: A. Because the transaction hash does not fully establish what occurred