What is a DApp?

A decentralized application (DApp) is an application that hands some of its core rules or state — balances, ownership and approval records, for example — to a decentralized network such as a blockchain to execute and store. Users normally still operate it through a web or mobile interface, but the key results can be validated by multiple participants in the network under shared rules, instead of depending only on one database held by the application's operator.

"Decentralized" describes how an application's control and dependencies are distributed; it is not a label acquired automatically. A DApp can run its core contracts onchain while still depending on a single website, data interface, administrator key or offchain server. Assessing a DApp therefore means looking layer by layer at what it is made of and who controls each layer.

What a DApp is usually made of

A DApp is usually not a single smart contract but a complete experience delivered by several components together:

• User interface: a web or mobile app that displays information and receives actions;
• Wallet: holds or invokes the user's signing capability, letting the user confirm account connections and transactions;
• Onchain programs: smart contracts or network programs that handle transfers, approvals and state updates according to their code;
• Network connection services: send queries and signed transactions to blockchain nodes;
• Offchain services: may handle search, indexing, notifications, image storage or the supply of external data.

Ethereum's introduction to DApps treats smart contracts and a frontend interface as the common combination. Other networks can use different program and account models. Solana, for instance, separates executable programs from the accounts that hold mutable data. Implementations differ, but a reader can still examine an application through the same questions: interface, authorization, network execution and data provenance.

The main stages one operation passes through

After a user opens a DApp, the interface can first read public information — a balance, a quote or a particular onchain record — through a node or through an indexing service (an indexer) that organizes onchain data for querying. Reads of this kind usually do not change blockchain state and do not require the user to sign for each query; what is displayed still depends on the data the connected service returns and on when the query was made.

When the user starts an operation that will change state, the DApp constructs a transaction request and passes it to the wallet. The wallet should show the user the network, the destination address, what is being authorized and the fees that may arise; once the user confirms, the wallet signs the transaction using the signing capability of the relevant account.

The signed transaction is then sent to blockchain nodes. Nodes check the signature and transaction format under the protocol, and execute the target program while building or validating a candidate block. Once the transaction is included in a valid block, the execution result becomes part of that chain's state and can be recomputed and read by other nodes. When execution fails, the interface should also update according to the actual transaction result, rather than only showing that it sent a request.

Being included in a valid block does not necessarily mean immediate final confirmation. A transaction may still need to wait for more confirmations, and under some network conditions block history can also be reorganized. When something can be treated as final depends on the particular network's consensus mechanism.

This process shows that the web page itself usually does not modify the blockchain directly. The interface prepares and displays requests, the wallet handles user authorization, and the network and onchain programs determine whether state changes according to the rules.

Connecting a wallet is not approving a transaction

Connecting a wallet usually only lets a DApp know which public address the user selected, and gives it a channel for sending requests to the wallet. Which accounts the application can see and which requests it can make depend on the wallet and the connection standard in use. Connecting should not be equivalent to handing over a private key, and it does not mean the user has approved any transfer of assets.

Subsequent requests can serve different purposes:

• Signing a message: proves the account signed a particular piece of text or data, without necessarily producing an onchain transaction;
• Sending a transaction: asks the network to execute a transfer or a contract call;
• Token approval: allows an address or program to move tokens within a specified scope;
• Switching networks: has the wallet change to a different blockchain or test network.

Users need to see clearly what each request actually contains. Disconnecting from a website usually just closes the current session; it does not automatically revoke token approvals or other permissions already written onchain.

Onchain rules and offchain interfaces

What onchain programs handle can be checked jointly by network participants, but the web page a user sees may still be hosted by a particular team. A website can be updated, taken down, access-restricted or made to display wrong information, while an already deployed contract may continue to exist.

A contract still being onchain does not mean ordinary users can conveniently keep using it. Users also need a working interface, the correct contract address, a node connection and the necessary interpretation of data. Technically confident users may go through another interface or call the contract directly, but that depends on whether the contract exposes a suitable entry point, and it raises the difficulty of the operation.

Conversely, an interface with open source code or distributed hosting cannot establish that the onchain program has no administrator permissions. Assessing a control structure means checking frontend publication, contract upgrade rights, pause rights, fund permissions and external dependencies separately.

Not all data is necessarily stored onchain

A blockchain suits state that needs to be validated jointly, but storing large volumes of images, video or search data directly on it can be expensive. DApps therefore often keep core balances and permissions onchain while placing other content on ordinary servers or distributed file networks.

Take the InterPlanetary File System (IPFS), a distributed file protocol that locates data by its content rather than by a fixed server location. IPFS generates a verifiable data identifier for content. That helps a reader check whether the content they received matches the identifier, but it does not guarantee that someone is always online to serve the file, nor does it establish that the file's content is true.

Recording a web link or content identifier onchain only establishes that the application stored that reference. Whether the link target is reachable, who maintains it, whether it can be replaced and how long it is kept all still require checking the specific arrangement.

The degree of decentralization has to be judged layer by layer

Rather than asking whether a DApp is "fully decentralized", it is more useful to check each layer:

• Execution: are the core rules executed jointly by multiple nodes, or decided by a single server?
• State: where do the key balances and permissions live, and who can modify them?
• Upgrades: can the contracts be upgraded, and whose approval does an upgrade require?
• Interface: is there only one official entry point, and can others deploy an alternative?
• Data: does the application depend on a single node service, indexer, oracle or file server?
• Governance: who is responsible for pausing, parameter adjustment and fund management?

Different answers produce different control structures. Requiring several participants to sign jointly, setting a waiting period before a change takes effect, or deciding through a public vote can each spread part of the permissions without automatically removing every concentrated dependency; equally, retaining an emergency pause may be a deliberate risk control choice. An article should state the actual arrangement rather than drawing conclusions from the name "DApp".

How a DApp differs from an ordinary application

Both kinds of application can have web pages, accounts and backend services. The difference lies mainly in who confirms the key state and rules.

An ordinary application usually has the operator's servers receive requests, modify a database and decide the software version. Users have to trust the operator to store data correctly, and can usually only reach the service through the interfaces the operator provides.

A DApp can place some rules and state in a blockchain network, to be executed by nodes under the protocol. Users sign transactions with their own accounts, and other interfaces may call the same onchain programs. This verifiability comes with trade-offs, however: fees, public state, waiting for confirmation, contract defects and the need to coordinate upgrades.

A DApp is therefore not "an application that needs no development team or servers". It moves certain decisions from a single backend to a shared network, while possibly keeping offchain components in place.

DApps, smart contracts and onchain organizations

A smart contract is code that executes onchain; a DApp is the complete user-facing application, usually including smart contracts, an interface and other services. One contract can be used by several DApps, and one DApp can call several contracts.

A decentralized autonomous organization (DAO) is a way of organizing that uses onchain rules, voting or multi-party permissions to coordinate decisions and resources. A DAO may provide a voting interface through a DApp, but a DApp is not necessarily a DAO and does not have to issue a governance token.

Similarly, an application having a token does not make it decentralized automatically. Token distribution, administrator permissions, contract upgrades and interface control all still have to be checked separately.

Main limitations and risks

A DApp's risks can come from every layer:

• smart contract code has defects, or administrative permissions go beyond what users expect;
• the interface is tampered with, leading users to sign the wrong transaction;
• the wallet does not display clearly what is being called;
• a node or indexing service returns stale, wrong or incomplete data;
• a service that submits external information onchain supplies inaccurate data;
• files, domain names or the official entry point stop working;
• the base network becomes congested, changes its fees or suffers a fault.

A transaction executing successfully on a blockchain only shows that it complied with the network and contract rules at that time. It does not establish that the user understood the request, nor that the offchain information the application provided was true.

FAQ

Must a DApp have its own token?

No. A token can be used for payment, permissions or governance, but it is not a necessary condition for something to be a DApp.

Is all of a DApp's data public?

Not necessarily. Transactions and state on a public blockchain can usually be read, but an application may also use offchain databases, encrypted data or privacy techniques. What is actually visible depends on the network and the design.

Can a DApp still be used after its official website shuts down?

The onchain programs may continue to exist, but users also need an alternative interface, a node connection and the correct contract information. Whether use can continue depends on whether each component is open and available.

Is a private key handed to the website when using a DApp?

Normal wallet interaction does not require giving a private key to a website. The wallet signs within its own security boundary and then passes the signature or signed transaction to the application. Users should still be wary of interfaces that ask for a seed phrase or private key, or that push them towards signing dangerous requests.

Does a DApp necessarily have no administrator?

Not necessarily. A contract may retain upgrade, pause, parameter adjustment or fund management permissions. Check the specific code and permission arrangements rather than relying on the application's name.

Related concepts

Continue with smart contract, Ethereum, the EVM, non-custodial wallet and blockchain, or return to the Crypto Glossary.

Sources

• Ethereum.org: introduction to dapps — the basic relationship between a frontend, smart contracts and a decentralized network.
• Ethereum.org: introduction to smart contracts — deployment, calls and the execution boundaries of onchain programs.
• IPFS Docs: how IPFS works — content addressing, data identifiers, routing and file transfer.
• Solana Docs: programs — an implementation example separating executable programs from standalone data accounts.