What a Token Actually Does

If Sector Classification tells you what a system sells, and the System Taxonomy tells you what kind of system is delivering that service, the next question is narrower and more exacting. What does token ownership actually confer?

Crypto still answers that question poorly. Tokens are often described as useful because they are staked, locked, burned, wrapped, rewarded, or simply treated as central to the story. But those things do not, by themselves, tell you what the token does. They describe activity around the token. They describe mechanics, incentives, or narrative. They do not necessarily describe a genuine right or utility that depends on ownership.

Token analysis is one of the places where crypto language becomes most imprecise. A token can look busy without being functionally important. It can sit inside a complicated economic design without conferring much that is actually necessary. Equally, a token can look superficially simple while still being central to participating in a service, influencing governance, or receiving system value. The question is not whether the token appears in the system. The question is whether owning it is actually required to perform a role, use a service, exercise a right, or receive a benefit.

That is the purpose of the Token Functionality Framework in Fundamentals. The point is not to decorate tokens with extra categories. It is to identify, with discipline, what token ownership genuinely enables.

The Ownership-Required Rule

The central rule is simple. Only those roles that require token ownership to engage with and benefit from a system qualify as token functionalities.

That may sound straightforward, but it excludes a great deal of noise.

If a token is merely used as the unit in which someone is paid, that is not enough. Bitcoin miners receiving BTC rewards do not demonstrate a BTC functionality that requires them to own BTC in advance. By contrast, users paying native transaction fees in BTC do. Proof of stake validation makes the same point from a different angle, because the right to participate is conditional on holding and staking the token. This does not mean every counterparty must own the token in advance. In a payments case, the functionality can arise because the payer must own the token to settle the obligation, even if the recipient need not hold it beforehand. The difference is not cosmetic. In the first case, the token is simply the unit of compensation. In the latter cases, token ownership is part of exercising the right itself.

This is why Fundamentals treats the token as functionally relevant only where the claimed right can be stated clearly. That right might involve participating in service delivery, influencing a governance surface, receiving a fee stream, obtaining a pricing privilege, posting collateral, or claiming an asset. But it has to be something specific. If the claimed functionality cannot be stated clearly in that form, it is usually a mechanism, an incentive, or a marketing claim rather than a functionality label.

The same rule also explains why non-transferable credits or accounting units created solely through burning, locking, or converting another token are generally treated as mechanisms of the original token unless they have independent issuance and independent rights. A new accounting representation is not automatically a new functionality. What matters is whether a distinct right exists and whether that right genuinely depends on owning the token in question.

Functionality Is Not Mechanism

This is the distinction that crypto analysis most often blurs.

Functionality tells you what the token does for its holder. Mechanism tells you how that right or utility is activated, enforced, or delivered.

Staking is a mechanism. Locking is a mechanism. ve-models are mechanisms. Wrappers are mechanisms. Burning is a mechanism. Slashing is a mechanism. Bonding curves are mechanisms. Restaking is a mechanism. Fee switches are mechanisms. None of them is a functionality class in its own right.

That matters because the same mechanism can sit beneath very different token rights. Staking can gate the right to participate as a validator, sequencer, relay operator, or other service provider. It can also create slashable exposure, where the same staked position can be penalised for misbehaviour or underperformance. But it can also be used much more thinly, where holders simply lock tokens to receive emissions or surplus without providing ongoing work or bearing performance risk. Looking only at the mechanism would make these cases look more similar than they are.

A staking mechanism can map to several functionalities based on its underlying purpose

The framework therefore insists on a separation between the two. Mechanisms still matter economically. They may be elegant, clumsy, reflexive, or deeply important to value accrual. But they are not the right classification layer for asking what ownership actually confers.

Some token functionalities are more utility-like, in that they require active use. Others are more right-like, in that they sit more as claims or entitlements in ownership itself. Payments and much of collateral are more utility-like in this sense. Value distribution and asset ownership are more right-like. Service provision and governance often combine both features.

The Seven Functionality Classes

Fundamentals organises token roles into seven functionality classes: Service Provision, Governance, Value Distribution, Membership, Payments, Collateral, and Asset Ownership.

These are not the final unit of classification. They are the top-level families.

Service Provision covers supply-side rights. Token ownership allows the holder to perform work or provide resources.

Governance covers decision rights. Token ownership allows the holder to influence or control some material decision surface.

Value Distribution covers surplus entitlements. Token ownership makes the holder eligible for a share of system value without requiring meaningful ongoing service provision or slashable risk underwriting.

Membership covers access and preference rights. Token ownership unlocks restricted features, better pricing, higher usage limits, or status-like credentials.

Payments covers transactional use. Token ownership allows the holder to settle obligations, pay native resource fees, redeem closed-loop service credits, or obtain discounts when paying in the token.

Collateral covers pledgeable value. Token ownership allows the holder to post the token as backing for leverage, reserve structures, underwriting, or performance bonding.

Asset Ownership covers claims on underlying assets. Token ownership gives the holder a redeemable or transferable claim on on-chain or off-chain assets.

These classes matter because they tell you the broad economic family a token role belongs to. But they are still too broad to do the real analytical work on their own. A token with governance might govern fee routing, treasury assets, technical upgrades, or the composition of a privileged actor set. Those are not the same right. A token with payments might be required for native resource fees, accepted voluntarily as a medium of exchange, or redeemable as prepaid service credit. Those are not the same right either.

That is why the subtype layer matters so much.

Endogenous and Exogenous Functionality

A second foundational distinction in Fundamentals is between endogenous and exogenous functionality.

Endogenous functionality is built into the native system by design. It exists because the system itself requires or enforces it.

Exogenous functionality arises when the token is used by external systems or in external economic settings. The native system may help create the conditions for that adoption, but it does not directly govern it in the same way.

Ethereum is a useful illustration. Endogenously, ETH is tied to Ethereum’s own system. Validators stake ETH to participate in block production. Users pay transaction fees in ETH. Ethereum’s base fee burn gives ETH an endogenous value-distribution functionality. Validator deposits are slashable, which creates an endogenous collateral role as well. Those are all endogenous because they arise inside Ethereum’s own economic design.

But ETH also travels beyond Ethereum itself. It is used as collateral in external lending systems. It is restaked to secure external services. It can be used as a payment asset in other environments. In the dashboard, those are exogenous functionalities. They still matter, sometimes a great deal. But they depend on adoption by external systems rather than on Ethereum’s native rules alone. The composable nature of cryptoeconomic systems also allows tokens to develop rich exogenous uses beyond their native system. This is especially visible in systems that function as platforms for other systems, such as blockchains.

Endogenous and exogenous functionalities behave differently. Endogenous functionalities are more directly tied to native system design and native governance. Exogenous functionalities are more dependent on outside adoption, integration, and market recognition. Both can contribute to demand and value accrual. They just do so through different channels.

It also matters because the endogenous or exogenous tag applies not only at the top-level functionality class, but at the subtype level as well. The same token can therefore express the same broad class in different ways across different environments. ETH, for example, can be an endogenous native resource fee asset on Ethereum and an exogenous financial collateral asset elsewhere.

Why the Subtype Layer Matters

An earlier public version of this framework, published in May 2025, introduced the seven headline functionality classes and the endogenous versus exogenous distinction. The current framework keeps that foundation, but develops it further through the subtype layer. That is the major refinement.

The subtype layer makes the framework more precise, more operational, and more comparable by specifying the exact economic right the holder can exercise. In the framework and documentation, each subtype has a canonical code. In the dashboard, the subtype is displayed by name as the relevant analytical unit. Here, the important thing is the underlying logic. Each subtype answers a simple question. What right does token ownership confer, and over what object?

The headline classes still flatten important differences. Treasury control is not the same as technical parameter control. A direct entitlement is not the same as a burn or buyback entitlement. Native resource fees are not the same as token-settled discounts. A claim on contract-controlled pool assets is not the same as a legal claim on a tokenised real-world asset.

Strength as a Further Refinement

On a Fundamentals profile, token functionality therefore appears in layers. The tabs show the seven functionality classes. Under each sit the relevant subtypes, their endogenous or exogenous tag, and, where simple presence is too crude, an additional strength label.

Strength does not replace the subtype. It refines it. Some rights differ not just in kind, but in degree, quality, or mode of execution. A governance right that merely signals preferences is not the same as one that binds decisions. A one-off or random value distribution is not the same as a regular discretionary programme, which is not the same as an algorithmic or guaranteed entitlement. The same logic applies elsewhere. A native resource fee that is the exclusive way to access a system’s valuable resources is stronger than one that is optional or only applies to a subset of them. An asset claim with immediate, credible redemption is stronger than one with gated or delayed exit. The point of strength is not to create a second taxonomy. It is to show, for selected subtypes, that how a right operates can matter as much as whether it exists. The subtype remains the primary analytical unit.

The Subtype Catalogue

What follows is the current subtype catalogue in article form. The documentation retains the formal reference version. The aim here is to make it easier to read without loosening the definitions.

Service Provision

Service Provision is about supply-side rights. The token gives its holder the ability to do work or provide resources that the system treats as economically meaningful.

State Transition Execution and Transaction Sequencing covers the right to participate in block production and transaction ordering.

Data Availability covers the right to make transaction data available under correctness guarantees for external execution domains.

Generalised Off-Chain Computation covers the right to perform off-chain computation whose outputs are later attested on-chain.

Cryptographic Proof Service covers the right to generate or verify proofs that other systems rely on.

Distributed Oracle Service covers the right to supply canonical truth to dependent contracts or applications.

Identity Attestation covers the right to issue identity claims that downstream systems treat as authoritative.

Data Processing: Data Indexing covers the right to provide structured access to already-published data.

Data Storage: Persistent Storage covers the right to supply long-term storage capacity backed by a durability promise.

Data Handling: Interoperability Relay covers the right to relay assets or messages across execution domains.

Data Handling: Confidentiality Relay covers the right to preserve confidentiality while routing or transforming user data.

Physical World Service: Geospatial Coverage Service covers the right to operate verifiable physical infrastructure within a geographic area and earn against validated coverage or delivery.

Dispute Resolution/Arbitration covers the right to adjudicate disputes between participants or external parties.

Block/State Attestation covers the right to attest to the validity or finality of proposed blocks or state updates.

Resource and Work Evaluation/Allocation covers the right to evaluate, curate, rank, signal, or weight the quality, demand, priority, relevance, or performance of system resources, service targets, data objects, or non-consensus work outputs where that input is consumed for discovery, allocation, service delivery, reward weighting, eligibility, or penalties.

Data Handling: Access Gateway/Request Routing covers the right to operate an access, gateway, routing, relay, or request-management layer between users or applications and backend suppliers or services.

Intent Fulfilment and Settlement covers the right to fulfil user intents by supplying routing, liquidity, capital, execution, or settlement work that satisfies user constraints.

Two distinctions matter here. First, service provision is about the productive role, not the penalty side of that role. If the same token position is also slashable, collateral may be present as well. Second, a system should not be treated as providing a given service merely because it supports its own internal operation. The data-availability subtype, for example, is not assigned to a base layer simply because it publishes its own transaction data. The question is whether it is genuinely serving external execution domains.

Governance

Governance is about control over material decision surfaces. The token does not just signal identity or affiliation. It confers some degree of authority over what the system can become or how it can operate.

Economic Design/Parameter Control covers monetary valves such as fee rates, fee routing, issuance, burn schedules, reward formulas, collateral factors, and similar economic parameters.

Technical Parameter Control covers upgrades to the codebase, execution environment, consensus rules, cryptography, security posture, and core architecture where the primary purpose is not to change monetary flows directly.

Process and Meta Parameter Control covers the rules that govern how decisions themselves are made.

Treasury Control covers authority over assets held in the on-chain treasury.

Actor Set Permissioning covers authority to appoint, remove, or re-weight privileged actors such as validators, sequencers, provers, or council members.

Product/Service Line Decisions covers authority to approve, veto, or direct the creation, retirement, or deployment of customer-facing products or markets.

Whole Entity Disposition Right covers the collective right to liquidate, transfer, or otherwise dispose of the entire system and distribute the proceeds pro rata.

This is one of the areas where the subtype layer matters most. A token can be called a governance token while governing only a narrow and weakly binding surface. Or it can govern economically decisive levers. Those are not remotely the same thing. This is also why signalling should be handled carefully. Non-binding polls are not governance in the same sense as live decision rights with a credible execution path. In the dashboard, governance strength can therefore be recorded at signal, partial, or unilateral levels.

Value Distribution

Value Distribution is about entitlement to system value without requiring the holder to provide ongoing service or to bear slashable performance risk.

Direct Entitlement covers a pro rata claim on protocol surplus or revenue.

Burn Entitlement covers benefit from permanent supply reduction caused by system operations.

Buyback Entitlement covers benefit from the system acquiring and redistributing its own token through buybacks or equivalent structures.

Inflation Entitlement covers a pro rata share of newly minted units of the same token where receipt is not conditional on ongoing service or slashable risk.

Third-Party Reward Distribution covers repeatable distributions of third-party tokens or assets through a programme that is conditional on holding, locking, or depositing the token, where the distributed assets are not sourced from the system’s own protocol surplus and are not newly minted units of the same token.

This is one of the areas where crypto narratives routinely overstate tokens. Many reward flows are not value distribution in the sense relevant here. If rewards are paid only to validators, sequencers, or other contributors who must own the token, and usually stake it, in order to perform that work, the relevant functionality is service provision, often alongside collateral. If holders merely lock tokens to access a distribution, with no meaningful work and no slashable exposure, that points towards value distribution instead. The distinction is economically important.

It is also important not to collapse all value distribution into one mental model. A direct entitlement resembles a payout claim. A burn entitlement works through relative ownership. A buyback entitlement changes supply dynamics differently again. A token can therefore have value distribution without resembling equity in any simple or uniform way. Some value-distribution rights look closer to a payout claim. Others work indirectly through supply reduction or buybacks, and others depend on discretionary programmes rather than binding claims.

Membership

Membership is about access, preference, or status that comes from holding or locking the token.

Access Privilege covers the right to enter a venue, use a feature, or receive a service that non-holders cannot access.

Preferential Pricing (Hold-Based) covers lower fees, rebates, or cash back unlocked by meeting a token holding or locking threshold, regardless of which currency is used for payment.

Usage Quota Uplift covers a higher usage allowance before throttling or extra payment applies.

Reputation Credential covers a token-based credential that affects social standing, voice weight, or recognised status within a system.

Membership is easy to underrate because it can sound soft. Sometimes it is. But sometimes it is commercially meaningful, especially where access, pricing, or quota rights materially shape demand. It is also important not to confuse membership with payments. A token-settled discount, where the discount only exists if payment itself is made in the token, belongs under payments. A hold-based discount, where mere holding or locking unlocks better pricing regardless of payment currency, belongs under membership.

Payments

Payments is about using the token to settle obligations or access system resources.

Native Resource Fee covers the right to consume a scarce internal resource where access is obtained by paying a system-enforced fee in the token.

General Medium of Exchange covers the right to discharge a payment obligation to a willing counterparty for goods or services, whether inside or outside the system.

Prepaid Credit covers the right to redeem the token with the issuer or system for a defined quantity of future services in a closed loop.

Token-Settled Discount covers the right to reduced pricing only when fees are settled in the native token.

This category is another place where broad market language obscures important differences. Native resource fees are about a system-controlled internal resource. Gas on Ethereum is the clearest example. A general medium of exchange is different. It depends on actual counterparty acceptance, and that acceptance is not system-enforced. Prepaid credit is different again. It resembles a closed-loop service claim more than an open medium of exchange. Token-settled discounts are narrower still. They do not say the token is a broadly accepted payment asset. They say the token is privileged as the settlement asset for a discount within a defined commercial context.

That last distinction matters because exchange tokens and other platform tokens are often described as having payment utility in a very broad sense. Sometimes what they really have is a token-settled discount, which is a much more specific and narrower right.

Collateral

Collateral is about posting the token to support leverage, underwriting, reserves, or honest behaviour.

Financial Collateral covers the right to pledge the token in order to obtain leveraged financial exposure, subject to liquidation on adverse price movement.

Stablecoin-Reserve Asset covers the right to deposit the token as backing for a pegged or synthetic currency.

Risk-Underwriting Stake covers the right to absorb protocol or contract risk in exchange for premium income, with the staked capital available to cover losses.

Performance-Bond covers surety posted to guarantee honest behaviour in a delegated role, with slashing or forfeiture on misbehaviour.

Collateral deserves careful treatment because it is never a free-floating magic property. A token can only function as collateral if there is already some basis for the market to treat it as value-bearing. This is why collateral is often downstream of other token functionalities and of broader market acceptance.

It is also one of the places where endogenous and exogenous distinctions matter most. ETH provides a good example. Validator deposits on Ethereum are an endogenous performance bond. ETH used as collateral in external lending markets is exogenous financial collateral. ETH restaked to secure external services can become exogenous performance-bond collateral. These are related, but they are not the same subtype.

Service provision and collateral also commonly co-exist. Where token ownership gives the holder the right to contribute work and the same position is slashable for failure or misbehaviour, both functionalities can be present at once. That is not duplication. It reflects two distinct economic facts. One is the right to perform the role. The other is the risk posted to secure that role.

Asset Ownership

Asset Ownership is about claims on underlying assets rather than on system participation, discounts, or value flows.

On-Chain Asset Title/Pool Share covers a redeemable or exchangeable pro rata claim on contract-controlled assets or pool balances.

Off-Chain Asset Title/Pool Share covers legal title or beneficial interest in a specified real-world asset that has been tokenised on-chain.

This is a strongly right-like category. The token is not primarily valuable because it grants a role. It is valuable because it represents a claim. That claim may sit against a pool of on-chain assets, as with redeemable staking receipts or wrapper tokens. Or it may sit against off-chain assets such as gold, cash reserves, securities, or other tokenised real-world assets.

This is also one of the places where surface appearance can mislead. A wrapper or receipt token does not count here merely because it exists. The relevant question is whether the holder has a real claim that can be redeemed or enforced. For off-chain assets, that means legal and operational reality matters. Marketing language about backing is not enough on its own.

What This Framework Is Really For

Taken together, these distinctions show why token functionality has to be read after sector and system analysis, not before it. The Token Functionality Framework does not exist to flatter tokens. In many cases, it does the opposite. It reveals that a token is surrounded by mechanisms and narratives that make it appear more economically central than it really is. Read alongside sector and system analysis, it can also expose a harder disconnect: a system may have real utility, real usage, and even real value capture while the token remains weakly fitted to that economic core.

But in other cases, it clarifies genuine importance. It shows that token ownership gates a productive role, a meaningful governance surface, a credible claim on value, or a form of asset title that actually matters. Those distinctions are easy to blur in casual crypto language. They become much clearer once the analysis asks a narrower question. What does ownership actually confer?

That is the contribution of the Token Functionality Framework in Fundamentals. It separates functionality from mechanism. It requires ownership to be genuinely necessary. It distinguishes endogenous from exogenous functionalities. It captures differences in kind through subtypes and, where needed, differences in degree through strength. And it makes it easier to see when tokens that look similar at first glance are economically different in practice.

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

Used properly, this is not a vocabulary for flattering tokens. It is a discipline for separating real token fit from decorative token design. It stops mechanisms, incentives, and vague ‘utility’ claims from doing analytical work they cannot support.