Ethereum is a public blockchain that lets people transfer value and run programs on a shared ledger. Its native asset is Ether, usually written ETH. Ethereum is the network; Ether is the asset used to pay for execution and help secure it. Buying ETH gives you neither shares in a company called Ethereum nor a claim on every application built there.
The useful way to understand Ethereum is to follow a transaction. A wallet authorises an instruction, computers check and execute it, and validators agree on the resulting history. That instruction might pay somebody, exchange tokens or interact with a lending program. The same infrastructure supports very different activities, with very different risks.
This guide checks the current mainnet design and original upgrade documentation as of October 8, 2026, UTC. It separates features already operating from proposals still being tested. Ethereum changes through coordinated software upgrades, so an explanation based only on its mining era or its original wallet design misses how the network works today.
What is actually live right now?
Ethereum switched from proof of work to proof of stake in September 2022. Mining no longer determines its mainnet consensus. The Dencun upgrade introduced blobs for rollup data in March 2024, Pectra followed in May 2025, and Fusaka activated in December 2025. The protocol’s technical history records those completed milestones.
Fusaka introduced PeerDAS, short for peer-to-peer data availability sampling. It lets participating nodes check the availability of blob data through distributed storage and sampling rather than requiring each one to download every complete blob. That supports scaling the data service used by rollups while managing what individual nodes must handle.
Glamsterdam is the next named upgrade in the documentation checked for this guide. The Ethereum Foundation’s testnet announcement scheduled Sepolia activation for October 6 and explicitly left mainnet activation undecided. The roadmap currently targets the fourth quarter of 2026, with no confirmed mainnet date. A testnet schedule is not evidence that the changes already govern real mainnet transactions.
Its planned changes include bringing proposer-builder separation into the protocol and introducing block-level access lists to help clients process and validate work more efficiently. Those belong in the upcoming column. They should not be used to describe the rules protecting a mainnet payment today.
The shared computer behind the apps
Ethereum maintains a state: account balances, deployed contract code and the data stored by those contracts. Transactions move that state from one valid version to the next. Nodes independently check the same instructions under the same rules, rather than trusting an application’s website to declare the result.
The Ethereum Virtual Machine, or EVM, provides the execution environment. A smart contract is a program deployed there. It can hold assets and expose functions that other transactions or contracts call. A token contract, for example, can record balances and define how authorised transfers change them.
The network needs deterministic execution. Given the same starting state and inputs, validating computers must reach the same result. A contract cannot simply consult whichever website happens to answer first and call that consensus. Information from outside the chain arrives through transactions or oracle systems, whose reliability remains a separate question.
A decentralised application also has parts outside Ethereum. Its interface may be hosted by a company, its wallet connection may use an infrastructure provider, and administrators may retain permissions over its contracts. The blockchain can independently enforce code while the surrounding service still depends heavily on particular organisations.
How accounts and wallets work
A conventional externally owned account is controlled by a private key. A wallet manages that authority and helps construct and sign transactions. The account’s records live on the network; the wallet is the tool used to interact with them. An interface showing a balance is not where the ETH itself sits.
Contract accounts operate through code. Their behaviour depends on the program and the instructions it receives. Smart-contract wallets can add approval policies, recovery arrangements or other features, but the exact powers depend on the implementation. Calling something a smart wallet does not establish that its recovery procedure is safe.
The old claim that a key-controlled account can never execute delegated code is now incomplete. Pectra’s EIP-7702 allows an account to authorise delegation to an existing contract’s code. Compatible wallets can build features such as batching and sponsored fees around that mechanism. The user’s signing authority still matters, and a dangerous delegation can grant dangerous powers.
A wallet request therefore deserves more attention than the word “confirm”. A signature authorises specified data; it does not certify that a website is honest or that the economic outcome will be desirable. Contract permissions and token approvals can also remain relevant after the particular action that prompted them.
What happens after you press send?
A transaction includes information such as the destination, value, account sequence number and fee limits. The sequence number, called a nonce, helps organise that account’s transactions and prevents a signed instruction from being reused as a fresh payment. A contract interaction also supplies data identifying the requested function and its inputs.
The signed transaction is broadcast to the network. An execution client checks it against the current rules and state, then evaluates its effects when processing a block. Contract calls may change several balances or storage values. A failed execution can revert its state changes while still consuming gas for work performed.
A full Ethereum node uses two cooperating clients. The execution client handles transactions, EVM execution and state. The consensus client handles proof-of-stake agreement and the chain’s accepted head. Validator software can be added to perform proposing and attesting duties. Running a verifying node does not automatically mean staking or earning rewards.
Block inclusion is one stage, not a universal definition of finished. A wallet, exchange or application may describe a payment as confirmed using its own threshold. Ethereum’s consensus then supplies stronger finality guarantees under its stated security assumptions. Knowing which stage a service means is more useful than treating every confirmation label as identical.
As previously reported by Apex, signatures, hash commitments and consensus protect different parts of a blockchain. Ethereum’s extra programmability does not collapse those jobs into one. Understanding that separation makes its wallets, validators and applications much easier to assess.
Who secures Ethereum now?
Validators commit ETH and participate in proof of stake. Activating an individual validator requires at least 32 ETH, although pooled services let users participate with smaller amounts through different arrangements. Pooling introduces its own contract, operator or custody dependencies; a service’s displayed return is not a protocol guarantee.
Time is organised into 12-second slots, grouped into epochs of 32 slots. A proposer is selected for a slot and validators attest to their view of the chain. A slot can be missed, so this schedule does not guarantee that every transaction gets a new block exactly twelve seconds after being submitted.
Fork-choice rules determine the chain head. Checkpoint voting provides finality when the required supermajority of stake supports the relevant links. Finality and continued progress depend on different conditions: a network can stop finalising when too little stake participates, even without an attacker successfully rewriting its history.
Some provable violations can trigger slashing, which destroys part of a validator’s stake. Routine downtime and deliberate conflicting votes are not the same event. Rewards, penalties, software reliability and operator concentration all belong in an assessment of staking. A high advertised yield leaves those questions unanswered.
How Ethereum differs from Bitcoin
Apex had earlier reported that Bitcoin is a peer-to-peer monetary network whose rules govern ownership, transfers and the accepted transaction history. Ethereum also transfers a native asset, but its general-purpose execution environment supports a much wider range of contract-driven state changes. Bitcoin has scripting capabilities too; the difference is not that one network has rules and the other has programs.
Their consensus and monetary designs differ. Bitcoin mainnet uses proof of work; Ethereum mainnet uses proof of stake. ETH has no Bitcoin-style fixed maximum supply. That does not make one asset a substitute for the other, or establish that one security model is stronger under every possible condition.
Where the transaction fee goes
Gas measures the work a transaction requires. ETH pays for that work. For an ordinary EIP-1559 execution fee, the amount charged is gas actually used multiplied by the applicable base fee plus the effective priority fee. The base fee is burned; the priority fee rewards block inclusion. Fee caps constrain willingness to pay rather than promising that the entire cap will be charged.
The worked example in the official fees documentation uses a plain transfer consuming 21,000 gas, a base fee of 10 gwei and a priority fee of 2 gwei. Those are illustrative inputs, not a live quote. The calculation produces a 0.000252 ETH fee: 0.000210 ETH burned and 0.000042 ETH paid as the tip.
A contract call may consume more gas, and account delegation or additional transaction data can change the required work. A gas limit sets a ceiling; the actual charge depends on execution and the fee mechanism. Blob-carrying transactions also have a separate blob-gas charge, so the example is not a complete fee model for every transaction type.
Burning ETH does not make its supply permanently fixed or guarantee that it falls. Validator rewards issue ETH, while execution and blob fees can remove it. The net change depends on both sides. Nor does greater application activity automatically translate into a higher ETH price: demand, issuance, fees and investor expectations interact rather than following one mechanical valuation rule.
Why so much activity happens on layer two
A rollup executes transactions outside Ethereum’s base-layer execution path and publishes the required data and commitments to Ethereum. It can spread some base-layer costs across a batch of users. The rollup has its own state and may give a rapid preliminary confirmation before its result reaches a stronger settlement stage.
Optimistic rollups use mechanisms for challenging incorrect state claims. Validity-proof rollups provide proofs checked by contracts on the base chain. Neither category eliminates questions about upgrades, operators, data availability or withdrawals. The practical protections depend on how the particular system implements those responsibilities.
Blobs give rollups a dedicated way to publish data. Blob gas follows a separate fee market from ordinary execution gas. The data are retained for a protocol-defined period rather than becoming permanent EVM storage, and contracts do not read the entire blob as though it were an ordinary storage slot. Long-term access needs additional arrangements.
PeerDAS addresses whether the required data are available. It does not, on its own, execute every rollup transaction or establish that every proposed state transition is correct. Availability and execution validity answer different questions, as the diagram shows.
A low rollup fee is therefore useful information, but insufficient information. Ask which network holds the assets, what its confirmation means, who can change its contracts and how an exit works during disruption. An application’s speed and the base chain’s security are connected through specific mechanisms, not through the word Ethereum in its branding.
What the network cannot promise
An Ethereum transaction can be technically valid and economically disastrous. A contract may contain an error, an oracle may report unreliable information, or a market may lack enough liquidity to complete a large trade at a sensible price. Validators check execution rules; they do not judge whether the user has made a good bargain.
Transaction ordering creates another concern. Participants may extract value by arranging inclusion around trades, liquidations or other activity. This is often called MEV. Slippage limits and other contract checks can restrict particular outcomes, but a simulation reflects a selected state. The state or code a transaction encounters can change before execution.
Current research includes native transaction assertions, discussed by the Ethereum Foundation in an October 5 technical post. The proposed approach could enforce rules over a transaction’s final outcome, beyond simply checking the request that was signed. That remains work under development, not a universal safety feature already protecting ordinary mainnet transactions.
Ethereum also has governance without one executive empowered to rewrite everyone’s ledger. Researchers, client developers, application builders, validators and other node operators influence upgrades. Coordination matters, and users depend on what software and services actually adopt. A successful proposal and an activated rule are different milestones.
What Ethereum is useful for
Ethereum provides a shared environment for assets and financial programs that different parties can verify and combine. A payment can interact with a contract, and one contract can use another’s functions. This composability is valuable when participants want common rules across services, but dependencies can transmit failures as well as useful features.
The decision to use it should start with the problem: who needs to verify the record, what conditions must be enforced and which intermediaries remain necessary? For many ordinary applications, a conventional database is cheaper and easier to manage. Ethereum earns its complexity where independently checkable execution and shared settlement are worth the costs, responsibilities and risks that come with them.