A ticketing team must decide whether attendees should sign in with portable wallets, receive transferable passes, and settle resales through shared contracts, or whether an ordinary account database would serve them better. Web3 is a broad product category for applications that give public networks, user-controlled accounts, and transferable digital objects an important role. The label describes an architecture and product ambition, not a guarantee of quality, ownership, or decentralization.
Most useful Web3 products are mixed systems. A blockchain may settle a payment or record a membership pass, while a company-operated website renders screens, an indexer organizes events, a cloud service sends notifications, and a support team handles mistakes. Product analysis begins by separating those layers. It then asks whether putting a particular action onchain creates portability, credible commitments, or coordination benefits that justify added cost and complexity.
What you will learn
- Define Web3 and dapp without assuming that every component is decentralized
- Trace a user action across wallet, interface, infrastructure, and onchain settlement
- Identify when portability or shared state creates a concrete product benefit
- Recognize where conventional operators still control access, presentation, and recovery
A stack of components, not a single technology
At the onchain layer, a network orders transactions and stores state according to its protocol. Smart contracts add application rules such as who can transfer a pass, how a marketplace settles a sale, or which credential satisfies an access check. Wallets hold or coordinate authorization keys and present requests for a user to approve. These components can create a shared state that competing applications inspect under the same technical rules.
Around that shared state sits familiar software. A front end can hide or highlight assets, an RPC provider relays requests, an indexer turns raw events into searchable data, and a database may store profiles or preferences. Each service has an operator and failure mode. Calling the complete product decentralized because one contract is onchain would erase the practical power of these other actors and make recovery or censorship claims impossible to evaluate.
What wallets and contracts change
A wallet can act as an account that works across unrelated products, but only where those products support the same network and standards. Instead of asking a platform to update its private customer table, a user signs a message to authenticate or a transaction to change onchain state. The signature proves control of an address under the relevant cryptographic rules; it does not prove a legal name, good intent, or entitlement to customer support.
Smart contracts can make selected rules inspectable and consistently executable. If a contract permits any holder of a pass to transfer it, the main website cannot quietly rewrite that contract rule. Yet upgrade keys, pause functions, token issuer controls, and interface restrictions may qualify the promise. The useful question is not whether control disappeared, but which powers moved into code, which remained with people, and how users can respond when either layer fails.
When onchain state earns its place
Onchain state is most defensible when several parties need a common record without appointing one application as the permanent owner of that record. Examples include a transferable access pass recognized by multiple venues, a payment that settles to a merchant-controlled address, or a game asset that independent marketplaces can read. Public verifiability can also help users audit supply rules or verify that a particular address authorized an action.
The trade-off is real. Transactions may cost money, confirmation can be delayed, public activity can expose relationships, and mistakes can be hard to reverse. A conventional database is often better for drafts, private messages, search indexes, fraud review, or data that must be corrected. Good product architecture uses onchain execution selectively, after defining the user benefit, instead of forcing every click into a permanent shared ledger.
Evaluate the promise layer by layer
Begin with the user's job: buying, publishing, playing, proving eligibility, or moving money. Then trace the happy path and the failure path. Record what the wallet signs, which contract changes, where data lives, who pays fees, and which company or community can pause, upgrade, remove, or restore access. This produces a control map rather than a marketing verdict.
Finally compare the Web3 design with a simpler alternative. Portability matters only if another usable application can interpret the state. Ownership matters only if the holder has meaningful control and understandable rights. Composability matters only if integrations are technically and economically viable. A token is not evidence of demand, and transaction volume can reflect incentives or automation rather than satisfied recurring users. Product outcomes require product evidence.
Common misconceptions
“Web3 means every part of an application runs on a blockchain.”
Most dapps combine onchain contracts with websites, wallets, indexers, gateways, databases, and support operations. The distribution of control must be assessed component by component.
“Adding a token automatically gives users ownership.”
A token can represent a transferable record, but practical ownership depends on contract permissions, custody, legal terms, supporting services, and whether the represented benefit persists.
Risks and limitations
- Wallet signatures and approvals can be confusing, allowing a deceptive interface to request authority broader than the visible product action.
- Public transaction history can reveal behavior and relationships when addresses become linked to people or reused across applications.
- A contract may remain available while its front end, indexer, gateway, or offchain content fails, leaving users with state they cannot easily use.
- Upgrade keys, issuer controls, or concentrated infrastructure can contradict broad marketing claims even when core transactions settle onchain.
Key takeaways
- Web3 describes applications that use wallets, open networks, and programmable shared state for meaningful product functions.
- A dapp is usually a hybrid stack whose onchain and centralized components should be mapped separately.
- Wallet control proves authorization by an address, not identity, safety, or legal ownership by itself.
- Onchain design is strongest when portability, shared settlement, or credible rules solve a defined user problem.
- Tokens, transaction counts, and the Web3 label do not substitute for retention and user-value evidence.
Primary and further reading
Test your understanding
Score at least 2 out of 3 to complete this lesson. Explanations appear after you submit.