Web3 app development: the dApp stack, layer by layer

Web3 app development means building a web or mobile front end that lets users act on smart contracts with their own wallets. This guide walks through each layer of a web3 dApp, the decisions at each layer, the main security risks, the build steps, and typical timelines.

A web3 app team writes the contracts and has them audited. The same team connects wallets, RPC access, indexing and storage, and builds an interface that handles gas fees, failed transactions and chain switches. The guide to dApp development companies covers dApp categories and how to choose a team.

The web3 dApp stack at a glance

Solana has a similar shape with different tools. Developers write programs in Rust, often with the Anchor framework. Solana stores data in accounts instead of contract storage, and dApps connect through wallet adapters instead of EIP-1193. Pick the chain first, because the chain decides most of the other choices.

Smart contracts

Contracts are the hardest part to fix after launch, so keep them small. Use audited standards where they exist: ERC-20 for fungible tokens, ERC-721 or ERC-1155 for NFTs, ERC-4626 for yield vaults and EIP-2981 for royalty information. Keep anything that needs no on-chain enforcement off-chain, such as profiles, search and recommendations.

• Testing. Write unit tests, fuzz tests and invariant tests in Foundry or Hardhat. An invariant is a rule that must always hold, such as "total deposits equal the sum of balances".
• Upgradeability. A proxy lets you fix bugs, but it also lets an admin change the rules. If you use a proxy, put upgrades behind a multisig wallet and a timelock, and tell users.
• Admin keys. Each privileged function gives attackers a target, so list these functions and keep as few as possible.
• Audit. A contract that holds meaningful value needs an independent review before mainnet. The smart contract audit guide explains audit scope and report contents.

The guide to smart contract development covers contract engineering in more depth.

Wallet connection and signing

Most dApps lose users at the wallet step. Current dApps use these patterns:

• Several wallets. EIP-6963 discovery stops browser wallet extensions from conflicting with each other, and WalletConnect adds mobile wallets.
• Sign-In with Ethereum. EIP-4361 lets users start a session by signing a readable message.
• Typed data signing. EIP-712 lets wallets show what the user approves in an off-chain order or permit.
• Embedded and smart-account wallets. Newcomers sign up with email or a passkey. ERC-4337 smart accounts, or EIP-7702 delegation, allow batched actions and gas paid by the app. EIP-7702 has been live on Ethereum since the Pectra upgrade in May 2025.
• Limited approvals. Ask only for the token allowance that the action needs, not an unlimited one.

The web3 wallet development guide covers how wallets are built.

Transaction lifecycle

Users need to see each state of a transaction: awaiting signature, submitted, pending, confirmed, failed or replaced. Simulate each transaction before you ask for a signature, so the app catches a revert early. Show the estimated fee in local currency, and handle transactions that are dropped or sped up. On a rollup, a sequencer confirms a transaction fast and final settlement on Ethereum comes later, so explain this difference where it matters, such as in bridging.

Reading data: RPC and indexing

Direct RPC calls to contracts work well for current balances. RPC calls are slow and costly for history, such as all trades by one user, and for totals, such as this week's volume. Indexers solve this problem by listening to contract events and writing them into a database that the app can query.

• Emit detailed events from your contracts, because the indexer sees only what the contracts emit.
• Handle chain reorganizations, so the indexer rolls back data from blocks that the chain replaced.
• Use at least two RPC providers with failover, so one provider's outage does not stop your dApp.
• Limit and cache reads in your own backend instead of exposing an RPC key in the browser.

Storage and front-end hosting

Store NFT metadata and media on content-addressed storage, such as IPFS with reliable pinning or Arweave for permanent storage. Reference each file by its content hash, so nobody can change it without notice. Many teams host the front end on normal servers for speed and also publish it to IPFS as a fallback. Attackers have taken over dApp front ends through DNS and hosting accounts and drained users' funds, so lock the domain registrar account, use hardware keys for deployment accounts and set a content security policy.

Choosing a chain

Most consumer dApps launch on a layer-2 rollup because fees are low. Ethereum's Dencun upgrade in March 2024 made rollup data much cheaper, and the Fusaka upgrade in December 2025 raised the data capacity again. Ethereum mainnet suits high-value actions that happen rarely. Other layer-1 chains, such as Solana, suit high-throughput consumer apps with their own ecosystem.

Four factors matter more than raw speed: where your users and liquidity already are, wallet support, available oracles and bridges, and how mature the developer tools are. If you need several chains, plan for them from the first day. The guide to interoperability and layer 2 covers the trade-offs.

The web3 dApp development process

1. Split on-chain and off-chain. Write down which rules need trustless enforcement and which can run on a server. Keep the on-chain part small.
2. Design contracts and events, including admin roles, the upgrade policy and failure cases.
3. Build a testnet prototype with a minimal front end, and test the flow with real wallets.
4. Build the indexer and backend in parallel with the contracts, so the interface has real data to show.
5. Harden the code. Run fuzz and invariant tests and an internal review, then freeze the contract code and commission an external audit.
6. Run a beta with limited value. Use deposit limits or allowlists on mainnet and monitor closely.
7. Launch with monitoring and an incident plan. Set on-chain alerts, add a pause function where it fits, and prepare messages for users.

Failure modes to design against

• Oracle manipulation. A contract that reads a price from one DEX pool in the same transaction is exposed, because an attacker can borrow a flash loan, move that price and exploit the contract. Use robust oracle feeds or time-weighted prices, and limit how far a price can move.
• Reentrancy and unchecked external calls. Follow the checks-effects-interactions order. Use reentrancy guards where state changes follow external calls. Watch for token callbacks, such as the hooks in ERC-777 tokens and ERC-1155 receivers.
• Signature replay. Off-chain signatures need nonces, expiry times and a domain separator that includes the chain ID. Without these, an attacker can reuse a signature on another chain or contract.
• Stale prices in the interface. The interface shows one price, and the transaction executes at another. Enforce slippage limits and deadlines in the contract call, not only in the interface.
• Single points of failure. One RPC provider, one indexer or one hosting account can stop the dApp. Give each a fallback or at least a tested recovery plan.

Web3 app development timeline and cost drivers

The ranges below assume an experienced team and exclude token and marketing work.

Audit cost and waiting time grow with contract complexity and code size, and well-known auditors are often booked weeks ahead. Running costs include RPC and indexing services, hosting, monitoring and gas for any transactions the app pays for.

Questions to ask a team

• Which parts of the design must be on-chain, and why?
• Who holds admin keys and upgrade rights after launch?
• Can you show invariant tests from a previous project?
• How does the front end handle reverts, reorganizations and RPC failures?
• Which audit firm will you use, what is the scope, and how do you track findings until they are fixed?

The guide to choosing a web3 development company covers contracts, costs and red flags in more detail.

Frequently asked questions