A full stack dapp combines a user interface, a wallet interaction, on-chain contracts, and a path for communicating with the blockchain; it may also rely on off-chain services such as data indexers or storage. These parts do not all run on-chain, and the label alone does not show how decentralized or dependable any particular layer is. For developers and technical decision-makers, the practical task is to identify which component performs each operation and what happens if a supporting service is unavailable.
What “full stack” means for a dapp
“Full stack” describes the components needed to present and operate an application, rather than just its contract code. A smart contract is one part of that stack. The interface, wallet, blockchain access path, and any supporting data services have distinct roles and may operate under different control and availability assumptions.
The on-chain layer consists of records and rules handled by the blockchain. Other components run off-chain: for example, the user interface and an application service that retrieves or organizes data. A dapp architecture can combine both. It should not be assumed that every component is decentralized simply because the application interacts with a blockchain.
The main layers of a full stack dapp
A component map helps separate the reader-facing application from the network and any services around it:
| Component | Typical role in the flow | Where it operates |
|---|---|---|
| User interface | Presents information and lets a user request an action | Off-chain application code |
| Wallet | Provides an interaction path for the user to authorize a transaction or other wallet-supported request | Separate from the application interface |
| Smart contract | Applies programmed rules to on-chain state when invoked | On-chain |
| Blockchain access | Carries requests to network nodes and returns protocol data | An access service or node connection |
| Optional backend, indexer, or storage | Supplies application-specific data or derived views | Off-chain |
The table describes a general architecture, not a required design. An application may use only some of these pieces, and their implementation and control can vary.
Interface. The interface turns application state and available actions into screens, forms, and status messages. It can request data and prepare an interaction, but it is not the same thing as the contract that enforces on-chain rules. A screen may also rely on off-chain services to populate information.
Wallet. A wallet is a separate component in the authorization path. The application can request a wallet-supported action, while the wallet handles keys and signing. The EIP-1193 provider model, for example, describes a request-and-event interface through which an application accesses Ethereum via a client; the wallet separately manages keys and signing. This is an Ethereum-specific example, not a universal wallet architecture.
Contract and blockchain. On Ethereum, a contract is code and data at a blockchain address. A user account can invoke a contract function by submitting a transaction to that deployed contract. These are network-specific descriptions; other networks can have different execution models. [claim_eth_code_state_address, claim_eth_transaction_invocation]
Blockchain access and data services. An access path lets application components communicate with the network. Ethereum JSON-RPC exposes protocol-level records such as blocks, transactions, receipts, state queries, and contract logs; it does not provide a universal application-specific entity model. An application may therefore use a separate service to organize records into a convenient view. One example is a Subgraph, which extracts and processes blockchain data into stored entities that applications can query through GraphQL. That indexed view is derived data and can lag, fail, or require correction as chain history changes. [claim_rpc_raw_records, claim_subgraph_indexing]
How a user action moves through the stack
Consider a user requesting a state-changing action. This sequence illustrates a common pattern; exact interfaces and access paths depend on the application and network.
- The interface prepares the request. It gathers the user’s requested action and any inputs the application needs. If it needs network data first, it can query through a blockchain access path or an application data service.
- The wallet handles authorization. Where the operation requires a signed transaction, the interface asks the wallet to present the request. The wallet’s role is distinct from the interface’s: the provider model separates application access from wallet key management and signing.
- The signed instruction is sent to the network. For an Ethereum state-changing interaction, a signed transaction is broadcast, selected for a block, executed, and later gains stronger confirmation or finality. A receipt can report failed execution even if the transaction was included in a block.
- The contract processes the interaction. If the transaction invokes a contract, the network applies that contract’s programmed behavior to on-chain state. The application should not treat a submitted request as proof that the intended state change succeeded; it can check the resulting network records and execution status. [claim_eth_code_state_address, claim_transaction_lifecycle]
- The interface displays a result. The application can read network records directly or use an indexed view for display. If it uses an indexer, that view is derived and may not immediately match the underlying chain history. The interface should make clear what status it is showing and which data path supplies it. [claim_rpc_raw_records, claim_subgraph_indexing]
A read-only request can follow a different path from a state-changing transaction. The important scoping question is whether the user is merely asking the application to retrieve data or authorizing an instruction that changes blockchain state.
Trust boundaries and design trade-offs
A trust boundary is a point where responsibility or assumptions change between components. The contract may enforce some on-chain rules, while the interface presents actions and an off-chain backend may decide what data to provide. A user should not assume that a display rule or backend policy is enforced by the contract unless the architecture makes that enforcement clear.
Blockchain access also has a distinct role from contract execution. Ethereum full nodes independently verify blocks and transactions against protocol rules rather than relying entirely on another node. But an application’s choice of access path and any services it adds remain separate architectural decisions; node verification does not establish that the interface or its data services are correct. source
Optional supporting services can add dependencies. For example, an indexer produces a derived view that can lag or fail. If the interface relies on that view, the application needs to decide how it communicates delayed or unavailable data rather than treating the indexer’s output as the chain itself.
The same separation matters when reviewing control. A DAO treasury, for example, can be governed by smart-contract rules and group approval processes rather than unilateral access by one operator. That example illustrates why authority should be identified at the component level: a contract’s rules, an application’s access policies, and a service operator’s controls are not interchangeable. source
Do not infer security, privacy, resilience, or recovery properties from a “full stack” label. Those conclusions require evidence about the specific contracts, wallet path, access services, data sources, and operating arrangements involved.
Questions to resolve before building or evaluating one
Use these questions to turn the component map into an architecture review:
- Which rules and state must be enforced on-chain, and which information can be handled by off-chain services?
- Which component connects the interface to the blockchain, and what records does it return?
- Does the application rely on an indexer or other derived view? If so, how does it distinguish that view from underlying network records when data lags or is unavailable?
- Where does wallet authorization occur, and how does the interface communicate transaction status or failure?
- Which decisions belong to the contract, the interface, a backend, or an operator?
For legal, tax, regulatory, or compliance questions, seek qualified advice and current evidence specific to the relevant jurisdiction. The technical component map does not answer those questions.
Sources and references
- JSON-RPC API — ethereum.org; retrieved 2026-10-18.
- Nodes and Clients — ethereum.org; retrieved 2026-10-18.
- What is a DAO? — ethereum.org; retrieved 2026-10-19.