DApps (Decentralized Applications)

Combine a smart contract as the brain, distributed storage as the memory, and a browser-extension wallet as the key, and you get an application that depends on no single company's servers: a DApp.

What a DApp is: architecture and how it differs from a normal web app

A DApp (Decentralized Application) places its backend logic not on a central server but in a smart contract. A typical DApp has four layers:

• Frontend: the screen the user touches, built with ordinary web technology (HTML/CSS/JS) and sometimes hosted on distributed storage such as IPFS.
• Wallet: holds the private key and acts as the intermediary that expresses the user's intent as a signed transaction.
• Smart contract: the program running on the blockchain that holds the business logic and state (balances, ownership, and so on).
• Distributed storage: where large data such as images, video, and metadata lives, since storing it directly in a contract is expensive.

The decisive difference from a traditional web app is that the app's core logic and data cannot be arbitrarily changed, stopped, or deleted by an operator. In an ordinary app, the server owner is the rule-maker who can change the terms or freeze an account at will. In a DApp, the contract's rules are public and self-executing, and ownership of assets and data is tied to the user's keys. The contract keeps running even if the operator disappears.

The wallet-connect and transaction-signing flow

DApps have no login ID or password. Instead you use a wallet (a browser extension or app such as MetaMask). The typical user flow looks like this:

1. Connect: pressing the DApp's “Connect Wallet” button launches the wallet, and the user approves the connection. The DApp then learns the user's public address (their account). No password is ever sent.
2. Request an action: when the user performs an action such as “swap tokens,” the DApp assembles a proposed transaction and hands it to the wallet.
3. Confirm the signature: the wallet shows what will happen and how much gas it costs, and the user reviews it and signs with their private key. The key never leaves the wallet.
4. Submit and finalize: the signed transaction is broadcast, and once it is included in a block via Distributed Consensus, the contract's state updates and the action is final.

This model, signing with your own key rather than entrusting a service, is continuous with the philosophy of DID.

Where the data lives: IPFS and Arweave

Storage inside a smart contract costs a lot of gas per byte, so large data such as images, video, and metadata is normally kept off-chain. The two standard-bearers are IPFS and Arweave, and their approaches are opposites.

IPFS (InterPlanetary File System) is a content-addressed P2P file system where the address (a CID) is derived from a hash of the content itself, and lookups run over a Kademlia-style DHT internally. IPFS itself does not guarantee permanence, though: unless someone pins the data and keeps hosting it, content can disappear once no node still references it. Since a contract only stores a reference to the CID, the availability of the underlying content has to be secured separately.

Arweave takes the opposite approach, aiming for permanent storage paid for once. Uploaders prepay a fee that bakes in the expected future decline in storage costs, and that payment funds an endowment that gives network participants a long-term economic incentive to keep replicating and hosting the data. "Pinning with recurring cost" versus "permanence paid up front" is the distinction that decides which one fits a given use case. It has also become common to host a DApp's own frontend on IPFS or Arweave and reference it by content hash instead of a domain name.

Querying on-chain data: indexing and The Graph

A smart contract is good at "call a function and read one piece of current state," but bad at cross-cutting queries like "every transaction this address has ever made" or "every current holder of this NFT collection." A blockchain node is a ledger, not a search index, so answering such queries naively would mean scanning every block, which is impractical at scale.

The typical solution is decentralized indexing, best known through The Graph. Developers define, as a “subgraph,” how a contract's event logs should be turned into structured data; indexers on the network process blocks continuously according to that definition and expose the result as a GraphQL API. The point of difference from a centralized API server run by a single company is that indexers, curators, and delegators are economically incentivized through staking and query fees. In practice, though, plenty of smaller DApps take a middle path, running their own backend that collects and caches logs via eth_getLogs.

Representative categories

• DeFi (Decentralized Finance): decentralized exchanges (often AMMs that build a price on-chain via a formula such as constant-product), collateralized lending, derivatives, all financial services with no intermediary.
• NFT marketplaces: venues for minting and trading digital art and collectibles under standards such as ERC-721/ERC-1155. Whether metadata lives on-chain or off-chain (e.g. on IPFS) is a design choice that trades off permanence against cost.
• DAOs (Decentralized Autonomous Organizations): organizations run by token-holder voting over rules and funds. A common hybrid pattern votes off-chain to save gas and only executes the result on-chain. The treasury is commonly managed with multisig or contracts.
• Blockchain games: an attempt to own in-game items as NFTs. The oft-repeated ideal of carrying items across multiple games is realized in only a handful of titles in practice; most amount to a proof of ownership within a single game.

Challenges: UX, gas, and the spectrum of “how decentralized”

DApps are still maturing, and several hurdles stand in the way of mainstream adoption.

• UX: installing a wallet, self-managing private keys and seed phrases, and confirming a signature for every action remain daunting for ordinary users, with the harsh reality that a single mistake can mean losing assets.
• Gas fees: when the network is congested, gas fees spike and small transactions stop being worthwhile.
• Scalability and L2: the base chain (L1) has limited throughput. The mainstream solution is Layer 2 (L2), especially rollups, which bundle many transactions into one, borrowing L1's security while greatly reducing fees and congestion.

“How decentralized” is not all-or-nothing

A common misconception is that a DApp is decentralized across the board. In reality, frontend hosting, data storage, the indexing/query layer, governance, and core logic are independent axes, and each one can lean centralized or decentralized on its own. It is not unusual for some centralization to remain somewhere: the frontend often still sits on a central cloud provider or domain, and price data may rely on a single oracle.

This state of affairs is sometimes called “Web2.5.” It is also common to see progressive decentralization: a founding team keeps keys and governance centralized at launch, then hands off authority to a DAO in stages as the project builds a track record and a community. Balancing true decentralization against usability is still where designers earn their keep.

A DApp is the point where the building blocks covered on this site (P2P, distributed consensus, key management, smart contracts) come together as a single application. It is the frontier of distributed systems, where the sum of a technology stack is put to the test.