Ethereum is best understood as a shared state machine rather than simply a payment network. ETH is its native asset, transactions request changes to its state, gas measures the computation required, and smart contracts define programmable rules that the Ethereum Virtual Machine executes. These components are tightly connected, but they are not interchangeable: ETH is not gas, a wallet is not an account, and a smart contract is not necessarily a legal contract.
A compact knowledge map and three reading routes
The central chain of ideas is: account and ETH → signed transaction → gas and fee market → EVM execution → smart-contract result → network confirmation → independent verification. Two adjacent branches matter in practice: token contracts explain why assets such as ERC-20 tokens differ from native ETH, while network selection explains why Ethereum Mainnet, layer 2 systems, and other EVM-compatible chains must not be treated as one interchangeable environment.
- Node 1 — ETH and accounts: what the native asset does, who can authorize transactions, and why a wallet is only an interface.
- Node 2 — Transactions: how a signed instruction transfers value or calls a contract.
- Node 3 — Gas: how Ethereum measures work and calculates transaction fees.
- Node 4 — Smart contracts and the EVM: how code changes blockchain state.
- Node 5 — Tokens and approvals: how contract-managed assets differ from ETH.
- Node 6 — Networks and layer 2: where a transaction actually executes and settles.
- Node 7 — Verification: what to inspect before signing and after broadcasting.
Route 1: Understand Ethereum quickly
Read Nodes 1, 2, 3, and 4 in that order. The result should be a working mental model: an account authorizes a transaction, the transaction pays for measured computation in ETH, and the EVM executes either a transfer or contract code.
Route 2: Prepare for a practical transaction
Read Nodes 1, 3, 5, 6, and 7. This route focuses on choosing the correct asset and network, maintaining enough ETH for fees where required, interpreting wallet prompts, and verifying the result with a block explorer.
Route 3: Understand the technical mechanism
Read all seven nodes, including the expandable technical notes. The expected result is the ability to distinguish transaction fields, gas units, fee parameters, contract calls, token permissions, execution results, and finality without treating a wallet’s simplified interface as the protocol itself.
Node 1: ETH, accounts, keys, and wallets
Ether, represented by the ticker ETH, is Ethereum’s native asset. On Ethereum Mainnet it can be transferred directly, used to pay transaction fees, held by user-controlled accounts or contracts, and used within applications. Native ETH is not an ERC-20 token, even though wrapped representations such as WETH can expose an ERC-20-compatible interface. [1]
Ethereum distinguishes externally owned accounts from contract accounts. An externally owned account is controlled through private keys and can initiate transactions. A contract account contains code and responds when a transaction or another contract calls it. Both types can hold ETH and tokens, but a contract account does not have a private key that a person can use to sign ordinary transactions. [2]
A wallet is software or hardware that helps a user manage keys, display balances, build transactions, and send signed instructions to a network. It is not the account itself. Changing wallet applications does not inherently create a new onchain identity if the same keys or recovery mechanism are used. Conversely, anyone who obtains the private key or recovery phrase can generally exercise the corresponding account’s authority. [2]
This boundary matters when troubleshooting. A balance displayed incorrectly may be a wallet-interface or network-selection problem; it does not automatically mean that the blockchain balance has changed. The relevant checks are the account address, selected network, asset contract where applicable, and onchain records.
Node 2: A transaction is a signed request to change state
An Ethereum transaction is a cryptographically signed instruction. The simplest form transfers ETH between accounts. A transaction can also deploy a contract or send input data to an existing contract, causing one of its functions to execute. Validators include eligible transactions in blocks, and Ethereum nodes reproduce the resulting state changes according to the same protocol rules. [3]
A typical transaction identifies the sender and destination, includes a sequential nonce, may carry an ETH value and input data, and sets limits on gas consumption and fee payment. The signature proves that the account controlling the relevant private key authorized the instruction; it does not prove that the destination is trustworthy or that the requested action is economically sensible. [3]
That distinction explains why “confirmed” and “safe” are different judgments. Confirmation shows that the network processed a valid signed transaction. It cannot determine whether the user copied the intended address, selected the intended network, understood a token approval, or interacted with authentic contract code.
Technical view: state transitions and transaction order
The EVM can be modeled as a deterministic state-transition system: given a valid previous state and a valid ordered set of transactions, it produces a new state. That state includes account balances, contract code, and persistent contract storage. [4]
Each externally owned account uses a nonce to order its transactions and prevent the same signed transaction from being executed repeatedly. If multiple pending transactions from one account depend on sequential nonces, a delayed earlier transaction can also delay later ones. [2]
Node 3: Gas measures work; the gas fee pays for it
Gas is a unit of computational effort, not a separate cryptocurrency. EVM operations have gas costs, and the total gas used depends on what a transaction makes the network execute. On Ethereum Mainnet, the resulting fee is paid in ETH. This mechanism prices limited computation and helps protect the network from spam and programs that would otherwise consume unbounded resources. [5]
The basic relationship is:
transaction fee = gas used × effective fee per gas
A straightforward ETH transfer between ordinary accounts normally uses 21,000 gas units. A token transfer, swap, NFT operation, lending action, or contract deployment invokes contract code and can require substantially more. Complexity affects the number of gas units; network demand affects the price paid for each unit. These are separate variables. [5]
How the EIP-1559 fee components fit together
| Component | Meaning | What the user should understand |
|---|---|---|
| Gas limit | The maximum gas units the transaction is allowed to consume | It is a safety and execution limit, not necessarily the amount that will be used |
| Base fee | A protocol-calculated price per gas unit that changes with block utilization | It is burned rather than paid to the validator |
| Priority fee | An additional amount per gas unit intended to incentivize inclusion | It is commonly presented as a validator tip |
| Maximum fee per gas | The sender’s cap on the total price per gas unit | The cap is not automatically the final price paid |
Under EIP-1559, the base fee can rise or fall from one block to the next according to block usage. A transaction specifies a maximum total fee and may specify a maximum priority fee. The effective payment depends on the base fee in the block that includes the transaction and the applicable priority fee, subject to the sender’s cap. [6]
Fee quotations are dynamic. A value seen in an article, screenshot, or earlier wallet session is not a reliable quote for a new transaction. Check the wallet’s current estimate immediately before signing and confirm whether it refers to Ethereum Mainnet or another network. The amount charged by an exchange, bridge, or application may also contain service or protocol costs that are distinct from the blockchain gas fee.
What happens to unused gas and failed transactions?
A gas limit does not mean that the entire limit will always be consumed. Unused gas is not charged as executed computation. However, if contract execution starts and runs out of gas, the EVM reverts the attempted state changes while the gas spent on the performed work is still consumed. A transaction can therefore fail onchain and still produce a fee. [5]
A contract can also deliberately revert because its conditions were not satisfied—for example, a deadline passed or an application-specific requirement failed. The wallet’s estimate and simulation can help, but neither should be interpreted as a guarantee of success under every later state or market condition.
Node 4: Smart contracts turn transactions into programmable actions
A smart contract is code and data stored at an Ethereum address. A user typically interacts with it by signing a transaction whose destination is the contract address and whose input data identifies a function and its arguments. The EVM executes the compiled contract code, checks its conditions, and applies the permitted state changes. [7]
Consider a simplified token swap. The visible interface might show “swap token A for token B,” but the underlying process can involve several steps: granting a contract permission to spend token A, calling a swap function, checking minimum-output and deadline conditions, moving tokens between contracts, and recording new balances. Each state-changing step requires an authorized transaction and consumes gas.
Reading public contract data is different from changing it. A wallet or application can query a token balance or other read-only function without creating an onchain transaction. A write operation changes state, needs authorization, and normally incurs a fee. A read performed internally during an onchain contract execution still contributes to that transaction’s computation. [8]
The word “contract” can be misleading. Code can enforce conditions encoded in the program, but it does not automatically establish legal status, resolve ambiguous real-world obligations, guarantee correct economic design, or protect users from bugs. Rules and legal treatment also vary by country, so legal or tax questions require jurisdiction-specific sources rather than conclusions drawn from the software’s name.
Technical view: calls, storage, and composability
Contract execution can read and modify persistent storage, emit logs, transfer assets, and call other contracts. This ability for contracts to call one another supports composability: an application can combine token contracts, exchanges, lending systems, identity mechanisms, and other onchain components within one transaction. The same property expands the dependency surface because failure or malicious behavior in one called component can affect the complete operation. [4]
Contract code normally runs as deployed, and interactions are not casually reversible. Upgradeable systems may route calls through proxy contracts, so the address visible to a user may not contain the final implementation logic. When meaningful value is involved, verification may therefore require examining both the proxy and its current implementation rather than trusting a token symbol or interface label.
Node 5: ETH, ERC-20 tokens, transfers, and approvals are different objects
ETH belongs to the Ethereum protocol itself. An ERC-20 token is generally accounted for by a smart contract that maintains balances and implements standardized functions. The standard supports operations such as transferring tokens, reading balances, and authorizing another address to spend up to an allowed amount. [9]
This creates several distinctions that a wallet interface may compress into a single button:
- Sending ETH changes native ETH balances.
- Transferring an ERC-20 token calls the token contract and changes balances recorded in that contract.
- Approving a spender gives another address or contract permission to move tokens within the specified allowance.
- Using the approved application is a later contract interaction that may exercise that permission.
An approval is therefore not merely a harmless connection request. Large or unlimited allowances can remain active after the immediate operation finishes. Before signing, inspect the asset, spender, amount, and requested function; afterward, review allowances that are no longer needed. Ethereum’s security guidance specifically warns against blind signing, unnecessary unlimited spending permissions, fake applications, and requests for recovery phrases. [10]
Token names and ticker symbols are not unique security identifiers. The contract address and network identify the actual token contract. A fraudulent contract can reuse the visible name of a legitimate asset, so verification should use the contract address supplied by an authoritative project or service source and compare it with the explorer record.
Node 6: Mainnet, layer 2, and EVM compatibility do not mean the same network
Ethereum Mainnet is the primary production Ethereum blockchain. Other networks can use Ethereum-compatible account formats or execute EVM-compatible code without sharing Mainnet’s balances, history, consensus, or security model. The same account address may be usable on multiple networks, but its assets and transaction records do not automatically carry from one network to another. [11]
Layer 2 systems are designed to process activity outside Ethereum Mainnet while using Mainnet in some way for data, settlement, or security. Rollups batch activity and post relevant results or proofs to layer 1, but implementations differ. Sidechains and other EVM-compatible networks may instead operate with separate consensus and security assumptions. “Compatible with Ethereum” should not be read as “identical to Ethereum Mainnet.” [12]
Network selection is part of the asset definition in practice. “ETH on Mainnet,” “ETH on a particular layer 2,” and a bridged or wrapped representation can require different deposit support, withdrawal procedures, contract addresses, fee models, and confirmation policies. Sending through an unsupported network can result in delayed access or loss, even when the destination address has the familiar hexadecimal format.
Before transferring, obtain the destination’s supported network from the receiving service itself. Match the asset, network, and address; check whether a memo or other identifier is required; and consider a small test transfer when the recipient supports that approach. Never infer network compatibility from the address format alone.
Node 7: A verification procedure before and after signing
The wallet confirmation screen is the final point at which an ordinary user can stop an unwanted transaction. Treat it as a technical instruction sheet, not as a routine pop-up.
Before signing
- Confirm the network. Identify whether the transaction is on Ethereum Mainnet, a named layer 2, or another EVM-compatible chain.
- Confirm the action. Distinguish an ETH transfer, token transfer, approval, contract call, bridge deposit, or contract deployment.
- Check the destination. Compare the complete address through a trusted channel rather than relying only on its first and last characters.
- Review value and permissions. Inspect both the ETH value and any token allowance. A transaction displaying zero ETH may still authorize token spending.
- Review the fee estimate. Ensure the account has enough native asset for the fee and that the maximum parameters are acceptable.
- Read warnings and simulation output. A failed simulation, unknown function, unexpected asset movement, or unexplained unlimited approval is a reason to stop and investigate.
- Verify the application source. Phishing websites and fake wallet interfaces can construct valid but malicious transactions. Never provide a recovery phrase to complete a transfer or receive support. [13]
After broadcasting
Record the transaction hash and inspect it on a block explorer for the correct network. Check its pending, successful, or failed status; sender and destination; transferred value; gas used and effective fee; decoded input where available; token-transfer events; and contract addresses. A transaction first enters the pending pool, then may be included in a block, and later gains stronger consensus status. Ethereum distinguishes block inclusion from justification and finalization. [3]
If the interface reports success but the expected token is not visible, first verify the network and token contract rather than immediately repeating the transaction. If the onchain transaction failed, inspect the failure or revert information before resubmitting. Repeating an instruction without identifying the cause can produce another fee without correcting the underlying issue.
Practical application: acquiring or exchanging ETH without confusing the network and fee
When obtaining ETH for a transfer or smart-contract interaction, work backward from the destination. Determine the exact receiving network, calculate the amount needed for the intended action, and leave an appropriate margin for a dynamic network fee. Do not assume that an exchange’s displayed amount includes later wallet, bridge, or application fees.
The exchange service supports ETH among its available assets, but specific pairs, networks, and directions may change and should be confirmed before creating a request. You can check currently available ETH exchange directions and then compare the offered network with the receiving wallet or platform’s requirements. Verification requirements can depend on the transaction direction and the outcome of compliance checks, so current conditions should also be reviewed before proceeding.
A safe preparation sequence is: confirm the destination network, verify the complete address, check current availability, read the quoted exchange conditions, and inspect the withdrawal or deposit network one final time. Once an onchain transfer has been confirmed, there is generally no central mechanism that can reverse an error; recovery depends on whether the unintended recipient or relevant service can and will assist. [13]
The useful mental model is therefore operational rather than promotional: ETH supplies native value and pays for Mainnet computation; gas measures that computation; transactions authorize state changes; smart contracts define programmable behavior; and the selected network determines where all of this takes place. Before acting, verify the network, address, contract action, permissions, and live fee parameters as separate fields—not as one generic “send” command.