Why Crypto Sector Labels Often Fail

The first question any serious analyst should ask is simple. What is the system’s product or service, meaning what does this system actually sell?

Crypto analysis still too often starts in the wrong place. Systems are often grouped because they share a technology stack, a token story, or because the market already talks about them together. They are called “infrastructure” or “DeFi” as though those labels settle anything important about their economics. Usually they do not. They tell you roughly how a system is talked about. They do not reliably tell you what service it provides, who is buying it, or which other systems are genuinely comparable.

That matters because sector is not a cosmetic label. It establishes the peer set. It shapes benchmarking. It informs the questions an analyst asks next. In the end, it affects valuation. If a system is assigned to the wrong sector, the rest of the analysis begins on the wrong footing.

Fundamentals starts from a different premise. Sector classification should describe the buyer-facing economic service a system materially delivers today. Put differently, the sector should be a statement about the problem being solved for buyers, not about the mechanism used to solve it. It should not describe the system’s governance posture, its internal architecture, or the story attached to its token. These points matter, but they answer different questions. Sector classification should answer the first one. What is this system actually selling?

When Sector Labels Become Tags

Much of crypto’s sector language behaves more like tagging than classification. A tag helps people talk about or find something. A classification is meant to place something in the right peer set. Broad terms such as infrastructure and DeFi are socially useful, but analytically loose. They gather together systems with materially different buyers, products, and economics simply because those systems occupy a similar part of the market conversation. In established equity analysis, sector classification is expected to tell you something substantive about what a company sells. If a company is classified in software, telecoms, or payments, you immediately have a rough sense of its buyer-facing activity. Fundamentals applies a sector-classification logic closer in spirit to frameworks such as GICS than to the looser tagging habits common in the crypto industry.

Consider infrastructure. Base layers, interoperability systems, oracle networks, storage networks, privacy networks, and proof providers are often placed in one bucket. Yet they sell different services to different buyers and face different demand drivers. The same problem appears in DeFi. Trading venues, lending systems, stablecoin issuers, liquid staking products, and asset managers are routinely treated as one family despite doing distinct economic work.

That may be adequate for casual discussion. It is not adequate for serious comparison and analysis.

A sector should not be a mood, a technology, or a community shorthand. It should be a classification of comparable economic activity. In crypto, that means identifying the service being delivered and the buyer problem being solved. Once that principle is applied consistently, many familiar labels turn out to be too broad to carry much analytical weight.

What Sector Is, and What It Is Not

In Fundamentals, sector classification is deliberately kept separate from the rest of the framework. Sector describes the service being sold to buyers. It does not describe the system boundary. It does not describe where value is created or captured. It does not describe who governs the material components. It does not describe what the token does.

Those are separate layers, and they should remain separate.

Sector Classification is the first of three analytical questions in understanding systems and tokens.

Crypto discourse often collapses them. A protocol may be treated as a governance project because tokenholders can vote on proposals. A chain may be treated as a payments system because its native token is used for gas. A stablecoin issuer may be treated as a real-world asset project because reserves sit off-chain. Each move blends together distinct questions that should be analysed separately.

Governance is a system or token question. Gas payment is a token-functionality question. Off-chain reserves are facts about the system boundary and value capture. Sector is narrower and more basic. It asks what service the system is materially selling to buyers today.

Get that right, and the later layers become easier to interpret. Get it wrong, and everything downstream becomes less reliable.

Start with the Buyer’s Job

For an investor or analyst, the organising principle is straightforward. Classify the system by the external party that pays or commits resources, and by the outcome that party is seeking.

That is why Fundamentals starts with the buyer’s job. The analyst is not trying to summarise the entire technology stack, and certainly not the mythology around the project. The task is to identify the service for which someone is economically showing up.

In stacked products, that means following the layer that is actually monetised or committed against. If a system contains several layers, but one layer is clearly the one buyers are paying for, that is where the classification should sit. Reward flows, and token incentives do not override the buyer’s job. Neither does narrative prominence.

This is also why Fundamentals privileges economic indicators of live demand. Fees and revenue are usually the strongest evidence. Where those are limited or not yet visible, other indicators can still establish the dominant service line. Metered work, assets under service, binding commitments to access, sustained usage of the core action, or a live commercial pipeline can all indicate the service that matters most. The goal is not to score every possible future path. It is to identify the dominant service the system is providing now. That also means a system’s sector classification can change over time as the buyer-facing service evolves. A system may still be commonly referred to under the same broad umbrella in market conversation, such as DeFi or middleware, even as the economically dominant service it sells has changed. That is one reason crypto’s familiar umbrella labels often persist even when they are no longer precise enough to serve as serious sector classifications.

This discipline also matters because activity can be inflated by subsidies, emissions, or narrative-driven participation. Reward-heavy activity can make a service look economically important when the underlying willingness to pay remains weak or unproven. That is a reason to treat raw activity with care, not to assume it cleanly reflects durable demand.

The hierarchy identifies metrics for demand signal that help to identify the dominant sector

Primary Sectors, Secondary Sectors, and Subsectors

Every system in Fundamentals receives one primary sector. That forces a judgement about the dominant service line. Without that discipline, classification quickly becomes too loose to support meaningful comparison.

A system may also receive up to two secondary sectors, but only where additional service lines are materially active today. Secondary sectors are not a place to record ambition, adjacency, or roadmap language. They exist for cases where the system is genuinely operating more than one economically meaningful service line at the same time.

Each assigned sector is then mapped to at least one subsector. This is where the description becomes more precise. Broad sector labels often remain too coarse on their own. “Blockspace Production”, for example, captures a common service family, but it still matters whether the system is an L1 blockchain, an L2, a data-availability layer, a decentralised sequencer, or a proof network. Those are not cosmetic distinctions. They imply different buyers, different demand drivers, and different peer sets.

The same is true elsewhere. A system in “Trading and Exchange” may be a spot venue, a derivatives venue, an aggregator, a launchpad, or an order-flow protection system. Grouping all of that under one headline label obscures more than it clarifies.

This is why Fundamentals is conservative about secondary classifications and serious about subsectors. Precision matters. It is better to record one clear primary service and a tightly evidenced secondary line than to overload a profile with every activity a team might one day want to pursue.

Where Sector Work Usually Goes Wrong

In wider crypto sector work, a few failure modes recur.

One is classification by technology stack. A system built with smart contracts is not thereby in the same sector as every other smart-contract-based system. Shared architecture says little about the buyer-facing service. Ethereum and Solana are best understood through the sale of blockspace. Chainlink’s trusted data services are not made comparable to decentralised storage simply because both are delivered through distributed networks.

Another is classification by token narrative. A project with a governance token is not in a governance sector because the token can vote. A protocol with a fee burn is not in a value-distribution sector because value distribution is a token-functionality question, not a buyer-facing service. A token used for payments does not automatically make the underlying system a payments system. Sector sits above the token. It explains the service the system sells, not the roles the token may play around that service.

A third is classification by community shorthand. Terms such as DeFi or infrastructure can be useful conversational umbrellas, but they are too broad and internally heterogeneous to function as rigorous sector classifications. Trading venues, lending systems, liquid staking providers, stablecoin issuers, and asset managers may all sit within the same broad discourse while serving different buyers and operating with different economics.

A fourth is classification by future ambition. Many projects are trying to become several things at once. That may be strategically interesting, but it is not a substitute for present classification. Sector should reflect what is materially being sold today. Roadmap ambition can be noted, but it should not determine the primary label.

What Better Sector Work Gives You

Better sector work produces better peer sets. Once a system is anchored to the service it sells, comparison becomes more informative. Blockspace providers can be compared with other sellers of execution, inclusion, availability, or proof services. Trusted data systems can be compared with other sellers of data, verification, or identity primitives. Money and payments systems can be analysed against other systems selling monetary instruments or settlement rails. Trading venues can be separated from credit platforms even where both sit inside the same market narrative.

Better sector work also sharpens the next questions. If the system sells blockspace, the relevant issues include throughput, demand, pricing power, and downstream dependencies. If it sells trusted data, the next questions concern data quality, integration depth, switching costs, and market structure. If it sells credit or asset management, the analysis turns towards underwriting, product design, assets under service, and risk management. Sector does not answer those questions by itself, but it tells you which questions actually matter.

Most importantly, better sector work stops classification from smuggling in conclusions. A sector label is not a thesis on whether the system is attractive. It is a disciplined statement about what the system does for buyers. That makes it a starting point rather than a verdict.

This is why Sector Classification comes first in Fundamentals. Before asking how a system is structured, where value is captured, or what role its token plays, it is necessary to establish what the system is actually selling.

For readers who want the full formal sector and subsector framework, the public Fundamentals documentation sets that out separately.

Once that question has been answered, the next questions follow naturally. What kind of system is delivering that service? Where does the economically valuable activity occur? Where is value captured and routed? Who has binding control over the material components?

That is the job of the System Taxonomy.