The Web3 industry map
You now understand the machine. This is the industry built on top of it.
This page is Landscape, not Core
You are not expected to master these sectors. You are expected to hear a protocol named and think "that is a lending protocol" or "that is infrastructure" — and to know roughly what problem that sector is trying to solve.
Recognition. Not expertise.
Learning objectives
- Name the major Web3 sectors and what problem each addresses
- Explain whether blockchain is load-bearing in a sector — if removed, would the core product stop working or meaningfully change?
- Give at least one representative example per sector you care about
- State a real limitation for any sector you name
Core
How to read every sector below
Each one gets four questions, and the fourth is the one that matters:
- What problem does this sector solve?
- How does blockchain actually matter here?
- What are one to three recognisable examples?
- What is one major limitation or risk?
Question 4 is not pessimism
Every sector below has real problems. A description that omits them is marketing. If you can only recite what a sector claims, you cannot evaluate anything in it — and the Week 4 mission asks you to evaluate something.
Want to see the industry at a glance?
No single map captures Web3 perfectly. Categories overlap, companies move between sectors, and maps become outdated. Use them for orientation, not as a definitive taxonomy.
Start here: a quick one-page view of Web3 companies and projects around Singapore.
An optional deeper global map with many sectors, sub-sectors and projects.
A sector map showing issuers, chains, payments, on/off ramps, infrastructure, analytics and financial services.
An industry map is a snapshot, not a fixed taxonomy. And every box on the map can become another map of its own.
This is an orientation map, not a complete taxonomy. Use the tabs below for the problem, blockchain role, examples and limitation in each sector.
Problem: applications need reliable access to chains without running their own nodes.
Why blockchain matters: it is the chain, plus everything needed to build on it — RPC providers, indexers, data availability, developer tooling.
Examples: Alchemy, Infura, The Graph
Alchemy
Infura
The GraphLimitation: convenience recentralises. When most applications read the chain through two providers, an outage at one takes down a large slice of "the decentralised web" — which is exactly what Week 2 Part 4 warned about.
Problem: people need to hold keys and sign transactions without understanding cryptography.
Why blockchain matters: self-custody is only possible if key management is usable. Wallets are the entire user-facing surface.
Examples: MetaMask, Phantom, Rabby, Safe
Limitation: the security burden sits with the user, and interfaces still ask people to approve things they cannot evaluate — Week 3 Part 5.
Problem: cross-border payments can involve several intermediaries, fees and settlement delays.
Why blockchain matters: it can enable fast global settlement without the same correspondent-banking path.
Examples: Circle (USDC), Tether (USDT)
Circle (USDC)
Tether (USDT)Limitation: the largest stablecoins are centralised claims on an issuer. Reserves, redemption and freezing are all trust assumptions — Week 1 Part 5. This is the clearest case where Web3 redistributes trust rather than removing it.
Problem: traditional financial services usually rely on institutions to hold assets, match transactions or enforce rules.
Why blockchain matters: contracts can enforce terms without a company, and many protocols are designed for permissionless access, subject to their interfaces and other controls.
Examples: Uniswap (DEX), Aave (lending)
Limitation: composability spreads failure, oracles can be manipulated, and much of the yield historically came from token emissions rather than genuine economic activity. "Permissionless" also means no recourse when something goes wrong.
Problem: most of the world's value is in assets that settle slowly and trade in limited hours.
Why blockchain matters: on-chain representation allows 24/7 settlement and programmability.
Examples: BUIDL (BlackRock's tokenised fund), tokenised treasuries and money-market funds
BUIDLLimitation: the token is a claim, not the asset. A tokenised bond depends entirely on the legal entity holding the real one. That is a legal question wearing a technical costume, and blockchain does not solve it.
Problem: digital items are usually controlled inside the platform that issued them, which makes independent ownership and portability difficult.
Why blockchain matters: it can provide an independently verifiable ownership record that can be referenced across applications.
Examples: ENS, OpenSea, event ticketing, in-game items
OpenSeaLimitation: the token usually points at a link — Week 3 Part 4. And the 2021 collectibles boom left the sector's reputation well behind its more durable uses.
Problem: games and consumer apps usually keep accounts, items and progress inside one platform. Players may invest years in digital items they cannot take to another application.
Why blockchain matters: some DApps use on-chain records so ownership or other state can persist beyond one publisher and be referenced by other applications. DApp means a decentralised application; it is an application style, not a separate industry sector.
Examples: Axie Infinity and other on-chain games. GameFi is a common label for blockchain games where tokens, tradable items or financial mechanics are central; not every blockchain game is GameFi. Consumer social applications are another possible use.
Limitation: many early blockchain games struggled to attract players beyond financial incentives. Financialising play can attract speculators rather than players, and "play-to-earn" economies have repeatedly collapsed.
Problem: coordinating people and money without a company structure.
Why blockchain matters: treasuries and voting can be enforced by contracts rather than trust.
Examples: Sky (formerly MakerDAO), Arbitrum DAO, Uniswap governance, LXDAO, grant programmes
Sky (formerly MakerDAO)
LXDAOLimitation: governance participation can be low, and token-weighted voting can concentrate influence in large holders. Legal status is unresolved in many jurisdictions.
Problem: contracts cannot see outside their own chain — Week 2 Part 3.
Why blockchain matters: without external data and cross-chain messaging, contracts can only act on what is already on their chain.
Examples: Chainlink; LayerZero, Wormhole, Across
Chainlink
LayerZero
Wormhole
AcrossLimitation: both can create concentrated points of failure. Bridges have historically been a major source of large crypto exploits — Week 2 Part 5.
On-chain data
Problem: Raw on-chain data is public but hard to use directly.
Why blockchain matters: The records are open for people and applications to inspect, while dashboards make them easier to explore.
Examples: Dune, DefiLlama, Nansen.
Dune
DefiLlama
NansenLimitation: Dashboards embed someone's definitions; "TVL" is a choice, not a fact.
ZK proofs — scaling and privacy
Problem: Some applications need to prove something without revealing all the underlying information.
Why blockchain matters: Zero-knowledge proofs can prove that a computation or statement is valid without requiring every underlying detail to be revealed or re-executed by everyone.
Examples: Starknet, zkSync and Scroll primarily use zero-knowledge proofs for blockchain scaling and validity; other systems use related techniques for privacy.
Limitation: These systems can be hard to build and audit, and privacy tools can attract regulatory attention.
DePIN
Problem: Physical or storage networks are expensive to bootstrap and need people to provide real-world resources.
Why blockchain matters: Token incentives can help attract contributors to those networks.
Examples: Helium and Filecoin.
HeliumLimitation: Real-world operations remain the hard part, and demand may not arrive as quickly as supply.
AI × Web3
Problem: AI projects may need ways to coordinate data, compute or contributors, but "AI × Web3" covers an emerging and unsettled area.
Why blockchain matters: In some designs, a blockchain can help record ownership or incentives. Ask what it is actually load-bearing for.
Examples: 0G and Sentient.
0G
SentientLimitation: A great deal of the category is narrative; sometimes the answer to the load-bearing question is "nothing".
The question to carry into every sector
Where is the blockchain actually load-bearing?
For each sector, ask: if you removed the blockchain, what specifically breaks?
Here, load-bearing means: if you removed the blockchain, would the core product stop working or meaningfully change?
- Stablecoin payments — settlement without correspondent banks. Real.
- A DEX — self-custodial swapping through smart contracts without a custodial exchange operator. Real.
- A supply-chain pilot with one operator and no external verification — usually a database with extra steps. Often not real.
Week 2 Part 1 asked this about private chains. It generalises to entire sectors.
Landscape
- TVL — total value locked. It estimates deposits in a protocol, but definitions and double-counting can change the headline number
- Protocol revenue vs incentives — asks whether a project earns from usage or pays users to show up. High activity is not automatically sustainable revenue
- Modular vs monolithic — whether one blockchain tries to do every job itself, or different networks specialise in different jobs. Specialisation can improve performance, but the pieces now have to work together correctly
- Account abstraction — making wallets follow programmable rules, such as recovery or paying fees for a user. The wallet code becomes another security surface
- Restaking — using ETH that is already staked to also help secure another service. The same capital can support several systems, so one failure may affect more than one
- Intents / chain abstraction — a user describes the result they want without choosing every blockchain step. An application or another service chooses the route, which simplifies the experience but adds a new dependency
Worked example
Someone tells you about "a decentralised protocol for tokenised carbon credits." You have never heard of it. Place it in ninety seconds.
| Question | Working answer |
|---|---|
| Sector? | RWA, with DeFi and data adjacencies |
| Problem? | Carbon markets are opaque, fragmented, and double-counting is rife |
| Blockchain load-bearing? | Partly. A shared registry nobody can quietly edit is genuinely useful |
| Limitation? | The credit's quality is an off-chain fact. Tokenising a worthless credit produces a worthless token, verifiably |
That last row is the whole skill
Week 1 Part 3 said it in a single line: blockchains secure the ledger, not reality.
The chain can prove a credit was issued, transferred and retired exactly once. It cannot prove a tree was planted. Any project in this sector lives or dies on its off-chain verification — so that is what you investigate, and Part 3 shows you how.
Further exploration — optional, not assessed
- DefiLlama — browse by category to see relative sector sizes
- ethereum.org — DeFi · NFTs · DAOs — deeper on three of the largest
- Pick the sector you find least convincing and find its strongest defender. Steelmanning is more useful than dismissing
Sources and attribution
- ethereum.org — Decentralized finance (DeFi) — Reuse (CC BY 4.0), adapted
- ethereum.org — NFTs — Reuse (CC BY 4.0), adapted
- ethereum.org — DAOs — Reuse (CC BY 4.0), adapted
- ethereum.org — Oracles — Reuse (CC BY 4.0), adapted
- DefiLlama — Link, referenced only
- Singapore Web3 Landscape — Onchain State Singapore — Link, referenced only
- Binance Research — Industry Map (March 2025) — Link, referenced only
- Artemis / Stablecoin.fyi — Stablecoin Market Landscape — Link, referenced only
Named organisations and protocols are illustrative examples chosen for recognisability, not recommendations or endorsements.