Decentralized Applications (dApps) & the Web3 Stack

Smart Contracts, DeFi & Web3 Security
Course 2 · Chapter 5 · Decentralized Applications (dApps) & the Web3 Stack

Chapters 1 through 4 covered writing, deploying, and reasoning about smart contracts — but a real user never types Solidity into a terminal. This chapter covers what actually sits between an ordinary web page and a deployed contract: how a dApp connects a wallet, reads and writes on-chain state, and where its own frontend and off-chain data actually live.

What a dApp Actually Is

A decentralized application (dApp) is, structurally, just an ordinary web frontend — often built with the same tools as any other website — paired with one or more smart contracts (Chapters 1–4) as its real, on-chain backend. What makes it "decentralized" isn't the frontend at all; it's that the actual application logic and data live on the blockchain itself, per every mechanism this course has already covered, rather than on a company's own private servers.

Frontend
An ordinary website (HTML/CSS/JavaScript) the user actually loads in a browser
↓
Wallet (e.g. MetaMask)
Holds the user's real private key; the only thing that can produce a valid signature (Course 1, Chapter 2)
↓
RPC node provider
Relays reads and broadcasts transactions to the actual Ethereum network
↓
The blockchain itself
Where deployed contracts (Chapter 1) actually run and store state

MetaMask: A Real, Widely Used Wallet Layer

MetaMask, developed by ConsenSys and launched in 2016, is the real, dominant browser-extension wallet most dApps are built to work with — reporting over 100 million users worldwide as of early 2026. It injects a JavaScript interface into every page a user visits, which a dApp's own frontend code can use to request a connection, read the user's public address, or ask the user to approve a transaction.

The Real Security Property This Depends On A dApp's own website-hosted JavaScript code never has direct access to the user's private key at any point. When a dApp wants the user to sign something, it sends a request through this injected interface, MetaMask displays a real, human-readable confirmation prompt, and only if the user explicitly approves does MetaMask itself — running as a separate browser extension, not as part of the website's own code — actually produce the signature using the key it holds. The website never touches the key directly, exactly matching Course 1 Chapter 7's own "a wallet stores keys, the network never needs to see them" principle.

The Real Interaction Flow

Applying this to Chapter 1's own Counter contract, end to end:

1
Connect wallet — the user clicks "Connect," MetaMask asks for approval, and the dApp receives the user's public address.
2
Read state, for free — the frontend calls the contract's own getCount(), a view function (Chapter 2), executed locally without needing any signature or gas at all.
3
Submit a transaction — the user clicks "Increment," triggering a call to the real, state-changing increment() function.
4
MetaMask prompts for a signature — showing the real destination contract, the function being called, and the estimated gas cost, before the user approves or rejects it.
5
Broadcast and confirm — the signed transaction is sent to the network exactly as Course 1 Chapter 7's own transaction flow described, eventually mined/validated and confirmed.

Talking to the Network: RPC Node Providers

Step 2 and step 5 above both require actually talking to the Ethereum network — but an ordinary website visitor's browser doesn't run a full Ethereum node itself (Course 1's own full-node/decentralization discussion covered why that's a real, meaningful piece of infrastructure to run). Instead, most dApps connect through a real, dedicated RPC node provider — a service that runs the actual full nodes on the dApp's behalf and exposes a simple API for reading state and broadcasting transactions. Infura, acquired by ConsenSys (MetaMask's own developer) in 2019, and Alchemy are two real, widely used examples, together powering a large share of real dApp traffic, including MetaMask's own default connection.

An Honest Centralization Tension This is a genuine, widely discussed point of friction in Web3: a "decentralized" application's own contract logic and data can be as decentralized as Course 1 described, while the specific path most real users actually take to reach it — their wallet's default RPC connection — often runs through one of a comparatively small number of centralized infrastructure providers. If a provider like this goes down or chooses to block certain addresses, many real dApps' own users can be meaningfully affected, even though the underlying blockchain itself keeps running completely unaffected. Running your own full node avoids this dependency entirely, but very few ordinary users actually do.

IPFS: Real, Decentralized Off-Chain Storage

Course 1 Chapter 8 noted that an NFT's own metadata and media typically live off-chain, linked from a URI. IPFS (InterPlanetary File System) is a real, genuinely decentralized protocol commonly used for exactly this — a peer-to-peer network where files are identified by content addressing: a file's own address is a cryptographic hash of its actual content, rather than a location like a normal URL. Anyone holding a copy of that exact content, on any node in the network, can serve it — and because the address is derived directly from the content itself, the hash also proves the content hasn't been tampered with, reusing exactly the same hash-integrity idea Course 1 Chapter 2 introduced. Storing a dApp's own frontend, or an NFT's metadata, on IPFS reduces (though doesn't fully eliminate) dependence on any single centralized server continuing to stay online.

Hands-On Exercises

Three exercises reinforcing the real Web3 stack before Chapter 6 turns to DAOs — organizations built entirely on top of exactly this stack.

Exercise 1
A user reports: "This dApp's website asked me to paste my seed phrase directly into a text box to connect my wallet." Using this chapter's own explanation of how MetaMask actually signs transactions, explain why this is a serious, non-standard red flag rather than normal dApp behavior.
→ Solution
Exercise 2
Using this chapter's own five-step interaction flow, explain specifically why step 2 (reading getCount()) doesn't trigger a MetaMask signature prompt, while step 3 (increment()) does.
→ Solution
Exercise 3
A colleague says: "As long as a contract's logic is deployed on-chain, the whole dApp is fully decentralized, with no single point of failure at all." Using this chapter's own centralization tension, explain what this claim overlooks.
→ Solution

Quick Reference

  • dApp — an ordinary web frontend paired with smart contracts as its real, on-chain backend.
  • MetaMask — ConsenSys, launched 2016, over 100 million users; signs transactions locally, never exposing the private key to a website.
  • Interaction flow — connect wallet, read state for free via view calls, submit a transaction, sign in MetaMask, broadcast and confirm.
  • RPC node providers — services like Infura (ConsenSys, acquired 2019) and Alchemy that run full nodes on a dApp's behalf, with a real, honest centralization tension around relying on them.
  • IPFS — a real, content-addressed, peer-to-peer storage protocol commonly used for dApp frontends and NFT metadata (Course 1, Chapter 8).