Web3 Foundations and the Decentralized Internet

Introduction

The internet has developed through several broad architectural phases. Web 1.0 was primarily a publishing environment in which users consumed information from relatively static websites. Web 2.0 introduced interactive applications, social participation, cloud computing, and large-scale platform businesses. Web3 seeks to extend participation by making digital ownership, programmable transactions, and decentralized coordination fundamental features of online systems.

Web3 is not simply “a blockchain website.” It is an architectural and institutional approach in which users may control digital assets and identities, interact through open protocols, and participate in networks without requiring every relationship to be mediated by a dominant platform. Blockchain networks are important because they provide shared state, verifiable transaction history, and programmable execution among parties that may not fully trust one another. However, Web3 also depends on wallets, smart contracts, decentralized storage, governance systems, user interfaces, and legal and social institutions.

This chapter establishes the conceptual foundation for later study of decentralized finance, tokenized applications, decentralized autonomous organizations, and blockchain-based business models.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain the evolution from Web 1.0 through Web 2.0 to Web3.
2. Define decentralization, trust minimization, permissionlessness, composability, and digital ownership.
3. Explain the read-write-own model of the internet.
4. Distinguish Web3 architectures from conventional platform architectures.
5. Identify the technical, economic, governance, ethical, and regulatory trade-offs of Web3.
6. Analyse an application scenario and determine whether decentralization creates meaningful value.

1. The Evolution of the Web

Web 1.0: Read

The first widely used web was dominated by static or semi-static documents. Publishers controlled content production, while users mainly searched, read, and navigated. A website generally had a clear owner, a centralized server, and a relatively simple relationship between the publisher and the audience.

Web 1.0 had important strengths: content was easy to distribute, systems were comparatively understandable, and users did not usually need accounts on every website. Its limitations included weak interaction, limited personalization, and few mechanisms for users to contribute or retain value from their participation.

Web 2.0: Read and Write

Web 2.0 describes the transformation of the web into an interactive, participatory environment. Social networks, marketplaces, streaming platforms, collaborative software, and mobile applications enabled users to create content, communicate, transact, and collaborate.

The dominant Web 2.0 architecture is platform-centred. A company typically operates the servers, controls the database, authenticates users, defines application rules, and monetizes activity through advertising, fees, subscriptions, or data analysis. The platform may provide enormous convenience and scale, but it also becomes a central point of control.

The platform commonly controls:

• account access and identity records;
• application logic and ranking algorithms;
• data storage and visibility;
• payment relationships;
• dispute resolution;
• developer access through application programming interfaces; and
• the terms under which users may participate.

Users may create valuable content or build businesses on a platform without possessing a legally or technically transferable claim over the underlying account, audience, or data. A platform can change its rules, suspend an account, alter an algorithm, or discontinue a service.

Web3: Read, Write, and Own

Web3 adds a stronger concept of user participation: ownership. Users can hold cryptographic keys that control assets recorded on a blockchain, authorize transactions, and interact with protocols directly. Ownership in this context is not automatically identical to ownership under every national property law. It generally means that control over a blockchain-recorded asset is associated with possession of the relevant private key or a smart-contract permission.

A simplified comparison is shown below.

The read-write-own model is useful, but it should not be treated as a strict historical law. Web3 systems may still use centralized interfaces, custodians, cloud services, and companies. The model describes an intended distribution of capabilities, not a guarantee that every Web3 application is decentralized.

2. Core Principles of Web3

2.1 Decentralization

Decentralization is the distribution of control, authority, data, validation, or infrastructure across multiple independent participants rather than concentrating them in one organization. It has several dimensions:

• Infrastructure decentralization: multiple independent nodes provide computation and storage.
• Validation decentralization: multiple participants verify transactions or state changes.
• Political decentralization: decision-making authority is distributed among participants.
• Logical decentralization: the system does not depend on one proprietary database or one administrator.
• Economic decentralization: no single entity captures all value or controls essential access.

These dimensions can diverge. A blockchain may have many validating nodes but still depend on a small number of software developers, cloud providers, exchanges, or token holders. Therefore, the correct question is not merely “Is it decentralized?” but “Which function is decentralized, to what degree, and against which threat or failure?”

Decentralization can improve resilience, censorship resistance, auditability, and neutrality. It can also reduce efficiency, complicate upgrades, increase coordination costs, and make accountability less direct.

2.2 Trust Minimization

Trust minimization does not mean that Web3 eliminates trust. Instead, it attempts to replace some forms of personal, institutional, or platform trust with verifiable rules and economic incentives.

In a conventional payment platform, users trust the operator to maintain balances, prevent unauthorized changes, process transactions, and follow applicable rules. In a blockchain system, some of these functions are performed by consensus protocols and smart contracts. Participants still trust software developers, hardware, cryptographic algorithms, governance processes, wallet providers, data oracles, and legal institutions.

A useful distinction is between:

• Trustless execution: a system can execute predefined rules without requiring a particular intermediary to approve each transaction.
• Trust minimization: the system reduces the number or scope of trusted parties.
• Trust-free interaction: an unrealistic claim that no assumptions or relationships of trust exist.

Smart contracts reduce discretion in the execution of coded rules, but they introduce code risk. If the code contains an error, faithful execution may produce an undesirable result. Consequently, trust is shifted from an institution to a combination of software, cryptography, incentives, governance, and operational practices.

2.3 Permissionlessness

A permissionless system allows a participant to use a protocol, submit a transaction, or deploy an application without obtaining individual approval from a central gatekeeper, subject to protocol rules and applicable law. Public blockchains commonly allow anyone with network access and the required transaction fee to create an address and submit transactions.

Permissionlessness encourages innovation because developers can build without negotiating bilateral access agreements. It also enables open participation in markets, payment systems, and digital communities. Nevertheless, permissionless access does not imply costless access, anonymity, legal immunity, or guaranteed inclusion. Network fees, congestion, technical knowledge, geographic restrictions, sanctions, identity requirements at regulated interfaces, and governance rules may limit participation.

2.4 Composability

Composability is the ability to combine protocols, smart contracts, assets, and interfaces as building blocks. A decentralized exchange, lending protocol, collateral token, wallet, and data oracle may be integrated into one transaction or application.

Composability produces innovation through reuse. A developer need not recreate every financial or identity function. However, composability creates dependency chains. If one component fails, is attacked, becomes insolvent, or changes its interface, applications built on it may also be affected. This is sometimes described as “systemic composability risk.”

Three forms are especially important:

1. Technical composability: contracts can call or exchange data with one another.
2. Economic composability: assets and incentives interact across protocols.
3. Social or governance composability: communities and organizations coordinate using shared standards.

2.5 Digital Ownership

Digital ownership refers to a recognized ability to control, transfer, use, or benefit from a digital asset. In Web3, control is often represented by a blockchain state associated with an address. A private key authorizes transactions from that address, although the legal meaning of that control depends on jurisdiction and contractual arrangements.

Ownership should be separated into several rights:

• possession or control;
• transferability;
• use or access;
• economic benefit;
• governance participation;
• licensing or intellectual-property rights; and
• legal title.

Holding a token does not automatically grant copyright, equity, voting power, or a claim on revenue. The rights are determined by the token design, smart contract, associated legal documents, and applicable law.

2.6 Transparency and Verifiability

Public blockchains often make transaction histories and smart-contract code inspectable. This can support auditability and reduce information asymmetry. Yet transparency is not equivalent to comprehension. Blockchain data may be pseudonymous, technically complex, incomplete without off-chain information, and difficult for ordinary users to interpret.

A transaction can be verifiable as having occurred while the real-world event it represents remains uncertain. For example, a token may record that an oracle supplied a temperature or exchange rate, but users must still assess whether the oracle was accurate and independent.

3. Conventional Platform Architecture and Web3 Architecture

Conventional platform architecture

A typical platform consists of a client application, centralized application servers, a proprietary database, authentication services, payment systems, and administrative controls. The platform operator can generally read and modify database records, determine access rights, reverse transactions, and update software unilaterally.

This design is efficient because one organization can optimize the database, coordinate upgrades, moderate content, and provide customer support. It also creates concentration risk. A technical outage, business failure, malicious administrator, government order, or policy change may affect the entire service.

Web3 architecture

A Web3 application commonly includes:

1. User interface: a website, mobile application, or other client.
2. Wallet: software or hardware used to manage keys and sign transactions.
3. Blockchain network: a replicated state machine that records transactions.
4. Smart contracts: deterministic programs that enforce specified rules.
5. Off-chain services: indexing, storage, computation, messaging, and analytics.
6. Oracles: mechanisms that communicate external information to contracts.
7. Governance: processes for changing parameters, upgrading contracts, or resolving disputes.

The interface may be hosted centrally even when the contracts are decentralized. Likewise, a supposedly decentralized application may rely on one company’s API, database, oracle, or upgrade key. Architectural analysis must therefore examine the complete system rather than its branding.

4. Blockchain as a Coordination Technology

A blockchain can be understood as a replicated state machine. It maintains a state, accepts proposed transactions, applies valid state-transition rules, and reaches agreement among participating nodes about an ordered history. The chain is not valuable merely because data is stored in blocks; its significance lies in coordinating parties that may not share a single administrator.

A simplified state-transition model is:

Here, S_t is the system state at time t, T_t is the set or ordered batch of valid transactions applied at that time, F is the protocol’s state-transition function, and S_t+1 is the resulting state. The model assumes that nodes apply the same validation rules and that the consensus mechanism establishes an accepted transaction order. It is a conceptual model, not a complete description of every blockchain.

Consensus mechanisms help participants agree on the accepted state. Cryptographic signatures help demonstrate authorization by a key holder. Hash functions help link records and detect alteration. Economic incentives and penalties attempt to align participant behaviour with protocol security.

These mechanisms do not solve every problem. They cannot independently determine whether a physical asset exists, whether a person gave informed consent, whether an oracle is truthful, or whether a legal claim will be enforced in court.

5. Identity, Keys, and Control

Web2 identity is usually account-based. A service provider creates and manages an account, and access may be recovered through email, customer support, or institutional procedures. Web3 identity is often key-based. The user signs a message or transaction using a private key, and the network verifies the corresponding public key.

Key-based control provides portability and reduces dependence on a single account provider. It also creates responsibility. Loss of a private key may result in loss of access. Theft or phishing may enable unauthorized transactions. A wallet is therefore not merely a digital username; it is a security instrument.

Professional practice requires:

• hardware-backed key protection for high-value assets;
• multi-signature approval for organizational funds;
• separation of operational and treasury accounts;
• transaction simulation and address verification;
• documented recovery procedures;
• least-privilege permissions; and
• regular review of contract approvals.

Account abstraction and smart-contract wallets seek to improve usability by enabling programmable recovery, spending limits, social recovery, and batch transactions. These features may reduce key-management burdens but introduce additional contract and governance dependencies.

6. Economic and Institutional Implications

Web3 changes the relationship between users, firms, and infrastructure. A protocol may be used by a global community, upgraded through governance, and monetized through transaction fees or token-based incentives. This can support new organizational forms, but it does not remove economic power.

Token systems may create network effects: the usefulness of a network can increase as more participants, liquidity, developers, or compatible applications join it. Incentive design must distinguish productive rewards from unsustainable subsidies. A token price increase is not proof of utility, security, or social value.

Web3 organizations also face the “decentralization paradox.” Early development often requires concentrated leadership and capital, while later decentralization may distribute control. Excessive centralization undermines credible neutrality; premature decentralization can produce unclear accountability and poor decisions.

Managers should evaluate:

• the actual source of customer value;
• who controls upgrades and emergency actions;
• whether incentives are durable;
• who bears losses when code fails;
• how users are onboarded and protected;
• whether regulation applies; and
• whether decentralization is necessary for the use case.

7. Applied Case: A Blockchain-Based Cross-Border Remittance Network

The following is an illustrative case, not a report of a specific company.

Background

A remittance provider serves migrant workers who send small payments to relatives in several countries. The existing process involves local agents, correspondent banks, foreign-exchange conversion, and settlement delays. Fees are difficult to compare, and recipients may have limited access to formal banking services.

Problem

The provider wants faster settlement and lower reconciliation costs but must address volatility, fraud, consumer protection, sanctions screening, and local licensing requirements. A public blockchain is proposed as the settlement layer.

Analysis

A blockchain could provide a shared transaction record among participating institutions and reduce duplicated reconciliation. Stable-value tokens could represent a settlement instrument, while wallets could enable direct receipt. However, the system would not automatically eliminate intermediaries. Users may still depend on regulated on-ramps, local cash-out agents, identity verification, foreign-exchange providers, and customer-support services.

The main Web3 advantages would be:

• programmable settlement;
• transparent transaction status;
• interoperable wallets and payment contracts;
• reduced dependence on one internal ledger; and
• potential access to open liquidity or financial infrastructure.

The principal risks would be:

• private-key loss or theft;
• incorrect oracles and exchange rates;
• smart-contract vulnerabilities;
• blockchain congestion and fees;
• stablecoin issuer risk;
• privacy leakage from public transaction data; and
• conflict between permissionless transfer and legal compliance.

Approach and solution

The provider designs a hybrid architecture. Regulated entities conduct identity checks and cash conversion. A smart contract manages settlement between approved liquidity providers. A stable-value asset is used only where its reserve, redemption, and legal status are understood. Multi-signature controls protect treasury funds. Transaction limits and monitoring address fraud and compliance. A public audit documents contract behaviour, while emergency procedures allow a narrowly defined pause subject to governance and regulatory oversight.

Outcome

The design can reduce reconciliation time and improve traceability, but it does not make the service entirely decentralized or trustless. Trust is redistributed among the blockchain, token issuer, regulated agents, liquidity providers, software auditors, and governance authorities. The business case depends on measurable improvements in settlement, cost, reliability, and inclusion rather than on the use of blockchain alone.

Learning points

1. A blockchain is most valuable when several parties need a shared state but lack a fully trusted administrator.
2. Hybrid systems may be more realistic than purely decentralized systems.
3. Token control is not the same as legal ownership.
4. Compliance and consumer protection must be designed into the system.
5. Decentralization should be evaluated function by function.

8. Limitations, Ethics, and Governance

Scalability and efficiency

Replicated execution means that many nodes may perform similar validation work. Public networks can face limited throughput, congestion, and variable fees. Layer-two systems, sidechains, and alternative execution environments seek to improve capacity, but they introduce new assumptions and bridge risks.

Privacy

Public ledgers may expose transaction patterns even when addresses are not directly named. Privacy-enhancing technologies can reduce exposure, but they may complicate compliance and investigation. A responsible design follows data minimization, avoids unnecessary personal information on-chain, and separates public proofs from private records where possible.

Security and consumer protection

Irreversible transactions can protect settlement finality but make mistakes difficult to correct. Phishing, malicious contracts, fake interfaces, oracle manipulation, bridge exploits, and governance attacks are significant risks. Users require clear disclosures, safe defaults, spending limits, incident response, and accessible remedies.

Governance and accountability

Governance tokens do not automatically create democratic governance. Voting power may be concentrated, voter participation may be low, and technically complex proposals may favour sophisticated participants. Effective governance defines proposal procedures, quorum requirements, emergency powers, conflict-of-interest rules, upgrade delays, and accountability mechanisms.

Regulation

Legal treatment varies by jurisdiction and may involve payments law, securities regulation, consumer protection, anti-money-laundering obligations, taxation, data protection, and financial-market rules. Developers and managers must not assume that decentralized software is outside regulatory scope. Legal analysis should examine functions, rights, control, marketing, and the location and role of responsible participants.

Environmental considerations

The environmental impact of a blockchain depends on its consensus mechanism, hardware, energy sources, transaction demand, and system design. It is inaccurate to generalize from one network to all blockchain systems. Sustainability analysis should use evidence about actual energy and resource use rather than slogans.

9. Best-Practice Framework for Evaluating a Web3 Proposal

Before adopting Web3, an organization should answer the following questions:

1. Problem fit: Does the problem involve shared state, cross-organizational coordination, digital scarcity, or portable ownership?
2. Decentralization need: What failure, censorship, or concentration risk is reduced?
3. Trust analysis: Which parties must still be trusted, and what evidence supports that trust?
4. Control analysis: Who controls keys, upgrades, or emergency functions?
5. Data analysis: What information is public, private, or stored off-chain?
6. Security analysis: What happens if a key, contract, oracle, bridge, or dependency fails?
7. User experience: Can ordinary users understand fees, permissions, risks, and recovery?
8. Legal analysis: Which jurisdictions and regulatory obligations apply?
9. Economic sustainability: Are incentives based on genuine utility or temporary speculation?
10. Exit and portability: Can users withdraw assets and continue using compatible services if the operator disappears?

This framework helps prevent “blockchain solutionism,” the assumption that adding a blockchain automatically improves a system.

Contemporary Developments

Current Web3 development is moving toward modular architectures, rollups and other scaling approaches, account abstraction, decentralized physical infrastructure, tokenized real-world assets, privacy-preserving computation, verifiable credentials, and improved interoperability. Artificial intelligence is also being combined with blockchain in areas such as agent payments, provenance records, model licensing, and decentralized computation.

These developments should be evaluated critically. Blockchain can provide evidence that a digital record was signed or that a transaction occurred, but it cannot by itself prove that AI-generated content is truthful or that an off-chain asset exists. Similarly, tokenization can improve transferability while also creating new liquidity, custody, valuation, and regulatory risks.

Chapter Summary

Web3 emerged from limitations associated with centralized platform architectures and proposes a more open model based on protocols, cryptographic control, programmable assets, and distributed coordination. Web 1.0 emphasized reading; Web 2.0 enabled reading and writing through centralized platforms; Web3 aims to add user ownership and portability.

The central principles are decentralization, trust minimization, permissionlessness, composability, verifiability, and digital ownership. None of these principles is absolute. Decentralization has technical, political, logical, and economic dimensions. Trust is reduced in some areas but remains necessary for software, governance, oracles, legal systems, and service providers. Permissionless protocols may still involve fees and legal constraints. Composability encourages innovation but creates dependency chains.

A Web3 system should be analysed as a complete architecture involving interfaces, wallets, blockchains, smart contracts, off-chain services, oracles, and governance. The strongest applications are those in which shared state, portable ownership, or reduced dependence on a central intermediary solves a genuine problem. Good professional practice combines technical design with security, privacy, legal compliance, economic sustainability, user protection, and accountable governance.

Key Terms

Decentralization: Distribution of control, validation, infrastructure, or authority across multiple independent participants.

Web 1.0: The early, primarily read-oriented and document-centred web.

Web 2.0: The interactive, platform-centred web in which users read, write, share, and transact.

Web3: An internet architecture emphasizing open protocols, cryptographic control, programmable assets, and user ownership.

Read-write-own: A model describing Web3 participation as consuming information, creating content or transactions, and controlling digital assets.

Trust minimization: Reduction of dependence on discretionary intermediaries through code, cryptography, incentives, and verification.

Permissionlessness: Ability to access or use a protocol without individualized approval from a central gatekeeper.

Composability: Capacity to combine software, assets, and protocols as interoperable building blocks.

Smart contract: Program deployed on a blockchain that executes according to coded rules.

Blockchain: A replicated, consensus-maintained record of transactions or state changes.

Consensus: Process by which network participants agree on an accepted state or transaction history.

Private key: Secret cryptographic value used to authorize transactions or signatures.

Wallet: Software or hardware that manages keys and interacts with blockchain networks.

Oracle: Mechanism that supplies external information to a smart contract.

Digital ownership: Control or rights over a digital asset, represented technically and interpreted legally.

Protocol: Set of technical rules governing communication, validation, or interaction.

Governance: Processes through which system rules, parameters, or upgrades are decided.

Platform architecture: Centralized design in which an organization controls application logic, data, and access.

Blockchain solutionism: Assumption that blockchain use is inherently beneficial regardless of the problem.

Account abstraction: Design approach that enables programmable wallet behaviour and more flexible transaction authorization.

Review Questions

Short Answer Questions

1. What are the principal differences between Web 1.0, Web 2.0, and Web3?
2. Define decentralization and identify two of its dimensions.
3. Why is “trustless” an imprecise description of most Web3 systems?
4. What does composability mean, and why can it create systemic risk?
5. Why does possession of a token not automatically establish legal ownership or copyright?

Long Answer Questions

1. Compare a conventional platform architecture with a Web3 architecture, including databases, identity, transactions, governance, and failure risks.
2. Explain the read-write-own model and critically evaluate whether it describes all Web3 applications.
3. Discuss the benefits and limitations of permissionless participation in financial and social applications.
4. Explain how blockchain systems function as coordination technologies without assuming that they eliminate intermediaries.
5. Analyse the ethical, privacy, security, and regulatory challenges associated with public blockchain applications.

Analytical / Application Questions

1. A university wants to issue blockchain-based certificates. Determine which functions should be on-chain and which should remain off-chain. Justify your design using privacy, verification, ownership, and governance considerations.
2. A decentralized finance application depends on one price oracle, one upgrade administrator, and a centralized web interface. Assess its degree of decentralization and identify the major trust assumptions.
3. Evaluate whether a blockchain is appropriate for a national food-traceability system involving farmers, distributors, retailers, regulators, and consumers. Use the problem-fit, trust, data, security, and legal questions in the evaluation framework.

Multiple Choice Questions with Answers

Question 1

Which feature most clearly distinguishes the Web3 read-write-own model from the Web2 read-write model?

A. Use of static HTML documents

B. User control over certain digital assets through cryptographic keys

C. Removal of all online intermediaries

D. Exclusive reliance on centralized databases

Correct Answer: B. User control over certain digital assets through cryptographic keys

Question 2

What is the most accurate meaning of trust minimization?

A. Eliminating every form of trust from a system

B. Replacing all laws with software code

C. Reducing dependence on discretionary intermediaries through verification, code, and incentives

D. Allowing transactions without any security assumptions

Correct Answer: C. Reducing dependence on discretionary intermediaries through verification, code, and incentives

Question 3

Which example best illustrates composability?

A. A company preventing external applications from accessing its database

B. A smart contract using a lending protocol and a token exchange in one application

C. A user storing a password in a spreadsheet

D. A website displaying a static document

Correct Answer: B. A smart contract using a lending protocol and a token exchange in one application

Question 4

Which statement about permissionless systems is correct?

A. They are always free of transaction fees

B. They guarantee anonymity and legal immunity

C. They allow protocol participation without individualized approval from a central gatekeeper, subject to rules and constraints

D. They cannot be used with regulated services

Correct Answer: C. They allow protocol participation without individualized approval from a central gatekeeper, subject to rules and constraints

Question 5

In the simplified state-transition model S_t+1 = F(S_t, T_t), what does S_t represent?

A. The system state at time t

B. The private key of a user

C. The transaction fee at time t

D. The name of the consensus algorithm

Correct Answer: A. The system state at time t

Question 6

Which statement best describes a blockchain oracle?

A. A device that permanently stores private keys

B. A mechanism that supplies external information to a smart contract

C. A replacement for all governance processes

D. A centralized database that validates every blockchain transaction

Correct Answer: B. A mechanism that supplies external information to a smart contract

Question 7

Why can a highly decentralized blockchain application still involve substantial trust?

A. Users must trust software, oracles, governance, wallet providers, or legal institutions

B. Decentralization automatically makes code correct

C. Public blockchains do not use cryptography

D. Consensus removes the need for any external information

Correct Answer: A. Users must trust software, oracles, governance, wallet providers, or legal institutions

Question 8

What is a major risk of composability?

A. Integrated components can create dependency chains in which one failure affects other applications

B. Protocols become impossible to reuse

C. Users cannot transfer digital assets

D. All transactions become private by default

Correct Answer: A. Integrated components can create dependency chains in which one failure affects other applications

Question 9

Which design choice is most appropriate for protecting a high-value organizational treasury?

A. A single employee’s unprotected personal key

B. A publicly posted seed phrase

C. Multi-signature approval and documented recovery procedures

D. An unverifiable anonymous administrator

Correct Answer: C. Multi-signature approval and documented recovery procedures

Question 10

What is blockchain solutionism?

A. The formal verification of smart contracts

B. The assumption that adding blockchain is beneficial regardless of the underlying problem

C. The use of multiple independent validators

D. The legal recognition of token ownership

Correct Answer: B. The assumption that adding blockchain is beneficial regardless of the underlying problem