dApp (Decentralized Application)

What makes an app a "dApp"

The defining property is that meaningful state and logic live on a blockchain rather than on the developer's servers. A typical dApp has:

• Smart contracts — the backend logic, deployed to a blockchain and accessible to anyone.
• A frontend — usually a regular web app (often React-based) that reads from and writes to the smart contracts.
• Wallet connection — users authenticate by connecting a wallet like MetaMask rather than by username/password.

The frontend can be hosted anywhere — IPFS for full decentralization, traditional web hosts for convenience. The smart contracts are what give the application its decentralized properties: anyone can verify the logic, anyone can interact with the contracts directly (without the official frontend), and the contracts can't be turned off by the developer once deployed.

Categories of dApps

The major categories of dApps as of early 2025:

• DeFi — Aave, Uniswap, MakerDAO, Lido, Curve, Pendle. Lending, trading, derivatives, yield protocols.
• NFT marketplaces — OpenSea, Blur, Magic Eden, Tensor.
• Games — Axie Infinity, Pixels, various smaller titles. Mostly experimental.
• Social — Farcaster, Lens Protocol. Decentralized social networking.
• Identity — ENS, Lens profiles, Worldcoin.
• DAOs and governance — Snapshot, Tally, governance interfaces for individual protocols.
• Bridges and interoperability — Across, Hop, bridge UIs.

The category is dominated by financial use cases, with social and identity expanding gradually.

Why dApps differ from regular apps

Several practical differences:

• No login. Users connect a wallet that authenticates by signing transactions. No password, no email, no account creation in the conventional sense.
• Open access to backend. Anyone can interact with the smart contracts directly, build alternative frontends, or fork the protocol entirely. The "official" interface is just one way to use the protocol.
• Permissionless participation. No KYC at the protocol layer (though regulated frontends may add it).
• Transparent state. Anyone can read the contracts' state, track historical activity, and verify behavior independently.
• Costly state changes. Every transaction costs gas, so dApps generally minimize on-chain operations. Pure frontend interactions (browsing, searching) are off-chain and free.

Trade-offs

dApps have real disadvantages compared to traditional apps:

• User experience friction. Wallet setup, gas, transaction signing, varying confirmation times. Each step is a hurdle relative to a Web2 product.
• Higher cost. Transactions cost gas, sometimes a lot. Layer 2 solutions help but don't eliminate the cost.
• Limited compute. Smart contracts can't easily run complex operations. Anything ML-heavy or data-intensive lives off-chain.
• Privacy by default is poor. Transactions and state are publicly visible, which makes financial privacy hard.
• Mistakes are permanent. Send to the wrong address? Sign a malicious transaction? The blockchain doesn't have an undo button.

How they evolve

dApps tend to be upgraded carefully because changes can lock funds or break user assumptions. Common patterns:

• Upgradeable contracts — proxy contracts that can be pointed at new implementations. Convenient for the team; introduces a trust assumption that the team won't deploy malicious upgrades.
• Immutable contracts — once deployed, can't be changed. Maximum security and predictability; new versions deploy as separate contracts (Uniswap V1 → V2 → V3 → V4).
• Multi-sig controlled upgrades — upgrades require multiple signers, often distributed across team members and trusted community figures.
• DAO-controlled upgrades — governance votes approve changes. Slowest, but most decentralized.

What "decentralized" actually means in practice

The label is often used loosely. A truly decentralized dApp would have:

• Open-source contracts with no admin or upgrade keys.
• Decentralized frontend hosting (IPFS, Arweave, multiple mirrors).
• No reliance on centralized infrastructure beyond the underlying blockchain.

Most real dApps fall short of this in some way. Many have admin keys for emergency response. Many host frontends on AWS or Vercel for performance. Most depend on RPC providers like Alchemy or Infura for blockchain access. Decentralization is a spectrum, not a binary.

The infrastructure under dApps

Beneath the surface, most dApps depend on a stack of services:

• RPC providers — Alchemy, Infura, QuickNode. Provide the blockchain-data API the frontend uses.
• Indexers — The Graph, Goldsky. Process blockchain events into queryable data.
• Wallet libraries — wagmi, viem, ethers, web3.js. Standardize wallet integration.
• Transaction simulation — Tenderly, Blocknative. Show users what a transaction will do before they sign.

Each layer adds capability and removes friction; each is also a potential centralization point. The trend is toward more redundant and decentralized infrastructure, but the practical reliance on a small number of providers remains real.