Crypto sectors are broad groupings based on the main function a project performs or the problem it addresses. To classify a project, separate what it does for users from the networks and services it depends on; the labels are practical descriptions, not fixed technical or legal categories, and projects can fit more than one.

What a crypto sector describes

A sector label answers a functional question: what role does this project play? It is not the same as an asset type, a protocol, or a legal classification. A project can be grouped by its application while separately described by the infrastructure it uses. For example, a consumer-facing service might operate on a blockchain and rely on another service for data. Those descriptions refer to different parts of its role.

The map below is an editorial way to organize common functions, not a complete or official taxonomy. Category names and boundaries can vary by source and context. In practice, it is often more informative to record a project’s principal function and its dependencies than to search for one label that captures everything.

A map of crypto sectors by function

Networks and execution infrastructure provide the environment in which transactions and applications operate. Ethereum, for example, has a native cryptocurrency, ether, that is part of the protocol’s market for computation. This is a description of one network’s role; it does not mean every project using that network belongs to the infrastructure sector. An application can be classified by what it does while the network is recorded as a dependency.

Scaling systems focus on handling activity in relation to an underlying network. For an Ethereum Layer 2, some security is derived from Ethereum’s Layer 1 consensus rather than relying only on a separate validator set. The exact guarantee depends on the system’s proof, data availability, settlement, governance, and exit mechanisms. Thus, the Layer 2 label describes an infrastructure relationship; it need not be the only useful description of a project that also provides an application.

Financial applications are grouped by their user-facing functions, such as trading, lending, or payments. A sector map can identify those as distinct activities without implying that all products with the same function use the same infrastructure or operating model. A trading application, for instance, can be described by its trading purpose and separately by the network or data services on which it relies. The category says what role it serves, not whether it is secure or suitable for a particular user.

Data services focus on making information available to applications or organizing it for use. The label alone does not specify how a particular service obtains, checks, or presents information. When classifying a project, name the data function that is actually supported by the available description rather than assuming that a broad label establishes reliability or completeness.

Interoperability services concern coordination between otherwise separate systems. This category is useful when a project’s main function is helping activity or information move between environments. It is still distinct from the application that uses the service: an application may depend on interoperability infrastructure without being primarily an interoperability project itself.

Consumer and digital-ownership applications group user-facing services around experiences, records, or uses associated with digital ownership. Such an application may also depend on a network, data service, or financial function. Its consumer-facing purpose and its technical dependencies should be described separately rather than collapsed into one sector label.

Physical-infrastructure networks coordinate people who deploy and operate real-world hardware, use token incentives, and pay participants onchain for contributions the network can verify. This definition does not establish that every claimed contribution is accurately verified or that the resulting service has demand. A cited architecture describes coordination across physical devices, communications and data handling, blockchain records, incentives, and application services; implementations may combine, omit, or centralize parts of these layers. The category therefore describes an intended coordination function, not proof that every system performs all those functions in the same way.

These are illustrations, not an exhaustive list. They organize projects by function without ranking sectors or suggesting that every project within a category shares the same design.

How sectors depend on and overlap with one another

A project may provide an application while relying on infrastructure built for another purpose. A trading service, for example, belongs in a functional grouping based on trading, while the network it uses is a separate dependency. If it also relies on data or interoperability services, those can be recorded as additional dependencies. The dependency does not automatically become the project’s primary function.

This distinction reflects how a technology stack can have multiple parts. The user-facing application is one part; the underlying network and any supporting services are others. The project may itself combine roles, but the label should make clear whether it describes the project’s principal function or a component on which it relies. Without that distinction, a list of sectors can mistakenly make a dependency look like the whole product.

The term “Web3” is a useful example of a broad label that needs context. It has no single rigid definition and is commonly used as a catch-all for a user-owned, decentralized vision of the internet. It may describe an ecosystem framing rather than one narrowly defined sector. If using it to classify a project, explain which function or design idea is intended rather than treating the word as a precise category.

Overlap is not an error. A project can have a primary function and secondary roles, or it can combine application and infrastructure functions. A sensible map records these relationships instead of forcing every project into mutually exclusive boxes. It also leaves room for uncertainty when public descriptions do not clearly establish what a project does.

How to classify a crypto project consistently

Start with the user problem: what task does the project claim to enable or coordinate? Use that answer to identify its principal function. Avoid starting with a promotional label or a technology name, since neither necessarily says what users can do with the system.

Then separate function from infrastructure. Note the network, scaling system, data service, or interoperability mechanism the project depends on when that information is available. A network dependency is not, by itself, evidence that the project builds or operates that network. Likewise, an application label does not explain the assumptions of the infrastructure beneath it.

Next, check the project’s description against the system functions that can be identified. If its stated scope spans several functions, record more than one role. If the available description does not make the principal function clear, mark the classification as uncertain instead of assigning a precise label without support.

A compact note can use three fields: primary function, infrastructure dependencies, and additional roles or uncertainty. For example, a note might describe a project as a consumer application, list its named network and data service as dependencies, and separately flag a payment function. This is an illustrative format, not a universal classification rule or an assessment of those services.

Limits of sector labels

A sector label does not establish security, reliability, quality, or suitability for a particular purpose. It does not verify a project’s claims about its functions or dependencies. In physical-infrastructure networks, for example, the category’s reference to verifiable contributions does not by itself prove that verification is accurate or that the service has demand. That limitation applies more broadly: a category identifies a kind of function, not the evidence behind every project-specific claim.

Sector membership also does not determine legal treatment or compliance obligations. A functional label is not a legal conclusion; treatment can depend on jurisdiction, product design, and activity. The map here is jurisdiction-neutral and does not classify any specific project under law.

Finally, sector labels do not predict performance, adoption, or future value. Use them to organize questions about a project’s principal function, the infrastructure it uses, and the roles it combines. Evaluate those details separately, and preserve uncertainty where the available information does not support a firm classification.

Sources and references