An Introduction to Web3 for Beginners: Wallets, Contracts and IPFS

“Web3” gets used for two different things. In product terms, it describes applications where users hold their own accounts and assets on a public blockchain instead of inside one company’s database. In developer terms, it often means the JavaScript libraries (web3.js, ethers.js, viem) that let a web page talk to a blockchain node.

This introduction covers both, then looks at the storage layer most web3 apps rely on: IPFS.

How the web got here

The web’s history is often split into three stages. The labels are loose, but they help explain what web3 is reacting to.

Web1: reading

From the early 1990s to the mid-2000s, most people consumed content. Pages were mostly static text and images, built by the few who could run a server.

Web2: reading and writing

Social networks, marketplaces and cloud apps made everyone a publisher. The trade-off is that the platform owns the account, the data and the relationship with the audience. If the platform changes its rules or shuts an account, the user has little recourse.

Web3: reading, writing and owning

Web3 moves some of that ownership to the user. An account is a key pair the user controls, assets live on a public ledger rather than in a company’s database, and application logic can run as smart contracts that anyone can inspect. Key ideas:

• Self-custody. Your wallet holds the private key. No company can reset or freeze the account itself (though apps and token issuers can still restrict what you do with it).
• Verifiable state. Balances and contract code are public, so anyone can check them without trusting an operator.
• Permissionless access. Anyone with a wallet can use a public contract; there is no sign-up gate.
• Built-in payments. Value moves with the same transaction model as data.

Web3 does not replace the existing web. Most web3 apps are ordinary websites that also connect to a blockchain, and many keep conventional servers for search, notifications and analytics.

The building blocks

A typical web3 application has four parts.

1. A blockchain such as Ethereum or a layer 2 network built on it, which stores balances and contract state.
2. Smart contracts, programs deployed to that chain. On Ethereum they are usually written in Solidity. See our Ethereum and Solidity getting started guide.
3. A wallet, which holds the user’s keys and signs transactions.
4. A front end that reads chain data and asks the wallet to sign.

Libraries that connect the front end

The front end talks to a node through JSON-RPC, over HTTP or WebSocket, usually via a hosted provider rather than a node you run yourself. Libraries wrap that RPC interface so you can read balances, call contracts and send transactions:

• web3.js was the original Ethereum JavaScript library. ChainSafe, its maintainer, sunset it in 2025, so it is not a good choice for new projects.
• ethers.js is a compact, widely used alternative.
• viem is a newer TypeScript-first library, often paired with wagmi for React hooks.

If you build with React, our web3-react overview shows how wallet connections fit into a component tree.

Wallets

A web3 wallet stores your keys and lets you approve transactions in apps. Wallets come as browser extensions, mobile apps, desktop apps and hardware devices. MetaMask is the most common wallet for Ethereum and EVM networks; Phantom is popular on Solana.

There are two broad types:

• Hot wallets (browser extensions and apps) keep keys on an internet-connected device. They are convenient for everyday use.
• Cold or hardware wallets keep keys on a separate device that signs transactions offline. They suit larger holdings.

Setting up MetaMask

1. Install MetaMask only from metamask.io or your browser’s official extension store. Fake wallet extensions are a common scam.
2. Choose to create a new wallet and set a strong password. The password unlocks MetaMask on that device only.
3. Write down the 12-word Secret Recovery Phrase on paper, in order, and store it somewhere safe and offline. Anyone with these words controls the wallet. MetaMask will never ask for them, and nor will any legitimate support team.
4. Confirm the phrase when prompted. You now have an account with a public address you can share to receive funds.

Before connecting to an app, check the URL, read what each signature request asks for, and be wary of requests to approve unlimited token spending.

Decentralized storage with IPFS

Blockchains are expensive places to store data. Every byte is replicated on every node and paid for in fees, so storing an image or a document on-chain rarely makes sense. Most web3 apps put files elsewhere and keep only a reference on-chain. The most common place for those files is IPFS.

What IPFS is

The InterPlanetary File System (IPFS) is an open protocol for storing and sharing files peer to peer. It borrows ideas from BitTorrent (fetching pieces from many peers) and Git (content-addressed, versionable objects). It is not a blockchain and has no token of its own.

Content addressing

On the regular web, a URL names a location: a file at a path on a particular server. If the server goes down or the file changes, the link breaks or silently points at something new.

IPFS names files by what they contain. When you add a file, IPFS splits it into blocks, hashes each block, and builds a content identifier (CID) from those hashes. A CID looks like bafybei… and has three useful properties:

• Integrity. If even one byte changes, the CID changes. A client can check that what it received matches what it asked for.
• Location independence. Any node holding the content can serve it. The request is “find whoever has this CID”, not “fetch from this server”.
• Deduplication. Identical content produces the same CID, so it is stored and transferred once.

Nodes find each other and locate content through a distributed hash table, then exchange blocks directly.

Pinning: keeping content available

Content addressing guarantees a file is the right file. It does not guarantee anyone still has it. IPFS nodes cache content they fetch and clear that cache during garbage collection. To keep a file available, at least one node has to pin it, which marks it as content to keep.

In practice you can:

• Run your own IPFS node (Kubo is the main Go implementation; Helia is the JavaScript one) and pin your files there.
• Use a pinning service that runs nodes for you, for a fee.
• Pay for storage deals on Filecoin, a separate network built on IPFS that adds economic incentives for providers to store data over time.

If nobody pins a file, it will eventually disappear, CID or not. This is the most common surprise for teams new to IPFS.

Gateways and mutable names

Most browsers do not speak IPFS natively, so HTTP gateways fetch content by CID and serve it over HTTPS. Gateways are convenient but reintroduce a central point of access, so store the ipfs://<CID> reference in your contract or metadata rather than a gateway URL.

Because a CID changes whenever content changes, IPFS also offers IPNS, a naming system that maps a key you control to the latest CID. Use it when you need a stable pointer to content that updates, such as a website.

Where IPFS fits in a web3 app

The common pattern is: store the file on IPFS, pin it, and write its CID to the blockchain. The chain records who owns or registered the file and when; IPFS holds the bytes; the CID ties them together and proves they match. NFT metadata and images, dapp front ends and document registries all use this approach. Our NFT explainer covers how token metadata points to files this way.

Where to go next

Web3 is still uneven. Wallet security puts real responsibility on users, fees and network choice vary widely, and regulation of tokens differs by country. The core ideas, though, are stable: user-held keys, public verifiable state, and content-addressed storage.

To try it hands-on, set up a local Ethereum test network, deploy a simple contract, and store a file on IPFS from the same app. For a wider view of the platforms involved, see our guide to open source blockchain platforms, or talk to Lightrains about blockchain development.

This article originally appeared on lightrains.com