Crypto categories are labels for describing a specified feature or function of an asset, protocol, application, or service. To classify an example, identify what kind of thing it is, state the dimension you are using—such as intended function or place in a system—and check the specific design. Categories can overlap; they do not, on their own, establish value, rights, security, availability, or suitability for a particular purpose.

What a crypto category describes

A category is informative only when its basis is clear. “Payment-oriented” would describe an intended function, while “base network” describes a position in a technical arrangement. Those labels answer different questions, so they are not competing categories in a single list.

It is also important to distinguish the subject being classified. An asset, protocol, application, node, and service are not interchangeable terms. A protocol describes rules and mechanisms for coordinating activity; an application uses system components to perform a task; infrastructure supports or participates in system operation. An asset can be used in relation to a protocol, but its category does not describe every system it depends on.

The same example may therefore fit multiple categories. An asset might be described by its intended role and separately by the network on which it is used. A protocol might be described by its place in an architecture and by a function it performs between networks. State the classification dimension explicitly rather than forcing the example into one exclusive box.

This framework is a way to organize descriptions, not a ranking. A category label is not an evaluation of quality or a conclusion about what a person should acquire or use. For each claim, the relevant question is what the specific design and its documentation establish.

Crypto categories by asset role

One broad dimension asks what role an asset is intended to serve. A payment- or transfer-oriented grouping describes a role in moving value between participants. It does not explain how a specific network records transfers, whether a service supports the asset, or what rights a holder may have.

Other functional groupings can refer to network use or governance-related activity. The wording should remain descriptive: an intended or documented function does not mean that every holder can perform every associated action. The protocol rules and project documentation determine what the asset actually enables. This article uses “function” as a classification dimension, not as a guarantee of access or outcome.

A separate question is whether an asset represents a claim, entitlement, or backing arrangement. A broad category name does not answer that question. Readers would need the specific design and documentation describing the relationship between the asset and any referenced rights or backing. Those details are outside this framework; the classification should not be stretched into an explanation of backing or redemption.

The distinction between role and rights is useful even when documentation uses overlapping terms. A role describes what an asset is intended to do within a system. A claim or entitlement concerns what the holder may be able to assert under a particular arrangement. The former does not establish the latter. If a source leaves the relationship unclear, record that uncertainty rather than inferring rights from a label.

Categories by protocol layer

Protocols and supporting infrastructure can be classified independently of assets by asking where they sit in a system and what work they perform. A base network is one useful architectural grouping: it provides the environment in which activity is recorded and validated. A concrete example of a component’s role is an Ethereum full node, which independently checks blocks and transactions against protocol rules rather than relying entirely on another node. That describes verification by a node; it does not define every asset or application associated with Ethereum.

Applications and supporting services are further subjects of classification. They may interact with a network or provide functions an application uses, but the category of one component does not automatically describe the others. A project description should identify whether it is referring to the protocol, an application, an infrastructure component, or an asset used by one of them. This prevents a system-level label from being mistaken for a complete description of an asset.

A permissioned-network example illustrates why a protocol arrangement can include many components. A Hyperledger Fabric network coordinates organizations, certificate authorities, peers, orderers, channels, policies, ledgers, smart contracts, and client applications. The example is useful for identifying the subject as a network architecture rather than a single asset. It does not imply that every project called a protocol has the same component structure.

Interoperability systems form another functional grouping. A bridge coordinates activity between otherwise isolated blockchain environments. Its category describes that relationship, not a universal implementation. For example, cross-chain asset transfer can use lock-and-mint, burn-and-mint, or atomic-swap and liquidity-network mechanisms. These are alternatives that may appear in particular designs; they should not be combined into one assumed process or treated as a guarantee about every bridge.

Scaling systems can likewise be classified by what activity they handle and how they relate to another network. The useful first step is to identify the work assigned to the system and the other components it depends on. A label alone does not identify those dependencies or guarantee a particular result. The classification framework can flag the relationship, while a more detailed technical account would require evidence about the specific system.

How to classify an example consistently

Use a repeatable sequence to keep descriptions specific:

  1. Identify the subject. Decide whether the example is an asset, protocol, application, node, or service. Avoid calling an entire project an asset when the question concerns one component.
  2. Name the dimension. State whether the category refers to intended function, architectural position, or a relationship between networks. If several dimensions apply, list them separately.
  3. Check the specific documentation. Look for the described mechanism and dependencies, not just the project’s category label. For example, bridge documentation may identify which transfer mechanism a particular design uses.
  4. Record overlap and uncertainty. Note when the example fits multiple groupings or the documentation does not establish a claimed function. Do not fill gaps with assumptions based on terminology.

Consider a hypothetical cross-network transfer. First decide whether the subject is the asset being transferred or the system coordinating activity between networks. If the subject is the latter, classify it by its interoperability function. Then consult the specific documentation to identify its mechanism and dependencies. The broad category and the mechanism are related, but they answer different questions.

The same method works for a network component. If the subject is a node, classify the task it performs rather than treating the node as the whole network. Ethereum full nodes, for instance, independently check blocks and transactions against protocol rules. This is a description of a verification role. It does not establish what a separate application does or what rights an asset associated with that application represents.

When making a comparison, keep the dimensions parallel. Compare two systems by function with function, or by architectural position with architectural position. If one description uses a broad label and another uses a specific mechanism, say so instead of presenting them as equivalent. This makes the comparison easier to interpret and exposes where the available documentation is incomplete.

Where category labels can mislead

Category terms can vary among sources, and designs may evolve. Treat a label as a concise description of one dimension, not as a permanent or exhaustive account. When a term is used differently across descriptions, identify the meaning being applied or replace the label with a concrete account of the function.

Do not infer legal or regulatory status or tax treatment from a category name. Nor does category membership establish security, recoverability, availability, compliance, fees, yield, or rights. Each of those issues requires evidence specific to the asset, system, service, or circumstances. A role-based classification, for example, does not prove what a holder can claim; a protocol-layer label does not specify every operational dependency.

A disciplined classification therefore has three parts: name the subject, state the dimension, and verify the specific design. It can also record overlap and uncertainty. This keeps categories useful for organizing information without turning a label into an endorsement, a guarantee, or a substitute for examining the system itself.

Sources and references