dApp Architecture: What Goes On-Chain, Off-Chain, and in Between

The word decentralized makes dApps sound as if everything runs on-chain. In practice a dApp is a conventional application with a small on-chain core: contracts hold ownership, settlement, and rules; indexers make chain data queryable; backends handle logic and integration; frontends manage wallets and transactions. Getting the split right determines cost, performance, security, and whether the platform decision can ever be revisited. This guide covers the architecture layer by layer, drawing on FISTA Solutions' blockchain practice. The developer roles are in hire web3 developers and the contract layer in the smart contract development guide.

What are the layers?

Layer	Responsibility	Technology
Contracts	Ownership, settlement, rules, commitments	Smart contracts on the chosen chain
Indexer	Turn events into queryable state; handle reorgs	Event listeners; database; query API
Backend	Business logic, integration, metadata, notifications, orchestration	Conventional services with chain adapters
Storage	Large data and content with hashes on-chain	Object or decentralized storage
Frontend	Wallet connection, transaction lifecycle, display	Web or mobile app with wallet libraries
Oracles and bridges	External data and cross-chain needs	Assessed per trust model

Oracle trust is in blockchain oracles explained and bridges in cross-chain bridges explained.

What belongs on-chain?

Only what needs trustless execution or shared state: asset ownership and transfers, settlement logic, rules the parties must not be able to change unilaterally, and commitments such as hashes that let off-chain data be verified. Every on-chain operation costs gas and is public and permanent, so business logic, personal data, and large content stay off. Gas discipline is in gas optimization techniques.

Why is the indexer essential?

Chains are append-only transaction logs, not query engines. An indexer subscribes to contract events, writes them to a database in a shape the application needs, handles chain reorganizations by rolling back and replaying, and exposes queries for lists, histories, and aggregates. Frontends that read the chain directly for anything beyond a single account's current state are slow and fragile. Real-time patterns are in real-time web applications.

What does the backend do?

Everything a conventional backend does: authentication that may include wallet signatures, business logic that need not be trustless, integration with payments, identity, analytics, and enterprise systems, metadata and content serving, notifications, and, where the product design calls for it, transaction orchestration on users' behalf with appropriate custody controls. Backend skills are in hire backend developers.

How should the frontend handle wallets and transactions?

Wallet connection that handles multiple wallets, networks, and account changes; gas estimation and clear cost display before signing; explicit lifecycle states from preparing through confirmed or failed, including reorg handling; retry and cancellation paths; and signing requests that explain what the user is authorizing. Most dApp abandonment happens at unclear signing prompts and silent pending states. Security patterns are in web3 security best practices.

Where does data live?

Large content, documents, media, and metadata live in conventional object storage or decentralized storage systems, with content hashes recorded on-chain so integrity is verifiable. Personal data stays in systems with access control and deletion capability, never on-chain. Anchoring patterns are in blockchain audit trails.

Where are the security boundaries?

Contracts: audited, minimal, with upgrade controls. Indexer: reorg-safe and validated against chain state. Backend: conventional API security plus key custody for any orchestrated transactions. Frontend: signing safety, phishing resistance, and input validation. Oracles and bridges: assessed by trust model and minimized. API security is in api security best practices and contract upgrades in smart contract upgradeability.

How do you keep the platform decision reversible?

Abstract chain interaction behind an integration layer with stable interfaces; keep business logic off-chain; use standard token and identity formats; keep keys and contracts under the organization's control; and document a migration path. Chains change; an application whose logic lives off-chain migrates in weeks rather than years. Platform selection is in how to choose a blockchain platform.

What mistakes are common?

Business logic on-chain that costs gas and cannot be changed; frontends reading the chain directly for lists; no reorg handling in indexers; personal data on-chain; large content on-chain; transaction states hidden from users; and architecture bound to one chain's specifics. Cost realism is in dapp development cost.

What does sound architecture look like?

A tokenized asset platform keeps ownership and transfer rules in audited contracts, indexes events into a database for portfolio views and histories, runs a backend for identity verification, compliance checks, document management, and notifications, stores documents in object storage with hashes on-chain, and builds a frontend with explicit transaction states and clear signing prompts. Chain interaction sits behind an adapter layer, and a second chain is added later as configuration. The tokenization context is in the real-world asset tokenization whitepaper.

How FISTA Solutions builds dApps

FISTA Solutions designs dApps with a minimal audited on-chain core, reorg-safe indexers, conventional backends with chain adapters, off-chain storage with anchoring, frontends with explicit transaction lifecycles, and platform-agnostic abstraction. The blockchain practice delivers the systems, web and mobile builds the frontends, and forward deployed engineers embed with client teams. The record behind the approach is 150+ projects with 99.9% uptime.

To build a dApp that is fast, secure, and not married to one chain, message FISTA on WhatsApp, or read the smart contract development guide for the on-chain core.