Decentralised Applications are applications whose important functions rely, wholly or partly, on decentralised networks such as blockchains rather than depending entirely on a single centrally controlled server. A Decentralised Application, commonly abbreviated as DApp, generally includes blockchain-resident smart contracts or other decentralised infrastructure for persistent state or critical logic, together with a user interface that allows people to interact with that infrastructure.
The term is not defined by one universally enforced technical standard, so applications vary considerably in how much of their functionality is actually decentralised. A user may interact with a web interface hosted through conventional infrastructure while the underlying transactions execute on a blockchain. Consequently, decentralisation is better considered as a property distributed across different application components than as a binary characteristic. A DApp can reduce dependence on a single operator for particular functions while still relying on centralised hosting, development teams, oracles, bridges, wallets, indexing services or other intermediaries.
A typical DApp architecture separates several functions. The front end may be a conventional web application written with ordinary web technologies, while smart contracts provide the on-chain logic and persistent state. Wallet software manages user credentials and signs transactions, and blockchain nodes or remote providers relay those transactions to the network. Indexing systems may transform blockchain data into structures that make application queries efficient, while decentralised storage networks may host larger files that are impractical to place directly on-chain.
Oracles can supply external information, and bridges can facilitate interaction with other blockchain environments. These dependencies mean that an application can be decentralised in one dimension and centralised in another. A DApp's actual architecture should therefore be assessed by identifying who controls each component, what happens if that component disappears, whether users can interact directly with the underlying contracts, and whether the application's critical state remains available without its original interface.
The history of DApps is closely connected with the emergence of general-purpose blockchain platforms. Earlier blockchain systems primarily focused on transferring native digital assets, whereas programmable networks enabled developers to create persistent on-chain programs that could implement arbitrary application logic. Ethereum's launch provided a particularly important foundation for DApp development because developers could deploy smart contracts without creating a separate blockchain for every application. This enabled decentralised exchanges, lending protocols, games, governance systems, digital-asset marketplaces and other applications.
As the ecosystem matured, developers increasingly adopted modular architectures in which some functions occur on-chain and others occur off-chain for reasons of cost, speed, privacy or usability. The result is that modern DApps are often hybrid systems rather than entirely blockchain-resident software, and their degree of decentralisation depends on the precise components involved.
DApps differ from conventional web applications primarily in the location and control of critical state and transaction logic. In a conventional application, a central service can typically modify database records, reverse transactions, change rules or suspend accounts according to its policies. In a DApp, critical operations may instead be governed by smart-contract code and blockchain consensus, making unilateral changes more difficult or impossible.
This can provide transparency and user-controlled asset ownership, but it can also reduce the ability to correct mistakes. A centralised application can generally process database changes quickly and privately, whereas blockchain-based applications may incur transaction fees, expose activity publicly and operate within network throughput constraints. DApps therefore introduce a different set of design trade-offs rather than simply constituting improved versions of conventional web applications.
Decentralised applications have been particularly prominent in decentralised finance, digital collectibles, blockchain gaming, governance and token management. A decentralised exchange can use smart contracts to facilitate trades without maintaining a conventional central order book controlled by one company. A lending application can encode collateral and borrowing rules in contracts, while a digital-asset marketplace can use contracts to transfer tokens and record transactions.
Blockchain games can place some assets or rules on-chain, although many game components may remain off-chain because of performance requirements. Governance applications can allow token holders or other authorised participants to submit and vote on proposals. Each application class exposes different decentralisation requirements, and an application should not be regarded as decentralised merely because it has a token or blockchain-based user interface.
DApp security encompasses more than smart-contract correctness. The front end can be compromised, altered or censored even when the underlying contracts remain secure. Malicious or misleading interfaces can direct users to sign harmful transactions. Wallet permissions can allow contracts to spend tokens under specified conditions, and users may approve more spending authority than necessary. Bridges, price oracles and external dependencies can create additional vulnerabilities. Upgradeable contracts may also introduce administrators who retain significant control over application behaviour.
Governance systems can be manipulated through concentrated token ownership, delegated voting or low participation. Because blockchain transactions are often difficult to reverse, an application exploit can cause rapid financial losses. Security analysis therefore requires mapping the complete dependency graph rather than inspecting only the most visible smart contract.
DApps also raise usability and governance challenges. Users may need to manage cryptographic wallets, transaction fees, network selection, token approvals and signature prompts, which can be less familiar than logging into a conventional service. Lost keys can result in loss of access, while centralised recovery mechanisms may reduce decentralisation. Governance can involve token voting, multisignature controls, developer councils, foundations or other structures, meaning that decentralisation is partly an institutional question as well as a technical one.
Applications can also experience network congestion, variable transaction fees and fragmented liquidity across different chains or layer-2 environments. These problems have encouraged the development of account abstraction, improved wallet interfaces, scaling systems and interoperability mechanisms intended to make decentralised applications easier to use without removing their underlying technical properties.
A common misconception is that a DApp must have every component decentralised or that decentralisation automatically means absence of human control. In reality, most DApps occupy a spectrum: the blockchain may decentralise transaction settlement, while a company controls the front end; a DAO may govern upgrades, while a small development team controls deployment infrastructure; or contracts may be immutable while external oracles remain centralised. Another misconception is that putting data on a blockchain automatically makes it trustworthy.
The blockchain can preserve the record of what the protocol accepted, but it cannot independently verify the truth of external information. Evaluating a DApp therefore requires examining its contracts, governance, front end, dependencies, data sources, upgrade mechanisms, custody model and failure modes. Its decentralisation should be described component by component rather than inferred from branding or the presence of a blockchain transaction.
