Bitcoin proved that money could work without a bank. Ethereum asked a bigger question: what if you could put any agreement — not just payments — onto a blockchain and have it run automatically? Launched in 2015, Ethereum is often described as a “world computer”: a single, shared, programmable platform that nobody owns and anybody can build on.
Beyond digital money
On Bitcoin, the main thing you can do is send bitcoin. Ethereum generalises that. As well as its own currency — ether (ETH) — it can run small programs. That turns the blockchain from a simple ledger into a platform for applications, from lending markets to games to digital art.
It helps to separate two things people muddle together: Ethereum is the network, and ether is the currency that powers it. You spend ether to use Ethereum.
Smart contracts: code as agreements
The heart of Ethereum is the smart contract — a program stored on the blockchain that runs exactly as written whenever its conditions are met. There is no manager to approve it and no way to quietly alter it once deployed.
A simple analogy is a vending machine. You do not negotiate with a shopkeeper; you insert the right amount, make a selection, and the machine is hard-wired to dispense your item. A smart contract is the same idea for digital agreements: meet the conditions in the code and the outcome happens automatically, identically, for everyone.
This is what enables decentralized applications, or “dapps” — entire services whose logic lives in smart contracts rather than on a company’s private servers.
Gas: paying for computation
Running programs on thousands of computers worldwide is not free, and unlimited free computation would invite spam and abuse. Ethereum solves both with gas.
Every operation — a transfer, a swap, minting a token — costs a small amount of computational effort measured in gas, paid for in ether. A simple transfer is cheap; a complex interaction with several contracts costs more. When the network is busy, users bid higher fees to get included sooner, which is why gas fees rise during periods of heavy demand. Gas is both the network’s pricing system and its spam shield.
Tokens, NFTs and standards
One of Ethereum’s most important inventions is the token standard — a shared template so that wallets and apps can handle new assets without custom code for each one.
- Fungible tokens follow the ERC-20 standard. Each unit is interchangeable, like currency. The vast majority of crypto tokens are ERC-20s.
- Non-fungible tokens (NFTs) follow standards where each token is unique and individually identifiable — useful for digital collectibles, tickets, or proof of ownership.
Because these standards are open, anyone can issue a token that instantly works across the whole ecosystem. That interoperability is a big part of why so much activity — including most of DeFi — was built on Ethereum first.
How Ethereum secures itself: the Merge
For its first years, Ethereum used proof of work, the same mining-based system as Bitcoin. In 2022 it completed a long-planned upgrade nicknamed “the Merge”, switching to proof of stake.
Instead of miners racing to solve puzzles, the network is now secured by validators who lock up ether as a stake and are rewarded for honestly confirming transactions — or penalised for cheating. The headline effect was a dramatic drop in energy use, since the puzzle-solving race was retired. If the difference between these two systems is unfamiliar, our guide on Proof of Work vs Proof of Stake breaks it down.
Why it matters
Ethereum’s significance is less about its price and more about what it unlocked: a neutral platform where developers can deploy financial tools, marketplaces and applications that run on shared infrastructure nobody controls. It is not the only smart-contract platform anymore — many newer networks compete on speed and cost — but it pioneered the model, and the ideas it introduced now run through most of the crypto landscape.
How the EVM executes code
Every Ethereum smart contract runs inside the Ethereum Virtual Machine, or EVM — a shared runtime that exists identically on every node in the network. When you send a transaction that calls a contract, each participating node runs the same code through the EVM and must arrive at exactly the same result. This shared execution is what lets thousands of independent computers agree on a single outcome without trusting one another.
A defining property of the EVM is determinism: given the same inputs and the same blockchain state, the code must always produce the same output. There is no randomness, no reaching out to the wider internet, and no “it depends on the machine.” That strict predictability is essential for consensus, but it also means contracts cannot directly fetch outside information — a constraint that shapes much of how Ethereum applications are designed.
Gas and determinism
Because contract code runs on every node, unbounded computation would let a single program freeze the entire network. Ethereum prevents this with gas, a unit that meters computational effort. Each EVM operation has a gas cost, the user pays for the gas a transaction consumes, and every transaction carries a limit. If execution runs out of gas, it halts and reverts, though the gas spent is not refunded.
Gas does more than price computation; it works hand in hand with determinism to keep the network safe. The deterministic design ensures every node agrees on exactly how much work a transaction performed, so they also agree on the fee. Together, gas and determinism turn a global, shared computer into something that cannot be spammed into collapse and whose costs everyone can verify.
What you can build with smart contracts
Smart contracts are general-purpose, so the range of applications is broad. A few durable categories dominate what people actually build:
- Tokens — both interchangeable, currency-like tokens and unique, individually identifiable ones.
- Decentralized finance — exchanges, lending markets, stablecoins, and other financial services that run as code.
- NFTs and digital ownership — collectibles, tickets, and proofs of ownership recorded on-chain.
- DAOs — organizations whose rules and treasuries are governed by contract logic and member voting.
- Infrastructure — bridges, identity systems, and tooling other applications depend on.
What unites them is that the core logic lives in public contracts rather than on a company’s private servers, so it runs the same way for everyone.
The lifecycle: write, deploy, interact
A smart contract passes through a clear lifecycle. First a developer writes it, usually in a high-level language designed for the EVM, then compiles it down to the bytecode the virtual machine actually runs. Careful testing belongs in this stage, because mistakes become far harder to fix later.
Next the contract is deployed by sending a transaction that places its bytecode permanently on the blockchain at a unique address. From that moment, anyone can interact with it by sending transactions to that address, calling its functions and triggering its logic. Reading data from a contract is typically free, while any interaction that changes on-chain state costs gas. Deployment is the pivotal step: once code is live, it is exposed to the whole world at once, which is exactly why so much care goes into everything that precedes it.
Immutability and upgradeability patterns
By default, a deployed contract is immutable: its code cannot be edited once it is on-chain. This is a feature, because users can rely on the rules not changing underneath them, but it is also unforgiving, since a bug cannot simply be patched in place.
Developers respond with deliberate upgradeability patterns. A common approach separates a stable “proxy” contract that users interact with from a separate contract holding the logic, so the logic can be swapped while the address and stored data stay put. This restores flexibility but reintroduces trust, because whoever controls the upgrade can change how the system behaves. The honest framing is a trade-off: pure immutability maximizes predictability, while upgradeability buys the ability to fix problems at the cost of added trust assumptions.
Security risks and famous classes of bugs
Because contracts often hold real value and cannot easily be changed, security is paramount, and certain categories of bug recur often enough to have names. Understanding them conceptually matters even for non-developers.
- Reentrancy — a contract calls out to another, which calls back in before the first finished updating its state, allowing repeated withdrawals.
- Access-control flaws — sensitive functions left callable by anyone, rather than restricted to authorized parties.
- Arithmetic errors — miscalculations such as overflows that corrupt balances.
- Oracle and price manipulation — feeding a contract bad external data to trigger profitable but illegitimate outcomes.
Auditing, best practices, and “code is law”
Professional development leans on a layered defense. Independent security audits, extensive automated testing, reuse of battle-tested standard libraries rather than novel code, and gradual rollouts all reduce the odds of a costly mistake. None of these guarantees safety; audited contracts have still been exploited, so they lower risk rather than removing it.
This is the practical limit behind the slogan “code is law.” The idea is that a contract does exactly what its code says, with no appeals process — which is empowering when the code is correct and merciless when it is not, since a bug executes just as faithfully as a feature. The nuance most newcomers miss is that immutable, automatic execution makes correctness everything. A contract cannot tell intent from accident; it only runs what was written, which is precisely why so much rigor surrounds getting that writing right.